How to Harden WordPress: 12 Steps That Actually Stop Attacks

Most WordPress sites get hacked in boring ways. Not by a genius in a hoodie, but by a script that tries ten thousand sites a night looking for an old plugin, a weak password or a folder that lets it upload a file. Hardening is the unglamorous work of closing those doors before the script arrives.

We clean hacked WordPress sites for a living, and the same handful of gaps show up every time. This guide walks through the twelve changes that would have prevented nearly all of them, in the order we’d do them on a site we’d never seen before. Where a step needs a line of code, the exact line is here.

One warning before you start: take a full backup first, and keep SFTP or hosting panel access open in another tab. A couple of these steps can lock you out if you mistype them.

011. Update everything, then decide who keeps it that way

Outdated plugins are the single most common way in. Not WordPress core, which updates itself, but that gallery plugin nobody has touched since 2022. Update core, every plugin and every theme, including inactive ones. Then look at the PHP version in your hosting panel: anything below PHP 8.1 stopped receiving security fixes, so move up.

Then the part people skip. Decide, by name, who checks for updates and how often. A site nobody owns drifts back to vulnerable within months.

022. Delete what you don’t use

Every inactive plugin and theme is code an attacker can target, even when it’s switched off. Delete them. Keep one default theme as a fallback and remove the rest. While you’re there, remove old admin users, the “test” account from the launch, and the agency login from three developers ago.

033. Fix the admin account

If your administrator username is admin, half the login attack is already done. Create a new administrator with an unguessable username, log in as it, then delete the old one and attribute its content to the new user. Use a long password from a password manager, not a word with a number on the end.

Use administrator accounts only for administering. Day-to-day writing should happen under an Editor account, so a stolen writing session can’t install plugins.

044. Turn on two-factor authentication

This is the single highest-value change on the list. With two-factor login, a leaked or guessed password is no longer enough. Wordfence, WP 2FA and Solid Security all offer it free. Make it mandatory for every administrator and editor, not optional. Optional means the one person who skips it is the way in.

055. Limit login attempts and hide nothing

Scripts try thousands of passwords against wp-login.php. Rate-limit them: after five failures, block the IP address for an hour. Most security plugins do this, and so does Cloudflare if you put the site behind it.

Changing the login URL is popular and mostly harmless, but it’s a nuisance, not a defence. Bots find login forms by other means. Do it if you like a quieter log, but don’t count it as protection.

066. Stop PHP running inside the uploads folder

When attackers do get a file onto your server, it usually lands in wp-content/uploads, because that’s the one folder the web server is allowed to write to. Nothing legitimate in that folder should ever execute as code. Create a file called .htaccess inside wp-content/uploads/ with this content (Apache and LiteSpeed hosts, which is most Indian shared hosting):

<FilesMatch "\.(php|php\d|phtml|phar)$">
    Require all denied
</FilesMatch>

On Nginx, ask your host to add the equivalent location block. This one step turns many successful uploads into harmless dead files.

077. Disable the file editor and lock down wp-config.php

WordPress ships with a code editor in the dashboard. Anyone who takes over an admin account can use it to drop a backdoor into your theme in ten seconds. Turn it off by adding this to wp-config.php, above the line that says “That’s all, stop editing”:

define( 'DISALLOW_FILE_EDIT', true );

While you’re in that file, set its permissions so only your own account can read it. wp-config.php holds your database password. Most hosts want 640; some need 600 or 440. Try the strictest one that still loads the site.

088. Set sane file permissions

A surprising number of sites run with folders at 777, meaning anyone on the server can write anywhere. The standard for WordPress is folders at 755 and files at 644. From SSH:

find /path/to/site -type d -exec chmod 755 {} \;
find /path/to/site -type f -exec chmod 644 {} \;

If you’re on shared hosting without SSH, your file manager usually has a bulk permissions option. Do the uploads folder last and check that image uploads still work afterwards.

099. Switch off XML-RPC if nothing uses it

XML-RPC is an old remote-publishing interface. The WordPress mobile app and Jetpack still use it; almost nothing else does. It’s also a favourite for password attacks, because one request can test hundreds of passwords. If you don’t use those tools, block it in your root .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Or let your security plugin do it. Check your site still works afterwards, especially if you use any publishing or backup tool that talks to WordPress from outside.

1010. Put a firewall in front of the site

A web application firewall blocks known attack patterns before they reach WordPress. You have two options, and they’re not exclusive. A plugin firewall such as Wordfence runs inside WordPress and knows about plugin vulnerabilities. A network firewall such as Cloudflare’s sits in front of your server and absorbs bad traffic before it uses your hosting resources, which matters on shared plans with tight limits. For a business site, we’d want both.

1111. Add security headers

Headers tell the browser how to behave, and the right ones stop a whole class of attacks that don’t involve your server at all. Add these to your root .htaccess or through your host’s panel:

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Only add the last one once your site is fully on HTTPS, because it tells browsers to refuse plain HTTP for a year. A Content-Security-Policy header is the strongest of all, but it breaks page builders and third-party scripts easily, so treat it as a project of its own rather than a copy-paste.

1212. Back up off the server and watch for file changes

Hardening reduces the odds; it never gets them to zero. Two things turn a hack from a disaster into an afternoon’s work. First, automatic backups stored somewhere other than the server itself, such as Google Drive or S3, kept for at least thirty days, and tested once by actually restoring one. Second, file change monitoring. Wordfence and similar tools can email you when a core or theme file changes unexpectedly, which is usually the first and only early warning you’ll get.

A detail from our own cleanups: don’t trust a file’s modification date when checking for intrusions. Attackers reset it to blend in. Monitoring tools that compare file contents against known-good copies catch what a glance at dates will miss.

13Things people do that don’t help much

• Hiding the WordPress version. Attack scripts don’t check it; they just try the exploit.
• Renaming the wp-content folder. Breaks plugins, stops nothing serious.
• Installing three security plugins. They fight each other and slow the site. Pick one, configure it properly.
• Buying an SSL certificate and calling the site secure. HTTPS protects data in transit. It does nothing about a vulnerable plugin.

14If you’re on shared hosting with several sites

One infected site on a hosting account can reinfect every other site on it, because they share the same file system user. Harden all of them or none of them, and if one does get compromised, assume the others are suspect until checked. We will cover that scenario in detail in a follow-up post on why malware keeps coming back on WordPress.

15Do this in an afternoon

If you only have a couple of hours, do steps 1 to 7 today. They stop the overwhelming majority of real attacks, and none of them needs a developer. Steps 8 to 12 can follow over the next week. If something already looks wrong, check our list of signs your WordPress site has been hacked before you harden, because hardening a site that’s already compromised just locks the attacker in with you.

Prefer to hand it over? Our WordPress security hardening service does all twelve steps, documents what was changed, and sets up the monitoring, as part of our WordPress development work. Tell us about your site using the form below and we’ll reply within 24 business hours.