A WordPress security checklist for small businesses

Open Plugins and Appearance → Themes and write down everything installed, active or not, with its version. Then look each one up on its WordPress.org page or its developer's site: when was the last release, and is it tested with your version of WordPress?

Anything that has not been updated in a year or more deserves a hard look. WordPress.org closes plugins that have unresolved security problems and says so on the plugin's page; a closed plugin will not receive a fix and should be replaced, not kept. Premium themes and page builders bought outside WordPress.org need a valid licence to receive updates, and an expired licence is a common reason a site falls years behind.

Then look at your site from the outside. Many WordPress sites print the core version in a generator tag and plugin versions in the links to their scripts and stylesheets. A free check can read those and tell you whether any of the exact versions on show have published vulnerabilities, which is a quick way to see your site the way automated tools see it.

WordPress has installed minor core releases — the maintenance and security ones — automatically since version 3.7, and since version 5.5 every plugin and theme has its own auto-update switch. Leave core's automatic updates on. For plugins, switch on auto-updates for those from developers with a good release record, and check the rest at least once a week.

The fear that holds people back is an update breaking the site. It does happen, and it is the reason for backups and for the one-click staging copy many hosts now provide. But a broken layout is fixed in an hour. A hacked site with customer data on it takes weeks to recover, and has to be explained to your customers.

Keep PHP current too. Your host's control panel shows the PHP version, and versions that have reached end of life no longer receive security fixes. The PHP project lists which versions are still supported on php.net.

Every person who logs in gets their own account, with the lowest role that lets them do their job: Editor to write and publish, Administrator only for the one or two people who install plugins and change settings. Shared logins make it impossible to tell who did what, and impossible to remove one person's access.

Give every admin account a long, unique password kept in a password manager, and turn on two-factor authentication; a well-established security plugin adds it if your setup does not already have it, and an authenticator app is stronger than SMS. Remove the accounts of staff and agencies who no longer work with you. An old agency login is one of the most commonly forgotten doors.

Limit login attempts as well. Automated password guessing against the login page is constant on almost every WordPress site. A security plugin or your host's firewall can block an address after a few failures, which turns that background noise into nothing.

A backup is the difference between an afternoon's work and losing the site. Back up both the database and the files, automatically, on a schedule that matches how often the site changes: daily for a shop taking orders, weekly for a brochure site.

Keep at least one copy off the server, in an account separate from your hosting. A backup stored on the same server is often deleted or encrypted along with everything else when the site is compromised.

Then restore one. Pick a backup, restore it to a staging copy or a test install, and check that the site works. Many businesses only discover that their backups were empty, partial or impossible to restore on the day they need them.

Serve the whole site over HTTPS with a certificate that renews automatically; most hosts provide one free. The admin area should never be reachable over plain HTTP.

Keep the server tidy. Delete old copies of the site in folders named old, backup or test, leftover installer files and database exports sitting in the web folder. Automated scanners look for exactly these, and they often contain passwords. File permissions should let the web server read your files but not write to most of them; your host's documentation gives the recommended settings.

On cheap shared hosting, ask what separates your account from the others on the server and whether there is a web application firewall. A firewall in front of the site, from your host or a CDN service, blocks a large share of automated attacks before they ever reach WordPress.

Deactivated plugins and unused themes are still files on your server, and a vulnerable file can often be reached whether or not the plugin is switched on. Delete them. Keep one default theme as a fallback and remove the rest.

Look at XML-RPC too. The xmlrpc.php file exists for remote publishing and for some apps and services, and it is a common target for password guessing. If nothing you use needs it, a security plugin or a server rule can switch it off.

Fewer plugins is the single most effective security setting. Each one is someone else's code running with full access to your site and your customers' data. If two plugins do the same job, or one does something a few lines of theme code could do, the shorter list is the safer site.

The signs include redirects to unfamiliar sites, spam pages appearing in Google under your domain, admin users you did not create, a warning from your host or from Google Search Console, and a sudden drop in search traffic. Do not start deleting files. Take a full copy first, because you will need it to find out how they got in.

Our guide on what to do when your website is infected with malware gives the recovery order step by step. Cleaning without finding the way in is the reason most infections come back within weeks.

If the site handles customer data and your business is in India, a compromise may also have to be reported to CERT-In within six hours, and a personal data breach brings obligations under the DPDP Act. Both are covered in our guides.