A site can launch fast, accessible, and passing every check, then quietly fail half of those checks a quarter later without anything breaking in between. Ongoing website maintenance is the recurring work that catches that drift, and what it actually covers is four things: performance, accessibility, dependency health, and the structural parts of a site that break without throwing an error.
Nothing dramatic happens as a site drifts. A dependency falls a few versions behind a security patch. A plugin update nudges a layout out of alignment on one template. A contrast ratio slips below AA the next time someone adjusts the brand color. A third analytics script lands because the marketing team needed it that week.
Each change is small, reasonable, and invisible on its own, and none of it trips an alarm. The site still loads, the build still passes, and the dashboard still shows green. What is missing at that point is ownership rather than tooling: the team that shipped the site has moved on to whatever came next, and nobody’s week has “check whether any of this still holds” in it.
The first real signal tends to come from outside the team: a ranking that slips, a user who cannot finish a form, a routine update that breaks something nobody had touched in a year. By then the fix is bigger than it needed to be, because six small regressions compounding across two quarters are harder to untangle than any one of them caught the week it landed.
Why a healthy site drifts
The site does not have to be broken for this to happen. Four things move after launch, and none of them throw an error when they do.
The dependencies age. Libraries, frameworks, and plugins ship updates on their own schedule, which means a site that stays still is really drifting backward against a moving baseline. A package a year behind a security patch is not a crisis on its own, but it is the start of one, and the distance between fine and urgent is measured in how long nobody looked.
The content changes. Headless or traditional, a CMS exists to let non-developers edit the site, and those edits accumulate: a new heading level that breaks the document outline, an image uploaded without alt text, a banner block dropped into a template it was not built for. Accessibility and structure drift toward whatever was quickest to publish.
The brand moves. A refreshed marketing page, a new brand color, a restyled button. Each one is a decision someone made for good reasons, and each one is a chance for a contrast ratio to slip, a focus state to disappear, or a component to ship without its keyboard path retested.
The bar itself moves. Accessibility standards update, and the metrics search engines grade you on change with them. INP replaced FID as a Core Web Vital, and sites that passed the old metric failed the new one without changing a line of code. When the rule moves and the site does not, the site is the thing that fell behind. We covered that swap in the INP post, and the pattern is general: a site can become noncompliant or slow without anyone touching it.
What ongoing website maintenance actually covers
The answer to “what am I paying for” is a short list, and it is worth stating plainly. Four areas, each with a specific thing it catches.
1. Performance against Core Web Vitals. A one-off Lighthouse run is a lab snapshot, not the signal. The signal is field data, how real users on real devices experience the site over time, watched on a schedule so a regression is caught when it is a single script or image rather than a slowdown nobody can trace back to its cause. A recurring check baselines LCP, INP, and CLS against the prior month and flags the movement, not the absolute number.
2. Accessibility against WCAG. Conformance is not a state you reach once. The WebAIM Million 2026 analysis found the average home page now carries 56.1 detectable accessibility errors, up 10.1% in a year, reversing years of gradual improvement. Most of that drift is the content and brand changes above, not failures introduced on purpose. A recurring audit catches a slipped contrast ratio or a missing label in the week it lands, while it is one element, instead of the next full audit reporting it as a regression from your last clean pass. The standard itself, and which rules apply to your site, is covered in the compliance post.
3. Dependency and security health. This is the piece developers think of first and buyers think of last. Outdated dependencies are the failure mode that stays invisible until it is urgent: a known vulnerability in a library you use, a patch you have not applied, a plugin the maintainer abandoned. A recurring check audits the dependency tree, flags what is behind, and separates the security-critical updates from the cosmetic ones so the work goes to what actually matters.
4. Structure and third-party creep. Broken internal links, redirected URLs that never got fixed, schema markup that went stale after a page restructure, and the scripts that accumulate one marketing campaign at a time. Each third-party script is a performance and privacy cost, and they rarely get removed when the campaign ends. A recurring check inventories what is loaded on the page and flags what was added since the last pass, because nobody on the team remembers asking for the fourth analytics tag.
That is the inventory. Notice what is not on it.
What maintenance is not
Hosting is infrastructure, not product care. Uptime, server health, backups, and managed platform updates are the hosting layer’s job, and they live or die on the provider rather than on whether someone is minding your site. The Monitor service exists to draw exactly that line, and a maintenance plan that lists “uptime monitoring” as a deliverable is describing the floor, not the work.
Maintenance is also not a build. New features, design refreshes, and platform migrations are project work, not recurring care, and they get scoped and priced as projects. The line matters because the two are sold differently and fail differently: a build fails by shipping late or wrong, maintenance fails by going quiet for six months and letting the drift compound. If the drift has already compounded into a real question about how far to go, that is a redesign versus rebuild decision, not a maintenance line item.
One check you can run now
You do not need a retainer to start. Run a baseline this week and compare against it next month.
Run a Lighthouse pass on your three highest-traffic pages and save the report. Run the same pages through a free accessibility checker and save those results. Generate a dependency audit, a single command in most stacks that lists every package and how far behind it is. Put all three in a folder dated today.
Next month, run the same three and diff them. Anything that moved is a regression that happened in the last thirty days, which means it is one change you can find and fix. Anything that did not move is a floor you can build on. The method is the whole point: a baseline plus a recurring comparison turns “the site got worse at some point” into “this changed between June and July, and here is the diff.” That is what ongoing maintenance is, whether you run it yourself or someone runs it for you.
The cost of catching it late
Recurring checks pay for themselves in a concrete way, because the same regression is cheap to fix the week it lands and expensive to fix two quarters later. A dependency one version behind is an update. A dependency a year behind, sitting next to three others in the same state, is a migration someone has to plan, schedule, and test against a site that has forgotten how it was built.
The math runs the same way across all four areas. One broken link is a redirect. Forty broken links, accumulated because nobody checked, is an SEO cleanup. One slipped contrast ratio is a one-line fix in the design system. A dozen of them, across templates that drifted independently, is a re-audit and a remediation pass. The difference is never the size of any single change; it is how long the changes were allowed to stack before someone looked.
Launch is half the job
Launch is half the job. The other half is the slow, invisible work of keeping the site where it was the day it shipped, against a baseline that moves whether you move or not. The teams whose sites stay healthy baseline where the site is, check it on a schedule, and fix the drift while it is still one line of code instead of two quarters of buildup.