Security
Why small-business websites get compromised
Why small business websites get hacked: almost never a targeted attacker, almost always automated software finding an already-patched weakness left open.
A small business’s website is very rarely the target of a person deliberately choosing to hack it. It is far more commonly the target of automated software, running continuously across the whole internet, that finds a specific and already-known weakness and walks through it without a human ever making a decision about that particular site. Understanding that distinction changes what cyber security defence actually looks like — not a countermeasure against a determined adversary, but the removal of the specific, ordinary things that software is scanning for.
Out-of-date software is the largest single cause of a website getting hacked
A CMS core, a theme, or a plugin with a known, publicly disclosed vulnerability is the single most common route into a hacked, compromised small-business site. Vulnerabilities are disclosed publicly, a fix is released, and from that point on, every installation that has not applied the fix is a known, searchable target rather than a hidden one — automated scanning tools exist specifically to find sites still running the vulnerable version at scale. This is why software updates and website security treats an update as a security control rather than routine housekeeping; the update is very often the entire defence against a specific, already-public weakness.
Weak or reused passwords are the second, and the route criminals try first
Automated tools attempt large numbers of common passwords, and separately, credential lists leaked from unrelated services elsewhere on the internet get tried against admin login pages wholesale, on the reasonable assumption that some fraction of people reuse passwords across sites — the same cybercrime tooling that runs this at scale is what most cyber security advice for small business is actually written to defeat. An admin account with a weak or reused password is functionally an open door, regardless of how well-maintained the rest of the site is. Passwords, accounts and who has access covers what actually closes this specific route.
Abandoned or unnecessary plugins
A plugin installed once, used briefly, and never removed remains active code capable of being exploited whether or not it is doing anything visible. A plugin whose developer has stopped maintaining it entirely — common across large plugin ecosystems — stops receiving security fixes even as new vulnerabilities in it are discovered and disclosed, turning it into a permanent, unpatchable weak point unless it is removed.
Compromised third-party credentials, and what the attackers actually want
Access to a hosting account, a CMS admin account, or a developer’s own machine can be compromised somewhere entirely outside the website itself — a phishing email, a reused password on an unrelated breached service, a stolen laptop — and used to reach the site through a legitimate login rather than a technical attack at all. What the hackers who buy or trade this access are usually after is not the small business’s own money directly: a compromised site more often becomes infrastructure for spam, malware distribution to its visitors, or a ransomware staging point, than the target of a direct ransom demand itself. This is why access control, covered in who holds the keys to your website, is a security question and not purely an operational one.
What is genuinely rare, and what a website hacked this way actually looks like
A sophisticated, targeted attack against a specific small business, custom-built to defeat its particular defences, is a real category of threat and it is overwhelmingly not what happens to an ordinary small-business site. Almost every real-world compromise this cluster is written to help prevent is opportunistic rather than targeted — which is the actually useful news, because opportunistic threats are defeated by ordinary, unglamorous maintenance rather than by anything sophisticated.
A short table of cause and the page that addresses it
| Cause | What actually prevents it |
|---|---|
| Unpatched known vulnerability | Software updates and website security |
| Weak or reused admin password | Passwords, accounts and who has access |
| Abandoned or unnecessary plugin | Regular review and removal, as part of maintenance |
| Compromised third-party access | Who holds the keys to your website |
What this means practically
Almost nothing on this list requires a sophisticated defence. It requires a schedule: updates applied, unused plugins removed, passwords strong and unique, and access reviewed periodically rather than granted once and forgotten. That is not a comforting answer if what is wanted is a single product that solves the problem, but it is the honest one, and it is why maintenance and this security section overlap as heavily as they do.
Why a business’s own habits matter as much as its supplier’s
Even a well-built, well-maintained site can be compromised through a phishing email that tricks a staff member into revealing a password, or a personal device used to access the site’s admin panel becoming infected with malware. Security is not solely a technical property of the software — it is also a set of human habits, and a business that trains staff to recognise a phishing attempt and to avoid accessing sensitive accounts from unsecured personal devices closes a category of risk no amount of software patching addresses.
Why this list should not produce fatalism
Reading a list of causes can feel discouraging, as though compromise is inevitable regardless of what a business does. The opposite is true: because the overwhelming majority of real incidents trace back to this short, ordinary list, closing all of them meaningfully changes a site’s actual risk profile, even though nothing can reduce risk to literally zero. Effort spent here is effort well spent, not effort wasted against an unwinnable problem.
Where to go from here
Whether the infrastructure a site sits on is pulling its own weight in this defence, and where that layer’s responsibility actually ends, is set out in hosting-level protections. And confirming a supplier is actually doing this work, rather than assuming it, is worth putting directly as security questions to ask a supplier.
Evidence for this page
This page exists because the demand below was measured, not assumed. The figures are search-market data about the topic — they are not prices.
- Entity this page targets
- why do small business websites get hacked
- Measured Google volume
- no data
- Keyword difficulty
- no data
- Advertiser cost per click
- no data
- AI assistant volume
- no data
- Advertiser competition
- no data
- Measured on
- 3 August 2026
- Search results inspected for intent
- No
Source: research/outer-volume-au.json · DataForSEO Google Ads search_volume and Labs bulk_keyword_difficulty, location_code 2036 (Australia), language en · pulled 3 August 2026.
Provenance
Written by Australian Website Design. Published 2026-08-03, last updated 2026-08-03.
Sources
- Outer-cluster demand measurement (this site) —
research/outer-volume-au.json