What Breaks on a Website Nobody Maintains

Nothing dramatic happens to a website nobody maintains. It does not fall over on a Tuesday. It degrades on a schedule, and most of that schedule was published years in advance by companies that have no idea your site exists.

Certificate authorities set validity periods. Platforms publish API expiry tables with dates in them. Language runtimes announce end-of-life years ahead. Browsers give months of notice before they change how they treat a page. Every one of those dates is public. None of them is sent to you.

What follows is what actually breaks, organised by when it arrives rather than by category, because that is the order an owner experiences it. The first year is short clocks and published requirements. Years two and three are where the quiet failures live, the ones that return a perfectly healthy response and change the answer underneath. After that it is less a failure than a drift, and the honest part of that story is how little of it has a number attached.

At a glance

• The dangerous failures are the ones that do not throw an error. Meta and Shopify both redirect calls to an expired API version to an older one instead of failing, so an integration keeps working and quietly changes shape.
• The certificate clock is speeding up while the reminders are being switched off. Maximum public certificate lifetime falls from 398 days to 47 between March 2026 and March 2029, and Let’s Encrypt ended its expiry warning emails in June 2025.
• Email is the failure nobody sees. Since February 2024 Gmail has required every sender to publish SPF or DKIM and pass reverse DNS, and the rejection for failing that goes to a server log rather than to a person.
• Runtimes run on a four-year clock. A PHP branch gets two years of active support and two years of security fixes, and then nothing.
• The headline statistic everyone quotes for content decay does not appear to exist. We went looking for it and could not find it at the source it is attributed to.

Every date in the table below was set by somebody other than the site owner, and every one of them is sourced in the section that covers it.

The first year: short clocks and published requirements

The clocks that run fastest are the ones that were never annual to begin with. None of them lands on the continuous, monthly and annual maintenance cadence most owners budget for.

Certificates, and the reminder that stopped arriving

A Let’s Encrypt certificate is valid for 90 days by default, and the issuer recommends renewing at 60. The same FAQ now documents an opt-in six-day certificate, renewed every three days. Both are fine while automated renewal works. The failure mode is that renewal is a background job, and background jobs stop for ordinary reasons: port 80 gets firewalled, a DNS record moves, a cron entry dies with the server it was migrated off. Those mechanisms are well documented. The rate at which they occur is not. We looked for a population-level measurement of how many live small-business sites are serving an expired certificate on any given day and couldn’t find one in any credible dataset, so treat certificate expiry as a documented mechanism rather than a quantified risk.

What changed recently is that the safety net came off. Let’s Encrypt ended its expiration notification emails on 4 June 2025 and deleted the stored addresses, pointing subscribers at third-party monitoring instead. The warning that used to catch a failed auto-renewal no longer arrives.

At the same time the interval is shrinking. The CA/Browser Forum passed ballot SC-081v3 in April 2025, scheduling maximum public certificate lifetime down from 398 days to 47 between March 2026 and March 2029. The Forum’s summary states the endpoints and the window; the intermediate steps that certificate vendors publish are not on that page, so treat those as vendor guidance rather than settled policy. Who this actually changes things for depends on what the site runs on. A site sitting on a one-year commercial certificate faces roughly eightfold more renewals by 2029, because 398 divided by 47 is a little over eight. A site already on Let’s Encrypt renews at exactly the cadence it renews at today, and gets no reminder when the job fails.

Expiry is not the only way a certificate stops working. Chrome stopped trusting new Entrust and AffirmTrust certificates after a pattern of compliance failures, which means a site with a valid, unexpired, correctly installed certificate can still fail because the browser changed its mind about the issuer.

What the visitor sees is a full-page interstitial saying the connection is not private. Almost nobody clicks past it, and on a site with HSTS nobody can.

Enterprise survey data suggests this is common at scale. CyberArk’s 2025 State of Machine Identity Security Report found 72% of surveyed organisations had at least one certificate-related outage in the previous year. Read the sample before you read the number. Censuswide surveyed 1,201 security and IT decision-makers at organisations with 500 or more employees, across six countries, between 9 and 17 January 2025, and CyberArk sells certificate lifecycle management. Nothing in that sample describes a small business.

Email that stops arriving

Since 1 February 2024, Gmail has required every sender, at any volume, to publish SPF or DKIM, have valid forward and reverse DNS, transmit over TLS, and keep reported spam below 0.3%. Bulk senders need more. Microsoft went further at the volume end: since 5 May 2025, mail reaching Outlook.com, Hotmail and Live from a sender pushing more than 5,000 messages a day has to pass SPF and DKIM and DMARC with alignment, which is stricter than Gmail’s all-sender tier, and non-compliant mail is rejected.

The all-senders tier is the one that matters for a small business. A contact form or an order confirmation sent from a server whose DNS was never finished fails a published requirement every day it runs. The rejection goes back to a server log nobody reads. The owner sees nothing, the customer assumes the purchase failed, and the complaint turns up weeks later.

There is a legal edge to this in Canada. CASL requires the unsubscribe mechanism in a commercial message to stay valid for at least 60 days after the message is sent, and requires the request to be actioned within 10 business days. An unsubscribe endpoint that was decommissioned during a hosting move is a statutory problem, not just an annoyance.

The integrations that move quarterly

Shopify ships a new API version every quarter and supports each stable version for a minimum of twelve months. Google Maps Platform publishes a rolling deprecation list with roughly twelve months of notice; google.maps.Marker was deprecated in February 2024, legacy cloud-based map styling ended in March 2025, and the Heatmap Layer and Drawing Library were discontinued in May 2026.

Maps has the most recognisable of these symptoms. A map with a missing key or disabled billing renders darkened and watermarked “for development purposes only”. Every visitor sees it. The owner, who loaded the page last week, often doesn’t.

Years two and three: the failures that do not throw an error

This is the band that does the real damage, because everything still looks fine.

Silent fallback to an older API version

Meta guarantees a Graph API version for a minimum of two years, and its documentation is explicit about what happens next: once a version becomes unusable, calls to it are automatically redirected to the next oldest usable version. Nothing errors. The integration keeps returning success while the data quietly changes shape.

The dates are published. Meta’s version table shows v18.0 expired in January 2026, v19.0 in May 2026, and v20.0, released on 21 May 2024, expiring on 24 September 2026. A Facebook login or page feed built on v20.0 reaches its expiry just over 28 months later. Shopify does the same thing, calling it falling forward to the oldest accessible stable version.

Stripe deliberately does the opposite. Accounts are pinned to an API version, monthly releases are backwards-compatible, and breaking changes ship twice a year as named major releases. Our reading of that policy is that payment integrations rarely break because Stripe removed something. They break one layer down, which is the next problem.

Runtimes reaching end of life

PHP gives each branch two years of active support plus two years of security fixes. Four years total. PHP 8.2 stops receiving security fixes on 31 December 2026. Node runs on a comparable clock: an even-numbered major gets 30 months of long-term support, and because long-term support begins roughly six months after the initial release, that is about three years from release to end of life. Node has announced that its release schedule changes from October 2026, so read the 30 months as current rather than permanent. In our experience four years is shorter than the gap between rebuilds on most of the sites we get asked to look at. Staying inside those windows is the line item that appears on a quote as three words, and what those three words actually cover is the whole question.

Plenty of sites are already past it. Of the sites W3Techs detects running PHP, 28.0% are on PHP 7 and 7.8% are still on PHP 5, both long unsupported. That is a share of PHP sites rather than of the whole web, and it counts every abandoned page as equal to a working storefront. It still describes a large population of software nobody has touched in years.

Runtime end-of-life is also how a payment integration eventually dies, though not on the timetable you would expect. Stripe deprecates SDK support for a language runtime once that runtime reaches end of life, with an extended support window of one to two years before the next major SDK drops it. PHP is the documented exception. Stripe states on that same page that it has no firm PHP version deprecation policy, supports PHP 7.2 and above, and lists PHP 7.4 and 8.0, both years past end of life, as supported with no deprecation plans. So the site most exposed by an abandoned PHP version is, on Stripe’s own published policy, among the least likely to lose its SDK. The runtime is still unpatched. The library carries on working on top of it, which is the worse outcome, because nothing signals the problem.

Measurement that quietly stops

Universal Analytics stopped processing hits on 1 July 2023, and from July 2024 the properties, interface and API were switched off and the historical data deleted. Sites that nobody maintained kept loading fine throughout. They just recorded nothing, and then lost years of history. It is the clearest example of the category: a failure with no symptom until the moment you need the data.

The domain, where the alarm is designed in

Domain expiry is the one case where the alarm is built into the policy. Under ICANN’s Expired Registration Recovery Policy, registrars must send at least two expiry reminders, may offer an auto-renew grace period of 1 to 45 days, and the registry guarantees a 30-day redemption window. The policy also requires registrars to disrupt the domain’s DNS service for up to eight days before deleting it, specifically so that the website and email stop working as a warning. The interruption is the mechanism, not a side effect. The site going dark is the alarm, not the end state.

Two practical notes. In our experience the trigger is rarely forgetting the renewal; it is the credit card on file expiring before the domain does. And a .ca does not follow the ICANN path. CIRA publishes its own lifecycle, and the first step is the reverse of the gTLD one: at expiry CIRA renews the name automatically for a year and charges the registrar. The registrar can delete it during the auto-renew grace period; otherwise that period runs its full 45 days and the domain returns to registered status. A deleted .ca then enters a 30-day redemption grace period, during which the website and email stop working and the registrar can still restore it, before the name goes to the To Be Released list. Same shape, different first move, and the automatic renewal is why a neglected .ca can keep working long enough for nobody to notice.

After three years: a moving baseline

Past the three-year mark the failures get harder to name, and this is where most writing on the subject starts inventing numbers. Here is what the evidence actually supports.

A site does not get heavier by itself. What moves is the baseline it is judged against. HTTP Archive’s Web Almanac measured median page weight in 2025 at 2,862 KB on desktop and 2,559 KB on mobile, with the median mobile home page up 202.8% since July 2015. That measures the web’s median growing, not one site decaying. An untouched site gets heavier for a much more ordinary reason: someone keeps uploading full-resolution photographs through the CMS.

The bar for performance also moves independently of your code. Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, with 9 September 2024 set as the deadline for moving off FID. A site that passed in 2023 could fail in 2024 without a single line changing. As of the 2025 crawl, 48% of mobile origins and 56% of desktop origins passed all three Core Web Vitals.

Dependencies you do not control accumulate. At least 90% of pages load a third party, with a median of 79 third-party requests on mobile. Each of those has its own deprecation schedule.

Databases accumulate too, and here the evidence is thin enough to say so. There is no credible measurement of how a CMS database grows on an unmaintained site. What exists is a change in WordPress itself: version 6.6 stopped autoloading any new option larger than 150 KB and added a critical Site Health warning above 800 KB of autoloaded data, because accumulated options slow every page request. That is primary evidence the problem is real enough to engineer against. Everything beyond it, in our experience, is agency anecdote, including ours.

Browsers are the one place where a hard date is coming. Chrome will enable Always Use Secure Connections by default in Chrome 154 in October 2026, warning users before any public HTTP navigation, with opted-in Enhanced Safe Browsing users getting it in Chrome 147 in April 2026. Any legacy page, embed or redirect still on plain HTTP becomes an interstitial. Mixed content is already handled quietly: Chrome autoupgrades audio, video and image subresources to HTTPS and does not load them if the HTTPS fetch fails. That is why old hardcoded http:// image paths vanish from a page without anyone editing it.

One counterweight, because this register invites overstatement. Third-party cookies were not deprecated. Google decided in April 2025 to maintain its existing approach in Chrome and not ship a standalone prompt. Some of what agencies told businesses to rebuild for never happened.

The claims that do not survive checking

Four things get asserted constantly on this topic. None of them holds up in the form it is usually repeated.

• The cost of an hour of downtime. We traced the figures in circulation back to a Gartner blog post by the analyst Andrew Lerner dated 16 July 2014, whose original page is no longer live, and could not find a current primary source for any of them. Lerner’s own framing was a midpoint of a wide range with large variance, in US dollars, which is not how the pages quoting it at you as a current figure present it. We will not repeat a twelve-year-old midpoint as a 2026 number, and neither should they.
• “66% of pages older than two years lose organic traffic.” This is attributed everywhere to a 2024 Ahrefs study. It is not on Ahrefs’ content decay article, which presents no original decay dataset at all, and a site-restricted search of ahrefs.com did not surface it either. The nearest real Ahrefs figure is from its link rot study, which states that since January 2013, 66.5% of the links pointing to the 2,062,173 websites it sampled have rotted. That is a measurement of dead links, not of traffic. One statistic appears to have mutated into a different claim.
• Search visibility decaying from age alone. No longitudinal study shows that an unchanged, technically healthy page loses organic traffic purely because time passed. What is documented is adjacent and real. Pew found 38% of web pages that existed in 2013 were no longer accessible by October 2023, so the link graph around a page erodes whether or not anyone touches it. Google states plainly that there is nothing wrong with pages that drop in ranking after a core update. And Pew measured Google users clicking a result on 8% of visits where an AI summary appeared, against 15% without one, on a US sample. Traffic falls for reasons that have nothing to do with your site.
• Mobile-first indexing as a hard cutoff. Half of this one is true, and it is the useful half. Google’s documentation, updated in December 2025, says a mobile version of your pages is not required for inclusion in Search but is very strongly recommended. Google’s Search Central blog is firmer about the floor: after 5 July 2024, when the last desktop-Googlebot crawling ended, content that is not accessible at all on a mobile device is no longer indexable. Both statements are current and they are not in conflict. A site that is merely awkward on a phone stays in the index. A site that will not load on a phone does not.

Fixing it late instead of early

We are not going to put a dollar figure on any of this, because the published ones are not trustworthy and ours would be a rate card. The market ranges, with their methodology stated, are in what you’re actually paying for in a website maintenance plan.

What we can describe is the shape of the difference, from doing the work both ways.

Scheduled work is bounded. A certificate renewal someone watches takes minutes. The same certificate expiring on a Saturday is an outage, a scramble for credentials nobody has used in two years, and an emergency rate.

Upgrades compound. One PHP major version is routine. Three at once, with a decade-old theme and plugins whose authors have disappeared, is a migration priced as a rebuild, and the business does not get anything new out of it. Falling behind converts maintenance into capital expenditure.

Someone else sets the deadline. Every date in this post was chosen by a certificate authority, a platform or a browser vendor. Work you plan happens when it suits you. Work you defer happens on the day Meta expires a version, which is not a day you chose and is often the week before your busiest month.

Everything here has a date on it

Certificates, API versions, runtime end-of-life dates, browser releases and email requirements are all published in advance, which means the failure modes of a neglected site are knowable rather than mysterious. Nobody sends you the calendar, but nobody is hiding it either.

The useful move isn’t alarm. It’s a list: every expiry date that applies to your site, on a calendar, with one named person against it. What that list looks like in practice, and how often each item needs attention, is in what happens after launch.

Canaan builds software and maintains it afterwards. That means tracking the expiry dates above, keeping runtimes and dependencies current, watching integrations that fall forward silently, and telling you plainly when something on your site has stopped working without saying so. Including when the answer is that you don’t need this yet.

Start a project

Sources

• Let’s Encrypt (ISRG), FAQ: certificate lifetime and renewal, retrieved September 2026. Default certificates are 90 days with renewal recommended at 60; the opt-in short-lived certificate is six days, renewed every three
• Let’s Encrypt (ISRG), Expiration notification service has ended, 26 June 2025. Service ended 4 June 2025
• CA/Browser Forum, Ballot SC-081v3: introduce schedule of reducing validity and data reuse periods, 11 April 2025. The summary page states the 398-to-47-day endpoints and the March 2026 to March 2029 window; intermediate steps reported by certificate vendors are not stated there
• Google Security Blog, Sustaining digital certificate security: Entrust certificate distrust, 27 June 2024. This post is the origin of every secondary write-up of the Entrust distrust; the claim made here is limited to the fact of the distrust and its scope to newly issued certificates
• CyberArk, 2025 State of Machine Identity Security Report, announced 13 March 2025 via Business Wire. Fieldwork by Censuswide: 1,201 security and IT decision-makers at organisations with 500 or more employees in the USA, UK, Australia, France, Germany and Singapore, 9 to 17 January 2025. CyberArk’s own report page now redirects to Palo Alto Networks following the acquisition, so the press release is cited as the origin. CyberArk sells certificate lifecycle management
• Google Workspace Admin Help, Email sender guidelines, requirements effective 1 February 2024, page current
• Microsoft, Strengthening the email ecosystem: Outlook’s new requirements for high-volume senders, effective 5 May 2025. Applies to senders of more than 5,000 messages a day to Outlook.com, Hotmail and Live, and requires SPF, DKIM and DMARC with alignment
• Government of Canada, Justice Laws, Canada’s Anti-Spam Legislation, S.C. 2010 c. 23, s. 11, in force 1 July 2014
• Shopify, API versioning, retrieved September 2026
• Google Maps Platform, Deprecations and Error messages, retrieved September 2026
• Meta for Developers, Graph API versioning and Graph API versions changelog, retrieved September 2026. v20.0 released 21 May 2024, expires 24 September 2026
• Stripe, API versioning and SDK versioning and support, retrieved September 2026. The one-to-two-year extended support window is the general policy; the same page states there is no firm PHP version deprecation policy
• The PHP Group, Supported versions, retrieved September 2026
• OpenJS Foundation, Node.js previous releases and release schedule, retrieved September 2026. The 30 months is the long-term support guarantee, which begins when a major enters LTS about six months after its initial release. Node has announced a change to the release schedule from October 2026
• W3Techs, Usage statistics of PHP versions, retrieved 22 September 2026. The denominator is sites that use PHP, not all websites: W3Techs states that PHP 8 is used by 64.1% of all the websites that use PHP
• Google Analytics Help, Universal Analytics sunset, retrieved September 2026
• ICANN, Expired Registration Recovery Policy: information for registrants, page dated 7 December 2018, policy in force since 2013. Applies to gTLDs only
• CIRA, .ca domain name life cycle, retrieved September 2026. CIRA returns an error to automated retrieval; the lifecycle steps cited here are from the published page
• HTTP Archive, Web Almanac 2025, Page Weight, Performance and Third Parties chapters, published 15 January 2026, July 2025 crawl
• web.dev (Google), Interaction to Next Paint becomes a Core Web Vital, 12 March 2024. The post sets 9 September 2024 as the transition deadline rather than recording the removal
• Make WordPress Core, Options API: disabling autoload for large options, 18 June 2024
• Google, A safer default for navigation: HTTPS, 28 October 2025
• Chromium project, Mixed content autoupgrades, retrieved September 2026
• Google Privacy Sandbox, Privacy Sandbox next steps, 22 April 2025
• Gartner, Andrew Lerner, The Cost of Downtime, 16 July 2014. Cited for provenance only. The original page is no longer live, and no figure from it is repeated in this post
• Ahrefs, Content decay and Link rot study, link rot study published April 2022, updated 2 February 2024, content decay article updated 13 March 2026. Both checked 22 September 2026 for the widely repeated “66% of pages older than two years” figure, which appears on neither page nor elsewhere on ahrefs.com in a site-restricted search
• Pew Research Center, When online content disappears, 17 May 2024, and Google users are less likely to click on links when an AI summary appears, 22 July 2025. The second study tracked 900 US adults and 68,879 searches; the sample is American, not Canadian
• Google Search Central, What site owners should know about core updates, August 2019, still live and still current guidance
• Google Search Central, Mobile-first indexing: the last of the last, June 2024, effective after 5 July 2024, and Mobile site and mobile-first indexing best practices, last updated 10 December 2025

This post contains no cost figures and no market price ranges, so no pricing methodology applies. Where remediation cost comes up it is described in relative terms from our own project experience and is explicitly not a rate card; published Canadian ranges, with their sample and collection window stated, are in the companion post.

← All writing