Website security basics for a small business come down to five things: keep all software current, use a unique password plus two-factor authentication on every admin login, give each person the smallest role that works, keep backups you have restored, and serve the whole site over HTTPS. The exotic attacks people worry about are far down the list.
Nobody is picking your business out of a lineup. The traffic hitting your login page and probing your plugin directory is automated, and it is looking for a version number it already has an exploit for. You are not targeted. You are scanned, constantly, and a scanner does not care that you have eleven employees and a nice logo.
Updates Are Most of the Job
Boring, and still the answer.
Think about what an automated attack actually needs. Somebody publishes a vulnerability in a plugin, a proof of concept goes into a scanning kit, and from that moment every site still running the old version is reachable by a script that costs nothing to run against the entire internet. No skill is involved and no decision is made about you. The window closes the moment you update, and stays open indefinitely if you do not.
So the practice that matters is unglamorous: update on a schedule, not when you remember. WordPress has shipped automatic background updates for minor core releases since version 3.7, which handles core security patches without you doing anything. Plugins and themes are the gap. Turn on automatic updates for the ones you would be comfortable seeing update unattended, and check the rest monthly.
Delete what you are not using. A deactivated plugin still has its PHP files on disk, and several historically nasty vulnerabilities were reachable in files that never checked whether the plugin was active. Deactivating is not removing. The same goes for that staging copy of the site in /old/ that has not been touched in three years and is still perfectly happy to execute code.
If you cannot update something because it would break the site, that is not a reason to leave it. That is the finding. Either the thing gets replaced or the site stays vulnerable, and pretending there is a third option is how sites end up compromised while everyone involved knew about the problem.
One Password Per Site, and a Second Factor Where It Counts
The other common way in is not an exploit at all. It is a password that was already published somewhere else.
Credential stuffing works like this: an unrelated service gets breached, its username and password pairs end up in a public dump, and bots replay those pairs against every login form they can find. If the password on your administrator account is the one you also used on a forum years ago, the attacker never needs a vulnerability. They log in. Your logs show a successful authentication, because that is exactly what it was.
Unique passwords per site, generated by a password manager, remove that attack entirely. You will not remember them and you are not supposed to. Check your own addresses against Have I Been Pwned once and you will usually find a dump you did not know about.
Two-factor authentication covers the case where a password leaks anyway. Three notes on setting it up:
- App-based codes (TOTP) are the sensible default. Free, offline, supported everywhere that matters.
- SMS is better than nothing and worse than everything else, because a determined attacker can talk your mobile carrier into moving your number to their SIM.
- Passkeys, built on WebAuthn, cannot be phished at all, because the credential is bound to the site's domain and will not present itself to a lookalike.
Then put whichever you chose on your hosting control panel and your domain registrar as well, which is the step people skip. Control of the domain outranks control of the website, since somebody who owns your DNS can point the name anywhere they like and your hardened site becomes irrelevant.
Give People the Smallest Account That Works
Administrator accounts get handed out because it is easier than thinking about it. Then the freelance designer who redid the homepage two years ago still has full control, and so does the marketing agency you stopped working with.
WordPress ships five roles, and the distance between them is large. An Editor can publish and edit anyone's content, which is what a content person actually needs. An Administrator can install plugins, edit user accounts, and change site-wide settings. Those are entirely different levels of blast radius when the account gets phished, and there is no reason a person who writes blog posts should hold the second one.
Two habits, both cheap:
Audit the user list quarterly and remove anyone who has left. Anyone, including the developer who built the thing.
And separate your own accounts. Write posts under a lower-privileged login and keep the administrator account for administration. It means the session sitting open in your browser all day is not the one that can install a plugin.
While you are in there, consider stopping code editing from inside the dashboard entirely. Adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php turns off the built-in theme and plugin file editors, one of several changes in the project's own hardening guide. It removes a convenient way for anyone who reaches an administrator account to write a backdoor without touching a file over FTP. You lose almost nothing, since editing production code through a browser textarea was never a good plan.
A Backup You Have Never Restored Is Not a Backup
Backups are the control that turns a catastrophe into a bad afternoon, and they are the one people most reliably get wrong. The usual failure is not the absence of backups. It is a job that has been quietly failing for months, or a copy that lives in the same account as the site it protects, which means whatever reached the site reached the backup as well.
Check two things today. Does the backup include the database as well as the files, since a WordPress site is mostly database and a folder of PHP restores nothing on its own? And can you actually restore one? Doing it once, on purpose, on a spare subdomain, tells you how long it takes and what breaks, which are exactly the two things you will not want to discover during an incident.
Retention matters more than people expect. Ransomware and defacements announce themselves immediately, but a quiet injection of spam links into your database can sit unnoticed for weeks, and a rotation that keeps only a few days will happily overwrite every clean copy you had.
HTTPS on Everything, Including the Redirect
Every page. Browsers mark plain HTTP as not secure, mixed content warnings break layouts, and anything served over HTTP can be read or modified in transit by whoever sits on the network between you and your visitor.
Cost stopped being a reason to delay years ago. Let's Encrypt issues free domain-validated certificates that renew automatically, and that is the right answer for most small business sites. Paid certificates still exist for organizational validation and wildcard coverage across subdomains, and the SSL certificate reference page explains what each type actually verifies.
If one of those turns out to be what you need, the SSL certificates page lists what is available to order.
Two things people forget after installing a certificate. Redirect HTTP to HTTPS with a 301 at the server level rather than trusting visitors to type the right thing, and once that redirect is stable, add HSTS so browsers refuse to make the insecure request at all. Start with a short max-age, because a long one is difficult to undo.
What Your Host Handles, and What Stays Yours
Platform-level protection is real, and it is not the same thing as your site being secure. A host maintains the operating system, patches the web server and PHP, isolates accounts from each other, and filters obvious attack traffic before it arrives. On shared and semi-dedicated plans the host owns that entire stack under your account, which is a real security advantage over running your own server badly. BestPaidHosting accounts are administered through the Hepsia control panel, where the account-level tools live.
What no host can do for you: choose your passwords, decide who gets an administrator account, update your plugins, or notice that the contact form plugin you installed has not had a release in four years. Application-layer security is yours on every plan and with every provider. Move to a VPS and the operating system becomes yours as well, along with its patching and its firewall rules, which is one of the things worth understanding before you outgrow a shared plan.
Migrations deserve a warning of their own. A host move leaves a copy of your site somewhere you have stopped paying attention to, and that copy keeps running an unpatched version of everything for as long as the old account stays open. The checklist for moving a site to a new host covers closing it down properly.
Do You Actually Need a Security Plugin?
Probably not, and here is the honest reason: a security plugin is not a substitute for updating the thing it is protecting.
Most of what these plugins block is background noise. Login attempts from bots that were never going to guess your password, scans for paths that do not exist on your site, requests for wp-config.php.bak. The dashboard counts them up and shows you a large number, and the large number feels like protection. Meanwhile the actual way in is a known hole in a plugin you did not update, and a generic rule set is unlikely to catch a request that looks exactly like legitimate use of that plugin's own endpoint.
They are not useless. Rate limiting on the login form and file integrity monitoring are worth having, and if a plugin is the easiest way for you to get them, use one. Install it, configure it in an afternoon, then go back to patching. Running three overlapping security plugins is a performance problem wearing a safety costume, and each of them is itself code holding a privileged position in your site.
If You Only Have an Hour, Work Down This List
Stop when the hour is gone. Pick up at the same line next time.
| Priority | Do this | Why it is here |
|---|---|---|
| 1 | Update core, plugins and themes, then delete what is unused | A published exploit is automated within days of disclosure |
| 2 | Unique password plus two-factor on site, host and registrar logins | Closes credential stuffing, which needs no vulnerability at all |
| 3 | Remove stale accounts, downgrade everyone who does not need admin | Limits what a single stolen login can reach |
| 4 | Verify backups run, are stored off the account, and restore | The control that makes every other failure survivable |
| 5 | HTTPS site-wide with a 301 redirect, then HSTS | Protects data in transit and removes browser warnings |
Everything past line five is refinement. Web application firewalls, file permission tuning, security headers beyond HSTS, and login page renaming are all reasonable things to do eventually, and every one of them is wasted effort while any of the first four lines is still open.
Start This Week
Open your plugin list and your user list, in that order. Delete what nobody uses, update what remains, and remove every account belonging to a person who no longer works on the site. Forty minutes, give or take. It closes the two doors that almost everything walks through.
Then set a recurring reminder for the same review each month. Security on a small business site is never finished, because the software under it keeps changing, and the sites that stay clean are the ones where somebody keeps doing the dull review after the interesting part is over.