WordPress Security Without a Sysadmin

Most WordPress compromises come through a vulnerability in a plugin or theme, not through someone guessing a password. That single fact should reorder how a small site spends its security effort, and it usually does not — because password advice is easier to give and easier to follow.

Brute force attempts are constant, automated, and mostly ineffective against any reasonable password. Outdated plugins are the actual door.

---

How small sites actually get compromised

Four routes, in rough order of how often they succeed:

1. A known vulnerability in an outdated plugin or theme. Vulnerabilities are published — that is the point of responsible disclosure — and automated scanners work through the published list against every WordPress site they can find. The window between disclosure and exploitation is short, which is why "I'll update next month" is the actual risk.

2. Abandoned plugins that will never be patched. A plugin whose author stopped maintaining it does not stop being installed. When a vulnerability is found, no fix arrives.

3. Credential reuse. Not guessing your password — using one leaked from somewhere else where you used the same one.

4. Brute force. Constant, automated, and the least likely of the four to succeed against a strong password with rate limiting.

Notice where the effort usually goes. Most security advice covers item 3 and item 4 thoroughly, and items 1 and 2 in a sentence about keeping things updated.

---

Updates: the boring fix that prevents most of it

Updating plugins is the single highest-value security action available, and it is the one most often deferred because it carries a small risk of breaking something.

That trade-off is real, and it is not close:

• The risk of updating is a site that breaks visibly and is fixed in an hour, with a backup as insurance
• The risk of not updating is a compromise found weeks later, after the damage

A workable policy:

• Security releases: immediately. Core minor releases are safe by design, and WordPress applies them automatically unless you disabled it
• Plugin updates: weekly, deliberately, one at a time on any site that matters
• Major core versions: after a fortnight, on staging first
• Anything with a published vulnerability: now, ahead of any schedule

Before updating, take a backup. Most backup plugins can trigger on update. Backups you can actually restore.

---

Logins: what actually helps

In order of effect:

1. Two-factor authentication on every administrator account. This defeats credential reuse and brute force at once, and it is the one login change worth the friction.

2. Unique passwords, from a password manager. Not complex — unique. A password used nowhere else cannot be leaked from anywhere else.

3. Rate limiting. Blocking an IP after a handful of failed attempts stops automated attacks cheaply.

4. No account named admin. Removes the free half of a guess.

5. Least privilege. Contributors do not need administrator. Most sites have more administrators than they need, and every one is a route in.

The full login setup.

What matters less than its popularity suggests: moving the login URL. It stops unsophisticated scanners and does nothing against anything targeted, and it locks people out regularly. Do it if you like; do not count it as security.

---

Backups you have actually tested

A backup you have never restored is a hypothesis.

The requirements:

• Files and database, both. Neither alone restores a site
• Stored off the server. A backup on the compromised machine is compromised too
• Automatic, on a schedule matching how often you publish
• Retained long enough to predate a problem you did not notice for weeks
• Restored once, deliberately, before you need to

That last point is where most backup strategies fail. What most people get wrong.

---

Hardening that is worth the effort

A short list. Most hardening guides are longer than they need to be and the marginal items produce more support problems than protection.

Worth doing:

• Disable file editing. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. Stops an attacker with admin access editing PHP through the browser, which is a common escalation step
• Correct file permissions — directories 755, files 644, wp-config.php 600 or 640
• Move wp-config.php above the web root, if your host structure allows
• Keep PHP current. Old PHP versions stop receiving security fixes
• HTTPS everywhere, which is free and no longer optional
• Remove what you do not use. Every inactive plugin and unused theme is code on your server that can be exploited

Not worth the trouble for most sites: hiding the WordPress version, disabling XML-RPC blindly (some apps and services need it), and elaborate .htaccess rules that break on the next host migration.

---

What security plugins do and do not cover

They are useful, and they are not a substitute for updating.

What they genuinely provide:

• Rate limiting and IP blocking
• File integrity monitoring — alerting when core files change
• Malware scanning against known signatures
• A firewall filtering common attack patterns
• Alerts when an installed plugin has a published vulnerability

What they do not do:

• Patch vulnerabilities. A firewall may block a known exploit pattern; the hole stays until you update
• Detect a well-hidden backdoor. Signature scanning finds known malware, not novel code
• Prevent credential reuse
• Replace backups

One plugin, not two. Two security plugins conflict, duplicate scanning load, and produce contradictory alerts. Why duplicates cause problems.

---

The signs you have been compromised

Most compromises are not defacements. They are quiet, because quiet lasts longer.

What to look for:

• Unfamiliar administrator accounts in Users → All Users
• Files modified at times you were not working, particularly in wp-content/uploads, where PHP files should never exist
• Unexplained outbound email, or your host reporting spam from your account
• New scheduled tasks you did not create
• Redirects that only affect visitors arriving from search, not direct visits
• Google Search Console security notifications
• Sudden unexplained traffic to pages you have never published
• Your domain appearing on an email blocklist

That last one is worth expanding, because it is the connection nobody makes.

The consequence WordPress security guides never mention

A compromised WordPress site is frequently used to send spam, because a working web server with mail capability is exactly what a spammer wants.

The sequence: your site is compromised, it sends spam for days or weeks, recipients complain, your domain lands on a blocklist like Spamhaus — and then your order confirmations, password resets and customer email stop being delivered.

Cleaning the site does not clear the blocklist. Delisting is a separate process, and a repeat listing for the same cause takes substantially longer to clear than a first one. Reputation damage outlives the compromise by weeks.

Two practical consequences:

• Check your blocklist status as part of hack triage, not weeks later when customers complain. Check it — or with the blocklist checker tool
• Fix the compromise before requesting delisting. Operators check, and a delisting granted while the site is still sending is followed by a faster relisting

---

If you are already compromised

Do not start deleting things. Triage has an order, and the most common mistake is restoring from backup immediately — which reverts the symptoms and reinstalls the vulnerability that let them in.

The full triage plan.

---

A monthly routine

Thirty minutes, monthly, prevents most of this.

• Update plugins, themes and core — deliberately, with a backup taken first
• Check for plugins not updated in over a year, and replace them
• Review user accounts. Remove people who have left, downgrade anyone who does not need administrator
• Confirm backups are running and check the most recent one exists where you expect
• Read your security plugin's log rather than only its alerts
• Check Search Console for security notifications

Quarterly, add:

• Restore a backup to staging, to confirm the backup is real
• Audit plugins properly — what is installed, what is used, what is maintained. The audit

---

Frequently asked questions

Do I need a security plugin?
One is useful for rate limiting, file integrity monitoring and vulnerability alerts. It is not a substitute for updating, because a firewall may block a known exploit while the vulnerability remains. Run one, not two — duplicates conflict and produce contradictory alerts.

How often should I update plugins?
Weekly, deliberately, one at a time on any site that matters, with a backup taken first. Anything with a published vulnerability should be updated immediately rather than waiting for the schedule, since the window between disclosure and automated exploitation is short.

Is WordPress less secure than other platforms?
WordPress core is well maintained. What creates exposure is the plugin ecosystem — tens of thousands of plugins of varying quality, many abandoned. The platform is not the weakness; unmaintained third-party code is.

How do I know if I have been hacked?
Look for administrator accounts you do not recognise, PHP files in the uploads folder, files modified when you were not working, unexplained outbound email, scheduled tasks you did not create, and redirects affecting only visitors from search. Search Console security notifications and a blocklist listing are both late signals.

Should I change my login URL?
It stops unsophisticated scanners and does nothing against a targeted attack, and it locks people out regularly. Do it if you want, but two-factor authentication and keeping plugins updated matter far more.

Can a hack affect my email deliverability?
Yes, and it commonly does. Compromised sites are often used to send spam, which puts the domain on blocklists — after which your order confirmations and password resets stop arriving. Cleaning the site does not clear the listing; delisting is a separate process, and the reputation damage outlasts the compromise.