Most WordPress sites that get hacked were never singled out. Bots scan the web for plugins with known vulnerabilities and try passwords around the clock, then break into whatever gives way. For a business website, good WordPress security is less about outwitting a determined attacker than about not being the easy target.
Those bots rely on a short list of weaknesses. This guide orders the fixes by impact, drawing on WordPress.org’s hardening guidance and the OWASP Top 10, the standard reference list of critical web application security risks.
The short answer
To secure a WordPress site, work through these in order. The first four close the most common ways in.
- Update WordPress core, plugins, themes and PHP, and delete what you don’t use.
- Protect logins with unique passwords and two-factor authentication.
- Give each person their own account with the lowest role they need.
- Install only maintained plugins from trusted sources.
- Serve everything over HTTPS with basic security headers.
- Put a web application firewall in front of the site.
- Limit login attempts, including through XML-RPC.
- Lock down files and configuration, so a breach can do less.
- Keep off-site backups you have actually restored.
How WordPress sites actually get broken into
WordPress core is well maintained, and minor security releases install automatically by default. Vulnerability databases such as WPScan, Patchstack and Wordfence show the same pattern year after year: the large majority of reported WordPress vulnerabilities are in plugins and themes, not core. The real risks sit in the layers added on top of core (see how websites are built) and in the people who log in.
| Risk, in plain terms | What it looks like on WordPress | Fixed by |
|---|---|---|
| Outdated components | A plugin with a published vulnerability nobody updated | Steps 1 and 4 |
| Weak authentication | Reused passwords, no second factor, unlimited attempts | Steps 2 and 7 |
| Broken access control | A shared admin login; a plugin bug that lets a subscriber change settings | Steps 1 and 3 |
| Injection | A form or plugin that passes unchecked input to the database | Steps 1 and 6 |
| Misconfiguration | Errors shown to visitors, missing security headers, the dashboard file editor left on | Steps 5 and 8 |
Priority 1: close the common ways in
1. Updates, applied promptly
New plugin vulnerabilities are published every week, often with a fix. Attackers read the same announcements, and popular targets can be attacked within hours, so the sites that get caught are those still running the old version weeks later.
- Leave WordPress’s automatic security updates switched on.
- Auto-update simple plugins. Test complex ones (page builders, e-commerce, memberships) on a staging copy first, then update promptly.
- If a disclosed flaw has no fix yet, deactivate or replace the plugin until a patch arrives.
- Run a PHP version that still receives security fixes. php.net publishes support dates, and Tools → Site Health flags an outdated version.
- Delete unused plugins and themes. Deactivated code still sits on the server, and some of it can still be reached.
Check it yourself. Anything waiting in Dashboard → Updates for more than a couple of weeks is a question for whoever maintains the site.
2. Strong logins and two-factor authentication
Bots try passwords leaked from other websites, so a reused password is only as safe as the weakest site it was ever used on. Use long, unique passwords from a password manager.
Two-factor authentication. At the time of writing (August 2026), WordPress core has no built-in two-factor authentication, so it comes from a plugin or security service. Require it for every account that can publish or change settings, not only administrators. An authenticator app, security key or passkey is stronger than a code sent by SMS or email. Store backup codes safely, and keep a second administrator in case someone loses their phone.
Protect the accounts around WordPress too. Hosting, domain registrar, SFTP or SSH, and above all the inbox that receives password resets: whoever controls it can reset your WordPress password. Then check the Application Passwords section of each user profile and revoke any that nobody can explain.
3. Least-privilege roles
The damage an attacker can do depends on the account they take. Our guide to WordPress best practices sets out the standard roles; for security, three rules matter most:
- Keep administrators to one or two accountable people. Administrators can install plugins, and a plugin can run any code it likes.
- Treat Editor as a trusted role. On a standard single-site install, Editors can add unfiltered HTML, including scripts.
- Remove access the day someone leaves, including former developers and suppliers, and check any extra roles that e-commerce or form plugins add.
One person, one account: shared logins make it impossible to remove one person’s access or see who changed what.
4. Trusted plugins only
Each plugin is code from a different author with broad access to your site and database. Before installing one, check:
- Source. WordPress.org, or the developer’s own site for premium plugins. Never a “nulled” (pirated) copy, a well-known way malware spreads.
- Maintenance. Recent updates and testing against current WordPress versions. The WordPress.org directory warns when a plugin hasn’t been tested with recent major releases.
- Track record. Search a vulnerability database for its name. Past issues fixed quickly and openly are a good sign.
- Licence. When a premium licence lapses, updates usually stop, security fixes included.
Priority 2: shield the site from outside
5. HTTPS and security headers
HTTPS encrypts logins and form submissions, and most hosts provide free certificates. Check that every http:// address redirects to https:// and that both addresses in Settings → General use https.
Security headers tell the browser what to allow on your pages:
| Header | What it does | Effort |
|---|---|---|
| Strict-Transport-Security | Forces HTTPS for your domain | Low; start with a short duration, as browsers remember it |
| X-Content-Type-Options | Stops browsers guessing file types | Low |
| X-Frame-Options | Stops other sites framing yours to trick clicks | Low |
| Content-Security-Policy | Controls which sources may load scripts and other content | High; page builders and analytics need allowing |
Set them at the server, firewall or with a plugin, and trial Content-Security-Policy in report-only mode first, so violations are reported rather than blocked. Mozilla’s HTTP Observatory grades the headers your site sends.
6. A web application firewall
A web application firewall (WAF) inspects requests before WordPress handles them and blocks known attack patterns, such as injection attempts and probes for vulnerable plugins. Some also apply “virtual patches” for new vulnerabilities before you have updated.
| Type | Strengths | Watch out for |
|---|---|---|
| Cloud firewall, in front of your server | Blocks traffic before it reaches your server | Can be bypassed if your server still accepts direct traffic |
| Plugin firewall, inside WordPress | Knows your users and plugins | Uses your server’s resources |
| Server firewall, run by your host | Nothing to install or maintain | Generic rules can miss plugin-specific exploits |
Managed WordPress hosting often includes a server firewall, malware scanning and isolated accounts, worth weighing when you choose web hosting. Whichever you use, a firewall buys time; it doesn’t replace updates.
7. Login rate-limiting
WordPress core doesn’t limit failed login attempts, so a bot can guess indefinitely. Limit attempts per IP address at the firewall, in a plugin or on the server.
Cover xmlrpc.php too: this older remote-publishing interface accepts usernames and passwords, so bots use it as a second door. Most integrations now use the REST API; if nothing on your site relies on XML-RPC (Jetpack, for one, still does), block it. Lockouts are a backstop; two-factor authentication is what makes a guessed password useless.
Priority 3: limit the damage
8. Files and configuration
This layer of WordPress hardening makes a break-in less useful:
- Permissions. WordPress.org’s hardening guidance is
644for files,755for folders and440or400forwp-config.phpwhere your server allows. Never777. - File editor off. Setting
DISALLOW_FILE_EDITto true inwp-config.phpremoves the dashboard’s code editors, the quickest way for a stolen admin login to plant code. It doesn’t stop plugin uploads, which is why step 2 matters. - No PHP in uploads. The uploads folder must be writable, which makes it a favourite hiding place for malicious scripts. Ask your host to block PHP from running there.
- Quiet errors. Keep
WP_DEBUGoff on the live site; error messages can reveal file paths. - No forgotten copies. Old staging sites and abandoned installs rarely get updated, and one compromised site can often reach others in the same hosting account. Delete them, and put staging behind a password.
9. Backups you have actually restored
- Files and database together. The database holds pages, settings and form entries; the files hold uploads, themes and plugins.
- Off-site, with separate credentials, so the attacker who reaches your site can’t delete the backups too.
- Daily for a site that takes enquiries or orders, with enough history to go back weeks, because infections often go unnoticed.
- Tested by restoring to a staging copy. Restoring to a new server is a migration in all but name; moving a website to a new host covers the DNS and email records that most often break.
WordPress security measures that help less than you think
- Hiding the login page cuts bot noise but doesn’t protect XML-RPC or stop anyone who finds the address.
- Changing the
wp_database prefix adds little, and is risky on a live site. - Hiding the WordPress version rarely matters: automated attacks usually just try the exploit.
- Stacking security plugins causes conflicts, slows the site and breeds false confidence. One well-configured layer per level is enough.
WordPress site hacked? The first hours
Typical signs: visitors redirected to spam sites (often only on phones or from Google, so you may not notice), a browser warning, a Search Console security message, unknown administrators, or pages in a site: search you never created.
- Contain it. If visitors are being redirected or served malware, switch on maintenance mode or ask your host to take the site offline.
- Keep a copy. Before changing anything, download the infected files and database, and ask your host for access logs: you need them to find the way in.
- Lock the doors. From a trusted device, change passwords for every administrator, hosting, SFTP or SSH, the database (updating
wp-config.phpto match) and the password-reset inbox. Delete unknown users, revoke application passwords and replace the security keys inwp-config.phpto sign everyone out. - Find the entry point. Check plugin versions against a vulnerability database and read the logs from when the first changes appeared. Skip this and the clean-up is temporary.
- Restore or clean. Restore a backup from before the compromise, update everything immediately and redo the WordPress side of step 3, because a restore brings back the old passwords, keys and database details. With no clean backup, reinstall core, plugins and themes from official sources, remove PHP files from uploads, and check the database,
.htaccessand scheduled tasks. Attackers often leave several backdoors, which is why partial clean-ups get reinfected. - Tell the right people. Request a review in Search Console if Google flagged the site. If personal data may have been accessed, take advice quickly: under Article 33 of the EU’s GDPR, for example, a notifiable breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it.
- Harden, then watch for new users, changed files and redirects over the following weeks.
If the clean-up reveals an abandoned theme or plugins that can’t be updated, cleaning only buys time: that’s one of the signs your website needs a redesign.
What to do next
This guide covers what to set up once. Keeping it working is a weekly and monthly routine of updates, backup checks and monitoring, set out in the website maintenance checklist.
If you would rather not own that routine, our website care plans cover core, theme and plugin updates, regular backups, and security and uptime monitoring, with clean-up if anything gets through. Unsure how your site measures up against the nine steps? Our free website audit includes a security check, so you know which gaps to close first.