WordPress Hardening Checklist for Small Business Sites

Websites of every size are probed by automated bots that try logins, look for known plugin paths and hunt for forgotten accounts. WordPress sites are no exception, and a known problem that nobody fixed is an easy target.

This checklist is for the owner or office manager who looks after the site. It also marks which steps belong to your host or developer.

In short: Keep everything updated, delete what you don't use, protect every admin login with two-factor authentication, and remove old users. Block file editing from the dashboard, keep PHP out of the uploads folder, and run tested off-site backups. Do the backups first, because every other step can go wrong.

Before you change anything

Hardening edits live settings. One typo in wp-config.php or one over-strict security rule can lock you out. Set up a safety net first.

• Know your ways back in: hosting control panel, SFTP or file manager access, and your domain and DNS logins.
• Take a backup you have actually restored. Restore it to a staging copy, then log in, open key pages and send a test form. A backup you have never restored is only a hope.
• Use staging if your host offers it. Try changes there, then repeat them on the live site.
• Check what your host's backups cover. Retention and restore terms differ by plan. If cover is thin, add your own backup to a destination you control.

1. Keep everything updated

Outdated software is a common way in, because details of plugin vulnerabilities become public and attackers can scan for them.

• WordPress installs minor core releases (security and maintenance) automatically by default, but a host or wp-config.php setting can change that. Check Dashboard > Updates at least weekly.
• You can switch on automatic updates per plugin and theme. For a small site with few plugins, that is usually safer than forgetting.
• Install plugins and themes only from sources you trust. "Nulled" (pirated) copies often carry backdoors.
• Delete plugins and themes you don't use. Deactivating is not enough. Keep a parent theme if a child theme depends on it.
• If a plugin looks abandoned, check its wordpress.org page, changelog and support forum, then plan a replacement.

2. Lock down logins

The login page (/wp-login.php, /wp-admin) is the obvious place for password-guessing.

• Use a strong, unique password on every account, kept in a password manager.
• Turn on two-factor authentication (2FA) for administrators, editors and shop managers. The WordPress hardening guide recommends two-step authentication. Save recovery codes first, or you may lock yourself out.
• Limit login attempts through a reputable security plugin or your host. This helps against one noisy source, and less against attacks spread across many addresses.
• Avoid usernames like admin or your business name.
• Moving the login URL can cut log noise, but it is not a real defence.

Tip: Test 2FA by signing in from a private window with a recovery code before you roll it out to everyone.

3. Clean up user accounts

A freelancer's administrator account from two years ago, with a reused password, is a real way in. Open Users > All Users and ask of each account:

• Does this person still need access?
• Would Editor or Author be enough instead of Administrator?
• Do I recognise it? Investigate unknown accounts before deleting, because some plugins create their own.

Take a backup before deleting anyone. WordPress will ask who should inherit their posts. When someone leaves, revoke access the same day everywhere: WordPress, hosting, email, DNS, CDN, analytics and shared passwords. Give each person their own login and never share an admin account.

4. Files, permissions and uploads

The WordPress hardening guide suggests 755 for folders and 644 for files, and tighter permissions for wp-config.php (440 or 400, where your host allows). Hosts often set these correctly already. If unsure, ask your host rather than making bulk changes, which can break the site.

As general good practice, never use 777. It lets every user and process on the server write to the file or folder.

PHP should not run inside /wp-content/uploads/, which should hold images and documents, not scripts. How you enforce that depends on your server: an .htaccess rule on Apache, a location block on Nginx, or a support request on many managed hosts. Ask your host to apply it, then test that normal uploads still work.

5. Protect wp-config.php

This file holds your database credentials and secret keys. Keep a copy of the original before editing. To stop people editing theme and plugin code from the dashboard, add this above the "That's all, stop editing!" comment:

define( 'DISALLOW_FILE_EDIT', true );

This removes the theme and plugin file editors. It does not stop an attacker with full admin access from uploading a plugin.

You can also replace your secret keys and salts with new values. This invalidates existing login sessions, so people must sign in again. It does not change passwords or remove malware, so after a staff departure or suspected incident it is only one step among several.

6. XML-RPC and the REST API

XML-RPC (/xmlrpc.php) is an older interface that some apps and plugins still use. If nothing you rely on needs it, consider blocking it at the server, CDN or security plugin, then test those tools.

The REST API (/wp-json/) powers the block editor, so do not switch it off. Usernames can be exposed through public pages and endpoints, and hiding them is not real protection, which is why strong passwords and 2FA matter.

7. HTTPS and security headers

A padlock on the home page is not the whole job.

• Set WordPress Address and Site Address in Settings > General to https://.
• Redirect HTTP to HTTPS at the server or CDN, and fix mixed-content warnings (resources still loaded over http://).
• Make sure your certificate covers the bare domain, www and every subdomain before enabling HSTS. Be careful with includeSubDomains and preload, which are hard to undo.

HTTPS encrypts the connection. It does not prove a site is legitimate or free of malware.

Security headers tell browsers to enforce HTTPS and block framing. Our post on security headers every small business website needs covers the headers and starting values. Set them at the server or CDN where possible, then check the live responses.

The official guide also suggests a non-default database table prefix. On an existing site, changing it is risky and gives limited protection, so only do it with a tested backup and your developer's help. More useful: check that the database user has a unique password and only the access WordPress needs.

8. Backups, monitoring and response

Hardening lowers the chance of trouble. Backups and monitoring decide how bad it gets.

• Automated off-site backups on a schedule that matches how often the site changes, kept long enough to cover an incident you might not notice for weeks.
• File-change monitoring in your security plugin, if it offers it. Legitimate updates will trigger alerts too.
• Uptime monitoring, so a service tells you about outages before a customer does. It will not catch every compromise.
• A written note of who receives alerts, where backups live and who can restore them.

Account takeovers often start with a password reused on a breached site, or a convincing email asking staff to "re-confirm" a login. Make sure everyone with an account can spot phishing that pretends to be WordPress, your host or Google.

Watch out: If you suspect a compromise, hardening is not the fix. Contact your host or a qualified responder, keep the logs, revoke affected access, and find how the attacker got in before restoring. Otherwise the same hole stays open.

A quick outside check

To see your site as an outsider does, you can run the free Safe Scan at pentest.lordevo.com. It checks from outside without logging in, so it cannot show settings visible only to admins or prove a site is clean. Use its output as a to-do list.

Who does what

Key takeaways

• Prove you can restore a backup before changing anything.
• Update weekly, and delete what you don't use.
• Turn on 2FA for every admin, with recovery codes saved.
• Review users monthly, and revoke ex-staff access everywhere on their last day.
• Add DISALLOW_FILE_EDIT and keep PHP out of the uploads folder.
• Get HTTPS right before enabling HSTS.
• Keep off-site backups and alerts that someone actually reads.

FAQ

Do I need a security plugin?

Not necessarily. Updates, 2FA, user clean-up and backups matter more. A reputable plugin can add login limits and file-change alerts, but check whether your host already offers them.

Will changing the salts hurt my site?

It logs everyone out, so users must sign in again. Consider it when staff leave or you suspect a problem, but it is not a complete fix.

Is it safe to block XML-RPC?

Often, once you have confirmed that no app or plugin you use depends on it.

How often should I review all this?

Follow the schedule in the table, and again whenever your host, theme or major plugins change.