On this page
A website is not a brochure you print once. It is software, connected to the internet, depending on half a dozen other pieces of software that keep changing underneath it.
Left alone it does not stay still. It degrades quietly, and the first visible symptom is usually something bad.
What actually happens to a neglected site
Not all at once. Roughly in this order.
- Months 1–6. Nothing visible at all. Updates accumulate. Some of them are security fixes for holes that are now publicly documented, which is the part people miss — a published fix is also a published description of the weakness.
- Months 6–12. Small breakages. A form stops sending. A layout goes wrong in a browser that updated. Nobody tells you, because the people affected simply leave.
- Year 1–2. Updates can no longer be applied safely one at a time, because too much has changed at once. The host starts warning about an unsupported PHP version. Every change now carries risk.
- Year 2 onwards. Something gets compromised, or an update is forced and breaks the site, and the catch-up costs more than two years of maintenance would have.
Compromised sites are rarely targeted. Automated scanners work through known vulnerabilities across millions of sites. Being small is not protection — it just means nobody chose you personally, and the bots do not care either way.
A real schedule
| How often | What | Why |
|---|---|---|
| Continuously | Uptime monitoring | You should find out before a customer does |
| Continuously | Off-site backups | A backup on the same server is not a backup |
| Weekly | Apply updates, then check the site still works | The checking is the part people skip |
| Weekly | Submit the contact form yourself | Silent form failures are depressingly common |
| Monthly | Test restoring a backup | An untested backup is a hope, not a plan |
| Monthly | Check Search Console for errors | Broken pages and indexing problems surface here first |
| Monthly | Review user accounts | Old logins from people who left are a standing risk |
| Quarterly | Performance check on a real phone | Sites get slower by accretion, never all at once |
| Quarterly | Remove plugins nobody uses | Every one is a door; unused doors should be closed |
| Quarterly | Fix broken links | Other people’s sites move without telling you |
| Yearly | Confirm domain renewal and ownership | The one failure you genuinely cannot undo |
| Yearly | Review content for accuracy | Prices, people, services, the copyright year |
| Yearly | Check the PHP version is still supported | Hosts drop old versions with limited notice |
| Yearly | Renew licences for premium plugins | A lapsed licence stops the security updates |
The two everybody skips
Testing the restore
Plenty of businesses discover their backups have been failing silently for eight months at precisely the moment they need one. A backup you have never restored is a belief, not a safeguard.
Restoring to a staging site once a quarter takes twenty minutes and converts the belief into a fact. It also tells you how long a real restore would take, which is worth knowing before the day you need it.
Submitting your own contact form
Forms break for reasons that have nothing to do with the form. A mail setting changes. A spam filter gets more aggressive. A plugin update alters a redirect. A caching layer serves a page with a security token that has since expired.
Enquiries then vanish with no error message anywhere, and the first you know is a customer asking why you never replied — or, far more often, nothing at all, because they went elsewhere.
Send yourself a test every week. It takes ten seconds, and it has saved more businesses more money than anything else on this page.
Updating without breaking things
The reason people avoid updates is that updates sometimes break sites. The answer is not to avoid them — it is to make breaking safe and cheap.
- Back up immediately before, every time, without exception
- Apply significant updates on a staging copy first
- Update in small batches, so you know what caused a problem
- Afterwards check the homepage, a content page and the contact form
- Never update on a Friday afternoon
That last one is not a joke. The cost of a broken site is mostly the time it stays broken.
If you have already neglected it
Most sites we are asked to take on are somewhere in that timeline already, and the instinct is to update everything at once on a Monday morning. Do not. A site that has not been touched in two years is one where several things will break, and doing them together means you will not know which did what.
The order that works:
- Take a full backup and verify you can restore it. Before touching anything. If this step fails, stop — you have found the most urgent problem.
- Copy the site to a staging environment and do everything there first. Most hosts provide this free.
- Delete what is not used before updating it. There is no point carefully updating a plugin nobody has opened since 2021.
- Update the platform core first, then plugins in small batches, checking the site between each.
- Deal with PHP last, once everything else is current, because old plugins are usually what blocks a newer PHP version.
- Then go live, and check the contact form before you tell anyone you are done.
Budget real time for this. A two-year catch-up is a day’s work if it goes well and considerably more if a plugin has been abandoned and needs replacing — which is the usual reason these jobs overrun.
Does every platform need this?
Less so on hosted platforms. Squarespace, Webflow and Framer handle their own updates, security and hosting — that is a large part of what the subscription buys, and a perfectly good reason to choose one.
You still need to check forms, fix links, keep content current, review who has access and own your domain. The list gets shorter; it does not disappear.
Self-hosted platforms like WordPress trade that convenience for control. Both are reasonable — the difference is simply where the work sits, and it is one of the real deciding factors in four platforms, honestly compared.
Do it yourself or pay somebody
Either is fine. What does not work is assuming it is happening when nobody has been asked to do it — which is, by a distance, the most common arrangement we find when a new client’s site arrives in a bad state.
Put a name against it. If that name is ours, this is what our maintenance work covers. If it is yours, the table above is the whole job — print it and work down it.
