We got an emergency call at 8:14 on a Wednesday morning last September. A regional services firm's website was throwing a 500 error on every URL. Their main contact phone number was wired through their site's chat widget. The chat widget was loading from a CDN that had also broken. The site had been live for six years on the same WordPress installation. None of the people who'd touched it last were still at the firm.
We had it back up by 11:30 that morning. It took the rest of the week to figure out what had actually broken, because the failure wasn't in any single place. A core WordPress update had auto-applied overnight. The auto-update broke compatibility with three of the seventeen installed plugins. One of those plugins was the form vendor. One was the security plugin that was supposed to alert them when something broke. One was the cache plugin that had cached the broken state and was serving 500s to every visitor including the admin. The whole stack had compounding failure.
That call is the reason this article exists. Sites don't fail loudly. They decay. The decay accumulates quietly for months until a single trigger, a core update, a vendor outage, a credential rotation, an SSL cert expiry, knocks the whole thing over. And the firm finds out from a customer who couldn't fill out a form, or from a Google Search Console alert two weeks late, or from an emergency call to whichever agency they can reach.
This piece is about the failure patterns we see most, and what an actual maintenance contract, the operational discipline that prevents the emergency call, looks like.
How websites actually break
Decay patterns, ranked by frequency in the audits we run.
Plugin and dependency rot. A WordPress site averages between fifteen and twenty plugins. A Next.js site averages between eighty and three hundred npm dependencies. Neither stack is broken at launch. Both stacks rot if nothing maintains them. Plugins go abandoned by their authors. Dependencies get CVEs published against them. The auto-update setting is either off (so the rot accumulates) or on (so a breaking change ships overnight without warning). Either failure mode shows up in the audit log months later when something visibly goes wrong.
SSL certificate expiry. Cert renewals are automated on most modern hosts, but every few weeks I find a site where the cert is about to expire because the host's automation didn't run, the DNS records moved without the cert authority knowing, or the cert was issued by a service that stopped renewing free certs and nobody noticed the new credit-card requirement. When the cert lapses, every browser shows a security warning instead of the site. We've had clients lose 38 percent of inbound traffic for the four hours their cert was lapsed. Forty-eight minutes of work to renew. Four-figure revenue impact.
Form vendor SMTP rotation. The form on the contact page sends notifications via Mandrill, SendGrid, or whatever service the original developer wired up. The vendor rotates an API credential. Nobody at the firm has the new credential. Form submissions silently stop arriving. The form appears to work, the prospect gets the success page, the auto-responder fires from the vendor's side, but the firm never sees the lead. We find this every other audit. It can run undetected for months.
Cache layer fighting the CDN. WordPress with W3 Total Cache, layered with Cloudflare, layered with a host-level cache. Three caches that don't know about each other. A new blog post publishes and one of the layers serves the old version. A pricing page updates and the cached version still shows the old price. A redirect ships and one of the layers hasn't invalidated. The site looks fine on a logged-in admin browser. The visitor gets stale content from one of the cache layers.
Schema markup that drifted. Schema gets generated by an SEO plugin or a custom script at launch. The plugin auto-updates and the schema schema changes. Or a developer pushes a new template and forgets the schema component on the new version. Or Google deprecates a property type and the existing schema validates as an error. The site keeps ranking for a few weeks while the search engine reconciles, then drops. Nobody at the firm noticed because the schema is in a <script type="application/ld+json"> block that no human reads.
Background third-party scripts going rogue. The chat widget vendor pushes a new version that loads twelve additional tracking scripts. The video embed adds a 4MB autoplay video to the homepage that wasn't there at launch. The cookie consent banner gets a new compliance feature that blocks render on the first paint. None of these changes were the firm's decision. They happened because a vendor pushed them. The site's Core Web Vitals scores drift from Good to Needs Improvement to Poor across two quarters and nobody noticed because nobody is monitoring.
Plugin and theme abandonment. The page builder the previous agency used was sold to a private-equity owner that stopped maintaining it. The theme is now eight major versions behind, and the only update path is a full rebuild on a different stack. The firm has a working site today and a $40,000 rebuild bill in twelve months because the stack the original agency picked is no longer a real product.
Domain and DNS ownership lost in transition. The original developer had the domain registered under their personal Gmail. The agency the firm hired to manage the site doesn't have access. The firm hires us to fix the SSL issue and we discover nobody on the firm's side can authorize the change because the registrar is locked to a personal email of someone who left two firms ago. This audit finding is more common than it should be.
What a maintenance contract should actually cover
Most "website maintenance" contracts are a euphemism for monthly invoices that don't tie to specific deliverables. The agency invoices $400 a month. The firm pays. Nothing measurable changes. Twelve months later, the firm asks what they're paying for and the answer is uptime monitoring nobody's looked at.
Real maintenance is a checklist of operational tasks with monthly cadence and clear ownership. The version we run on every client we host through our managed hosting tier:
Weekly: dependency review. Patch level on every plugin. Pending updates. Plugins flagged as abandoned by their author. CVE feed reviewed against the installed dependency list. Decisions logged for what to update, what to defer, what to replace. Five to ten minutes of operator time per week.
Weekly: Core Web Vitals scan. Synthetic test against the homepage and three high-value templates from a fresh mobile browser. LCP, INP, CLS captured against the previous week's baseline. Any regression over 10 percent triggers an investigation. We run this in Orbit so the trend line is visible across the engagement, not a one-time PageSpeed report.
Weekly: form trigger test. Every public form on the site gets submitted with a traceable identifier. Submissions are confirmed in the firm's inbox, the CRM, and (where applicable) the ad platform conversion log. If any leg of the trip is broken, we find out within a week instead of within a quarter.
Weekly: 404 + redirect audit. Crawl finds new broken paths from the prior week. Internal links pointing at 404s get fixed. New external 404s get redirected to the right replacement page so backlink equity isn't lost.
Monthly: schema validation. Every page with structured data gets validated against Google's Rich Results test. Any new error or warning gets fixed the week it surfaces.
Monthly: SSL + DNS check. Cert expiry, DNS record drift, registrar lock status. We hold the credentials for our managed clients (or the credentials are held by a named person at the firm with documented escalation). The cert never lapses because the renewal is monitored.
Monthly: security log review. WordPress + plugin security logs reviewed for failed login attempts, unauthorized admin creations, suspicious file changes. Wordfence or equivalent at the application layer, plus host-level WAF, plus geographic rate limiting on /wp-login.php. None of this is novel. It's just operational discipline that almost nobody runs consistently.
Quarterly: backup restore drill. Backups don't exist if you've never restored from them. We restore the most recent backup to a staging environment quarterly to confirm the backup is real. About one in fifteen audits, the backup is corrupt or incomplete. Better to find out in a drill than at 8:14 a.m. on a Wednesday.
Quarterly: vendor review. Every third-party service the site depends on gets reviewed. Pricing changes. Deprecations. Acquisition or shutdown announcements. The chat widget the firm has used for three years gets re-evaluated against the alternatives. The form vendor's pricing tier gets checked against actual volume. The CRM integration gets stress-tested against the new release cycle.
Annual: full security audit + penetration test. On the annual cadence rather than monthly because pen tests are expensive and most months don't need one. The annual sweep finds the issues that monthly hygiene didn't catch.
That's roughly the cadence. The bill for this kind of monitored maintenance, properly run, is between $1,500 and $4,500 a month depending on the platform, traffic, and integration count. It's substantially more than the $400 / month placeholder most firms are paying for nominal "maintenance." It's also the difference between an emergency call at 8:14 a.m. and a Slack message at 4 p.m. on Tuesday.
The math on doing this versus not doing this
Skipping the maintenance discipline doesn't save money. It defers cost.
A WordPress site that hasn't been maintained for two years takes between forty and a hundred and twenty hours to rehabilitate when the firm finally decides to fix it. At our blended rates, that's $10,000 to $30,000 in remediation work. Or, more often, the site is past the point of clean rehab and the answer is a full rebuild for $48,000 to $120,000. Either way, the deferred cost compounds.
The math on a $2,500-per-month maintenance contract: $30,000 over a year. Six years of clean maintenance is $180,000. That's roughly the cost of one emergency rebuild that becomes necessary because nobody was watching the decay. Maintenance is actually cheaper than the alternative the moment the alternative becomes a real rebuild.
We see clients pick the wrong side of this math constantly. The marketing budget gets cut, the maintenance line gets killed first, the rebuild bill arrives 18 months later. Most CFOs would have signed the maintenance line if anyone had shown them this math directly. The reason they don't see it is that maintenance is sold as a checkbox on the agency invoice, not as the structural risk reduction it actually is.
When you should not pay for managed maintenance
Two cases.
You have an in-house developer who actually does the work. Not nominally, actually. They run the weekly dependency review, the form trigger test, the schema validation. They're not the marketing person who knows enough to deploy a content change. They're a developer with the time and the discipline to run the cadence. If that's true, you don't need us. You have us.
The site is shipping low-stakes content with no integrations and no commerce. A five-page consultancy site on Squarespace, no forms wired to a CRM, no paid program running, no real revenue going through the site. Maintenance still matters in principle, but the risk-adjusted cost of a managed contract is over the value of the site itself. Get the basics right at launch and check it once a quarter manually.
Otherwise, don't run a service-business website without an actual maintenance program behind it. The decay starts week three. The cost of remediation grows monthly. The first emergency call is the warning shot.
If you're not sure where your site is on the decay curve, the audit is the same audit we run before any of our managed engagements. Half a day of operator time, finds whatever is broken, and we'll either scope the fix or hand you a punch list for whoever does the work. We do this free for two to four firms a quarter as the entry point to longer engagements.