Introduction
New website security is easy to overlook when launching a website with only a few pages, limited traffic, and a small audience:
“Why would anyone attack my website? It is too small for hackers to care about.”
Unfortunately, this is a common website security myth.
Many modern cyberattacks are automated. Bots continuously scan the internet for websites, identify technologies such as WordPress, probe common endpoints, attempt logins, and search for vulnerable configurations.
Attackers do not necessarily need to know your business or manually select your website.
Your website does not have to be popular to attract malicious traffic. It simply has to be online.
Hackers May Not Be Looking for Your Business Specifically
Cyberattacks are not always targeted at a specific business. Many are performed by automated bots capable of scanning thousands of websites.
A Typical Automated Process
Discover Websites → Identify WordPress → Probe Common Endpoints → Try Credentials → Look for Vulnerabilities → Attempt Exploitation → Move to the Next Website
The attacker may not care whether your website receives 100 or 100,000 visitors per month. The system is simply looking for websites where an opportunity exists.
For automated attacks, the vulnerability can matter more than the popularity of the website.
Bots Don’t Care How Much Traffic You Have
Automated bots can scan websites simply because they are publicly accessible. A new WordPress website has recognizable endpoints that bots can probe, such as:
Common WordPress Endpoints
Requests to these URLs do not automatically mean your website has been compromised. They may simply represent scanning or failed attack attempts.
The important point is that bots do not care whether your website receives 10 or 10,000 visitors.
Your website can attract malicious traffic long before it attracts significant human traffic.
What Does Automated WordPress Attack Activity Look Like?
Automated attacks can appear in several different forms. One of the most common is repeated login attempts.
A security log might first show:
Unknown username
followed a few minutes later by:
Known username
The source IP may then change and another set of attempts may begin. You might also see strange usernames that appear machine-generated, such as:
This kind of repetitive behavior can indicate automated scripts rather than someone manually typing usernames into the WordPress login form.
What Web-Server Logs Can Show
- IP Address
- Timestamp
- HTTP Method
- Requested URL
- HTTP Status
- User Agent
A request with a user agent identifying something such as a Python HTTP library may indicate that software, rather than a normal browser, generated the request.
Individual log entries should always be interpreted carefully. A Python user agent or unusual request alone does not prove that an attack succeeded.
What Does Automated WordPress Attack Activity Look Like?
Automated attacks often appear as repeated login attempts. Security logs may show:
- Failed login — Unknown username
- Failed login — Known username
You may also notice machine-generated usernames such as:
The attempts may continue from different IP addresses, suggesting automated scripts rather than someone manually trying to log in.
Web-server logs can provide additional clues, including the IP address, timestamp, requested URL, HTTP method, status code, and user agent.
Suspicious activity does not automatically mean a successful attack. Logs should be analyzed carefully to distinguish scanning and failed attempts from an actual compromise.
When Should You Become Concerned?
Not every failed login means your website has been compromised. However, some events require immediate attention:
Warning Signs to Watch For
- An Administrator account you did not create
- Successful logins from unfamiliar IP addresses
- Unknown posts, pages, comments, or redirects
- Plugins or themes you did not install
- Unexpected PHP files or modified website files
- Unexplained database or WordPress setting changes
- Security features being disabled
An unfamiliar Administrator account is particularly serious because Administrator users can have extensive control over WordPress.
Hundreds of failed login attempts may simply be bots. One unauthorized successful login or Administrator account can indicate a real security incident.
Why Would Anyone Want a Small Website?
Even a website with limited traffic can be valuable to attackers because the website, domain, and server are useful resources.
How a Compromised Website May Be Abused
- SEO Spam – Injecting unwanted pages, links, or content to manipulate search rankings.
- Malicious Redirects – Sending legitimate visitors to unwanted or harmful websites.
- Phishing – Hosting fake pages designed to collect information from visitors.
- Malware Distribution – Hosting or delivering malicious files and scripts.
- Persistent Access – Creating additional accounts or modifying files to maintain access.
- Server Resources – Abusing the server’s IP address, bandwidth, storage, processing power, or domain reputation.
A small audience does not necessarily mean a website has no value to an attacker.
WordPress Is Popular — and That Makes It Attractive to Automation
WordPress powers a large number of websites and has an extensive ecosystem of themes, plugins, APIs, and integrations. This popularity also makes it attractive to automated attacks.
Instead of targeting one website manually, bots can search for many WordPress sites using the same vulnerable plugin, theme, or configuration.
A Typical Automated Process
Detect WordPress → Identify Component → Test Vulnerability → If Unsuccessful, Move On → If Successful, Attempt Further Access
This is why keeping WordPress core, plugins, and themes updated is an essential part of website security.
A Security Plugin Alone Is Not Enough
A WordPress security plugin is useful, but it should not be your only line of defense. Strong website security uses multiple layers of protection, such as:
Multiple Layers of Protection
- Updated WordPress core, plugins, and themes
- Strong Administrator passwords
- Two-factor authentication (2FA)
- Limited Administrator accounts
- Secure database credentials and file permissions
- Regular backups
- Security and server monitoring
If one security layer fails, another can still help protect the website or reduce the damage.
This layered security approach is commonly known as defense in depth.
Protect Your Administrator Account
The WordPress Administrator account has extensive control over your website, so protecting it should be a priority.
Use Strong Authentication
Use a strong, unique password and enable two-factor authentication (2FA) whenever possible:
Username + Password + Authenticator Code
Even if a password is compromised, 2FA provides an additional authentication layer.
Regularly check:
WordPress Admin → Users → All Users
Make sure you recognize every Administrator account. If an unfamiliar Administrator appears, investigate immediately, as this can be a serious sign of unauthorized access.
Disable Public Registration If You Don’t Need It
If your website does not require visitors to create accounts, keep public registration disabled.
Check the Membership Setting
Go to:
WordPress Admin → Settings → General → Membership
Make sure Anyone can register is unchecked.
This removes an unnecessary registration entry point, although it cannot prevent unauthorized user creation if an attacker has already compromised the website.
If you don’t need a feature, don’t expose it unnecessarily.
Protect the WordPress Database
WordPress requires database credentials, but it should not normally connect to MySQL using the powerful root account.
Use a Dedicated Database User
Create a dedicated database user and grant it access only to the WordPress database:
WordPress → Dedicated Database User → WordPress Database
This follows the principle of least privilege, where an application receives only the permissions it actually needs.
If database credentials are ever exposed, limiting the account’s privileges can help reduce the potential impact.
Protect WordPress Authentication Keys and Salts
WordPress uses authentication keys and salts to strengthen login cookies and sessions. These values are stored in wp-config.php and should always contain strong, unique random strings.
Never Leave Default Placeholder Values
define( 'AUTH_KEY', 'put your unique phrase here' );You can generate secure values using the official WordPress generator:
WordPress Secret-Key Generator →
Keep these values private. If you suspect a security compromise, regenerating the keys and salts invalidates existing WordPress login cookies, forcing users to authenticate again.
Disable WordPress File Editing When You Don’t Need It
WordPress includes built-in theme and plugin file editors. On a production website where code is managed through Git, SSH, or SFTP, this functionality may not be necessary.
Disable the Built-in File Editor
Add the following line to wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );This prevents administrators from editing theme and plugin files directly through the WordPress dashboard, reducing an unnecessary path for modifying executable code.
Treat the Uploads Directory as Data, Not Application Code
The WordPress wp-content/uploads/ directory is primarily intended for media and downloadable files such as images, PDFs, documents, spreadsheets, and videos. It generally should not execute PHP code.
Restrict PHP Execution
If you manage your own server, consider disabling PHP execution inside the wp-content/uploads/ directory.
This creates an additional security boundary: even if a malicious PHP file reaches the uploads directory, preventing it from executing can significantly reduce the risk.
Keep Backups Outside the Production Website
Backups are essential for recovering from a security incident.
What Should You Back Up?
- WordPress database
- Uploads and media files
- Custom themes and code
- Important configuration files
Keep at least one copy outside the production server. If the server is compromised, backups stored only on that server may also be affected.
Back up regularly and make sure you know how to restore your website.
Server Logs Can Tell a Story
Web-server logs can be extremely valuable when investigating suspicious activity. Apache access logs, for example, can reveal important information about incoming requests.
What Server Logs Can Reveal
- IP addresses
- Timestamps
- Requested URLs
- HTTP methods
- Status codes
- User agents
These logs can be compared with WordPress database timestamps and security-plugin events such as user registrations and successful logins to build a clearer incident timeline.
Logs should be interpreted carefully. A suspicious request occurring near an incident provides useful evidence, but it does not necessarily prove how the website was compromised.
If Your Website Is Compromised, Don’t Just Delete the Obvious Problem
If you discover an unknown Administrator account, deleting it is important—but you should also ask:
How was this Administrator created?
A compromise may involve more than one change. After removing suspicious users or content, consider a more complete recovery process:
Preserve Logs and Backups → Change Credentials → Invalidate Sessions → Rotate Authentication Salts → Inspect Database and Files → Reinstall Suspicious Components → Update and Harden → Monitor
For a serious compromise, replacing WordPress core and reinstalling plugins from trusted sources can provide a cleaner baseline than trying to identify every potentially modified file individually.
Failed Attacks After Hardening Are Not Necessarily Bad News
After securing your website, you may still see events such as:
Failed login — Unknown username
This does not necessarily mean your security measures failed. Bots may continue using old usernames or attack methods, but the attempts are now being rejected.
Before: Bot → Attack → Unauthorized Access 🚨
After Hardening: Bot → Same Attack → Failed Authentication ✅
A public website cannot prevent every malicious request from reaching the server. The real objective is to prevent those attempts from becoming successful compromises.
Don’t Spend All Day Blocking Individual IP Addresses
Blocking suspicious IP addresses can help, but automated attacks often come from many different IPs. Blocking one address may simply be followed by attempts from another.
Focus on Stronger Security Controls
- Strong passwords and two-factor authentication (2FA)
- Login rate limiting
- Updated WordPress, plugins, and themes
- Restricted user and application privileges
- Firewall protection
- Security monitoring
IP blocking is useful as one security layer, but it should not be your entire defense strategy.
Security Should Start on Day One
Don’t wait until your website becomes popular before taking security seriously.
A new WordPress website should start with:
- Updated WordPress, plugins, and themes
- Strong passwords and two-factor authentication (2FA)
- Limited plugins and user privileges
- Secure database credentials and file permissions
- Regular off-site backups
- Security monitoring
These protections matter whether your website receives 10 visitors or 100,000 visitors.
Website security should begin on day one.
Small Website Does Not Mean Small Security Risk
A small website still has valuable resources such as a domain, server, bandwidth, software, and user accounts.
Automated bots can scan thousands of websites, making even new or low-traffic sites potential targets.
If your website is publicly accessible, assume that automated systems may eventually probe it.
You don’t need to fear launching a website—just make security part of it from day one.
Final Thoughts
A new website may have little traffic, but that does not make it invisible to automated attacks.
The goal is not to stop every malicious request—it is to ensure those attempts fail.
Keep WordPress updated, protect Administrator accounts with strong passwords and two-factor authentication (2FA), maintain backups, and monitor suspicious activity.
Website security should grow with your website—but it should begin on day one.