Guide

WordPress security checklist (2026)

Most WordPress sites are not hacked through clever attacks. They are hacked through an outdated plugin, a reused password or a forgotten backup file. This checklist covers the things that actually matter, in order of impact.

Last updated · 5 min read

Logins and accounts

  • Turn on two-factor authentication for every administrator and editor. An authenticator app is enough.
  • Use unique passwords from a password manager, and check them against known breaches.
  • Limit failed login attempts and lock out repeat offenders.
  • Give people the lowest role they need. Most content writers do not need Administrator.
  • Remove accounts for people who have left, and agency or developer accounts once a project ends.
  • Do not use "admin" or your domain name as an administrator username. It is one less thing an attacker has to guess.

Updates

Outdated plugins are the most common way into a WordPress site. Updating promptly matters more than any other single item on this list.

  • Keep WordPress core on a supported version. Minor (security) releases install automatically by default; leave that on.
  • Update plugins and themes promptly, and fastest when an update fixes a known vulnerability. Check what an update fixes with the WordPress plugin vulnerability lookup.
  • Turn on automatic updates for plugins you trust, ideally with a way to roll back if an update breaks the site.
  • Delete plugins and themes you do not use. Deactivated plugins are still files on the server and can still be exploited.
  • Replace plugins that are abandoned (no update for a long time) or closed on wordpress.org.
  • Keep premium plugins licensed so you actually receive their security updates.

Hosting and PHP

  • Run a PHP version that still receives security support. Webforta flags end-of-life PHP versions when the server advertises them.
  • Serve the whole site over HTTPS and redirect HTTP to HTTPS. See how to fix "Not secure" warnings.
  • Use SFTP or SSH, never plain FTP, and remove hosting accounts nobody uses.
  • Keep file permissions tight: typically 644 for files and 755 for folders, and stricter for wp-config.php (400 or 440) where your host supports it.
  • Make sure one site on a shared account cannot read another. A hacked old test site in the same account can infect the main one.

Configuration

  • Disable the built-in file editor with define('DISALLOW_FILE_EDIT', true); in wp-config.php.
  • Turn off WP_DEBUG in production, and make sure wp-content/debug.log is not publicly readable.
  • Disable XML-RPC if nothing you use needs it (Jetpack and some mobile apps do). It is a favourite target for password guessing.
  • Block username enumeration through author archives and the REST API users endpoint.
  • Add security headers: HSTS, X-Content-Type-Options, a clickjacking policy and a Referrer-Policy at minimum. Test them with the security headers checker.
  • Delete backup copies of configuration files such as wp-config.php.bak, wp-config.old or .zip archives in the web root. They are readable as plain text.
  • Publish a security.txt so researchers can report problems to you. The security.txt generator makes one in a minute.

Backups

  • Back up files and the database automatically, at least daily for sites that change often.
  • Keep copies off the server, for example in cloud storage. A backup in the same hosting account can be deleted or infected with the site.
  • Keep several days or weeks of history, because infections are often discovered late.
  • Test a restore at least once. A backup you have never restored is a hope, not a plan.
Webforta does not make backups. Use your host's backup feature or a dedicated backup plugin or service.

Firewall and monitoring

  • Put a web application firewall in front of the site (an edge WAF) or inside WordPress (a plugin), and start it in a monitoring mode to avoid blocking real users. See what a WAF does and does not do.
  • Monitor uptime and certificate expiry so you hear about problems before customers do.
  • Watch file integrity: get alerted when core or plugin files change.
  • Keep an activity log of logins, user changes, plugin installs and updates.
  • Get alerted when a plugin you run gets a newly published vulnerability.

How Webforta covers this list

Webforta Scan checks the outside of the site: exposed configuration backups and debug logs, XML-RPC, version leaks, username enumeration, security headers, HTTPS and known vulnerabilities in the WordPress core, plugin and theme versions it can see. Webforta Monitor watches uptime, certificates, DNS and new external scripts.

The free Webforta WordPress Security plugin covers the inside: login limits and two-factor authentication, a firewall inside WordPress, hardening switches for most of the configuration items above, file integrity checks against official checksums, an activity log, breached-password warnings and opt-in automatic updates with rollback. When connected, Webforta tells you whether each pending update fixes known vulnerabilities ("safe to update" advice), using public vulnerability data only.

Before something goes wrong

  • Write down who has access to hosting, DNS, the registrar and WordPress, and where the backups are.
  • Keep your host's support contact and your developer's details somewhere you can reach if the site is down.
  • Read what to do when your website is hacked once now, so you are not reading it for the first time in a crisis.

Frequently asked questions

What is the single most important WordPress security step?

Keeping plugins, themes and core updated, closely followed by two-factor authentication for administrators. Most compromises use a known, already-fixed vulnerability or a weak or reused password.

Do I need a security plugin?

Not strictly, but a good one makes login protection, 2FA, file integrity checks and hardening much easier. Use one firewall plugin at a time: two can conflict.

Is hiding the WordPress version worth it?

It is a small step. Attackers usually try exploits regardless of the version they see. Updating matters far more than hiding the number.

Should I change the login URL?

It reduces noise from bots but is not real protection. Two-factor authentication and login limits do much more.

Is managed WordPress hosting secure enough on its own?

Good hosts handle server patching, backups and often a firewall, but you are still responsible for your plugins, themes, users and passwords.

See what your website shows attackers

Webforta scans websites you verify for exposed files, weak HTTPS, missing headers and signs of compromise, and keeps watching uptime, certificates and DNS. A clean scan is not a guarantee, and we never say it is.