10 WordPress Security Best Practices, Ranked by What Actually Stops Attacks
WordPress core had six vulnerabilities in 2025. Plugins had 91 percent of 11,334. Here are ten practices in the order we would apply them, ranked by risk removed per hour spent.
Almost everything written about WordPress security tells you to harden WordPress. The data says WordPress is not where you are being attacked.
Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42 percent rise on the previous year. Of those, 91 percent were in plugins and 9 percent in themes. WordPress core accounted for six — all rated low priority.
Your risk is not WordPress. It is the twenty-three plugins sitting on top of it. Every security decision below follows from that one number.
These are ten practices in the order we would apply them to a site we had just inherited, ranked by how much risk each removes for the effort it takes. Do them in this order. If you stop after four, you will still have closed most of the door.
1. Update plugins within days, not months
This is not the boring advice it sounds like. The overwhelming majority of compromised WordPress sites are running a plugin with a patch already available. The vulnerability was disclosed, the fix shipped, and nobody applied it.
Attackers monitor disclosure feeds. When a vulnerability is published for a plugin with a large install base, mass scanning begins within hours. The gap between disclosure and your update is the entire window you are exposed in.
Turn on auto-updates for plugins you trust, and check the rest weekly. If a site is important enough to make you money, it is important enough for a scheduled fifteen minutes.
2. Delete every plugin and theme you are not using
A deactivated plugin is still on disk. Several classes of vulnerability are exploitable without the plugin being active, because the file is still reachable over HTTP.
Most sites we audit carry between five and fifteen plugins nobody has used in a year, plus three unused themes. Deleting them removes that attack surface permanently and takes about ten minutes. It is the highest ratio of risk removed to effort spent on this entire list.
3. Check a plugin before you install it, not after
Every plugin is a dependency you are trusting with database access. Before installing, look at four things: when it was last updated, how many active installs it has, whether the developer responds in the support forum, and whether it has a disclosed vulnerability history.
An abandoned plugin with 40,000 installs and no update in two years is a liability regardless of how well it works today. Nobody is going to patch it when the disclosure lands.
Patchstack also found that 76 percent of vulnerabilities discovered in premium components were exploitable. Paying for a plugin buys you support, not safety.
4. Put two-factor authentication on every administrator account
Credential stuffing does not care how strong your password is if it appeared in a breach somewhere else. Two-factor stops the entire category.
Apply it to every account with administrator or editor rights, without exception. The one account you skip is the one that gets used.
5. Stop sharing logins, and give people the role they need
The developer who built your site three years ago probably still has an administrator account. So does the agency you stopped working with, and the freelancer who fixed one thing in March.
Audit your user list today. Delete accounts nobody uses. For the rest, drop them to the lowest role that lets them do their job — most people writing content need Author, not Administrator. A compromised Author account is an inconvenience. A compromised Administrator account is a rebuild.
6. Get backups you have actually restored from
Almost everyone has backups. Far fewer have ever tested one. A backup you have not restored is a hypothesis.
Three things make a backup real: it runs automatically, it is stored somewhere other than the server it is backing up, and you have restored it to a staging site at least once. If your backups live on the same hosting account as your site, ransomware or a server failure takes both.
Keep enough history to survive a compromise you do not notice immediately. Seven days is not enough — malware often sits quietly for weeks. Thirty days is a reasonable floor.
7. Choose hosting that patches below your application
Patchstack found that hosting-level defences blocked only a fraction of the exploits they tested. That is a reason to check what your host actually does rather than assume it is handled.
Ask directly: do they run a web application firewall, how quickly do they patch PHP and server software, do they isolate accounts so one compromised site on a shared server cannot reach yours, and do they keep their own backups independent of yours. Cheap shared hosting frequently fails the isolation question, which means your security depends on strangers.
8. Lock down the login page
Your login page is the most attacked URL on the site. It receives automated attempts continuously, from the day it goes live.
- Rate-limit login attempts so brute force becomes impractical
- Disable XML-RPC unless something you use genuinely needs it — it is a common brute-force amplifier
- Do not use the username admin, and make sure your display name is not your username
- Consider restricting wp-admin by IP if your team works from fixed locations
None of these are clever. All of them remove volume, and volume is how these attacks succeed.
9. Force HTTPS everywhere and set your security headers
HTTPS is a given now, but it is worth checking that it is actually enforced rather than merely available — every HTTP request should 301 to HTTPS, including subdomains.
Beyond the certificate, a small set of response headers costs nothing and closes real attack classes: HSTS to stop protocol downgrade, X-Content-Type-Options to stop MIME sniffing, X-Frame-Options to stop clickjacking, and a sensible Referrer-Policy. These are a few lines of server configuration.
10. Watch for compromise, because prevention eventually fails
Assume something will get through and make sure you find out quickly. The damage from a compromise is largely a function of how long it goes unnoticed.
File integrity monitoring will tell you when a core file changes unexpectedly. Search Console will email you if Google flags the site. Uptime monitoring catches the crude cases. Set all three up once and forget about them until they speak.
The Ones People Argue About
Two pieces of common advice we deliberately left out.
Hiding the login URL is security through obscurity. It stops unsophisticated bots and inconveniences your team, and it does nothing against anything targeted. Rate limiting achieves more.
Renaming database table prefixes on an existing site carries real breakage risk and defends against a narrow, largely historical attack. On a new install, fine. On a live store, not worth it.
If you want the full treatment — twenty practices including hardening file permissions, database security, and the e-commerce-specific work for WooCommerce stores handling payment data — we have written it up separately.
Frequently Asked Questions
Is WordPress less secure than other platforms?
No. WordPress core had six vulnerabilities in 2025, all low priority. The ecosystem around it is where the risk lives, and that is a consequence of WordPress being extensible and enormously popular rather than a flaw in the software.
Do I need a security plugin?
One is useful for rate limiting, file integrity monitoring and firewall rules. More than one is counterproductive — they conflict, they slow the site down, and each is itself another plugin to keep patched.
How often should I actually update?
Weekly as a routine, immediately for anything flagged as a security release. Enable auto-updates for plugins whose updates you trust not to break your layout.
My site was hacked. What now?
Take it offline or into maintenance mode, change every password including hosting and database, restore from a backup predating the compromise, and only then work out how they got in. Restoring without finding the entry point means being compromised again within days.
Does managed WordPress hosting mean I can skip all this?
It covers items 7 and part of 1. Everything else — plugin hygiene, user roles, two-factor, tested backups — is still yours. Managed hosting reduces the work; it does not remove it.
Not sure where your site stands? We will audit it against this list — plugin inventory, user roles, backup status and exposure — and send you the findings. No cost, and no pitch if everything checks out.
Why trust our experts?
At ARIOSETECH, every article is written by specialists who build and operate real e-commerce stores — not generalists. Our content is grounded in hands-on experience across WordPress, WooCommerce and Shopify, and reflects what actually works for stores in live markets. We keep it practical, current, and honest so you always get reliable, actionable guidance.
