Securing a WordPress Site: The Complete Checklist

WordPress powers a considerable share of the world's websites. That popularity makes it a profitable target for bots that sweep the Internet looking for outdated versions, vulnerable plugins or weak passwords. Most attacks do not target your site specifically: they target any installation that exposes a known flaw.

WordPress core is audited and patched quickly. The vast majority of compromises come from the plugin and theme ecosystem, from compromised credentials and from neglected hosting configurations. The good news is that these vectors can be handled with simple measures, provided they are applied systematically.

This checklist is ordered by impact. The first sections block the most common attacks; the last ones strengthen defence in depth and your ability to respond if an incident happens anyway. No single measure replaces the others.

Updates are the most effective and least expensive security measure. A vulnerability published in a plugin is exploited by bots within the following hours or days. A site that is not updated remains exposed indefinitely, whatever the quality of the rest of its configuration.

Enable automatic updates for minor core releases, and schedule a regular review of plugins and themes, ideally on a staging environment to catch regressions before going live. Remove anything you do not use: a plugin that is deactivated but still present remains a potential entry point.

Check the PHP version too. Each PHP branch receives security fixes only for a limited period; an end-of-life version no longer gets patches. Your host must allow you to stay on a supported branch, and the switch must be tested.

Brute-force attacks and reuse of leaked passwords remain extremely common. Every administrator account must have a long, unique password managed by a password manager, and two-factor authentication must be enforced for every role with administrative rights.

Apply the principle of least privilege: editors do not need the administrator role. Delete the default "admin" account if it still exists, and periodically review the user list to remove inactive accounts, especially those of former contractors.

Limit the number of login attempts and, if you use neither a mobile app nor a remote publishing tool, disable the XML-RPC interface, which enables amplified authentication attacks. The REST API can also be restricted for unauthenticated users depending on your needs.

Several settings reduce the attack surface without affecting how the site works. Disable the file editor built into the dashboard with the DISALLOW_FILE_EDIT constant: an attacker who gains administrator access will not be able to inject PHP code directly from the interface.

Check file and folder permissions: the web server must not be able to write to core PHP files, and wp-config.php must be protected from reading. Prevent PHP scripts from executing in the uploads folder, where backdoors are often dropped.

On the hosting side, require HTTPS everywhere with a valid, automatically renewed certificate, isolate each site in its own space with no shared system user between sites, and add the HTTP security headers: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and Strict-Transport-Security.

A web application firewall (WAF) filters malicious requests before they reach PHP: SQL injection, file inclusion attempts, exploitation of known flaws. It can be provided by an upstream service, such as a CDN with a WAF, or by a server-side security plugin. An upstream WAF also protects against volumetric attacks.

Monitoring complements prevention. File integrity checking alerts you if a core or plugin file is modified outside an update. A log of logins and administrative actions lets you quickly identify the origin of an incident and its extent.

Also set up availability alerts and watch browser and search engine blocklists: a compromised site is often flagged by Google before its owner notices, with an immediate effect on traffic.

No preventive measure is infallible. Backups are what turn a hack into an incident of a few hours rather than a disaster. They must cover files and the database, run automatically, at least daily, and be stored off the site's server.

Test restoration regularly: a backup that has never been restored is only a hypothesis. Keep several versions over time, because a compromise may be discovered weeks after the intrusion, and the latest backup may already contain the backdoor.

Document the recovery procedure: who steps in, how to restore, how to change every credential (WordPress, database, FTP, hosting, salt keys) and how to verify that the site is genuinely clean before putting it back online.

If you notice redirects, unknown content, browser warnings or unknown administrator users, put the site into maintenance mode, change every password immediately and keep a copy of the compromised state for analysis. Do not clean blindly.

Cleaning means reinstalling core and plugins from official sources, examining recently modified files, the database and scheduled tasks, then identifying the entry vector to fix it. Without that last step, the site will be reinfected.