How to Secure a WordPress Site Before It Gets Hacked

Most guides on how to secure a WordPress site give you the same ten-item checklist in the same order: strong passwords, then updates, then a security plugin. The order is wrong. In 2025, 11,334 new vulnerabilities were disclosed across the WordPress ecosystem and 91% of them were in plugins; 6 were in core (Patchstack, 2026). The sites I get called in to clean were not brute-forced through a weak password. They were opened through a plugin nobody had updated, or an account nobody remembered creating. This is the checklist in the order the breaches actually happen.

Is WordPress secure?

Yes, and the number that proves it is the one people find hardest to believe. Of the 11,334 new WordPress vulnerabilities disclosed in 2025, 91% were found in plugins, 9% in themes, and 6 in WordPress core itself (Patchstack, State of WordPress Security in 2026). Core is maintained by a security team, ships automatic updates for security releases, and has done since version 3.7. The software that runs 41.2% of all websites (W3Techs, 2026) is, on the evidence, one of the harder targets on the web.

What is not secure is a WordPress site with 38 plugins, four of which have not been updated since 2023, two administrator accounts belonging to people who left, and a hosting login shared over email. That is the typical site I inherit, and none of its problems are WordPress problems. They are ownership problems, and they are all fixable in an afternoon.

What actually gets WordPress sites hacked?

Three things, and the security-plugin marketing will not tell you the order, because the order makes the plugin the third priority rather than the first.

Plugins that were never updated, or could not be. The 91% figure is only half of it. Patchstack also found that 46% of the vulnerabilities disclosed in 2025 had no fix from the developer at the time they went public, and that for heavily exploited flaws the median time from disclosure to mass exploitation was 5 hours (Patchstack, 2026). Read those two numbers together: nearly half the time there is no update to install, and when there is one, you have hours, not weeks. The only defence that works at that speed is not having the plugin in the first place.

Software left out of date. In its analysis of hacked sites, Sucuri found 39.1% were running an out-of-date CMS at the point of infection (Sucuri, 2023 Hacked Website Report). Not exotic. Just old.

Access that should have been revoked. Broken access control, the category covering user permissions and authorization, was the most exploited vulnerability class of 2025 (Patchstack, 2026). That is the technical version. The human version is the ex-contractor whose administrator account still works, and the application password an old plugin created in 2022 that nobody has looked at since.

What lets attackers in	2025 share of disclosed vulnerabilities	Step that closes it
Plugins never updated, or with no patch available	91% of 11,334 in plugins; 46% unpatched at disclosure (Patchstack, 2026)	Step 1, then Step 5
Software left out of date	39.1% of hacked sites ran an outdated CMS (Sucuri, 2023)	Step 5, with Step 6 as the safety net
Access that should have been revoked	Broken access control was the most exploited class of 2025 (Patchstack, 2026)	Step 2, then Step 3

Every step below maps to one of those three. That is the whole method for how to secure a WordPress site: passwords and firewalls are in here, but they are steps 3 and 4, where the data puts them.

Step 1: Cut the plugin surface before you protect it

If you only do one thing from this guide to secure a WordPress site, do this one. Go to Plugins, sort by “Last Updated” on each one’s WordPress.org page, and be ruthless. My rule on client sites is four questions per plugin, in order:

• Is it active and doing something you can name? If not, delete it, do not deactivate it. An inactive plugin’s files are still on the server and still exploitable if the flaw is in a file that runs on its own.
• When was it last updated? A plugin untouched for a year is a plugin whose next vulnerability will land in the 46% with no patch. Replace it or remove it.
• Could core, the theme or one existing plugin do this? Most sites carry three plugins that overlap. Each one is a separate maintainer whose response time you now depend on.
• Is it premium code with a licence you are actually renewing? Lapsed licences stop receiving updates silently. Patchstack found 76% of the vulnerabilities reported in premium components were exploitable in real attacks (Patchstack, 2026), and a premium plugin that cannot update is worse than a free one that can.

Then turn on automatic updates for every plugin that survives, at least for minor releases. The objection is always “an update might break the site,” and the answer is a staging copy and a backup you have tested, which are steps 5 and 6. Between a plugin update breaking a layout and an unpatched plugin handing over the database, the first is the problem you want.

A build that uses lean custom code instead of a plugin for each feature shrinks this surface permanently, which is one of the less-advertised reasons a custom WordPress build is cheaper to own than a template stacked with add-ons.

Step 2: Audit who, and what, can already get in

This is the step every checklist skips, and it is the one that would have prevented most of the repeat infections I have cleaned. WordPress has no screen that answers the question “who can reach this site right now?” so nobody asks it. Ask it. Four places to look:

• Users. Every account with the Administrator role is a full set of keys. Anyone who no longer needs to log in gets deleted (with their content reassigned), and anyone who only edits content gets Editor, not Administrator. The WordPress hardening handbook calls this limiting access, and it is where most of the broken-access-control damage stops (WordPress.org, Hardening WordPress).
• Application passwords. An application password is a second, long-lived password tied to one user account that outside software uses to log in through the REST API without the real password. Since WordPress 5.6 in late 2020, any user can create them that let external apps use the REST API as them (WordPress.org, 2020). They live on each user’s own profile page, so on a site with twenty users, checking them means opening twenty profiles, and nobody does. Open them. Revoke anything you cannot name and anything that has not been used in 90 days.
• Active sessions. A user who logged in from a laptop that was later lost, or from a shared computer, is still logged in. Each profile has a “Log Out Everywhere Else” button. For anyone who has not logged in for months, use it on their behalf.
• Remote management connections. MainWP, ManageWP, UpdraftCentral and similar dashboards hold standing administrator access from outside the site. If a previous agency set one up, it may still be connected.

Doing this by hand is tedious enough that I wrote a small free plugin to put all four on one screen with the stale ones flagged. It is called Application Password Audit and it is in the WordPress.org review queue as I write this; details are on my plugins page. Until it is approved, the manual route above takes about twenty minutes and is worth every one of them.

Step 3: Make the login expensive to attack

Now the part every guide on how to secure a WordPress site leads with, in its correct place. Across 2024, Wordfence blocked more than 55 billion password attacks against WordPress sites (Wordfence, 2024 Annual WordPress Security Report). Volume like that is automated and indiscriminate, which means it is also cheap to stop:

• Two-factor authentication for every Administrator and Editor. An authenticator app, not SMS. Most security plugins include it in their free tier; use whichever one you already have rather than adding another.
• Unique passwords from a password manager, including the database password in wp-config.php and the hosting account. A reused password is the one credential-stuffing lists are built for.
• Rate-limit login attempts. Five failures, then a lockout. Your host may already do this at the server level; check before installing anything.
• Block XML-RPC if nothing uses it. It is a legacy API that accepts login attempts in bulk. The Jetpack app and a few older mobile apps need it; most sites do not.

Renaming the “admin” username and hiding the login URL are the two tips you will see everywhere. Do the first if the account is literally called admin; skip the second. Obscurity is not a layer, and the hardening handbook says as much (WordPress.org, Hardening WordPress).

Step 4: Harden the install

Four changes from the official handbook that take five minutes and close whole categories of attack:

• Disable the theme and plugin file editor. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. The handbook is honest that this will not stop an attacker uploading files, but it removes the built-in code editor that a stolen admin session would use first (WordPress.org, Hardening WordPress).
• Fix file permissions. Directories 755, files 644, and wp-config.php tighter still. The handbook has the exact table; the short version is that nothing should be writable by the web server unless WordPress needs to write it.
• Serve everything over HTTPS and force the redirect. Free with any host worth using in 2026.
• Keep PHP current. Your host’s control panel sets the version. Anything past its security-support date is receiving no fixes, no matter how current WordPress is.

Step 5: Update on a schedule, on a staging copy

Given the 5-hour exploitation window, “update when I get round to it” is not a policy. Mine, on every site I maintain, is: security releases of core and plugins apply automatically; everything else is applied weekly on a staging copy, checked, then pushed live; and the site is never more than one release behind on anything. The staging copy is what makes the weekly update safe enough to actually do. I break down what that costs in what WordPress maintenance costs, and the honest answer is that the update work is most of the bill.

Step 6: Keep a backup you have actually restored

A backup you have never restored is a rumour. Daily, stored off the host (a host outage or a compromised hosting account takes local backups with it), and restored to a test site at least once a quarter so you know the process works and how long it takes. The restore drill is the part everyone skips and the part that decides whether a hack costs you an hour or a week.

Step 7: Know within hours, not months

Sucuri found a backdoor on 49.21% of the compromised sites it cleaned (Sucuri, 2023), which is another way of saying the first sign of most hacks is the second hack. Cheap early warning:

• Google Search Console, with email alerts on. It is the fastest free signal that Google has seen something you have not.
• File-change monitoring, which most security plugins include. A modified core file you did not modify is the alarm.
• A weekly look at Users and at the plugin list. New entries you did not add are the tell.
• Uptime monitoring, because a redirect hack often shows up as visitors landing somewhere else.

If any of those fires, stop reading prevention guides. The steps for containing a live infection are different and time-sensitive, and I have written them up separately in how to fix a hacked WordPress site before it comes back.

What does it cost to secure a WordPress site?

Almost nothing in software, which is why every guide on how to secure a WordPress site lists the same free tools. Two-factor, rate limiting, file monitoring and backups are all available free. What costs money is doing steps 1, 5, 6 and 7 every week without fail, and that is the real product behind every “care plan.” Mine starts at $120 a month and the rate is on the maintenance service page. The comparison worth making is with the alternative: a fixed-price cleanup after the fact runs $450 on my malware removal service, and that is the cheap outcome. The expensive one is the site that stays infected for months and gets its rankings pulled. The sites I build and look after are public in my case studies, if you want to see what “maintained” looks like from the outside.

If you would rather hand the whole list to someone, describe your site to me and I will tell you honestly which steps it needs and which it does not.

Sources

• Patchstack, State of WordPress Security in 2026, retrieved 2026-09-18.
• Sucuri, 2023 Hacked Website and Malware Threat Report, retrieved 2026-09-18.
• Wordfence, 2024 Annual WordPress Security Report, retrieved 2026-09-18.
• WordPress.org, Hardening WordPress, Advanced Administration Handbook, retrieved 2026-09-18.
• WordPress.org, WordPress 5.6 “Simone” release announcement (Application Passwords), retrieved 2026-09-18.
• W3Techs, Usage Statistics and Market Share of WordPress, retrieved 2026-09-18.

Frequently asked questions