Search “WordPress security” and you’ll find 40-point checklists that read like preparing a site for war: rename your login URL, hide your WordPress version, block entire countries, install three security plugins.

Here’s the honest version: small-business WordPress sites are almost never “hacked” the way owners imagine, a person, targeting you, defeating your defenses. They’re compromised by automated scripts scanning millions of sites for a handful of known, boring weaknesses. The bots don’t care who you are. They care whether you left one of five doors open.

Close those five doors and you’ve prevented the overwhelming majority of real-world compromises. Everything else is diminishing returns.

Every hacked site we’ve rescued in the past two years traces back to the same two causes: an outdated plugin or a compromised account.

The five doors, in priority order

1. Outdated software: the front door

The number one cause of WordPress compromises, and it isn’t close: a plugin or theme with a publicly known vulnerability, left unpatched. When a security hole is found in a popular plugin, it gets a public disclosure, and within hours, bots are scanning the internet for every site still running the vulnerable version. Your risk window is the gap between the patch existing and you applying it.

What this means practically: updates are not a chore to batch up quarterly. They are the security measure. Everything else on this list is secondary to simply staying current, which, as we’ve written before, is best done tested on staging rather than blindly.

2. Weak or reused passwords, the key under the mat

The second-biggest cause is embarrassingly simple: an admin account with a password that’s guessable, or one that leaked from some other service in some other breach and gets tried here by bots (“credential stuffing”). The fix costs nothing:

• A long, unique password per admin account, kept in a password manager
• Two-factor authentication (2FA) on every administrator login – this single free measure defeats the entire password-guessing category
• Delete stale admin accounts. Every account is a door; a departed contractor’s forgotten admin login is a door nobody’s watching. We routinely find 5+ admin accounts on sites run by two people.

3. No firewall, nothing filtering the door traffic

A web application firewall (WAF) filters malicious requests before they reach WordPress: exploit attempts, brute-force login floods, known bad actors. This is one plugin (or a host/DNS-level service) and it’s the measure that buys you time when door #1 is briefly open, many firewalls block exploitation attempts for freshly disclosed vulnerabilities before you’ve had a chance to update.

4. No malware scanning, a break-in nobody notices

Compromises aren’t loud. The profitable ones are silent: SEO spam injected into your pages, redirect code that only triggers for Google visitors, a phishing kit parked in a subdirectory. Sites run compromised for months while looking normal to the owner. Regular malware scanning, and someone who actually reads the scan results turns “months” into “days.” The damage difference is enormous: early detection is a cleanup; late detection is a cleanup plus blacklisted domain, poisoned search results, and burned customer trust.

5. SSL and forced HTTPS, the minimum the world now expects

By 2026 this is nearly universal, but “we have a certificate” is not the same as “everything is forced through HTTPS.” Mixed-content sites and non-redirected HTTP variants still turn up in audits, and they cost trust (browser warnings) and SEO. Certificates are free (Let’s Encrypt); there is no excuse tier anymore.

The noise: popular advice that barely matters

In fairness-to-your-time order, things checklists love that bots don’t care about:

• Hiding your WordPress version. Bots don’t check your version and politely leave, they fire exploits at everything. Patched is protected; hidden is not.
• Renaming the login URL. Mild spam reduction, zero protection against the actual causes above. 2FA does this job properly.
• Country blocking. Attacks come through proxies and hijacked servers everywhere, including your own country.
• Multiple security plugins. Two firewalls don’t make you twice as safe; they conflict, slow the site, and double the false alarms. One good one, configured, beats three installed.

None of these are harmful (except the plugin stacking). They’re just where paranoia goes to feel productive while door #1 stands open.

The honest small-business security checklist

The complete version, printable:

1. ☐ Everything updated promptly (core, theme, plugins, PHP) — tested on staging
2. ☐ Unique passwords + 2FA on all admin accounts; stale accounts deleted
3. ☐ One firewall, configured
4. ☐ Malware scanning that a human reviews
5. ☐ SSL with forced HTTPS everywhere
6. ☐ And — tested, off-site backups, because security is what you do before an incident; backups are why an incident isn’t fatal

If maintaining that list sounds exactly like the ongoing work you didn’t want to own: that’s what a care plan is, doors 1 through 5, handled continuously, reported monthly. Across the sites under our care, we’ve had zero successful compromises in over 5 years.

Find out which doors are open on your site

Our free WordPress Health Check covers security as one of seven scored areas, including exactly the five doors above, checked with evidence. You get the report either way; what you do with it is up to you.

Request the free Health Check →

Almost every website owner we audit says the same sentence: “Backups are handled, they’re included with my hosting.” It’s said with complete confidence, and it’s the single assumption most likely to cost a business its website.

Host backups are real, and having them is better than not. But “included backups” and “a backup strategy” are different things, and the difference only becomes visible on the day you need to restore – which is the one day you can’t afford to learn it.

Hosting companies often don’t explain clearly what they offer with what package. A client came to us recently who thought she had daily hosting backups, only for us to see that her hosting provider offered backups as an option on a more expensive tier. Luckily, we caught this in time, before she needed those backups, but it was a catastrophe waiting to happen.

What host backups actually are

When a hosting plan says “daily backups included,” here is what that typically means in practice:

• A server snapshot, on the same infrastructure. Often stored on the same physical machine or, at minimum, the same provider. If the server dies, is compromised, or the account is suspended over a billing dispute, the backup can go with the site.
• A short retention window. 7 days is common on shared hosting; sometimes 14 or 30. Problems that go unnoticed longer than the window, and hacked sites routinely go unnoticed for weeks, mean every stored backup is a backup of the compromised site.
• Restores nobody has ever tested. The backup exists as a file. Whether it restores into a working website: correct database, correct file permissions, correct WordPress URLs – is unknown until someone tries. Corrupt and partial backups are discovered at restore time, by definition.
• Sometimes, not actually daily. Read the fine print: some hosts back up “periodically”, exclude databases above a size limit, or exclude the database entirely from “file backups”. Your WordPress content: every post, page, order, and form entry lives in the database.

None of this makes hosts dishonest. Backups are a checkbox feature priced into a $10/month plan; treating them as a business-continuity system is the customer’s mistake, not the host’s lie.

What can actually take your site down

A backup strategy is designed against failure modes. The realistic list:

1. A bad update – the most common. You need a restore point from hours ago, not last week.
2. A hack – needs retention reaching back before the compromise, which is often 30+ days back.
3. Server/host failure – needs a copy stored somewhere that isn’t the host.
4. Human error – deleted the wrong page, broke the theme. Needs granular, recent restore points.
5. Account-level problems – billing disputes, suspended accounts, a host going out of business. Needs a copy you control.

Host backups reasonably cover #3 and partially #4. They routinely fail #1 (too coarse), #2 (retention too short), and #5 (the copy lives with the account).

The 3-2-1 rule, translated to WordPress

The old sysadmin rule says: 3 copies of your data, on 2 different types of storage, 1 of them off-site. For a WordPress business site, that translates to:

Copy	Where	Covers
1. The live site	Your host	This is the thing being protected
2. Host backups	Same host	Quick rollbacks, server-side restores
3. Independent off-site backup	Cloud storage you or your maintainer controls (Google Drive, S3, Dropbox…)	Everything else – including the host itself failing you

Plus two properties that matter as much as the copies:

• Retention with history – daily points for the recent past, plus older points reaching back 30+ days, so a slow-burn problem can be rewound past its start.
• Tested restores. A backup is not real until it has been restored somewhere and produced a working website. This is the step virtually nobody does, and it’s the entire difference between “we have backups” and “we can recover.” We use LocalWP to set up your website instance on our local machine, where we can safely test backup files before doing it on the live site.

The uncomfortable audit – five minutes, right now

Answer these about your own site. “I don’t know” counts as “no”:

1. If your site vanished this second, how old is the copy you’d restore – hours, or days?
2. Is at least one copy stored completely outside your hosting account?
3. How far back can you go? Past 30 days?
4. Does your backup include the database (not just files)?
5. Has anyone, ever, test-restored one of your backups and confirmed the result works?

Five yes answers: genuinely rare – you’re in great shape. Three or fewer: your website’s continued existence currently depends on nothing going seriously wrong. In our experience, 4 out of 5 websites do not have a proper backup strategy implemented.

What this costs to fix

The honest news: this is one of the cheapest serious problems to solve. Independent backup plugins with off-site storage cost $0–100/year; cloud storage for a typical site is a few dollars a month; the setup is an afternoon. The part that doesn’t come in a plugin is the discipline – the off-site copies being verified, the restore being tested periodically, someone noticing when backups silently stop running (they do).

That discipline layer is part of every one of our care plans – off-site backups with retention, restore drills included. But whether it’s us, another provider, or your own afternoon with a backup plugin: close this gap this month. It’s the highest ratio of catastrophe-prevented to money-spent anywhere in WordPress.

Not sure where your site actually stands? The free Health Check audits your backup situation as one of its seven areas — including the questions above, answered with evidence instead of assumptions.

Request the free Health Check →

If you’re reading this with a broken website open in another tab: skip to the recovery steps below, they come first. The explanation of why this keeps happening can wait until your site is back.

Updates are the most common way working WordPress sites break. Not hackers, not hosting failures. Routine Tuesday update to a plugin, a theme, or WordPress core that conflicted with something else on the site. It’s so common that preventing exactly this is half the reason professional maintenance exists.

Last month a site came to us where an Elementor page builder update had silently broken the home page because of a version mismatch between PRO and standard Elementor; the owner found out three days later when a customer called. Ads running on an “empty” page, client ads budget wasted.

First: what “broken” looks like

Update failures usually show up as one of these:

• The white screen of death: a blank page, sometimes with a PHP error. Usually a fatal code conflict between the updated component and something else.
• “Briefly unavailable for scheduled maintenance”: stuck maintenance mode. The update was interrupted halfway; WordPress left its lock file behind.
• The site loads but looks wrong: broken layout, missing styles, weird spacing. Typically a theme update overwrote customizations, or a caching plugin is serving stale CSS against new HTML.
• Something specific stopped working: forms don’t send, checkout errors, images missing. The subtlest and most expensive kind, because nobody notices immediately.

Recovery, in the right order

1. Don’t keep clicking update on other things. The instinct to “update everything else and hope” compounds the problem and destroys the evidence of which change caused it.

2. Restore the backup, if you trust it. If you have a backup from before the update and you know it works, restoring is almost always faster than debugging. This is also the moment many owners discover their “backup” is six months old, stored on the same server, or was never actually tested. If that’s you, don’t restore blindly: a bad restore can make things worse.

3. No backup? Roll back the component. If you know which update broke things, the previous version of most plugins can be reinstalled from its own changelog/advanced view on WordPress.org, or via a rollback plugin, even if the admin still loads. Deactivating the suspect plugin via FTP (rename its folder in wp-content/plugins/) is the classic move when the admin is unreachable.

4. Stuck in maintenance mode? Delete the .maintenance file in the site root via FTP or your host’s file manager. Thirty-second fix.

5. Check the actual error. Enable WP_DEBUG_LOG in wp-config.php (never display errors on a live site) and read what PHP is actually complaining about. The error names the file, the file names the culprit.

6. If any of the above feels out of your depth, stop. Half of the rescue work we do is not fixing the original problem; it’s untangling the fixes that were attempted on top of it. Client came to us a few months ago after a junior developer tried to update plugins without checking the PHP version first. Instead of 15 minutes of work, we had a few hours of untangling to do.

Why this keeps happening

Here’s the part nobody explains to site owners. WordPress is an ecosystem: your site is WordPress core plus a theme plus typically 15–30 plugins, each written by a different team, each updating on its own schedule, each tested against WordPress, but not against each other, and never against your exact combination. Every update is a small compatibility experiment, and your live site is the laboratory.

Most updates are fine. But “most” multiplied across a couple hundred updates a year means a broken site is not bad luck, it’s a statistical certainty on a long enough timeline. The only question is whether the breakage happens somewhere safe or in front of your customers.

The boring solution: break the site where nobody can see it

The professional answer is unglamorous: test every update on a staging copy first.

A staging site is a private clone of your live site. Updates are applied there, checked: pages render, forms send, checkout completes and only then applied to the real site. When an update is going to break something, it breaks on the copy. Nobody outside ever knows.

This is the single clearest line between real maintenance and “auto-updates enabled” and it’s precisely what auto-updates can’t do, because auto-updates apply changes directly to production and no one looks at the result. Automated hosting maintenance has the same blind spot: it can apply updates, but it cannot notice that the mobile menu is now broken.

Across the 40+ sites we maintain, staging catches a breaking update roughly every few months. Updates that would each have been a live incident.

What a proper update routine looks like

For readers who want to do this themselves, this is the checklist, and it’s the same one we run:

1. Verified, off-site backup taken before anything is touched
2. Updates applied on staging, never live first
3. Visual + functional check: key pages, checkout, mobile menu
4. Updates promoted to live, same-day
5. Post-update check on live (caches purged, forms re-tested)
6. It’s written down: what was updated, what was blocked and why

Time cost: 30–90 minutes per site per cycle, done properly. That’s the honest reason maintenance costs money, and the honest reason “free” maintenance so often means “no maintenance.”

If your site is broken right now and you want it handled

We take over broken and half-recovered WordPress sites as a fixed-scope rescue: diagnose, restore or repair, then harden so the same failure can’t repeat. You’ll get a plain-English explanation of what happened. No blame, no jargon. And if you’d rather never think about updates again, that’s literally what our care plans are for: staging-tested updates on every site, every cycle.

Not broken, just worried? Start with the free Health Check. It will tell you, among other things, whether your backup would actually save you and how much update debt your site is carrying.

Request the free Health Check →

Most WordPress disasters aren’t sudden. The hacked site, the white screen after an update, the checkout that silently stopped working. The story is the same in almost every rescue we’ve done: the warning signs were visible for months; it’s just that nobody was watching.

Here are seven signs you can check yourself, today, in about ten minutes. No technical skills required!

1. You don’t know when your site was last backed up

Ask yourself one question: if my site disappeared right now, who would I call, and what would they restore? If the answer involves the word “probably,” you don’t have a backup; you have a hope. A real backup setup means daily copies, stored off your hosting account (if your host has a bad day, backups stored with them go down too), and the part that almost everyone skips, occasional test restores. A backup you’ve never restored is untested equipment you’re betting your business on.

2. The plugin update count keeps growing

Log in to your WordPress admin dashboard and look at the number badge next to “Plugins.” Five pending updates is a normal week. Fifteen-plus that have been sitting for months is update debt. Old plugins are the number one way WordPress sites get hacked, because every published update is also a public announcement of the hole it fixed. Attackers automate scanning for sites that haven’t been patched. The longer you wait, the bigger the version jump when you finally update, and big jumps are exactly when things break.

3. Your site was built by someone you can no longer reach

This might be the most common situation we see: the site works, but the person who built it has moved on, and nobody has the keys, or the knowledge. Nothing is wrong yet. But you’re one bad update, one expired plugin license, one hosting migration away from needing someone who understands the site, urgently, with no documentation. If this is you, get a technical audit before something breaks. Handover under calm conditions is cheap; handover during an outage is not!

4. Pages take more than three seconds to load

Test your site right now at pagespeed.web.dev. This is Google’s own free tool. If your mobile score is in the red, you’re paying for it twice: visitors leave (half of mobile users abandon pages that take over three seconds), and Google ranks you lower, because speed is a confirmed ranking factor. Slow WordPress sites are usually slow for boring, fixable reasons: oversized images, too many plugins, no caching, cheap hosting. An afternoon of engineering routinely cuts load times by more than half.

5. There’s no padlock or mixed-content warnings

Look at your address bar. If your site shows “Not secure” instead of a padlock, that’s visible to every visitor and every search engine. Even with SSL installed, half-migrated sites often load some images over the old insecure connection (“mixed content”), which browsers increasingly punish. This is a solved problem in 2026; there is absolutely no legitimate reason for a business site to have it.

6. You’ve never seen a maintenance report

If you’re paying someone for “maintenance,” when did you last see proof? A real maintenance service sends a monthly report: what was updated, what was backed up, what security events occurred, how the site is performing. If the answer to “what did I get for last month’s fee” is silence, you might be paying for a service that isn’t happening or is not complete. Invisible maintenance and no maintenance look identical, that is, until the day they don’t.

7. Your contact form goes to an inbox nobody checks or spam folder

Submit your own contact form right now. Did the email arrive? In the inbox, or spam? WordPress’s default email sending is notoriously unreliable! Form notifications silently vanish more often than anyone realizes. Every lost submission is a customer who tried to reach you, failed, and called your competitor instead. This one costs real revenue and is completely invisible from the outside.

What to do with this list

If you checked all seven and everything passed, well done! Your site is in better shape than most. If two or more failed, your site isn’t broken, but it’s drifting toward the expensive kind of problem.

That’s exactly what our free written audit is for: send us your URL, and within two business days you’ll get a plain-English review covering all of the above and more: what’s solid, what’s risky, and what fixing it would take. No obligation, no sales call unless you want one.

Request your free audit →