WordPress Security Checklist: 20 Steps That Actually Matter

Short answer: Most WordPress sites are compromised through outdated plugins or themes, weak or reused admin passwords, and abandoned software. The checklist that matters most is: keep core, plugins, themes and PHP updated; remove what you do not use; protect logins with strong unique passwords, two-factor authentication and fewer admin accounts; keep tested off-site backups; run the site on HTTPS with a valid certificate and basic security headers; and monitor the site from outside so problems are noticed quickly.

WordPress itself is actively maintained and its core receives security fixes quickly. Most real incidents happen around it: a plugin that was not updated for two years, an administrator account with the password “Summer2019”, a forgotten staging copy, a theme bought once and never touched again. Security plugins with long lists of toggles can make owners feel safe while missing these basics. This checklist is ordered by impact – start at the top, and you will have covered the causes behind the majority of real-world WordPress compromises.

1. Updates: the most important habit

1. Update WordPress core promptly. Minor releases, which include security fixes, can be applied automatically; leave that enabled. Plan major releases within a few weeks.
2. Update plugins and themes regularly. Vulnerabilities in plugins are the most common entry point. Check for updates at least weekly, or enable automatic updates for well-maintained plugins you trust.
3. Run a supported PHP version. Old PHP branches stop receiving security fixes. Your hosting panel usually lets you switch; test the site on a staging copy first.
4. Replace abandoned plugins. A plugin that has not been updated in a year or more, or has been removed from the official directory, will not receive fixes. Find a maintained alternative.

A practical routine: once a week, log in, apply updates, check that the home page, a form and (for shops) the checkout still work. If the site is important, run updates on a staging copy first.

2. Remove what you do not use

5. Delete inactive plugins and themes. Deactivated code still sits on the server, and some vulnerabilities can be exploited even when a plugin is inactive. Keep one default theme as a fallback and remove the rest.
6. Remove old staging copies, backups and test installations from the web-accessible folders. Forgotten copies in folders such as /old/, /test/ or /backup/ are rarely updated and are a frequent way in.
7. Remove unused user accounts, especially former employees, agencies and freelancers who no longer work on the site.

3. Protect logins and accounts

8. Use strong, unique passwords for every account with editing rights, stored in a password manager. Reused passwords from breached services are regularly tried against WordPress logins.
9. Enable two-factor authentication for administrators and editors. It stops the vast majority of password-based attacks. Several well-maintained plugins provide it.
10. Limit administrator accounts. Most people who publish content need the Editor or Author role, not Administrator. Fewer admins means fewer valuable accounts to steal.
11. Limit login attempts or use a service that blocks brute-force traffic. It reduces noise and slows down password guessing.
12. Do not use “admin” as a username, and avoid showing author usernames that match login names where you can.

4. Backups you can actually restore

13. Back up files and database automatically, daily for active sites, and keep several versions – a backup taken after an infection is not much use.
14. Store backups off the server, in a separate storage service or account. A backup on the same server can be deleted or encrypted along with the site.
15. Test a restore at least a few times a year, for example by restoring to a staging site. Many people discover that their backups were incomplete only when they need them.

5. HTTPS, headers and server settings

16. Run the whole site on HTTPS with a valid, automatically renewed certificate, a permanent redirect from HTTP and no mixed content. Set both addresses in Settings → General to HTTPS.
17. Add basic security headers: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options (or CSP frame-ancestors) and Referrer-Policy. They take minutes to add at the server level.
18. Harden the configuration: disable the built-in file editor by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php, turn off PHP error display in production, hide software versions, and make sure file permissions do not allow the web server to write everywhere.

6. Monitoring and response

19. Monitor from the outside. Uptime, certificate expiry, unexpected redirects and changed pages are the first visible signs of many problems. External checks notice them even when the site’s own plugins have been disabled by an attacker.
20. Know your incident plan: who to call, where the backups are, how to put the site into maintenance mode, and how to change all passwords and keys quickly. Write it down while things are calm.

Beyond WordPress: hosting and access accounts

The WordPress admin is not the only door. Attackers who get into the hosting account, the domain registrar or the DNS provider can take over the site without touching WordPress at all. Give these accounts the same care:

• Enable two-factor authentication on the hosting control panel, domain registrar, DNS or CDN account and the e-mail account used for password resets.
• Use SFTP or SSH keys instead of plain FTP. Plain FTP sends passwords unencrypted, and FTP accounts created years ago for a developer are often still active.
• Keep database access private. The database should accept connections only from the web server, and tools such as phpMyAdmin should not be publicly reachable without additional protection.
• Record who has access to what, and remove access when a contract with an agency or freelancer ends.

These accounts are rarely changed, which is exactly why old passwords and forgotten users accumulate there.

Security plugins and overrated measures

What security plugins can and cannot do

Security plugins can add login protection, two-factor authentication, file change detection, malware scanning and a basic firewall. These are useful. But no plugin can make an outdated, vulnerable plugin safe, fix a reused password or restore a site without a backup. Treat a security plugin as one tool on the list, not as the list itself. Also avoid installing several overlapping security plugins – they conflict, slow the site down and make troubleshooting harder.

Measures that sound good but matter less

• Changing the database table prefix on an existing site: little protection against modern attacks and some risk of breaking things.
• Hiding the login page URL: reduces bot noise in logs, but is not a substitute for strong passwords and two-factor authentication.
• Blocking entire countries: can reduce spam, but attacks come from compromised servers everywhere, and you may block real customers.
• Removing the WordPress version number: good hygiene, but scanners can still fingerprint the site; updates are what count.

A simple monthly routine for owners and agencies

• Apply all updates and check key pages afterwards.
• Review the user list and remove accounts that are no longer needed.
• Confirm the latest backups exist off-site.
• Check the certificate expiry date and the site’s security headers.
• Look at the plugin list: anything unused, abandoned or duplicated?
• Run an external audit and compare the result with last month.

Agencies managing many client sites benefit most from standardising this routine, so that no site is forgotten simply because nobody has complained about it recently. The official WordPress hardening guide is a good complementary reference.

How Site AI Audit helps

Site AI Audit checks a WordPress site from the outside, the way visitors and attackers see it: SSL certificate and expiry, HTTP to HTTPS redirect, security headers and exposed software versions, alongside SEO, speed and e-mail authentication. Each finding is explained in plain words and ranked by impact. Paid plans add re-checks and weekly or daily monitoring with alerts, and the Agency plan adds reports with your own logo for client work. See the plans, or start with a free check.

Related reading

• Exposed Software Versions: How to Hide Server and CMS Details
• HTTP Security Headers Explained: What Each One Does
• Mixed Content Errors: How to Find and Fix Them on Your Site

The bottom line

WordPress security is mostly about routine, not tricks. Keep everything updated, remove what you do not use, protect accounts with strong passwords and two-factor authentication, keep tested off-site backups, run on HTTPS with sensible headers, and monitor from outside. Do those consistently and you have addressed the causes behind most real WordPress compromises.

KKK

Is WordPress secure enough for a business website?

Yes, when it is maintained. WordPress core is actively developed and patched; most problems come from outdated plugins and themes, weak passwords and missing backups, all of which are under the owner’s control.

Do I need a security plugin for WordPress?

A good one can help with login protection, two-factor authentication and malware scanning, but it is not required and cannot replace updates and backups. Choose one well-maintained plugin rather than several overlapping ones.

Should I enable automatic updates for plugins?

For well-maintained plugins it is usually a good trade-off, because security fixes arrive without delay. For complex plugins such as page builders or shop extensions, many owners prefer updating manually after testing on staging.

How often should I back up my WordPress site?

Daily for sites that change often, such as shops or active blogs, and at least weekly for static sites. Keep several versions off the server and test restoring one from time to time.

What is the first thing to do if my WordPress site is hacked?

Take the site offline or into maintenance mode, change all passwords and keys, and restore from a clean backup or clean the site with professional help. Then find and fix the entry point, usually an outdated plugin or a stolen password, before bringing it back.