Is your website really secure? Here's how to find out
Almost nobody finds out the easy way. A compromised website usually looks completely normal — it loads, it takes enquiries, it looks like yours — while quietly working for somebody else. This is the honest version: the seven ways in, what actually happens in the hours and months after a hole opens, and a 12-point inspection you can run yourself in about twenty minutes without paying anyone.
Three things almost every business owner assumes
None of them are unreasonable. All three are the reason most compromised sites stay compromised for months.
“We're a small business. Why would anyone bother with us?”
Nothing is choosing you. Automated scanners crawl the entire internet looking for one specific weakness, and every address gets tried. Being small does not make you invisible — it makes you cheaper to break into. Smaller businesses now get hit at several times the rate of large enterprises, and it is not because anyone knows their name.
“Our hosting company handles the security side.”
Your host is responsible for the server, the network and the walls. They are not responsible for the plugin you installed in 2022, the contact form that never validated an upload, or the admin account belonging to a developer who left. Roughly nine in ten website vulnerabilities live in the add-ons the owner chose, not in the platform underneath them.
“We would obviously know if something happened.”
The median breach runs for around 181 days before anyone notices. Not because owners are careless, but because a well-built compromise is specifically designed to leave the site looking exactly as it did yesterday. The whole business model depends on you not finding out.
Nobody is targeting you. That is exactly the problem.
There is a picture most people carry of what a website attack looks like: someone deciding to come after your business, sitting down, and working at it. That picture is almost entirely wrong, and it is comforting in the worst possible way — because if nobody has a reason to target you, you can reasonably conclude you are fine.
What actually happens is duller and far more effective. A security researcher publishes a flaw in a plugin that four hundred thousand websites happen to use. Within hours, automated tools are sweeping the internet asking one question of every site they can reach: do you have this plugin, at this version? The question takes milliseconds. It costs nothing to ask it of a million sites. Your website answers honestly, because that is what websites do.
Recent research puts the median time from public disclosure to mass exploitation at about five hours, with a large share of flaws under active attack inside the first day. Roughly four in ten of those flaws need no login at all — no stolen password, no insider, no clever social engineering. Just a request sent to a public address.
Then, if the answer is yes, something small is installed. Usually not a defacement — those are rare now, because a defaced site gets fixed immediately and is therefore worthless. Instead: a hidden administrator account, a file that lets the attacker back in later, a block of invisible links pointing at somewhere else entirely, or a quiet piece of code sitting on the checkout page.
A hacked website almost never looks hacked. Looking normal isn't a failure of the attack — it is the attack.The reason self-inspection matters more than reassurance
This is why "the site seems fine" is not evidence of anything, and why a yearly glance is not a security posture. The useful question is not has anyone attacked us — something has, this week, automatically. The useful question is which doors are open, and would we be able to tell?
So let's walk the doors.
The seven ways into a small business website
Every website, on every platform, has the same small set of entry points. Open a door to see what sits behind it, how it actually gets used, and the one-minute test you can run yourself today.
Your website's attack surface
Select a door · arrow keys work tooThe login page: the one door with a sign on it
Most content-managed sites publish their admin login at a completely predictable address. Bots know all of them. They arrive, try a few thousand of the most common username and password combinations, wait, and come back tomorrow. It is not sophisticated and it does not need to be — it only has to work on one site out of every hundred thousand it tries.
The tell is almost never a successful break-in you can see. It is the slow drag on the server from thousands of failed attempts a day, and an account list that has quietly grown by one.
Check it yourself · 1 minute
Open your site's admin login in a private browser window. Does it load for anybody on the internet, with no second factor and no limit on wrong guesses? Then open your user list and read every account out loud. Anyone you cannot name is a finding.
The fix
Two-factor authentication on every administrator, a cap on failed attempts, and a login address that is not the default one. All three are configuration, not budget.
Plugins: the code you inherited without reading
Every add-on is somebody else's software running with full access to your site and your database. Some are maintained by teams. Many are maintained by one person who has since moved on to other things. When the flaw is published, the site does not care who wrote the plugin — it only matters whether a patch exists and whether anyone applied it.
This is where the overwhelming majority of website vulnerabilities live: around 91% sit in plugins, with a small remainder in themes and only a handful in the platform core itself.
Check it yourself · 3 minutes
Open your plugin list and sort by last updated. Anything not touched by its author in over a year is a liability, not a feature. Then count the plugins you are actively using. If you have twenty-eight installed and use nine, you are maintaining nineteen unnecessary doors.
The fix
Delete what you do not use — deactivated is not removed, and deactivated code can still be reachable. Update what is left on a schedule someone owns.
Themes: the layer nobody remembers is software
A theme feels like decoration, so it gets treated like decoration. It is not — it is code with the same reach as anything else, and premium themes often bundle several plugins inside themselves. When one of those bundled components has a flaw, the fix has to come through the theme author, who may or may not still be shipping updates.
The other quiet risk here is the pile of unused themes left installed after a redesign. They are inactive, so nobody looks at them, and they go unpatched for years.
Check it yourself · 2 minutes
Look at your theme list. How many are installed and how many are actually in use? Check the active one's version against the author's current release. If your theme was bought from a marketplace and the licence lapsed, you are almost certainly not receiving security updates at all.
The fix
Keep one theme plus its child theme, delete the rest, and either renew the licence or move to something maintained.
Hosting: shared walls and old foundations
Cheap shared hosting puts your site on a machine with hundreds of others. Good hosts isolate accounts properly; weaker ones do not, and a compromise next door can become a compromise at yours. The more common problem is quieter: the language version your site runs on has stopped receiving security updates and nobody mentioned it, because the site still works.
Hosting-level filtering also gets oversold. It catches broad, noisy attacks well and misses narrowly targeted ones routinely — useful, but not a substitute for patching.
Check it yourself · 2 minutes
In your hosting panel, find the PHP or runtime version and search whether that version is still supported. Then find out whether daily off-server backups are included or an upsell you never bought. Ask support one direct question: "If my site is hacked tomorrow, what exactly do you do, and what is my responsibility?"
The fix
Move to a supported runtime, confirm backups leave the server, and get the answer to that question in writing before you need it.
Forms and uploads: the door you built on purpose
A contact form is an invitation for strangers to send data into your systems. That is its job. The risk is what happens to that data next: whether the site checks what it receives, whether a file upload will accept something that is not a document, and whether what gets typed into a field is ever displayed back to another visitor without being made safe first.
That last one — text from a stranger rendered straight onto a page — is the single most common category of web vulnerability there is, accounting for close to half of everything disclosed.
Check it yourself · 2 minutes
Submit your own contact form and see where the message lands. Does it arrive by email only, or is it stored somewhere you can reach? If you accept file uploads, try uploading something that is not an allowed type — a rejected upload is a good sign, an accepted one is a finding. Check whether any page displays visitor-submitted text publicly.
The fix
Restrict uploads by real file type rather than by extension, store submissions somewhere you control, and never render submitted text back onto a page unescaped.
Certificates: the padlock proves less than people think
The padlock in the address bar means the connection between the visitor's browser and your server is encrypted. It does not mean the site is safe, clean, or trustworthy — plenty of malicious sites have perfectly valid certificates. It is a floor, not a badge.
Where it does bite is in the failure modes. An expired certificate throws a full-screen browser warning that stops visitors dead. A site that loads over both HTTP and HTTPS leaves the insecure version indexed. And a page that is encrypted but pulls one image over plain HTTP loses the padlock entirely on the page where it matters most.
Check it yourself · 1 minute
Click the padlock and read the expiry date — put it in a calendar. Then type your address with http:// in front and confirm it redirects to the secure version rather than loading. Finally, load your checkout or contact page and confirm the padlock is still there.
The fix
Automatic renewal, a forced redirect to HTTPS everywhere, and no mixed content on any page that collects information.
People: the door with no lock at all
The most reliable way into a website is not a flaw in the software. It is a password that was reused on a service that was breached three years ago, or an administrator account belonging to an agency you stopped working with in 2023 and never removed.
Phishing has also become far harder to spot. The clumsy grammar that used to give it away is gone; convincingly written approaches now get clicked at several times the rate of the old ones. Assuming your team will simply recognise a fake is no longer a control.
Check it yourself · 3 minutes
List everyone with access to the website, the hosting account and the domain registrar — including former staff, freelancers and agencies. For each one ask: do they still need it, and is their access protected by two-factor authentication? Then check whether the business email address used for password resets is itself protected.
The fix
Remove access the day someone leaves, give every person their own named account instead of a shared one, and enforce two-factor on the domain and hosting accounts first — those two control everything else.
None of these seven are exotic
There is no advanced attack in that list. Every one of them is a thing a business owner can check without a security background, and every one of them is a thing that gets missed because nobody has ever been given the list.
of website vulnerabilities sit in plugins — not in the platform itself
hours — the median gap between a flaw being published and mass exploitation
of disclosed flaws need no login of any kind to exploit
days — the median time a breach runs before anyone notices it
What actually happens, and when you find out
Step through the six moments after a flaw goes public. The left panel is what is happening on your website. The right panel is everything you can see from where you are sitting.
Tap a stage to step through the six moments
On your website
Nothing yet. A researcher has published a flaw in a component that your site — along with a few hundred thousand others — happens to run. The patch exists. The clock has started.
What you can see
Absolutely nothing. The disclosure was posted somewhere you have never read, about a plugin you may not remember installing. There is no email, no alert, no reason to look.
This is the only moment where doing nothing costs nothing — and it is the moment nobody knows about.
On your website
Automated scanners are now sweeping the internet asking every site whether it runs the affected component. Yours answers. Five hours is the median gap between publication and this becoming mass activity.
What you can see
Still nothing, unless someone is reading server logs — and almost nobody is. If you look at all, you see a slightly busier day. The site loads. Enquiries arrive as normal.
A site on a maintained update schedule has usually already closed this door by now, without anybody making a decision.
On your website
A foothold is placed: a small file that allows a return visit even after the original hole is patched, and often a second administrator account with an unremarkable name. Nothing on the public site changes.
What you can see
The homepage looks perfect. This is deliberate. A visibly broken site gets fixed within the hour, which makes it worthless — so the attack's first priority is that you carry on as normal.
This is why patching after the fact is not the same as cleaning up. The patch closes the window; it does not remove what came through it.
On your website
The access is now earning. Hidden pages appear, invisible to you but not to search engines. Visitors arriving from Google — not from your usual links — are quietly redirected somewhere else. If you take payments, a few lines are watching the checkout.
What you can see
Your own visits look fine, because the redirect is written to ignore anyone who types the address directly or arrives logged in. If enquiries dip, it reads like a slow month.
The first honest signal usually arrives from outside: a customer asking why your link sent them somewhere strange.
On your website
Search engines and browser safety services detect the injected content. The site is flagged. Depending on what was found, visitors now meet a full-screen red warning instead of your homepage, and rankings fall.
What you can see
Now you see it — usually because a customer sends a screenshot. The warning is the moment the problem becomes public, which means the reputational cost lands before the technical fix even starts.
Getting a warning removed is not instant. It requires the site to be genuinely clean, then reviewed — typically days, not minutes.
On your website
Six months in, at the median. By this point the cleanup is archaeology: which files changed, which accounts are real, whether the backups you have are older than the compromise or already contain it.
What you can see
Everything, all at once, on the worst possible day. And the honest reckoning: several months of enquiries and search traffic that quietly went somewhere else, which no cleanup can give back.
Every hour of that timeline was preventable at the first stop — by an update nobody had to think about.
The 12-point inspection you can run yourself
No tools, no security background, no spending. Four zones, three checks each, about twenty minutes end to end. Anything you cannot answer is itself the answer.
Zone A — The front door
Access & identityThe padlock is real and not expiring
A certificate that lapses takes the whole site down behind a browser warning, and it always happens on a weekend.
Do this now: click the padlock, read the expiry date, put a reminder in your calendar two weeks before it.The login page is not wide open
Unlimited guesses at a predictable address is the single most attempted route into any website.
Do this now: try three wrong passwords in a private window. If nothing slows you down or locks you out, that is a finding.You can name every account
An extra administrator with a plausible name is the most common thing found on a compromised site.
Do this now: open the user list and say each name out loud. Remove anyone who no longer needs access.Zone B — The engine room
Code & versionsUpdates are applied by someone, on a schedule
"When we remember" is not a schedule. The median window between disclosure and mass exploitation is about five hours.
Do this now: open your dashboard and count pending updates. Then name the person responsible for them.You use everything you have installed
Unused plugins and themes are unpatched code sitting on your server for no benefit at all.
Do this now: count what is installed versus what you actually use. Delete the difference — deactivating is not deleting.The version underneath is still supported
An unsupported runtime receives no security fixes at all, no matter how current your plugins are.
Do this now: find the PHP or runtime version in your hosting panel and check whether it is still supported.Zone C — The safety net
Backups & watchingA backup exists somewhere other than the server
A backup stored on the same machine as the website is not a backup. Whatever reaches one reaches the other.
Do this now: find your most recent backup and confirm where it physically lives. If the answer is "the host has it", get that in writing.Somebody has actually restored one
An untested backup is a belief, not a safety net. Most first restores are attempted during an emergency, which is the worst time to discover a file is corrupt.
Do this now: ask whoever manages your site to restore last week's backup to a staging copy this month.Something is watching between your visits
Six months of silence is the default outcome. Monitoring is the only reason that number ever gets smaller.
Do this now: confirm you would get an email if the site went down, changed unexpectedly, or got flagged. If not, you are the monitoring.Zone D — The people
Keys & habitsNo password is used in more than one place
Reused passwords are how old breaches at unrelated companies become your problem years later.
Do this now: check whether the website password is the same as the email password. If yes, change one of them today.Two-factor is on the accounts that matter most
Domain registrar and hosting first — whoever controls those controls everything else, including your email.
Do this now: log into your domain registrar and turn on two-factor authentication. It takes about ninety seconds.Nobody who left still has keys
Former staff, past freelancers and previous agencies routinely keep working access for years after the relationship ends.
Do this now: write down everyone with access to the site, hosting and domain. Remove any name that surprises you.If the inspection turns something up
Do not start deleting files. Take a full backup of the site as it is now first, even though it is compromised — it is the only evidence of what happened and the only way to recover anything created since the last clean copy. Then change the passwords on your email and domain registrar before touching the website itself, because those are what an attacker uses to lock you out while you are working. Then get help. Cleaning a live site while guessing which files are yours is how a bad morning becomes a bad fortnight.
Where the holes are, and what they actually cost
Two things worth knowing before you decide how much of this matters: where the weaknesses genuinely live, and which parts of a hack you never get invoiced for.
The bill nobody quotes you
ItemisedEmergency cleanup
The only line anyone expects. It is also usually the smallest one, and it is charged at emergency rates because you need it today.
Downtime while it is fixed
A site being cleaned is a site not selling. If yours takes bookings or payments, this line is measured in whatever a day of trading is worth.
Search visibility, rebuilt from scratch
Warnings and spam content get you removed from results. Coming back is not a switch — it is a review process, then months of rebuilding position you had already paid for once.
Telling people it happened
If customer data was exposed, notifying them is not optional, and the conversation is the same whether the breach was sophisticated or a plugin nobody updated.
Doing properly what should have been done anyway
After a hack, the update schedule, the backups and the monitoring all get set up — at the worst possible moment, under pressure, at a premium.
The customer who saw the red screen and simply left
Nobody invoices you for this and nobody tells you it happened. They saw a warning with your business name on it, closed the tab, and went to a competitor. That line has no number and it is almost always the largest.
Three things people believe that quietly cost them
“We have a security plugin installed, so we are covered.”
A security plugin is a smoke alarm, not a fire service. It helps if it is configured, updated and someone reads its alerts. Most are installed once, never configured, and their notifications go to an inbox nobody checks. More than nine in ten breached businesses already had security tools in place.
“We don't take payments on the site, so there is nothing worth stealing.”
Card details are only one product. A site with clean search reputation is valuable precisely because it looks legitimate — it can host spam pages, send phishing that lands in inboxes, or redirect your visitors elsewhere. Your reputation is the asset, and you built it.
“If it gets hacked we will just restore the backup.”
Only if the backup predates the compromise, lives somewhere the attacker could not reach, and has actually been restored once before. If the breach ran for months, every backup you hold may already contain it — which is why untested backups fail exactly when they are needed.
What "secure" means when Senux builds it
Not a product you buy on top of a website. A set of decisions made while it is being built, and a routine that keeps running afterwards.
Fewer moving parts by design
Ninety-one percent of the risk lives in add-ons, so we build the functionality rather than bolting on a plugin for every feature. A site with four components instead of twenty-eight has a fraction of the surface to defend.
Updates on a schedule somebody owns
Patching is not left to whoever remembers. It happens on a rhythm, on a staging copy first, so a security update never takes the live site down as a side effect.
Backups you own, stored away from the server
Automatic, off-server, and restored on a test copy periodically so we know they work. You keep your own copy too — if you ever leave us, the backups leave with you.
Monitoring instead of six months of silence
Uptime, file changes, certificate expiry and search-console warnings all report in. The point is simple: somebody finds out in hours, not in half a year.
Named access, two-factor, and an exit routine
Every person gets their own account, never a shared login. Two-factor on hosting and domain from day one. And when someone leaves your business, removing their access is part of the process rather than an afterthought.
Your automation, in your own dashboard
The forms, the follow-up emails and the reporting run inside your site rather than on a third-party subscription — so there is no extra account, no extra vendor and no extra monthly fee to secure on top of everything else.
Security is not a feature you add at the end. It is the difference between a site somebody maintains and a site somebody built once.How we think about it at Senux
The honest word
Nothing here makes a website unhackable, and anyone who tells you otherwise is selling something. Software has flaws, flaws get published, and the internet is scanned continuously by machines that do not care who you are. That is the permanent condition, not a temporary problem to be solved once.
What you can change is your position on the timeline. The difference between a business that shrugs off a published vulnerability and one that spends a fortnight in recovery is almost never the sophistication of the attack. It is whether the update was applied inside the window, whether the backup existed somewhere else, and whether anyone found out in hours rather than in six months.
That is a maintenance question far more than a technology question — which is good news, because maintenance is affordable and predictable in a way that emergencies never are. Run the twelve checks this week. If everything passes, you have spent twenty minutes and gained something worth having. If something fails, you have found it on a normal Tuesday instead of on the day a customer sends you a screenshot of a red warning screen with your business name on it.
A note on the numbers
The figures used here come from published industry research on vulnerability disclosure, exploitation timing and small-business breach outcomes. They describe patterns across very large samples, not a prediction about your specific site. Treat them as a sense of scale — and as a reason to run the checks rather than to worry.
Questions we get asked about this
Start with four checks that take about five minutes. Search your own site on Google using the site: operator and look for pages you did not create, especially ones in other languages or about unrelated products. Open your site in a private window from a phone on mobile data, arriving from a search result rather than by typing the address, and see whether you land where you expect. Open your user list and confirm you can name every account. Finally, check Google Search Console for security notices. Those four catch the large majority of real compromises. What they cannot catch is a well-hidden backdoor, which is why a clean result means "no obvious signs" rather than "definitely clean".
The attacks are automated, so size does not affect whether you get scanned — it only affects whether anyone helps you afterwards. And a small site is still worth taking, because the value is rarely the data. A legitimate-looking website with clean search reputation can host spam pages, send phishing, or redirect visitors, and all of that works better on a real business site than on an obvious fake. The twelve checks in this article cost you twenty minutes and no money. That is a reasonable amount of effort regardless of how small the business is.
Partly, and the split matters. Your host is responsible for the server, the network and the infrastructure. You are responsible for everything installed on top: the platform, the plugins, the themes, the accounts and the passwords. Since roughly nine in ten website vulnerabilities live in that second category, most of the real exposure sits on your side of the line. Hosting-level filtering also catches broad automated attacks far better than narrow ones. The clearest way to find out where you actually stand is to ask your host directly what they do if your site is compromised, and get the answer in writing before you need it.
Take a complete backup of the site exactly as it is, compromised and all, before changing anything — it is the only record of what happened and the only copy containing anything created since your last clean backup. Then change the passwords on your email account and your domain registrar before you touch the website, because those are what an attacker uses to lock you out mid-cleanup. Then get help rather than deleting files by instinct. If customer data may have been exposed, find out what your notification obligations are early, because those have deadlines that do not pause while you fix the technical problem.
A review of an existing site — walking the seven doors, checking versions, accounts, backups and search status, and telling you plainly what we find — is a small, fixed piece of work, and we will tell you the number before we start. Ongoing maintenance is priced by how much is actually running on the site, because a lean build takes far less looking after than one carrying twenty-eight plugins. If the honest answer after a review is that your site is in decent shape and just needs two things fixed, that is what we will tell you. We would rather do a small job well than sell you a plan you do not need.
Would you rather find it, or be told?
Run the twelve checks yourself — genuinely, it costs nothing. And if any of them come back with an answer you do not like, tell us which one and we will look at the site properly, tell you plainly what we find, and give you a fixed number before you commit to anything.
Senux — websites built to work, maintained so they keep working. You own the site, the backups and the automation behind it.
One team for everything your business needs online
From the website itself to the automation running behind it — here's how Senux helps you grow.
Web Application Development
Custom web platforms, portals, and dashboards built for performance and scale.
Get StartedMobile App Development
Native-quality iOS and Android apps built from a single, efficient codebase.
Get StartedAI & Automation Solutions
Smart tools and AI integrations that cut repetitive work and speed up decisions.
Get StartedMultimedia & Digital Design
Graphics, animation, and video production that make your brand look the part.
Get StartedDigital Marketing & SEO
Data-backed campaigns and search strategy focused on real revenue.
Get StartedSocial Media Management
End-to-end planning, content creation, and management across your platforms.
Get StartedTell us what the inspection turned up
Message us on WhatsApp for a quick reply, or email us and we'll run the full inspection on the site properly. Even one failed point out of the twelve is enough to start.
Follow Senux
Tips, work and updates from the team — come say hello.