Guides9 min read

Website Security Basics Every Founder Should Know (Before Something Goes Wrong)

Most small business websites that get compromised aren't targeted by anyone. They're found by automated bots scanning the internet for outdated software, and they're broken into because of five preventable things: an unpatched CMS or plugin, a weak or reused admin password with no two-factor authentication, no working backup to restore from, no one watching for anything unusual, and too many people holding admin access long after they needed it. That's the actual list. There's no hoodie, no genius, no targeted attack — just neglect, found by a script.

This matters because the fix is boring, cheap, and almost entirely a matter of habit rather than budget. You don't need a security team. You need updates applied on a schedule, unique passwords with 2FA on anything that can log in, backups that are actually tested, HTTPS configured correctly, admin access kept tight, and someone checking that nothing looks wrong. This guide walks through each one, plus what actually happens when a site does get compromised — because it's rarely dramatic, and that's exactly why it goes unnoticed for months.

Why most small business sites get hacked (it's rarely sophisticated)

Attackers don't sit down and pick your business. They run automated scanners across huge blocks of the internet looking for websites running a known-vulnerable version of a CMS, a plugin, or a server component — the kind of vulnerability that gets published publicly the moment a patch is released, because the patch notes themselves describe the hole it fixes. If your site is still running the old version a week later, it's now a documented target, and the scanner finds it in seconds. No one is reading your "About" page first. The bot doesn't care what you sell. It cares whether your software is current.

That's the uncomfortable part for founders who assume they're too small to be worth attacking. Size has nothing to do with it. A five-page brochure site on an old CMS install is a more attractive target than a well-defended enterprise platform, because it's easier. Attackers optimize for effort, not prestige. A neglected small business site is exactly the kind of low-effort, high-yield target automated tools are built to find.

What actually happens when a site gets compromised

It's almost never a defaced homepage or a ransom note — that would get noticed and fixed in a day. The far more common outcome is quiet: an attacker plants hidden spam links or redirect scripts deep in your site's pages, invisible to a normal visitor, and uses your domain's existing search authority to push pharmaceutical spam, gambling links, or malware downloads. Your site keeps looking completely normal to you and your customers while it's doing this in the background.

Search engines, however, do notice. When Google's crawler indexes those injected pages, one of two things tends to happen: your rankings quietly collapse as the algorithm devalues a site that appears to be part of a spam network, or the site gets flagged outright with a security warning in search results and browsers, which is about as effective a way to stop new visitors as taking the site offline. Either way, by the time you notice — usually because traffic dropped, not because anything looked broken — the compromise has often been running for weeks or months. That delay is the real damage. A breach caught on day one is an afternoon of cleanup. A breach caught on day ninety is a rebuild of trust with both Google and your customers.

A breach doesn't cost you the day it happens. It costs you the months no one noticed.

The six basics that prevent almost every compromise

01
Keep the CMS, plugins, and dependencies updated
Most compromises exploit a known vulnerability that was already patched — the site just never got the update. Set a recurring schedule (weekly for security patches, monthly for everything else) instead of updating reactively whenever someone remembers.
02
Use strong, unique passwords and 2FA on every admin account
A reused password from some other breached service is often the actual entry point, not the CMS itself. A password manager plus two-factor authentication on every account with admin or publishing access closes most of that door on its own.
03
Run real backups, and actually test restoring from them
A backup you've never restored from is a hope, not a plan. Automate backups on a schedule that matches how often your content changes, store them somewhere separate from the live server, and restore one to a test environment at least twice a year to confirm it actually works.
04
Use HTTPS/SSL correctly, sitewide
HTTPS encrypts the connection between a visitor's browser and your server, so passwords, form submissions, and payment details can't be read or altered in transit. It doesn't stop your site from being hacked, but without it, browsers actively warn visitors your site is "not secure" — which kills trust before anyone reads a word.
05
Limit who has admin access, and remove it the day someone leaves
Every extra admin account is another password that can be weak, reused, or forgotten. Give people the lowest level of access that lets them do their job, and treat removing access as a mandatory step the same day a contractor or employee relationship ends — not a cleanup task for later.
06
Remove or replace abandoned plugins and third-party scripts
A plugin the developer stopped maintaining two years ago will never get patched again, no matter how many new vulnerabilities are found in it. If something on your site hasn't been updated in over a year, assume it's a liability and either replace it or remove it.

Passwords and access: the boring stuff that actually matters

Password hygiene sounds too basic to be worth writing about, which is exactly why it keeps working against small businesses. A weak or reused admin password isn't a hypothetical risk — credential lists from unrelated breaches circulate constantly, and automated tools try them against thousands of admin login pages without any human involved. Two-factor authentication is the single highest-leverage fix here: even a leaked password becomes useless without the second factor, and it takes minutes to turn on for most CMS platforms and hosting dashboards.

Access sprawl is the quieter version of the same problem. Every agency, freelancer, and past employee who ever got an admin login is a standing risk if that access was never revoked. It's not usually malicious — it's just an account nobody remembers exists, sitting there with full publishing rights and a password set years ago. A once-a-year audit of who actually has access to your site, hosting, and domain registrar catches this before it becomes a problem instead of after.

Backups: the difference between an incident and a disaster

This is the basic that turns a bad afternoon into a bad quarter when it's missing. If your site gets compromised and you have a recent, tested backup, the fix is straightforward: identify when the breach happened, restore to a clean version from before that point, patch whatever let the attacker in, and you're back online in hours. If you don't have a working backup, you're rebuilding from scratch, negotiating with a hosting provider, or paying a specialist to reconstruct what you can from whatever's left — while your site sits down or compromised the entire time.

The word "tested" is doing real work in that sentence. Plenty of backup systems run silently for years, technically saving files nobody ever confirms are complete or restorable. The only way to know a backup actually works is to restore it somewhere and check. Do that on a calendar reminder, not "whenever we think of it."

HTTPS and what it actually protects

It's worth being precise about what an SSL certificate does, because the marketing around it tends to overstate it. HTTPS encrypts data moving between a visitor's browser and your server — so a login form, a checkout page, or a contact form can't be intercepted or tampered with by someone sitting on the same network. That's genuinely important, and it's also table stakes now: browsers flag any non-HTTPS site as "not secure," and search engines factor it into ranking.

What HTTPS does not do is protect your site from being hacked. It doesn't patch a vulnerable plugin, stop a weak password from being guessed, or prevent spam injection. It's one basic among several, not a security program on its own — which is exactly the misunderstanding that leads founders to think "we have the padlock icon, we're covered" and stop there.

Monitoring: knowing before your customers tell you

The gap between a compromise happening and someone noticing is where almost all the real damage occurs. Basic monitoring closes that gap without requiring a security team: uptime monitoring that alerts you if the site goes down or redirects unexpectedly, malware scanning that checks your pages against known threat signatures, and keeping an eye on Google Search Console's security issues report, which will flag injected spam or malware Google has detected on your site — often before a human would ever spot it by browsing normally.

None of this needs to be expensive or constant. A weekly scan and a security-issues check once a month catches the overwhelming majority of problems while they're still small, quiet, and cheap to fix — instead of three months in, when a customer emails asking why your site tried to download something onto their laptop.

A basic incident plan you can write in twenty minutes

Most founders never think about what happens if the site gets compromised until it happens, which is the worst possible time to figure it out. A short, written plan — even five bullet points in a shared doc — turns a panic into a checklist.

Who gets called first: your host's support line, your developer, or both — with contact details saved somewhere other than the compromised site itself.
Where the most recent tested backup lives, and who has the access needed to restore it.
A step to immediately reset every admin password and revoke active sessions, not just the one account you suspect.
A plan to request re-review from Google Search Console once the site is clean, so a security warning doesn't linger after the problem is fixed.
A short, honest note ready to send to customers if the compromise touched any of their data — decided calmly in advance, not drafted in a panic.

Security is a maintenance habit, not a one-time project

None of the six basics above are exotic, and none require a specialist to implement. They require someone to actually own them on an ongoing schedule — because a site that was secure at launch and untouched for two years is not a secure site, it's a site that hasn't been checked yet. That's the pattern behind almost every compromise we've seen: not bad initial setup, but good initial setup with no one responsible for maintaining it afterward.

This is also why security tends to fall through the cracks between founders who assume their developer is handling it and developers who were only ever hired to build the site, not maintain it indefinitely. If that's the situation you're in, it's worth asking directly, this week, who is actually responsible for updates, backups, and monitoring on your site — before you find out the answer was no one. At Serenity Labs, this is built into how we run every site we build and maintain, so our clients don't have to think about it until we bring something to their attention. If you'd rather that be true for your site than hope it already is, that's a conversation worth having before something goes wrong, not after.