Why small business websites get hacked

Almost no small business website is hacked by someone who chose it. It is found by a script that crawls the whole internet looking for one specific weakness, tries that weakness on every address it finds, and moves on. Your site was not a target. It was a match.

That changes what defence looks like. You are not trying to outwit an attacker who is interested in you. You are trying to stop looking like a match. Most of what makes a site match is visible from the outside, to anyone, and you can look at it yourself in about a minute.

What a stranger can learn from the street

Think of it as walking past a building. You cannot open the safe, but you can see whether the door is standing open, what brand of lock is on it, and whether the alarm sticker is from a company that closed in 2011.

Four things leak, in order of how useful they are.

1. Which software you run, and which version

Most content management systems announce themselves. WordPress publishes a generator tag in the page source and a readme.html at a predictable path. Themes and plugins load files from URLs that contain their name and, very often, a version number in the query string. A scanner reads those, compares them against a public vulnerability database, and knows within seconds whether you are running something with a published exploit.

This is the single biggest signal. Not because old software is always dangerous, but because a published vulnerability in a popular plugin is a recipe: the attacker does not need skill, only your address.

2. Files that were never meant to be reachable

The recurring ones are depressingly mundane, and every one of them is something a person left behind:

• Backup archives in the web root. backup.zip, site-old.tar.gz, a database dump named after the domain. Downloadable by anyone who guesses the name, and the names are guessable.
• Configuration and environment files. A .env file containing database credentials and API keys, served as plain text because the server has no rule saying otherwise.
• Exposed version control. A .git directory left in the web root lets someone reconstruct your entire source code, including every secret ever committed and later removed.
• Directory listings. An uploads folder with no index file that cheerfully prints everything inside it.
• Test and staging copies. dev.yourdomain.com.au running a year-old snapshot with debugging on and no maintenance.

3. Missing security headers

Headers are instructions your server sends with every page, telling the browser how to behave. They cost nothing and they are frequently absent. The ones that carry weight, all documented by Mozilla on MDN:

• Strict-Transport-Security tells the browser to only ever connect to your site over HTTPS, and to convert any plain HTTP attempt automatically. Without it, the first request a visitor makes can be intercepted.
• Content-Security-Policy controls which sources the browser is allowed to load scripts and other resources from. It is the strongest defence against cross-site scripting, and it is the one that takes real work to get right.
• X-Content-Type-Options: nosniff stops the browser guessing a file’s type from its contents rather than trusting the declared type, which is how an uploaded file gets executed as a web page.
• Referrer-Policy limits how much of the address a visitor came from is passed to third parties.

Missing headers do not get you hacked on their own. They decide how far a problem spreads once something else goes wrong, and they are a very good proxy for whether anybody is looking after the site at all.

4. Doors that should not be open to the public

Admin login pages reachable from any address on earth, with no rate limiting and no second factor. Database administration tools installed at a guessable path. Directory listings on a folder holding client documents. File upload endpoints that accept anything.

Why it keeps being the same handful of causes

The OWASP Top 10, the industry’s standard list of application security risks, was updated in 2025. Two of its categories describe most small business website compromises on their own: A02:2025 Security Misconfiguration and A03:2025 Software Supply Chain Failures, which covers the components you did not write and do not control.

That second one deserves a moment. A typical small business site is perhaps five per cent code written for you and ninety five per cent other people’s work: a content management system, a theme, and somewhere between ten and forty plugins. Every one of those is an independent project maintained by a stranger, on their own schedule, with their own view of what a security release is. Some are abandoned entirely and stay installed for years.

You did not choose that risk. It arrived with the convenience.

What actually happens when a small site is compromised

The popular image is data theft, and it does happen, but far more often the site is simply taken and put to work. The common outcomes:

Spam pages. Hundreds or thousands of new pages are injected, usually selling pharmaceuticals, counterfeit goods or gambling, hidden from you and served only to search engines. The first symptom is usually a customer mentioning that your business comes up in Google attached to something embarrassing.

Redirects that only fire for strangers. The site behaves perfectly when you visit it, because the injected code checks for a login cookie or a known address and skips you. Meanwhile visitors arriving from search get sent somewhere else entirely. This is why “it looks fine to me” is not evidence.

Mail relay. Your server is used to send bulk spam. The consequence lands weeks later when your domain is on blocklists and your ordinary business email stops arriving.

A quiet foothold. A small file is left behind to keep access open. Nothing visible changes for months, and if you clean up the obvious damage without finding that file, you are compromised again by the same person.

Google flags you. Once Search notices, you get a warning in Search Console and potentially an interstitial in Chrome telling visitors the site may be harmful. Getting that removed is a review process, not a switch, and the traffic does not come back the day the flag clears.

What to do this week

In the order that removes the most risk for the least effort:

1. Run the scan and read the whole list, not just the red items. Note anything that reveals a version number.
2. Delete what is not in use. Every deactivated plugin, old theme, forgotten staging copy and stale backup archive is a door with nobody watching it. Deactivated is not removed; the code is still on disk and often still reachable.
3. Get updates onto a schedule with a backup in front of them. People avoid updating because they fear an update will break the site, and that fear is rational. The answer is a tested backup and a place to try the update first.
4. Put a second factor on every admin login and stop sharing one account between people.
5. Add the headers. They are a server configuration change, usually an afternoon, and they never need touching again.
6. Have someone watch for changes. The value is not in blocking every attack. It is in noticing on day one instead of month three, because cleanup cost scales with how long it sat there.

When a site is past patching

Sometimes the honest answer is that a site cannot be made safe at a sensible price: a theme whose author vanished in 2017, plugins with no maintained replacement, a custom build nobody can explain. Patching that is money spent to arrive back where you started.

That is the case where a rebuild is the cheaper option, and it is what our rebuilds and rescues work is for: getting the content and the search equity out, and putting them on something with a much smaller surface to attack. If you are unsure which situation you are in, run the Security Scanner first. The report will usually make the answer obvious.