Nobody is targeting your site.
That's the first thing worth understanding, because it changes how you think about all of this. Small WordPress sites are almost never chosen — they're found, by automated scanners crawling the web looking for a known vulnerability in a specific plugin version. Your site gets compromised because it matched a pattern, not because someone decided to come after you.
Which is good news, mostly. Automated attacks are stopped by unglamorous, generic defences. You don't need a security team. You need about six things done properly and a monthly habit.
The short version
Where the risk actually is: Patchstack's State of WordPress Security in 2026 found 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, a 42% increase year on year — and 91% of them were in plugins. WordPress core accounted for two.
So core isn't your problem. Your plugins are.
The six things that matter, in order:
- Update fast — but understand its limits (below)
- Harden logins — 2FA and unique usernames
- Audit and reduce plugins — the actual attack surface
- Back up properly, and test a restore
- Use a security plugin or service with virtual patching
- Pick hosting that helps
How small sites actually get compromised
Four routes, roughly in order of frequency.
A vulnerable plugin. By far the biggest. A known vulnerability is disclosed, automated scanners begin probing every WordPress site on the internet for it, and unpatched sites get hit.
Weak or reused credentials. Brute-force attempts against wp-login.php are constant and automated. They mostly fail — but a weak admin password, or one reused from a site that's been breached elsewhere, doesn't need brute force at all.
An abandoned plugin or theme. No update in years means any vulnerability found in it stays unpatched forever. How to spot these.
Compromised hosting or credentials. Shared hosting where a neighbouring site is breached, or FTP credentials stolen from an infected local machine.
Not on this list: WordPress core itself. It's actively reviewed by thousands of contributors, and the vulnerability data reflects that — two core vulnerabilities in a year against thousands in plugins.
Updates: essential, and not sufficient
The standard advice is "keep everything updated," and it's correct. It's also less protective than it sounds, and the 2026 data makes that uncomfortably clear.
Patchstack found that 46% of vulnerabilities disclosed in 2025 had no developer patch available at the time of disclosure. Nearly half were made public while the affected plugin remained unfixed.
And the timing is brutal. Among heavily exploited vulnerabilities, Patchstack's data shows 20% were exploited within six hours of disclosure and 45% within 24 hours, with a weighted median time to first exploitation of five hours.
What that means practically: updating quickly is your second line of defence, not your first. If mass exploitation begins five hours after disclosure and you update weekly, you were never going to win that race by patching.
So the real strategy is reducing exposure:
Fewer plugins. Every one is a potential entry point, and this is the lever you fully control.
Auto-update the low-risk things — WordPress core minor releases and security plugins, where a delayed patch is its own risk.
Manually update the high-risk things on a schedule, tested on staging: page builders, commerce plugins, anything heavily customised.
Consider virtual patching. Services like Patchstack and Wordfence Premium apply protective rules before a vendor patch exists, which directly addresses the 46% gap. (Worth noting both companies sell this, so read their framing accordingly — but the underlying mechanism is sound.)
Logins
Brute-force attempts run continuously against every WordPress site. Five changes stop essentially all of them.
Two-factor authentication on every administrator account. The single highest-return change, because it makes a stolen or guessed password insufficient on its own.
No admin username. It's the first thing every automated attempt tries.
Strong, unique passwords via a password manager. Reuse is what turns someone else's breach into your breach.
Rate limiting on login attempts.
Least privilege. Not everyone needs an Administrator role. Editor is enough for most people who write.
Backups you've actually tested
A backup you've never restored is a hypothesis, not a backup.
What people get wrong:
Storing backups on the same server. If the server is compromised or fails, so are they. Backups need to be somewhere else.
Backing up files but not the database, or vice versa. You need both — the database holds your content, the files hold your themes, plugins, and uploads.
Never testing a restore. The first time you find out your backup is incomplete should not be during an incident.
Keeping only one. If a compromise went undetected for three weeks, a three-day-old backup contains the compromise. Keep a rolling series.
Hardening wp-config and file permissions
Some genuinely useful, low-effort hardening.
Disable file editing. In wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );
That removes the built-in theme and plugin editor from wp-admin. It's a convenience feature that lets anyone with admin access execute arbitrary code — which is exactly what an attacker who gets in wants.
Move or protect wp-config.php. It contains your database credentials. Your host should already block direct access; verify by trying to load yoursite.com/wp-config.php and confirming you get nothing useful.
Sensible file permissions. Generally 644 for files and 755 for directories. Never 777 on anything — that means writable by anyone, and hosts sometimes suggest it as a lazy fix for upload problems.
Keep PHP current. Old PHP versions stop receiving security patches, and hosts often leave sites on outdated versions until pushed.
Use unique security keys. The salts in wp-config.php should be genuinely random. WordPress provides a generator; if yours look like placeholder text, regenerate them (this logs everyone out, which is fine).
What a security plugin does and doesn't cover
What they genuinely do: monitor for known vulnerabilities in your installed plugins, provide a firewall filtering malicious requests, scan for file changes and malware, enforce login hardening, and alert you when something changes.
What they don't do: make an abandoned plugin safe, prevent a compromise through stolen credentials with 2FA disabled, protect against a genuinely novel attack, or fix a site that's already compromised.
One finding worth taking seriously: Patchstack's testing found common host and WAF setups blocked only 12% of known exploited WordPress-specific attacks. Generic firewalls aren't tuned for WordPress-specific vulnerability patterns. (Patchstack sells virtual patching, so factor that in — but it's a specific, testable claim rather than marketing vagueness.)
The practical position: a security plugin is worth having and is not a substitute for fewer plugins, current updates, 2FA, and real backups. It's a layer, not a solution.
Signs you've been hacked
Often subtle, because modern compromises try to stay hidden — infected sites are more valuable operating than defaced.
Watch for: unexplained redirects to unfamiliar sites, admin users you didn't create, posts or pages you didn't write, Google flagging your site, a sudden traffic collapse, unfamiliar files in your directories, spam links in your footer or in content, or your host suspending the account.
One pattern worth naming: SEO spam. GoDaddy's 2026 malware research reported SEO spam as a substantial share of detections — injected links and pages designed to be invisible to you and visible to Googlebot. Check site:yourdomain.com occasionally and look for pages you don't recognise.
If you suspect a compromise, don't troubleshoot it as a bug. Triage plan.
Hosting-level protections worth paying for
Genuinely valuable and often overlooked:
Automatic daily backups stored off-server, with one-click restore.
Server-level firewall and malware scanning.
Staging environments, so updates get tested before they reach live.
PHP version management without needing a support ticket.
Isolation from other accounts on shared infrastructure.
Managed WordPress hosting bundles most of this, and for a business site the cost difference against cheap shared hosting is usually smaller than one incident.
A monthly routine
Twenty minutes, once a month.
Check for updates and apply them, staging first for anything significant.
Review your user list. Any accounts you don't recognise? Anyone with Administrator who shouldn't have it?
Check plugin maintenance status. Anything not updated in over a year is a liability. The audit.
Verify a backup exists and is off-server. Actually look, don't assume.
Skim your security plugin's log for anything unusual.
Run site:yourdomain.com and check for pages you didn't create.
Once a year: restore a backup to staging and confirm it works.
Frequently asked questions
Do I need a security plugin?
It's worth having, though it isn't the main thing protecting you. A security plugin provides a WordPress-aware firewall, vulnerability monitoring, malware scanning, and login hardening. What it can't do is make an abandoned plugin safe or protect an account without 2FA. Given that 91% of WordPress vulnerabilities are in plugins and nearly half are disclosed without a patch available, the higher-return actions are running fewer plugins, enabling 2FA, and keeping real backups.
How often should I update plugins?
As quickly as you reasonably can for security releases — Patchstack's 2026 data puts the weighted median time from disclosure to mass exploitation at five hours, so weekly updating isn't fast enough to outrun exploitation. Enable auto-updates for WordPress core minor releases and security plugins. Update page builders, commerce plugins, and anything heavily customised manually, tested on staging first. And since updates alone can't cover the 46% of vulnerabilities disclosed without a patch, reducing your plugin count matters more than update frequency.
Is WordPress less secure than other platforms?
Core is not — Patchstack recorded just two core vulnerabilities in 2025 against 11,334 across the ecosystem. What differs is the plugin ecosystem: tens of thousands of extensions from independent developers with no standardised security review, where 91% of vulnerabilities originate. A WordPress site running few, well-maintained, current plugins with 2FA enabled is about as secure as any comparable platform. A site running twenty-five plugins, several abandoned, is not.
How do I know if I've been hacked?
Look for unexplained redirects, admin users you didn't create, content you didn't write, Google flagging your site, or a sudden traffic drop. SEO spam is deliberately hidden from site owners while visible to search engines, so run site:yourdomain.com occasionally and check for pages you don't recognise. If any of this appears, treat it as a security incident rather than a bug — the diagnostic steps are completely different.
What to do next
Two things today, both about fifteen minutes.
Enable two-factor authentication on every administrator account. It's the single highest-return change available, and it makes a stolen password insufficient on its own.
Then count your plugins, and check when each was last updated. Given where the vulnerabilities actually are, that number is the clearest measure of your exposure — and it's the one thing you fully control.
Free: The WordPress maintenance checklist.
Related guides
- Two-factor and login hardening — the five login changes
- My WordPress site is hacked — triage, if it's already happened
- Auditing plugins for security risk — the five warning signals
- WordPress backups — the restore you'll eventually need
- When WordPress breaks — if it's a bug rather than a breach
- WordPress plugin audit — the performance side of the same work
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]