A company's website stops working on a Friday afternoon. Nobody fixes it before Monday, because the person who built it is on holiday and nobody else has access. On Monday it turns out that somebody did set up backups, but nobody ever tried restoring one, and now it emerges that they contain files and no database.
This is not a story about hackers. It is a story about none of it being discovered earlier, because none of it was ever tried. A site being attacked is only one cause of an outage, and far from the most common one.
This article is about what has to be ready in advance, how to notice something is wrong, and what to do in the first hour. Without scaremongering: on most company websites it is more likely you will switch it off yourselves than that somebody will break into it.
Short answer
- The most important thing is not antivirus or a firewall but a backup you have restored from at least once. An untested backup is just a feeling.
- The three most common causes of an outage are not attacks: an expired domain, an expired certificate and an unpaid hosting bill.
- When a site is compromised it is usually through a neglected plugin or a weak admin password, not through a flaw in the server.
- Finding out something is wrong costs nothing: Search Console e-mails you when Google finds harmful content on your site.
- A site with no third party plugins and no dozens of dependencies has nowhere to be attacked. The cheapest security is having nothing to watch.
Websites go down because of the calendar, not because of hackers
Say website security and everybody pictures an attacker. In practice the most common causes of an outage are dull, and they all have one thing in common: somebody should have put a reminder in a calendar.
| Cause | How it shows | How long the fix takes |
|---|---|---|
| Expired domain | Website and company e-mail vanish at once | Hours, if the grace period is caught |
| Expired certificate | The browser shows a warning instead of the site | Minutes, if there is somebody to call |
| Unpaid hosting | The site is switched off, usually without warning | Hours to days |
| A failed update | Broken layout or a blank page | Minutes from a backup, otherwise hours |
| A neglected plugin | Foreign content on the site, redirects elsewhere | Days, and that is the better outcome |
| A weak admin password | Somebody inside, often unnoticed for a long time | Days to weeks |
The first three rows have nothing to do with security and still account for most of the outages we see. One thing fixes them: knowing when things expire, written down somewhere other than in one person's head.
The domain is the nastiest of them, because e-mail goes with it. At that moment the company not only has no website, it will not even be told, because the notification cannot reach it.
A backup you have never restored is not a backup
This is the most important paragraph in the article and the thing almost nobody does.
Nearly every host offers backups today and nearly every company will tell you they have them. When they are actually needed, three things keep turning up: the backup holds files but no database, so the site's content is missing; the backup is weeks old, because the job stopped running at some point and nobody noticed; or restoring is possible but nobody knows how, so it gets learned at the worst possible moment.
The test takes half an hour and is done once a year: ask whoever runs the site to restore yesterday's backup to a test address and show it to you. If that cannot be done within an hour, you effectively have no backup.
We have backups, the host does them automatically. When anything was last restored from them nobody knows, and what exactly is inside them nobody knows either.
Backups run daily, contain the database as well as the files, are kept for thirty days, and once a year a site is restored from one to a test address so everybody knows it works and how long it takes.
Why the sites that get attacked are the ones assembled from plugins
An attacker is not looking for your company. They write a program that sweeps millions of addresses trying one known hole. Your site is a target because it runs the same system as millions of others, not because you are interesting.
That tells you where the holes come from. Not servers, and usually not the core of the content management system either. Plugins: each one is code from a stranger, some written in somebody's spare time, some unmaintained for years, and every one of them has full access to the site and the database.
That creates the trap most of the companies who come to us are sitting in. Updating is necessary but risky, because an update occasionally breaks the layout. Not updating is comfortable but dangerous. Most people choose the second and never think of it as a choice.
A site without a plugin ecosystem does not have this problem. Not because it is better written, but because there are not twenty pieces of somebody else's software in it for anyone to watch. The cheapest security is having nothing to watch.
Six things that should be ready in advance
None of them costs a monthly fee and four of them a company can do itself in an afternoon.
- 1Write down when the domain, the certificate and the hosting expire, and set a reminder a month ahead. Not in your head, in a calendar more than one person can see.
- 2Verify a backup by restoring it to a test address. Note two numbers while you do: how old the backup is and how long the restore takes.
- 3Turn on two factor login for the admin and remove accounts belonging to people who have left. There are usually more of them than you expect.
- 4Set up Google Search Console. It is free and e-mails you when Google finds harmful content or an indexing problem.
- 5Write down who runs the site, where it runs and who holds the credentials. One page, stored somewhere other than on the site.
- 6Agree with your supplier how quickly they respond to an outage and how a fault should be reported outside office hours.
What to do in the first hour when the site is down
In the order it should be done. Half of all outages are solved by step two.
- 1Check the problem is not at your end. Try the site on mobile data and from another network, ideally through a service that tries it from abroad.
- 2Find out whether the domain and the certificate are still paid for. The browser will tell you about the certificate; for the domain, check the public registry.
- 3Look at the host's status, in case they are reporting an incident. It is usually on their status page.
- 4Only now call the supplier. With the information from the first three steps you cut the search to a fraction.
- 5If the site is compromised, do not fix it by editing. Restore it from a backup taken before the compromise, change every password, and only then work out how it happened. Fixing without restoring leaves the attacker a way back in.
A website that has not been updated for a year is not out of date. It is open
When it is not worth bothering with
Security sells well on fear, so it is fair to say where the line is.
A one page site with no admin, no form and no login has nothing to steal and nowhere to be attacked. Watching the domain and the certificate is enough there, which is two dates in a calendar. A paid security retainer has no business being there.
Equally, there is no sense buying security plugins for a site assembled from other plugins. You are adding more third party code with full access to the system, which is exactly the source of the problem. Reducing the number of plugins is more useful.
And a last point that sounds like a contradiction: most company websites do not need more security, they need fewer things. Every extra feature is another place where a mistake can be made.
How we handle it
- Backups run daily and contain the database as well as the files. The restore is tested rather than merely configured, and there is a script for it, not a procedure in somebody's head.
- We apply patches ourselves. The difference against a site built from plugins is the count: a few vetted dependencies instead of dozens of add-ons from twenty authors.
- Zero third party scripts on the page. What is not on the site cannot be attacked or misused for something else.
- Two factor admin login from the start, not as an add-on installed after an incident.
- You hold credentials too. If you cannot reach us, you are not dependent on us picking up the phone.
And the honest other side: total security does not exist, and anybody promising it is selling. The difference is not that nothing can happen here. It is how quickly the site comes back, and that is a matter of backups and access, not of a security badge on a supplier's website.
Frequently asked questions
How do I secure a company website?
Start with a backup you have restored from at least once, because an untested backup is just a feeling. Then two factor login for the admin and removing accounts of people who have left. And watching the expiry dates of the domain, the certificate and the hosting, because those account for most outages. A security plugin comes far behind all of that.
How often should a website be backed up?
Daily, if content changes or orders arrive. Two other things matter more than frequency though: whether the backup contains the database and not only files, and whether anybody has ever tried restoring from it. The restore test takes half an hour and is done once a year.
Why are WordPress sites attacked more often?
Because it powers roughly two fifths of the world's websites, so it pays to write attacks against its known holes. The main weakness is not the core but the plugins: of 11,334 new vulnerabilities found in the ecosystem in 2025, 91 per cent were in plugins. Every plugin is somebody else's code with full access to the site and the database.
What should I do if my site is compromised?
Do not fix it by editing. Restore from a backup taken before the compromise, change every password including hosting and database, and only then work out how it happened. Fixing without restoring typically leaves the attacker a way back in. After restoring, request a review in Google Search Console, or the site stays flagged in the results.
Does a small company website need a paid security retainer?
A one page site with no admin, form or login does not. Watching the domain and certificate is enough. A retainer makes sense for a site that has an admin, accepts data from visitors, or runs on a system with dozens of plugins, because those have to be patched continuously.
How do I find out something is wrong before somebody tells me?
Set up Google Search Console; it is free and e-mails you when it finds harmful content or an indexing problem. An uptime monitor to alert you to outages helps too. Both are cheaper than hearing it from a customer.
Summary
- Most outages have nothing to do with attacks. An expired domain, an expired certificate and unpaid hosting account for most of them.
- A backup you have never restored from is not a backup. The test takes half an hour, once a year.
- The holes are in plugins, not in the server. Nine out of ten vulnerabilities found in the ecosystem are there.
- A compromised site is restored from a backup, not repaired. Repairing without restoring leaves a way back in.
- Search Console is free and will tell you before a customer does.
- The cheapest security is having nothing to watch. Every extra feature is another place for a mistake.
Not sure where you stand
Send us your website address. We will check when the domain and certificate expire, how much third party code the page loads, and whether the site shows up in places it should not. You will get it back in plain language, including what you can fix yourself.