A WordPress site is secured before the incident, never during it. The distance between an alert closed in twenty minutes and three days offline is decided months earlier — by the plugins installed, the accounts left open, and whether anyone has ever actually restored the backup.
The installations handed over in a hurry look alike: thirty or so plugins, half no longer used; several administrator accounts, some belonging to contractors who finished years ago; a daily backup nobody has tested. That is not negligence: it is what happens when a site is looked after in reaction rather than on a schedule.
What follows are the WordPress security best practices that genuinely reduce risk, and the ones that mainly produce a feeling of safety. If the damage is already done, the sequence is different: that is the procedure for a site that has already been hacked.
The risk almost never comes from WordPress core
WordPress runs 40.3% of all websites and 58.8% of those with an identified CMS, according to W3Techs figures dated 11 September 2026 (an automated survey of the top ten million sites). That share explains the volume of attacks, not their cause.
Patchstack's State of WordPress Security report, published on 25 February 2026, counts 11,334 new vulnerabilities across the WordPress ecosystem during 2025, 42% more than in 2024. The breakdown leaves little room for interpretation: 91% affect plugins, 9% themes, and only six concern core itself, all rated low priority. Your attack surface is what you added.
Two further figures matter: 46% of the vulnerabilities had no patch available when they were publicly disclosed, and 29% of reports concern premium or freemium components. Paying for a plugin guarantees nothing.
Updates: what should be automatic, and what should not
The current branch is WordPress 7.1, released on 19 August 2026 per the official release archive. Since WordPress 5.6, new installations receive both minor and major core updates automatically; older ones receive only minor releases and translations by default, as the official documentation explains. Plugins and themes update automatically only in exceptional cases decided through the WordPress.org API.
A workable rule: automatic for minor core releases and low-regression plugins — security, technical SEO, backups. Manual, after a test on staging, for anything touching display or money: page builder, theme, e-commerce module, payment gateway. Then a twenty-minute weekly slot for the rest. A site updated when someone happens to remember is a site that is not updated.
Reducing the surface: choosing and pruning plugins
Every plugin is third-party code executed with your site's privileges. Four things are worth checking before installing one: the date of the last update, the number of active installations, how the developer answers on the support forum, and the compatibility declared with the current release. A plugin with no update for twelve months is a liability, whatever its star rating.
Pruning matters as much as choosing. A deactivated plugin is still on disk and can still be exploited: deactivating is not uninstalling. An annual review is enough to remove what is no longer used and replace what is no longer maintained. On sites taken over from someone else, that operation usually lowers risk more than any tool added afterwards.
Accounts, roles and authentication
Least privilege applies literally here. An author does not need the Administrator role, and neither does a contractor brought in for one project. Keep administrators to a list you can recite from memory, and delete contractor accounts at the end of an engagement rather than disabling them.
Be strict about it: a compromise often starts with a credential being used rather than a flaw being exploited, and no patch protects an account whose password was reused elsewhere.
Passwords and two-factor authentication
The French data protection authority's recommendation on passwords (deliberation of 21 July 2022) reasons in entropy rather than imposed composition rules, and drops mandatory periodic changes for ordinary users while keeping them for privileged accounts. That guidance is French, and cited here for its reasoning rather than as a rule binding you. In practice: a password manager, a unique secret per site, and no ritual monthly rotation that ends up on a sticky note.
Two-factor authentication remains the measure with the best ratio of effort to effect. Core does not include it, but the Two Factor plugin, maintained by the WordPress.org community (more than 100,000 active installations), covers TOTP codes from an authenticator app, backup codes and email, with a companion plugin for WebAuthn security keys. Enable it on every administrator account.
Application passwords
Since WordPress 5.6, application passwords let an external tool authenticate against the REST API without being handed the account password, as the REST API documentation describes. Each key is named and individually revocable: when a contractor leaves, you revoke that key alone.
An untested backup is not a backup
The principles are not specific to WordPress: several copies on different media, at least one disconnected or off site, and a regular check that restoring actually works. The third is the one that gets skipped.
For a WordPress site that means a backup covering the database and the files, stored somewhere other than the site's own server, with enough retention to cover a compromise found late. Thirty days is a reasonable minimum: a backdoor installed six days ago sits in every backup from the past six days. Once a quarter, restore for real on a test environment with a clock running — the only way to know your recovery time before you need it.
Hosting, PHP version and logging
WordPress 7.1 runs on PHP 7.4 and above, but that is a compatibility floor, not a target. According to the official PHP support schedule, PHP 8.2 receives security fixes only until 31 December 2026, PHP 8.3 until the end of 2027 and PHP 8.4 until the end of 2028. An end-of-life branch accumulates flaws nobody will fix. Check your version under Tools, then Site Health. A current branch usually helps page generation time too — a separate subject, covered in our notes on website speed.
On hosting, the criteria that matter are unglamorous: isolation between sites on the same platform, SSH or SFTP rather than plain FTP, a self-renewing TLS certificate, one-click staging, and log retention. Access logs, administrator logins, file changes — without them, investigating an incident is guesswork. Thirty to ninety days is usually enough. These things are settled when you choose the platform, at the point of building the site.
The application firewall: useful, in its place
A web application firewall, installed as a plugin or placed upstream at DNS level, filters requests before they reach PHP. Its value follows from the figure quoted earlier: with 46% of disclosures lacking a patch, there are windows during which you cannot update. Virtual patching rules block known exploitation while you wait for the developer.
It replaces nothing else. On an installation with twelve abandoned plugins and four orphaned administrator accounts, a firewall only moves the problem out of sight.
What is (almost) useless
Some recipes survive mainly because they are easy to apply. Hiding the WordPress version number: a scanner infers it from the loaded assets in seconds. Deleting readme.html: the same. Renaming wp-content: breaks plugins regularly, for no measurable gain.
The case of wp-login.php is more nuanced. Moving the login page cuts bot noise in your logs, a real convenience, but it protects against no plugin vulnerability and sometimes breaks integrations expecting the standard URL. The official hardening documentation puts it well: security through obscurity is a weak primary strategy. It complements the rest; it never replaces it.
One quiet measure does earn its place. A single line in wp-config.php removes the dashboard file editor, and with it the handiest tool available to an attacker holding an administrator account:
define( 'DISALLOW_FILE_EDIT', true );A routine that fits in a calendar
| Frequency | Action | Signal that should worry you |
|---|---|---|
| Weekly | Apply the updates that are not automated; skim the administrator login log | An admin login outside working hours or from an unexpected country |
| Monthly | Review accounts and roles; revoke unused application passwords | An administrator account nobody claims |
| Quarterly | Restore a backup for real on a test environment | A restore that takes longer than the target you set yourself |
| Annually | Prune plugins; check the PHP version and what the host actually commits to | A plugin with no update for more than twelve months |
Those four lines cost less than an hour a month, little next to the time a clean-up demands. They are also where technical debt shows: if the inventory turns up an abandoned theme, an obsolete page builder and PHP 7.4, the subject is no longer security alone but a WordPress redesign to plan before you are forced into one.
Common questions
Should I switch on automatic updates for plugins?
Yes for plugins with a low risk of visual or functional regression: security, backup or technical SEO tools. For a page builder, a theme or a payment module, test on staging first. Either way, keep a weekly slot for what was not automated.
How many plugins can I install without taking a risk?
There is no numeric threshold. What counts is how well each plugin is maintained, not the raw count. Patchstack attributes 91% of 2025 ecosystem vulnerabilities to plugins, which is reason enough to remove anything no longer in use — and a deactivated plugin still needs uninstalling.
Does WordPress include two-factor authentication?
No, core offers no second factor natively. You need a plugin — Two Factor, maintained by the WordPress.org community, handles TOTP codes, backup codes and email. Enabling it on administrator accounts is one of the most effective measures for the effort involved.
Does a web application firewall replace updates?
No. Its main use is covering the period during which a vulnerability is known but not yet fixed by the developer, through virtual patching rules. It does not remove the need to patch, prune plugins or secure accounts.
Does moving wp-login.php improve security?
Marginally. It reduces bot noise in the logs, but protects against no plugin or theme vulnerability, and can break integrations expecting the standard URL. It should never be treated as a primary protection.
How often should backups be tested?
A full restore test once a quarter is a reasonable rhythm. The aim is twofold: confirm the archive is usable, and measure the real time it takes to get back online. Keep at least thirty days of history, since a compromise is often found days after it began.