Nobody touched the website. That’s the part that stings.
The checkout worked in March. By August, one order in five was dying with a 500 error — the HTTP status code that means “the server itself broke,” not “the customer did something wrong.” The homepage took eight seconds to load on a mid-range Android. A competitor had slipped above it in the search results that used to pay the bills. No redesign. No botched deploy. Nobody did anything to the site.
That was precisely the problem.
(To be clear up front: that scenario is illustrative, not a named client. But it’s assembled from failure patterns anyone doing website maintenance for a living sees over and over — usually in that order.)
So here’s the claim, stated plainly: a website with no maintenance plan is not stable. It’s decaying. The decay is invisible for months because it happens a few milliseconds and one outdated package at a time. Then it becomes very visible, very suddenly — and almost always during your best trading week, because that’s when the most traffic is hitting the weakest parts.
A website isn’t a brochure. It’s a running system
The mental model most businesses carry is print: you design the thing, you approve the thing, you ship the thing, it’s done. A brochure never un-prints itself.
A website is nothing like that. Even a “simple” five-page site is a stack of interdependent layers: the browser rendering it, the HTML/CSS/JavaScript you shipped, the framework or CMS generating that markup, a pile of plugins and packages, a server runtime like PHP or Node.js, a database, a CDN in front of all of it, DNS pointing at the CDN, and a TLS certificate proving you are who you say you are. Then marketing adds analytics, a chat widget, and three ad pixels on top.
Every one of those layers changes on its own schedule, whether or not you’re paying attention. Chrome ships a new version roughly every four weeks. PHP versions reach end-of-life — PHP 8.1, which an enormous number of business sites still run, stopped receiving security fixes at the end of 2025. Google retires and replaces its ranking signals. Third-party scripts push updates straight into your visitors’ browsers without asking you.
The best analogy I know: an unmaintained website is a person standing still on a moving walkway that runs backwards. Doing nothing doesn’t mean staying in place. Doing nothing means drifting backwards at a speed you don’t control — and the distance only becomes obvious when you try to catch up in one jump.
Dependency drift: the slow rot you can’t see
“Dependency drift” is the gap between the software versions your site runs and the versions the world currently maintains. In plain English: your site was built on top of other people’s code, and other people’s code moves on without you.
The scale of this surprises non-developers. A modern JavaScript build doesn’t have five dependencies; it has hundreds, because every package you install brings its own dependencies, which bring theirs. These are transitive dependencies — the packages your packages depend on — and they’re where problems usually hide, three layers down from anything you chose deliberately. WordPress has the same anatomy with different names: themes, plugins, and the PHP version underneath them all.
Drift compounds like unpaid interest. Most packages follow semantic versioning — version numbers shaped like 2.4.1, where the first number only changes when something breaks compatibility. Skip one minor update and the next one is trivial. Skip eighteen months of them and you’re no longer performing an update; you’re performing a migration, with breaking changes stacked on breaking changes, against documentation written for people who kept up.
Here’s the hypothetical that makes it concrete — and again, it’s a composite, not a case study. A firm launches a handsome marketing site, then freezes it for two years because it “works.” Their hosting provider, quite reasonably, retires an end-of-life PHP version and force-upgrades every account. The site’s abandoned form plugin — last updated four years ago — isn’t compatible with the new runtime. The contact form doesn’t error loudly. It just stops delivering enquiries. They find out six weeks later, from a customer who happened to mention they’d tried to get in touch.
Nothing about that story is exotic. The only unusual part is that they found out at all.
Performance decay: fast sites get slow one upload at a time
No one decides to make their website slow. It happens the way a spare room fills with boxes — one reasonable decision at a time.
First, the yardstick. Google’s Core Web Vitals are three field measurements of real-user experience, each with a public “good” threshold: Largest Contentful Paint (LCP) under 2.5 seconds — how long until the main content is actually visible; Interaction to Next Paint (INP) under 200 milliseconds — how quickly the page responds when someone taps or clicks (INP replaced the older First Input Delay metric in March 2024, and it’s stricter); and Cumulative Layout Shift (CLS) under 0.1 — how much the page jumps around while loading. Google assesses these at the 75th percentile of real Chrome users, which means your site has to be fast for most people, not just for you on office wi-fi.
Now, the decay mechanisms — the boxes that fill the room:
Content bloat
The site launched with optimised images. Eighteen months later, someone uploads a 4.5 MB photo straight off a phone as a hero image. Without an automated pipeline converting uploads to modern formats like WebP or AVIF and serving responsive sizes via srcset, every upload is a small performance tax that nobody ever refunds. LCP drifts from 1.9 seconds to 4-something, one image at a time.
Third-party script accumulation
Every tool marketing adopts — analytics, session recording, a chat widget, retargeting pixels — arrives as a <script> tag. Each one either blocks rendering or competes for the browser’s main thread, which is the single lane where JavaScript executes and where your visitor’s tap gets processed. Translation: every widget is another person talking over the conversation between your page and your customer. This is what quietly murders INP. Individually, each tag was a reasonable request. Nobody was ever asked to approve the sum.
Database growth and lazy queries
Code that was fast with 50 products can be catastrophic with 5,000. The classic culprit is the N+1 query: instead of asking the database one question (“give me these products with their prices”), the code asks one question per item — 5,001 questions where one would do. At launch, nobody notices. At scale, it shows up as rising TTFB — time to first byte, how long the server thinks before it starts answering — which is the delay users feel as the site doing nothing.
Cache rot
Caching — serving pre-computed copies from a CDN edge near the visitor instead of rebuilding every page — is what makes most sites feel fast. It’s also fragile configuration, and configuration rots. A plugin update starts setting a cookie on every page, and suddenly the CDN treats every visitor as uncacheable. The infuriating detail: the site feels fine to you, because your machine has warm caches and fibre. Your first-time mobile visitor on a train gets the cold-start experience. This is why lab tools like Lighthouse and field data from the Chrome UX Report disagree — the lab measures your best case; the field measures the truth.
Even best practices decay. Optimisation guides from the HTTP/1.1 era told everyone to shard assets across multiple domains; HTTP/2’s multiplexing — many files over one connection — made that advice actively harmful. A site “optimised” in 2016 and untouched since is now optimised for a protocol its visitors no longer use.
One honest aside: you’ll see precise claims everywhere about how many visitors each second of load time costs. I’m deliberately not quoting them — most numbers circulating on LinkedIn are mangled versions of narrow studies. Verify any figure like that before you put it in a deck. The directional truth needs no embellishment: slower sites convert worse, and Core Web Vitals are a documented ranking input for Google Search.
The internet is scanning your website right now
This part sounds paranoid and is simply mechanical: automated scanners are probing your site today, whether you run a bakery or a bank. They aren’t targeting you; they target everyone, because scanning is nearly free.
What they’re looking for are known vulnerabilities — CVEs, the public registry entries that catalogue security flaws in software, including the exact CMS versions and plugins your site runs. When a vulnerability is disclosed in a popular WordPress plugin (databases like WPScan track thousands of these), exploitation attempts follow quickly — the window between “patch available” and “actively exploited” is measured in days, sometimes hours. Your patching cadence — how fast fixes actually reach production — is the whole game. A fix that ships upstream on Tuesday protects nobody if it reaches your site next quarter.
And security failure isn’t always dramatic. The most mundane version is the TLS certificate that silently expires, at which point every browser greets your customers with a full-screen warning — functionally a “closed” sign on your shop. It happens to giants: Microsoft Teams went down for hours in February 2020 because Microsoft let a certificate lapse. If it can happen there, it can happen to a site nobody is watching.
Which raises the uncomfortable backup question. Backups you’ve never test-restored aren’t a recovery plan; they’re a hope. The moment to discover your nightly backup has been silently failing for months is a drill on a quiet Tuesday — not the morning after a compromise.
What disciplined maintenance actually looks like
None of the above is fixed by heroics. It’s fixed by boring, scheduled discipline — which is exactly why it’s skipped, and exactly where you can tell a professionally maintained site from a lucky one. A few practices that separate them:
Monitoring before everything. Uptime checks, error alerting, and a monthly look at real-user Core Web Vitals trends. Decay is only invisible if nobody’s instrumented the site. A form that breaks silently should page someone — not wait six weeks for a kind customer.
A staging-first update cadence. Dependency and plugin updates reviewed on a schedule — weekly or fortnightly — applied to a staging copy, checked with visual regression tests (automated screenshot comparison that catches the layout breaking), then promoted to production. The anti-pattern is updating everything directly on the live site at 5 p.m. on a Friday. The other anti-pattern is never updating at all.
Patch SLAs by severity. Not all updates are equal. A critical security fix in an internet-facing component should ship within days at most; a cosmetic minor bump can wait for the scheduled window. Having tiers — written down — is the difference between a policy and a mood.
Performance budgets in CI. Tools like Lighthouse CI let you fail a build when it exceeds a budget — in plain English, the site refuses to ship a change that makes it meaningfully slower. Decay gets caught at the moment of introduction, when it’s one diff, instead of eighteen months later, when it’s archaeology.
Quarterly tag audits and restore drills. Walk the list of third-party scripts and make each one re-justify its main-thread cost. Restore a backup somewhere real and confirm the result works. Both are an hour of unglamorous work that removes an entire category of 2 a.m. phone call.
Notice what’s on that list: schedules, budgets, drills, checklists. Aviation-grade tedium. That’s the tell — well-maintained websites look boring from the inside. The drama all lives on the unmaintained ones.
A checklist you can run this week
You don’t need an engineer to take a first reading. An hour, honestly spent:
- Run PageSpeed Insights on your homepage and your money page. It shows both lab scores and — if your site has enough traffic — real-user Core Web Vitals. Check against the thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. WebPageTest and GTmetrix go deeper if you’re curious.
- Test on a real phone over mobile data — not your desktop on office broadband. Feel the version your customers get.
- Count your third-party scripts. Open your site, open browser dev tools, watch the network tab, and tally the domains you don’t recognise. Ask which of them still earn their keep.
- Count your pending updates. Log in to your CMS and note the number on the updates badge. Note the PHP version while you’re there. If either makes you wince, that’s drift, quantified.
- Check your TLS certificate’s expiry date — click the padlock in the address bar. Find out whether renewal is automated or resting on someone’s memory.
- Submit your own contact form and place a test order. Confirm the enquiry actually arrives. Silent failure is the most expensive kind.
- Ask when a backup was last restored — not taken, restored. “Never” is a finding.
- Confirm something is watching uptime — a basic monitor that emails you when the site is down beats finding out from a customer.
If every answer came back clean: genuinely, well done — someone is doing quiet, competent work on your behalf. If two or three answers made you uncomfortable, that’s not a crisis. It’s just the walkway, moving. It only becomes a crisis if nothing changes.
If you’d rather have specialists take that reading, Zayn Digital offers a free, no-obligation website audit — performance, security posture, and update debt, reported in plain English with the jargon translated and the priorities ranked. Bring us the site nobody’s touched in two years; those are our favourites. Book a call and we’ll show you exactly where yours stands.
Websites don’t stay built. Plan for it.