Nobody chose your website.
A bot found it. That is the whole story for most small business hacks. Software crawls the internet looking for one specific broken thing, finds your site sitting among ten thousand others with the same broken thing, and takes it. Nobody read your About page first. Nobody decided you were worth it.
The Australian Signals Directorate puts the average self-reported cost of a cybercrime report to a small business at $56,600 for FY2024 to 2025, up 14 percent in a year. Medium businesses: $97,200, up 55 percent. (ASD Annual Cyber Threat Report 2024 to 2025)
This piece has two halves. First, what actually breaks sites, ranked by how often it does it. Second, what to do about it, ordered by how much risk each hour of your time removes. If you already know you are exposed and just want the list, skip to Fix it in this order.
What actually gets small sites taken, in order
Most security guides list threats alphabetically, or in whatever order made the article reach eighteen items. Here is the order that matches reality.
1. A plugin you installed once and forgot
Patchstack runs the largest vulnerability database for the WordPress ecosystem. In 2025 they logged 11,334 new vulnerabilities across that ecosystem, a 42 percent jump on 2024. 91 percent were in plugins. Nine percent were in themes. Six were in WordPress core. (Patchstack, State of WordPress Security in 2026)
Read that again. Six. The core software is not your problem. The thirty pieces of other people's code you bolted onto it are.
And it is the old holes that get you. Of the ten vulnerabilities attackers hit hardest during 2025, only four were published in 2025. The rest had been patched, some of them years earlier, and were still landing hits because the sites they landed on had never been updated.
One more number from the same report, and it is the uncomfortable one: 46 percent of vulnerabilities had no fix from the developer by the time they went public. Updating on time is necessary. It is not sufficient.
2. A password that works somewhere else too
Verizon's 2025 Data Breach Investigations Report is built on 22,052 security incidents. Credential abuse is still the single most common way in. In the pattern Verizon calls Basic Web Application Attacks, the get in, take the data, get out pattern, about 88 percent of breaches involve stolen credentials. (Verizon 2025 DBIR, SMB Snapshot)
Stolen. Not guessed. Somebody else got breached, your email and password went into a list, and the list got tried against your login because you used that password twice.
3. Somebody phishes you, not your site
Automated does not mean nobody is involved. Verizon puts a human element in roughly 60 percent of breaches. The scan is a machine. The mistake it exploits is usually a person's.
Your site does not need a single flaw if you can be talked into typing your hosting password into a page that looks exactly like your host's login screen. That page took four minutes to build.
4. Something you stopped using but never removed
The staging copy still sitting at /old. The plugin you deactivated instead of deleting, whose code is still on the server. The contractor account from 2023 that still has full admin. The abandoned subdomain pointing at a service you cancelled.
None of this is exotic. All of it is scanned for, constantly, by the same bots.
5. Your supplier's breach becomes your breach
Verizon found third-party involvement in breaches doubled year over year, from 15 percent to 30 percent. In the same report: the median time to remediate a leaked secret discovered in a public GitHub repository was 94 days. Three months of a working key sitting in the open.
You did not do anything wrong. The plugin vendor did, or the agency did, or the payment integration did. You still wear it.
It is not personal. It is a bot
Patchstack measured the gap between a vulnerability going public and the first real attempt to exploit it. The weighted median for heavily exploited flaws: five hours. About half of high-impact vulnerabilities see exploitation within a day of disclosure.
Five hours. You cannot beat that with a person and a maintenance window. Nothing about that scan is aimed at you, which is the reassuring part and the useless part at the same time. "We are too small to be a target" was never a defence, because nobody is choosing targets.
While we are here, kill the other comfortable line. Patchstack ran two pentests against the security setups of popular web hosts. Common defences blocked 12 percent of WordPress-specific vulnerability attacks in the first study, and 26 percent of a broader set in the second. So "my host handles security" is worth about a quarter. Useful. Not a plan.
What it actually costs you
Money. $56,600 on average for an Australian small business, per the ASD figures above. That is the reported cost, which means it excludes everyone who quietly ate it.
Everything stopping. Verizon found ransomware present in 88 percent of breaches at small and medium businesses, against 39 percent at large organisations. Big companies have people whose job is this. You have a Tuesday.
Google. This is the one that gets underweighted everywhere and it should not be. Google's Safe Browsing systems discover thousands of new unsafe sites every day, and Google says plainly that many of them are legitimate websites that have been compromised. (Google Safe Browsing Transparency Report)
When you land on that list, your site gets a full red warning page in Chrome, Safari and Firefox, and a warning next to your name in search results. For a business that gets work from search, that is worse than the hack. The malware gets cleaned in a day. The ranking does not.
Fix it in this order
Ordered by risk removed per hour spent. Do them top to bottom and stop when you run out of time. You will still have done the parts that matter.
1. Passkeys or MFA on every admin login. Fifteen minutes. Hosting, domain registrar, site admin, and the email address that can reset all three. This one control removes most of items 2 and 3 above. Nothing else on this list comes close.
2. Delete what you do not use. Thirty minutes. Every deactivated plugin. Every old theme. Every user who left. Every staging copy. If you are not sure whether something is in use, that is a strong signal it is not.
3. Make updates automatic, or somebody's actual job. Thirty minutes to set up. Turn on auto-updates for plugins and themes. If a plugin is too fragile to auto-update, you have found your real problem: a fragile plugin.
4. Cut the plugin count. One hour. Every plugin is another vendor you are trusting to write secure code and ship a patch quickly. Nearly half of them will not have the patch ready when the flaw goes public. Twelve plugins is twelve suppliers.
5. A backup you have actually restored. One hour. Off the same server, and tested. An untested backup is a feeling, not a backup. Restore it somewhere once and you will find out in a comfortable hour instead of a terrible one.
6. Separate the accounts. Thirty minutes. Your day-to-day login should not be an administrator. Neither should the plugin that only needs to publish posts.
7. Then SSL.
Here is the honest bit. Every major security guide in this category leads with SSL. Bluehost gives it a quarter of the page. It is first on the list at UpGuard, first at Quicksprout.
SSL is free, automatic, and almost certainly already on. It encrypts traffic between your visitor and your server, which matters. It stops nothing in the ranked list above. A site with a perfect certificate and an unpatched plugin gets taken exactly as fast as one without.
If a security guide opens with SSL, the guide is padding.
Passkeys, in plain words
The whole field is asleep on this. The category's most-cited reference guide was last updated in January 2024 and has multi-factor authentication as a clause inside a section about passwords. The number one ranked article on the topic gives passkeys twenty-four words.
Here is what a passkey is. It is a key stored on your phone or laptop, unlocked by your face or your fingerprint. Nothing gets typed, so there is nothing to reuse, nothing to write down, and nothing to steal from somebody else's breach.
The part that matters most: a passkey only works on the real website. A convincing fake login page can capture your password and the six-digit code you were texted. It cannot capture a passkey, because the browser refuses to hand one over to the wrong domain. That single property removes the entire phishing route.
This is not early technology any more. The FIDO Alliance reports 5 billion passkeys in active use, with 90 percent of consumers now familiar with them and 75 percent having enabled them on at least some accounts. (FIDO Alliance, The State of Passkeys 2026)
If your platform supports passkeys, turn them on today. If it does not, turn on app-based multi-factor authentication and stop using SMS codes wherever you have the choice.
Security headers, without the jargon
Three settings your site sends to the browser with every page. You do not need to understand how they work. You need to know they exist, so you can ask whoever runs your site whether they are on.
- HSTS. Tells the browser this site is only ever reachable over an encrypted connection. It must never quietly fall back to an unencrypted one.
- Content Security Policy. A list of the only places your page is allowed to load code from. If an attacker injects a script tag pointing at their own server, the browser refuses to run it. This is the one that turns a lot of successful injections into nothing.
- Frame protection. Nobody can load your site inside an invisible frame on their site and harvest your customers' clicks.
They cost nothing and take minutes. Paste your address into securityheaders.com and you will get a grade in about four seconds. If it comes back with an F, that is a conversation to have this week.
What actually shortens the list
Every item in the ranked section traces back to one thing: other people's code, running on your website, that somebody has to keep patched. Fewer of those, shorter list. That is architecture, not a product pitch.
So the useful question is not "is my site secure". It has no answer. The useful question is:
How many things on my site need patching, and who exactly is the person patching them?
Ask it of your current setup. Ask it of any agency pitching you. Ask it of us.
Our answer, since we are asking you to ask: the sites we build carry a low count of third-party components, and that count does not grow every time somebody wants one more feature. Every build runs a dependency scan in CI against known vulnerabilities. Patching sits on the plan, not on your Tuesday.
That is not immunity, and we are not going to dress it up as immunity. We run a database. Our subscription covers hosting, domains and integrations, so there is software on our side that needs patching too. The difference is the size of the list and whose calendar it lives on.
You have been hacked. Do this in the next hour
Four of the five biggest articles on this topic have nothing at all for this moment, which is strange, because it is the moment you will actually need one.
1. Do not delete anything yet. Not the files, not the logs. You need them to work out how they got in. If you clean before you know, you will be cleaning again next week.
2. Take the site down or into maintenance mode. This stops further damage to visitors and stops Google indexing the injected pages, which is the part that outlasts the hack.
3. Change every password, from a device you trust. Order matters: domain registrar first, then hosting, then the email account that can reset both, then the site admin. Revoke active sessions and rotate every API key. If your machine might be compromised, do this from a different one.
4. Restore from a backup dated before the first sign of trouble, then patch before you go back up. Restoring without patching puts you back on the internet with the same hole and a fresh invitation. The bot will be back within the day.
5. Ask Google for a review. Search Console, Security Issues, request review. Only once the site is genuinely clean, because a failed review costs you more time than waiting did.
6. Report it, and check your obligations. In Australia, report at ReportCyber. If customer data was exposed, check whether the Notifiable Data Breaches scheme requires you to notify the OAIC and the affected people. That is a legal clock, and it starts without asking you.
Five questions for whoever runs your site
Most of this list is not work you will do yourself. So here is the script for delegating it.
- What software on my site receives security updates, and who applies them?
- When did you last restore my backup somewhere to prove it works?
- Who has admin access right now, and can we delete two of them today?
- Is multi-factor authentication on for every admin login, including yours?
- If my site is compromised on a Saturday, what happens, how fast, and who pays for it?
Anyone who cannot answer 2 and 5 in a single sentence each is hosting your site. They are not managing its security. Those are different products and you may only be paying for one.
Where we stand, and when not to buy from us
We sell websites. Bespoke builds and templates, with hosting and care under both. That is a conflict of interest on an article like this one, so here is the straight version.
If your WordPress site works and it sells, do not rebuild it for security reasons. Cut the plugin count, turn on passkeys, buy a real maintenance plan from someone who answers question 5 above. A rebuild is an expensive answer to a problem that has a cheap one.
If you are compromised right now, we are not the call. We do not do incident response or malware cleanup. Get a specialist to clean it, get back online, and talk about rebuilding after, with a clear head.
If nobody at your business is ever going to log in and update anything, be honest about that. It is a real argument for a site with less to update, and it is a better argument than fear. It is a staffing decision wearing a security costume.
That is where the honest line sits. Everything above it is true whoever builds your site.
Building or rebuilding? Tell us what your business does and we will draw the site around it.
Questions people actually ask
Is WordPress insecure?
No. Six vulnerabilities were reported in WordPress core in all of 2025. The ecosystem around it produced 11,334. WordPress is not the risk. The number of third-party plugins you have installed is the risk, and that number is a choice you make.
How often do small business sites actually get attacked?
Constantly, and not on purpose. Automated scanners sweep the whole internet looking for specific known flaws. Patchstack measured a median of five hours between a vulnerability going public and mass exploitation beginning. Nobody picks you out. You just have to be findable and unpatched at the same moment.
Does an SSL certificate make my website secure?
It makes the connection between your visitor and your server private, which is worth having and is free. It does not stop an outdated plugin, a stolen password, a phishing email or a compromised supplier. Treat it as table stakes, not as a security measure.
Is my host taking care of this?
Partly. Patchstack's pentests of popular hosting providers found their defences blocked 12 percent of WordPress-specific vulnerability attacks in one study and 26 percent of a wider set in another. Ask your host, in writing, exactly which of the seven items in the fix list they perform.
What is the single highest-value thing I can do today?
Turn on passkeys, or multi-factor authentication if passkeys are not available, on your domain registrar, your hosting account, your site admin and the email address that can reset all three. Fifteen minutes, and it removes the most common way in.
Do I need a web application firewall?
It helps, and it is not a substitute for patching. Patchstack notes that broken access control, the most exploited class of WordPress vulnerability in 2025, is particularly hard for a firewall to catch because the traffic looks like a legitimate logged-in user. A firewall buys time. Only patching closes the hole.
My site was hacked and cleaned. Why is Google still warning about it?
Because Safe Browsing warnings are removed after a review, not automatically. Go to Google Search Console, open Security Issues, confirm the site is genuinely clean, and request a review. If any injected page or redirect survives, the review fails and you start the wait again.
Are template sites and custom builds different on security?
The build method matters far less than two things: how many third-party components run on the finished site, and who is contracted to patch them. A lean template that somebody maintains beats an expensive custom build that nobody has touched in two years. Ask both questions of whatever you are buying.
Sources, all linked above and all primary: Patchstack, State of WordPress Security in 2026 (data updated 25 February 2026). Verizon 2025 Data Breach Investigations Report, Small and Medium-Sized Business Snapshot. Australian Signals Directorate, Annual Cyber Threat Report 2024 to 2025. FIDO Alliance, The State of Passkeys 2026. Google Safe Browsing Transparency Report.
Want this done for you?
We build custom sites, sell templates you can put live today, and host and look after both.