Anyone who’s driven a car through a few Canadian winters knows what road salt does. Nothing dramatic happens on any single day. But leave the undercarriage unwashed for three years and one spring you’re staring at a repair bill that costs more than the maintenance ever would have.
Your website is sitting in the salt right now.
Here’s the claim, stated as bluntly as we can make it: a website without a maintenance plan is not “done” — it’s corroding. The damage accumulates in places you never look: a few outdated packages here, a few hundred milliseconds there, one silently failing form. Then, months later, it all surfaces at once — usually during the exact week you can least afford it.
Consider a scenario. (It’s illustrative, not a client story — but every individual piece of it is something maintenance teams encounter routinely.) An Ontario retailer’s checkout runs flawlessly through spring. By fall, one in five orders dies with a 500 error — the HTTP status code meaning the server itself failed, not the shopper. Page loads have crept past seven seconds on an average phone. A competitor now outranks them for their own product category. And here’s the kicker: no developer deployed a single change all year. That’s not the alibi. That’s the cause.
A website is software, and software ages
Most business owners carry a print-era mental model: design it, approve it, publish it, done. A printed flyer never un-prints itself, so why would a website?
Because a website isn’t a document — it’s a running machine assembled from parts you don’t control. Even a modest five-page site stacks up like this: the visitor’s browser, your HTML/CSS/JavaScript, the CMS or framework that generates it, a heap of plugins and packages, a server runtime such as PHP or Node.js, a database, a CDN out front, DNS records, and a TLS certificate vouching for your identity. Layer marketing’s analytics tags and chat widgets on top and you have dozens of moving parts.
Every part moves on its own schedule. Chrome ships a new version roughly every four weeks. Server runtimes hit end-of-life on published dates — PHP 8.1, still running under a staggering number of small-business sites, stopped getting security patches at the end of 2025. Google swaps out ranking signals. Third-party scripts update themselves in your visitors’ browsers without so much as an email.
So “we haven’t touched the site” never means “the site hasn’t changed.” It means the ground moved and nobody checked the foundation. The salt keeps working whether or not you look underneath.
Dependency drift: your stack ages while you sleep
Developers call it dependency drift — the widening gap between the software versions your site runs and the versions the rest of the world maintains. Translated: your site stands on other people’s code, and other people’s code keeps walking.
The numbers surprise anyone who hasn’t seen a modern build. Install a handful of JavaScript packages and you inherit hundreds more, because each package carries its own dependencies, which carry theirs. Those are transitive dependencies — the code your code’s code needs — and they’re where trouble hides, several layers beneath anything you consciously chose. WordPress has the same anatomy under different names: themes, plugins, and the PHP runtime beneath everything.
Drift behaves like compound interest running against you. Most packages use semantic versioning — numbers like 3.2.1, where only the first digit signals breaking changes. Stay current and each update is a five-minute chore. Ignore eighteen months of them and you’re not updating anymore; you’re migrating, with several breaking changes stacked into one risky jump, guided by documentation written for people who kept pace.
Make it concrete with another flagged-as-hypothetical example: a physiotherapy clinic launches a polished site with online booking, then freezes it because it works. Two years on, their host retires an end-of-life PHP version — responsibly, on schedule — and force-upgrades every account. The clinic’s booking plugin, abandoned by its developer years earlier, quietly stops submitting. No error page, no alert. Appointments just stop arriving, and the front desk assumes it’s a slow month.
The failure isn’t exotic. The lucky part is ever finding out.
How fast websites become slow
Nobody chooses a slow website. Sites get slow the way a junk drawer gets full — one perfectly reasonable deposit at a time.
Start with the measuring stick. Google’s Core Web Vitals score real-user experience on three axes, each with a published “good” threshold: Largest Contentful Paint (LCP) within 2.5 seconds, meaning the main content actually appears; Interaction to Next Paint (INP) within 200 milliseconds, meaning taps and clicks respond promptly (INP took over from the older First Input Delay in March 2024 and is a tougher test); and Cumulative Layout Shift (CLS) under 0.1, meaning the page doesn’t lurch around while loading. Google grades at the 75th percentile of real Chrome visitors — your site must be fast for most people, not just for you at your desk on office fibre.
Now the deposits that fill the drawer:
Images that nobody resized
Launch day, every image was tuned. Eighteen months later someone drops a 5 MB phone photo straight into the CMS as a banner. Without an automated pipeline converting uploads to compact formats like WebP or AVIF and serving size-appropriate copies through srcset, every upload levies a small speed tax that no one ever refunds. LCP creeps from 2 seconds toward 5, one photo at a time.
Scripts that nobody audited
Each marketing tool — analytics, heat mapping, live chat, ad pixels — arrives as a <script> tag. Every one either delays rendering or fights for the browser’s main thread, the single lane where JavaScript runs and where a visitor’s tap gets handled. Picture one more person interrupting a conversation that was already crowded. This is the classic INP killer, and it’s nobody’s fault exactly: each tag was individually justified, and the total was never once reviewed.
Queries that nobody profiled
Code that flies with 40 products can crawl with 4,000. The textbook offender is the N+1 query: rather than asking the database one bulk question, the code asks one question per item — 4,001 round trips where one would have done. The symptom is rising TTFB — time to first byte, the pause before the server sends anything at all — which visitors experience as the site simply hesitating.
Caching that nobody re-checked
Caching — serving ready-made copies from a CDN edge node near the visitor instead of rebuilding pages on demand — is most of what makes a site feel instant. It’s also configuration, and configuration rots. One plugin update starts stamping a cookie on every response and suddenly the CDN treats every visitor as un-cacheable. Cruelest of all, the site still feels quick to you: your browser has everything warmed. The first-time visitor on cellular data in a parking lot gets the truth. That gap is why lab tools like Lighthouse and field data from the Chrome UX Report tell different stories — the lab is your best case; the field is reality.
Even the advice ages. HTTP/1.1-era guides pushed spreading assets across multiple domains; HTTP/2’s multiplexing — many files down one connection — turned that trick into a penalty. A site tuned in 2016 and untouched since is now tuned for a protocol its visitors abandoned.
One transparency note: you’ll find suspiciously precise claims online about revenue lost per second of load time. We won’t repeat any of them — most are second-hand mutations of narrow, dated studies, and you should verify any such figure before quoting it. The unembellished version is enough: slow sites convert worse, and Core Web Vitals are a documented input to Google’s rankings.
Someone is scanning your site right now
This sounds like paranoia and is actually just arithmetic: scanning the whole internet is cheap, so automated tools do it continuously. Whether you sell software or maple syrup, your site gets probed daily by bots hunting one thing — known vulnerabilities.
Known is the operative word. CVEs are public catalogue entries describing security flaws in specific software versions, including whatever CMS and plugins you run (trackers like the WPScan database list tens of thousands for WordPress alone). When a flaw is disclosed in a popular plugin, working exploits circulate within days — sometimes hours. From that moment, the only variable that matters is your patching cadence: how quickly fixes actually land on your production site. A patch released Tuesday defends nobody if it’s deployed “next quarter.”
Security failures can also be entirely boring. The classic is the TLS certificate that expires unnoticed, at which point every browser blocks your site behind a full-screen warning — a closed sign hung on your digital storefront. Scale is no defence: Microsoft Teams went down for hours in February 2020 because a certificate lapsed. If it happens inside Microsoft, it can happen to a site nobody’s watching.
Then the question nobody enjoys: when did someone last restore one of your backups? A backup that’s never been test-restored is a wish, not a plan. The right time to learn your nightly job has been failing silently since March is during a calm rehearsal — not the morning after an incident.
What real maintenance looks like
None of this gets fixed by heroics or talent. It gets fixed by unglamorous routine — which is precisely why it gets skipped, and precisely how you can tell a professionally run site from a lucky one:
Instrumentation first. Uptime monitoring, error alerts, and a monthly review of real-user Core Web Vitals trends. Decay is only invisible on sites nobody measures. A form that breaks should page a human within minutes, not surface through an awkward customer conversation weeks later.
Updates through staging, on a schedule. Dependency and plugin reviews weekly or biweekly, applied to a staging copy first, screened with visual regression tests — automated before-and-after screenshot comparison that catches layouts breaking — and only then promoted live. Updating production directly on a Friday afternoon is one anti-pattern; never updating is the other.
Severity tiers, written down. A critical security patch in anything internet-facing ships within days at the longest. A cosmetic version bump waits for the scheduled window. Without written tiers, patching speed depends on whoever’s mood, which is to say it’s a mood, not a policy.
Performance budgets that block releases. Tools like Lighthouse CI can fail a build that exceeds a speed budget — in plain terms, the site refuses to ship a change that would make it meaningfully slower. Regressions get caught as one reviewable diff instead of excavated eighteen months later.
Scheduled housekeeping. Quarterly, walk the third-party script list and make every tag re-earn its main-thread cost. Twice a year, restore a backup somewhere real and click around the result. Each is an hour of tedium that deletes an entire genre of emergency.
Read that list again: schedules, tiers, budgets, rehearsals. Airline-maintenance boredom. That’s the giveaway — well-maintained websites are boring from the inside. The excitement all happens on the neglected ones.
An hour of checks you can run yourself
No engineer required for a first inspection — just an honest hour:
- Run PageSpeed Insights on your homepage and your highest-value page. It reports lab scores plus, if traffic allows, real-user Core Web Vitals. Compare against the thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. WebPageTest and GTmetrix dig deeper if you’re inclined.
- Load the site on an actual phone over cellular — not office Wi-Fi. That’s the version most customers meet.
- Inventory your third-party scripts. Open dev tools, watch the network panel, count the domains you can’t name. Ask what each still earns.
- Read the update badge in your CMS. Note the number, and the PHP version while you’re in there. If either number makes you pause, you’ve just measured your drift.
- Click the padlock and check your TLS certificate’s expiry — and find out whether renewal is automated or riding on somebody’s memory.
- Submit your own forms and run a test transaction. Confirm the results genuinely arrive. Silent failures are the costliest kind.
- Ask when a backup was last restored. Restored — not taken. “Never” is itself a finding.
- Make sure something is watching uptime — a simple monitor that emails you beats hearing about an outage from a customer.
Every answer clean? Genuinely well done — quiet, competent work is happening on your behalf. A few uncomfortable answers? That’s not an emergency. It’s just the salt, doing what salt does. It only becomes an emergency if another year passes.
If you’d rather hand that hour to specialists, Zayn offers a free, no-obligation website audit covering performance, security posture, and accumulated update debt — delivered in plain English, priorities ranked, no scare tactics. The sites nobody has touched since launch are honestly our favourite kind. Book a call and we’ll show you exactly where yours stands.
Rust never sleeps. Your maintenance plan shouldn’t either.