Hardening WordPress is often presented as a long checklist of obscure settings: rename the database prefix, hide the version number, move the login page. Some of those have a small effect. Most miss the point, because they defend against attacks that rarely happen while leaving the common ones wide open.
Almost every compromised WordPress site we have been asked to clean was breached in one of a few ordinary ways: a plugin that had not been updated, a password that had leaked elsewhere, an administrator account nobody remembered, or hosting that let one infected site spread to others. This guide covers eight defences in order of how much real risk they remove.
What hardening WordPress is actually defending against
The attacks against WordPress sites are mostly automated. Tools scan huge numbers of sites looking for known weaknesses: a specific plugin version with a published vulnerability, a login page that accepts unlimited password guesses, a backup file left in a public folder. They do not care what your business does. They are looking for any site that matches.
That is good news, because automated attacks are predictable. The official WordPress hardening guide and the broader OWASP Top 10 both point at the same categories: outdated components, broken authentication and misconfiguration. Close those doors and most automated tools move on to an easier target.
The WordPress project itself takes security seriously; its security page explains how core vulnerabilities are handled and released. The weak points are almost always in what is added around the core.
Defence 1: Update everything, on a schedule
Outdated plugins are the most common way in. When a vulnerability in a popular plugin is published, automated scanning for it often begins soon after. A site that updates within days is rarely affected; a site that updates every few months is exposed for weeks.
Turn on automatic updates for minor WordPress core releases, which are mostly security fixes. For plugins and themes, choose a fixed routine, weekly or fortnightly, and stick to it. On business-critical sites and shops, test updates on a staging copy first, then apply them to the live site. The WordPress upgrade documentation covers the process.
Delete plugins and themes you are not using, rather than only deactivating them. Deactivated code still sits on the server, and some vulnerabilities can be reached even when a plugin is inactive. Every component you remove is one less thing to keep updated.
Defence 2: Strong, unique passwords and two-step login
The second most common way in is simply logging in. Passwords reused from other services appear in leaked lists, and automated tools try those lists against WordPress login pages constantly. A strong password that is used nowhere else defeats this completely.
Add two-step authentication for every account that can publish or change settings. With it, a stolen password on its own is not enough to log in. WordPress documents the options in its two-step authentication guide, and several well-maintained plugins provide it.
Limit login attempts as well, either through your host or a plugin, so that password guessing slows to a crawl. Combined with two-step login, this makes the login page one of the least attractive targets on the site.
Defence 3: Fewer administrators, fewer permissions
Many sites have accumulated administrator accounts over the years: a former developer, an agency that finished its project, an employee who left, a temporary account for a plugin support request. Each one is a door, and nobody is watching it.
Review the user list and remove every account that is no longer needed. Give remaining users the lowest role that lets them do their work. Someone who writes blog posts needs an Author or Editor role, not Administrator. Use a named account for each person so that activity can be traced, instead of a shared login.
When a developer or agency needs access, create a temporary account for them and remove it when the work is finished. That single habit closes one of the most common gaps we see.
Defence 4: Hosting that isolates and protects
Hosting quality affects security as much as speed. On poorly configured shared hosting, one compromised site can sometimes reach others on the same account or server. Good hosting isolates each site, keeps server software patched, runs a current PHP version and often includes a firewall that blocks known attack patterns before they reach WordPress.
If you host several sites on one account, understand that a weakness in the least maintained of them can put the others at risk. Old test sites and forgotten installations are a frequent source of infection. Delete what you no longer need, and keep what remains updated.
Use secure connections everywhere: HTTPS for the site, and SFTP or SSH rather than plain FTP for file access. Most reputable hosts now make both the default.
Defence 5: Backups you have actually restored
Backups are not strictly prevention, but they decide how bad a successful attack becomes. With a clean, recent backup, a compromised site is an inconvenience. Without one, it can mean rebuilding from nothing.
Keep automatic backups of both files and database, stored away from the server itself so an attacker who controls the server cannot delete them. Keep several days or weeks of history, because an infection is sometimes discovered long after it began. The WordPress backup guide explains what to include.
Most importantly, test a restore. A backup that has never been restored is an assumption, not a plan. Restore to a staging site once and confirm everything works, so you know the process before you need it under pressure.
Defence 6: File and configuration settings that matter
A few configuration changes are genuinely worth making. Disable the built-in file editor in the WordPress dashboard, so an attacker who gets into an administrator account cannot edit theme and plugin code from the browser. Make sure file permissions follow the host's recommendations, so the web server cannot write to files it has no reason to change.
Protect the configuration file that holds your database credentials, and make sure backup files, logs and exports are not left in publicly reachable folders. Automated tools look specifically for files with names like backup archives and database dumps.
Settings such as hiding the WordPress version or renaming the login page have some value in reducing noise, but they are not a substitute for the defences above. Treat them as optional extras, not the core of hardening WordPress.
Defence 7: A firewall and monitoring
A web application firewall filters requests before they reach WordPress, blocking known attack patterns and known bad sources. It can be provided by the host, by a service in front of the site, or by a security plugin. Any of these adds a useful layer, especially for sites that cannot be updated immediately.
Monitoring tells you when something changes. File change alerts, uptime checks and notifications when a new administrator is created all help you notice a problem in hours instead of weeks. Search Console also warns site owners when Google detects hacked content or malware, so make sure it is set up and that its emails reach someone who reads them.
Defence 8: A plan for when something goes wrong
No defence is perfect, so decide in advance what you will do if the site is compromised. Write down who has access to the hosting account, where backups are kept, how to put the site into maintenance mode and who to call. Keep that note somewhere other than the website.
If an incident happens, act in order: take the site offline, change every password including hosting, database and email accounts, restore from a clean backup or have the site professionally cleaned, then find and close the weakness that let the attacker in. Restoring without closing the gap usually leads to the same infection returning.
Afterwards, request a review in Search Console if Google flagged the site, and check that no unexpected users, scheduled tasks or files remain.
The accounts around the site
A WordPress site is only as secure as the accounts that control it. The hosting account, the domain registrar, the email inbox that receives password resets and any DNS or CDN service can each be used to take over the site without touching WordPress at all. An attacker who controls the email address of the main administrator can simply reset the password.
Protect each of those accounts with a strong, unique password and two-step login. Make sure the business, not a former employee or freelancer, owns the domain and hosting accounts, and that renewal notices go to an inbox someone checks. An expired domain or hosting plan can take a site offline as effectively as any attack.
Hardening WordPress for shops and member sites
Sites that take payments or store customer accounts need extra care. Keep payment handling with a reputable payment provider, so card details never pass through or sit on your own server. Update the shop plugin and its extensions promptly, because they handle sensitive data and are attractive targets.
Review who can see orders and customer information, and give shop managers only the access they need. Keep an eye on new customer accounts created in unusual numbers, which can signal automated abuse. Make sure the checkout and account pages are always served over HTTPS and excluded from caching. For these sites, testing updates on a staging copy before applying them live is not optional; a broken checkout costs money every hour it stays broken.
A realistic routine for hardening WordPress
Most of this work is set up once and then maintained with a short routine. Weekly or fortnightly: apply updates, check that backups ran, glance at the user list. Monthly: remove unused plugins and themes, review firewall and monitoring alerts, test that the contact form and checkout still work after updates. Once or twice a year: restore a backup to staging, and review who has access to hosting, domain and email accounts.
That routine takes little time, and it prevents the great majority of incidents. The expensive cases we see are almost always sites where nobody owned the routine.
Keep a written list of every plugin, theme and external service the site relies on, with who is responsible for each. When a vulnerability is announced, that list tells you within minutes whether your site is affected, instead of forcing someone to log in and check under pressure. It also makes handing the site to a new developer much safer, because nothing important depends on one person's memory.
When to hand it over
If nobody on your team has time to own updates, backups and monitoring, it is worth paying someone who will. A maintained site costs less over a few years than a single serious clean-up, especially for a shop where downtime means lost orders.
We build and maintain WordPress sites with this routine built in; our WordPress development service explains what is included. You can see everything else we offer on the services page, or get in touch if your site needs attention now.