WordPress Security: The Minimum Viable Hardening Checklist for SMBs

Most of the WordPress sites I get called in to clean up were not hacked through some exotic zero-day. They were hacked because an admin account used the password the owner uses for everything, or because a plugin nobody had opened in two years had a known vulnerability sitting in a public database. So before the fourteen things, let me be blunt about the one that matters most. The single highest-impact free WordPress security fix is a strong, unique password on every administrator account paired with two-factor authentication. If you do nothing else on this page, do that, because the overwhelming majority of small business compromises I see at WitsCode are credential attacks, not code attacks, and a password manager plus a 2FA app closes the door the attacker actually walks through.

I run WitsCode, a small web development agency, and we maintain north of 250 WordPress sites for small businesses across the UK and US. This article is the minimum viable hardening checklist, the fourteen things every site needs regardless of budget, and every one of them is free or close to it. I have written it as prose rather than a checklist you skim, because a checkbox tells you what to tick but not why it matters or how to do it without breaking your site. At the end I will tell you honestly what a paid security plugin adds on top, and where it starts padding the invoice.

Access control: locking the front door

Access control is the first pillar because it is where almost every real-world compromise starts, and the foundation of it is the credentials on your administrator accounts. A strong admin password means a randomly generated string of at least sixteen characters, unique to that site, stored in a password manager rather than reused from your email or bank. Just as important, and routinely ignored, is the username. WordPress shipped with "admin" as the default for years, and bots still hammer that username on every site they find. Every administrator account should use a username that is not "admin", not your business name, and not the string in the author URL of your blog posts. To fix an existing "admin" account, create a fresh administrator account with a unique username, log in as it, and delete the old one, assigning its content to the new user.

Two-factor authentication is the layer that makes a stolen password worthless. Even if an attacker phishes or buys your password, they cannot complete the login without the rotating code from your phone. The free Two-Factor plugin from the WordPress.org repository, or the two-factor module in Wordfence's free tier, adds this in about ten minutes using any authenticator app such as Google Authenticator or Authy. Turn it on for every account with publish or admin capability, not just your own, because a compromised editor account is still a compromised site.

Limiting login attempts addresses the brute-force problem directly. Without it, a bot can try thousands of password combinations against your wp-login.php page until something works. The free Limit Login Attempts Reloaded plugin caps the failed attempts from a single IP, locks that IP out for an escalating period, and emails you when it happens. Set it strict, four attempts before a twenty-minute lockout, and you have converted an unlimited guessing game into a slow, noisy one that any attacker will abandon for an easier target.

The last access control item is least-privilege roles, which means nobody gets more capability than their job requires. A freelance copywriter who publishes blog posts needs the Author role, not Administrator. A virtual assistant who updates product descriptions needs Shop Manager or Editor. Every extra administrator account is another full set of keys that can be phished, and I regularly find sites with six admin accounts where one person left a year ago. Audit your Users screen, demote everyone who does not genuinely need to install plugins or change settings, and delete accounts for people who no longer work with you. This is free, takes fifteen minutes, and shrinks your attack surface immediately.

Update hygiene: closing known holes

Update hygiene is the difference between a site attackers can compromise with a published, documented exploit and one they cannot. The single most useful setting here is automatic updates for minor WordPress core releases and for plugins. Minor core releases, the ones that go from 6.5.1 to 6.5.2, are almost always security and bug fixes and rarely break a well-built site, so WordPress applies them automatically by default and you should leave that on. Plugin auto-updates are toggled per plugin on the Plugins screen, and for most small business sites I recommend enabling them on every plugin from a reputable developer, because the window between a vulnerability being disclosed and bots scanning for it is now measured in hours. The one caveat is to have a recent off-site backup in place first, covered below, so the rare bad update is an inconvenience rather than a disaster.

The companion habit is removing inactive plugins and themes entirely rather than just deactivating them. A deactivated plugin still has its code sitting in your wp-content directory, and a vulnerability in that code can often still be reached by a direct request even though the plugin is not running. The same applies to the two or three unused themes most sites carry. If you are not using it, delete it. Keep one fallback theme, kept updated, so you have something to switch to if your main theme breaks. This is free, lives on the Plugins and Themes screens, and is one of the most common findings in every audit we run.

Server and file hardening: shrinking the attack surface

Server and file hardening is the set of changes that make WordPress itself less useful to an attacker who does get a foothold. The first is disabling the built-in file editor by adding a single line to your wp-config.php file: define('DISALLOW_FILE_EDIT', true);. By default, any administrator can edit your theme and plugin PHP directly from the browser, which means a compromised admin login hands the attacker a code editor with which to install a backdoor. Turning the editor off does not stop legitimate development, because real changes should go through staging and version control anyway, but it removes the easiest path from stolen login to permanent backdoor. There is no good reason for a production site to leave it on.

Next is your SSL certificate and HTTP Strict Transport Security. SSL, the certificate that puts the padlock in the browser bar and serves your site over HTTPS, is now free everywhere through Let's Encrypt and included by default on every host worth using, so there is no excuse for a site still on plain HTTP. HSTS is the often-missed companion: a response header that tells browsers to only ever connect over HTTPS, even if a user types the plain address, which closes a window attackers use to intercept that first insecure request. You enable HSTS in your host's control panel, in Cloudflare's SSL settings, or with a header rule, and once your site is confirmed working entirely over HTTPS it costs nothing to turn on.

Beyond HSTS sit the broader security headers, a handful of HTTP response headers that instruct the browser to behave defensively. X-Content-Type-Options stops the browser guessing file types in ways that can be abused, X-Frame-Options stops other sites embedding yours in a hidden frame for clickjacking, and a Content-Security-Policy, the most powerful and the fiddliest, restricts which sources may run scripts on your pages. You can add the simpler headers free through Cloudflare's rules, your host's configuration, or a lightweight plugin, and even the basic set meaningfully reduces the damage a cross-site scripting flaw can do.

XML-RPC is a legacy WordPress interface that almost no modern small business site uses, yet it remains a favourite target because it lets attackers attempt many password guesses in a single request and can be abused to amplify denial-of-service attacks. Unless you rely on the classic WordPress mobile app, pingbacks, or a specific integration that needs it, you should disable XML-RPC entirely. The free Disable XML-RPC plugin does it in one click, or Cloudflare can block requests to xmlrpc.php at the edge. Check first that nothing you depend on uses it, then turn it off, because for most sites it is pure attack surface with no offsetting benefit.

Hiding the WordPress version number is a smaller, quieter measure. By default WordPress prints its exact version into your page's HTML and RSS feed, which hands an attacker a precise list of which published vulnerabilities might apply to your site. Removing that meta tag does not patch anything and will not stop a determined attacker, but it removes the free reconnaissance and slows the automated scanners that filter targets by version. A few lines in your theme's functions file, or a setting in most hardening plugins, handles it at no cost. Treat it as tidying up rather than a primary defence.

Changing the database table prefix is similar useful-but-modest hardening. WordPress installs its tables with the prefix wp_ by default, and certain SQL injection attacks are written assuming that exact prefix, so a non-default prefix breaks those copy-paste exploit attempts. This one carries real risk if done carelessly on a live site, because it touches the database directly, so it is best done at install time or by someone comfortable taking and restoring a backup first. If you are building a new site, set a custom prefix during installation at zero cost. If your site is already live, weigh it against the simpler wins above rather than rushing it.

The last item in this pillar is correct file permissions, which govern who on the server may read, change, or execute your files. The standard safe values are 644 for files and 755 for directories, with wp-config.php often tightened to 640 or 600 because it holds your database password. Permissions that are too loose, such as the 777 that some tutorials hand out to make an upload error go away, let any process on the server rewrite your files, which is how a single compromised neighbour on shared hosting can spread. You can check and correct permissions through your host's file manager or over SFTP at no cost, and a well-configured managed host will usually have them right already.

Monitoring and backup: assuming the worst

The final pillar accepts that no defence is perfect and prepares for the day something gets through. Monitoring means knowing your site changed before your customers, or Google, tell you. At its free minimum this is an uptime monitor such as UptimeRobot, which pings your site every few minutes and alerts you if it goes down or starts redirecting somewhere strange, plus a file-change notifier, in the free tier of most security plugins, that emails you when a core or plugin file is modified outside of an update. Most compromises stay invisible for weeks, quietly serving spam or stealing card details, and that gap between infection and discovery is what turns a quick clean-up into a Google blacklisting. Free monitoring closes the gap.

Off-site backups are the last line and, in my experience, the most neglected. A backup that lives on the same server as the site it is backing up is worthless the moment that server is compromised, ransomwared, or suspended by the host, because the outage takes the backup with it. A real backup runs on a schedule, captures both your files and your database, and stores the copy somewhere else entirely: Google Drive, Dropbox, or dedicated backup storage. The free tier of UpdraftPlus does exactly this, scheduling automatic backups to a remote destination of your choice, and it is the plugin we reach for on smaller sites. Test a restore at least once, because an untested backup is a hope, not a plan. This is the difference between a bad afternoon and a closed business.

What paid security plugins genuinely add

Everything above is free or near-free, and for a low-risk brochure site it is a genuinely solid baseline. So what does a paid security plugin, Wordfence Premium or Solid Security Pro, actually add on top? Three things are real. The first is a web application firewall, a WAF, that inspects incoming traffic and blocks known malicious requests before they reach WordPress at all, and crucially the paid tiers update their rules in real time as new attacks emerge rather than on a delay. The second is malware scanning that compares your files against known-good copies and known-bad signatures, so an infection is caught quickly rather than weeks later. The third is an intelligent login firewall that blocks credential attacks using a live list of compromised passwords and known-bad IP addresses, going meaningfully further than the simple attempt limiting you get for free.

What paid plugins mostly do not add is anything that replaces the fourteen fundamentals. A WAF in front of a site with a reused admin password and an "admin" username buys you very little, because the attacker logs straight in through the front door the firewall is designed to wave through. Some of what you pay for is also genuine padding: vanity security scores, dashboards that restate what you already know, and country-blocking that frustrates real customers more than attackers. A paid plugin is worth it when the basics are done and the site carries real risk, an e-commerce store, a membership site, a lead database, but it complements the hardening above, never substitutes for it.

That ordering, fundamentals first and paid tooling second, is exactly how we run our managed WordPress security retainer at WitsCode. We apply every one of the fourteen items above, layer a properly configured WAF and malware scanning on top, monitor for changes, keep off-site backups tested, and handle updates so the rare bad one is caught on staging. If keeping all of this current is not a job you want to own month after month, that is the retainer in one sentence: the hardening done once, then kept done. The checklist above is yours to use for free. Having someone make sure it stays true twelve months from now is what the retainer is for.