Website maintenance for custom-built sites: 2026 guide

The real cost isn't downtime; it's the slow erosion of the value the original build delivered. This guide breaks down what actually decays, what a real maintenance model, cadence, and SLA look like, and what it should cost in 2026. In more extreme cases, years of deferred maintenance can push a team past patching and into rebuilding legacy web apps entirely.

What is website maintenance? (BLUF)

Website maintenance is the ongoing work of keeping a live site secure, fast, and functional after launch: patching dependencies, watching for regressions, and upgrading frameworks before they lose support. On a custom build, none of this happens automatically the way it does on a managed platform. The original development lifecycle explains where maintenance picks up once planning and launch are behind you.

That's the trap. A custom site doesn't fail loudly on the day something breaks. It decays through dependency drift and framework end-of-life first, then shows up months later as a failed security review or a Core Web Vitals score that's quietly tanked, per web.dev's Core Web Vitals guidance, which replaced FID with Interaction to Next Paint as the interactivity metric in March 2024.

After running long-term maintenance retainers across replatforming and dependency-upgrade projects, we've measured the CWV/INP recovery and vulnerability-count deltas neglect causes on sites left unmaintained for a year or more. Quick win: run npm audit or a Snyk scan today. More than a handful of high-severity findings means maintenance is already overdue, not upcoming.

What actually decays on a custom-built site

What actually decays on a custom-built site is the stack itself, not the content. Dependency drift, framework end-of-life, Core Web Vitals regression, and integration rot compound quietly, invisible until a security scan, an audit, or a lost ranking surfaces all four at once.

Dependency drift. Every package.json starts pinned to current, stable versions. Eighteen months later, transitive dependencies have moved through several major releases, and the gap between installed and available versions is where known CVEs stack up unnoticed. Renovate or Dependabot catch this automatically if someone is watching the pull requests; Snyk or npm audit catch it if nobody is.

On sites we've inherited after a year or more without attention, it's routine to find dependency trees carrying dozens of unpatched, publicly disclosed vulnerabilities in packages nobody remembers adding.

Framework end-of-life. Next.js and React both run an LTS-style cadence: security patches stop landing on old major versions once a new one ships. A site frozen on an end-of-lifed framework version isn't insecure on day one, it's insecure the day the next CVE targets exactly the version it's stuck on.

Core Web Vitals and INP regression. Google replaced First Input Delay with Interaction to Next as the responsiveness metric in March 2024, setting 200 milliseconds as the threshold for a "good" rating. Unmonitored builds drift past it as third-party scripts, unoptimized images, and unmemoized components accumulate release over release, each shipping clean in isolation.

Integration and API rot. Payment gateways, CRMs, and marketing tools version their APIs and deprecate endpoints on their own schedule, not yours. A webhook that worked at launch can fail silently for weeks before anyone downstream notices the data stopped flowing.

CMS drift. In a headless CMS setup (Contentful, Storyblok, Strapi), content editors add fields and reference structures the front end was never built to render, and the model drifts out of sync with the code that consumes it.

Accessibility drift. Every new component and marketing page shipped without a WCAG 2.2 check erodes conformance the same way dependency drift erodes security. In the EU, this is no longer discretionary: the European Accessibility Act has been enforceable since 28 June 2025, per the EU directive text.

Security debt. Left long enough, all five of the above collapse into the same failure mode covered by OWASP Top 10: outdated dependencies, unpatched frameworks, and unreviewed integrations are the paths attackers actually use. Each one is invisible from the outside until someone goes looking.

We'd argue that's the real threat model for a custom build: not a single hack, but five slow leaks nobody is watching at once.

Why the standard maintenance checklist stops working for custom builds

The standard checklist, renew SSL, update plugins, back up weekly, exists because most sites run on WordPress, Wix, or Shopify, where the vendor owns and patches the runtime centrally.

That checklist assumes one thing: a shared, vendor-managed core doing the heavy lifting underneath your content. A custom-built site, a Next.js or React front end on a headless CMS like Contentful, Storyblok, or Strapi, has no such core. Every dependency, build step, and integration is something your team owns and patches directly.

If you're planning a custom build from scratch, it helps to revisit the full project lifecycle before maintenance even becomes a concern.

According to GitHub's Octoverse security report, the median repository carries dozens of known-vulnerable transitive dependencies before a single manual audit catches them, a risk that plugin-based platforms absorb centrally and custom stacks do not.

Running a plugin-update routine against a headless CMS setup checks nothing that matters: no plugins to update, no vendor SSL renewal, and no theme layer masking a framework three major versions behind end-of-life. The failure mode moves from the CMS layer to the code you or your vendor wrote and now must maintain, permanently.

The seven layers of a real website maintenance model

A real website maintenance model has seven layers, security, dependencies, performance, content and CMS, accessibility, infrastructure and uptime, and SEO, and each one decays on a different clock. Treating maintenance as one item on a checklist instead of seven separate disciplines is the single biggest reason custom builds rot quietly.

If managing all seven disciplines in-house feels unrealistic, professional software maintenance services can absorb the routine and specialized work so internal teams stay focused on critical tasks.

Each layer needs its own cadence and its own owner, not a shared Tuesday-morning glance.

On security, a Content Security Policy is table stakes, not a bonus header, because it is the first line of defense OWASP lists against injection and data-exfiltration attacks. On dependencies, Snyk's annual open source security research has repeatedly found that most commercial codebases carry at least one dependency with a known, unpatched vulnerability.

Of the codebase audits we've run on client sites that had gone 12+ months without a maintenance owner, nearly all surfaced double-digit counts of outdated major dependency versions before the first sprint even started.

Google Search Console and PageSpeed Insights answer two different questions, whether Google can find and understand the site, and whether the site is fast enough to rank once it does. Treat them as separate diagnostics feeding into the performance and SEO layers, not one dashboard you check once a quarter.

Website maintenance checklist: Weekly, monthly, quarterly, annual

A useful website maintenance checklist is organized by clock speed, not by task type. Some things belong in CI. Others run weekly, some need a human quarterly, and a few only matter once a year, but rarely at all.

Most published checklists (ours included, in earlier drafts) mix these together and end up with a list nobody actually runs. The version below is the one we use on retainer engagements.

On one long-running retainer we audited in 2026, the client's CI ran unit tests but nothing budget-based. By the time we wired Lighthouse CI into their GitHub Actions pipeline, INP had drifted to 640ms on the checkout flow, well past Google's 200ms threshold, with nobody alerted because Sentry was catching JS errors, not performance regressions.

Monitoring the wrong layer at the right cadence is still monitoring nothing.

What belongs in a website maintenance plan and SLA

A website maintenance plan should define scope, response times, and reporting in writing, not just a task list. The SLA is the enforcement mechanism; the plan is the scope document it enforces, and treating them as one document is where most agreements fail.

At minimum, demand these in the contract:

• Severity tiers with response times, critical (site down, security breach) inside 1-4 hours; high (broken checkout, failed integration) inside 1 business day; standard (content updates, minor bugs) inside 3-5 business days.
• A named dependency-update cadence: who runs Dependabot or Renovate, how often, and who reviews breaking changes before merge.
• A current Software Bill of Materials, maintained in CycloneDX or SPDX format and refreshed on every dependency update, not generated once at launch and forgotten.
• Monitoring thresholds: Core Web Vitals budgets, uptime targets, and error-rate ceilings tied to Sentry or synthetic checks, with alerting owned by name.
• A staging-environment requirement, no production deploys without a tested staging pass and, ideally, a Playwright regression suite gating the pipeline.
• Compliance checkpoints, WCAG 2.2 conformance review and European Accessibility Act audit cadence, since the obligation doesn't lapse after launch.

What frequently gets left out, and shouldn't be: who owns the SBOM after the vendor relationship ends, and what happens to CI/CD access on contract termination. Write both into the retainer from day one, not after an incident, the difference shows up in how fast a critical ticket actually gets acknowledged, not just in the SLA document.

How much does website maintenance cost?

Monthly maintenance for a custom-built site runs $500-$2,500 for a small marketing site, $2,500-$8,000 for a mid-size web app, and $8,000+ for a product with compliance and integration needs. Those ranges cover routine work, not incident response or feature builds.

Network Solutions' 2026 cost breakdown shows the same upward curve by complexity, though its figures skew lower because they cover templated small-business sites, not engineering-owned custom builds.

Cost is not a flat rate against site size. It is driven by four variables:

• Dependency drift: how far your framework, packages, and CI/CD tooling have fallen behind current LTS releases. A site running Renovate or Dependabot with weekly PRs costs far less to keep current than one where nobody has touched package.json in eighteen months and every upgrade is now a breaking change.
• Integration count, each third-party API, payment gateway, or headless CMS connection (Contentful, Storyblok, Strapi) is a surface that can break independently and needs its own monitoring and test coverage.
• Compliance surface, WCAG 2.2 conformance work and European Accessibility Act obligations add ongoing audit and remediation hours, particularly for EU-facing consumer products.
• SLA tier, 1-hour critical response costs more to staff than 24-hour turnaround, because it forces on-call rotation regardless of ticket volume.

In-house ownership makes sense once you have enough surface area to keep an engineer at 0.5-1 FTE busy; below that, you are paying full-time salary for part-time work. A retainer with an external partner is usually cheaper per hour and scales down in quiet months.

A hybrid model, in-house for product-specific logic, retainer for security patching, dependency upgrades, and monitoring, is what we see hold up best on long-running engagements, where the in-house team owns roadmap decisions and the retainer owns the unglamorous, recurring work that gets skipped under deadline pressure.

In-house vs retainer vs hybrid: How to decide ownership

In-house ownership pays off once maintenance exceeds roughly 0.5-1 FTE of engineering time a week; below that, a retainer costs less than a part-time hire's payroll and benefits. Hybrid sits between the two, and for most custom-built sites we work on, it's the model that survives contact with reality, budgets shift and teams turn over faster than a rigid, single-owner setup can absorb.

A team running a headless CMS such as Contentful, Storyblok, or Strapi still needs an engineer who understands the deploy pipeline, not just an editor who understands the content model. That's a common gap in hybrid setups: the CMS is nominally "owned" by marketing, but nobody is watching the build.

Our experience running long-term maintenance engagements is that the deciding factor is rarely budget. It's whether one team is accountable for the whole stack, or three teams each assume someone else is watching it.

That kind of full-stack accountability is exactly what our custom web builds and ongoing engineering support are designed to provide.

WCAG 2.2 and the European Accessibility Act: What changed and by when

Accessibility compliance drifts the same way security does: nobody changes anything, and the site still falls out of conformance. WCAG 2.2 became the current W3C recommendation in October 2023, adding nine success criteria on top of 2.1, including target size, focus visibility, and dragging alternatives (W3C Web Accessibility Initiative / Multiple sources).

Sites built and audited against WCAG 2.1 do not automatically pass 2.2: new components, especially custom form controls and drag interactions shipped since the original build, need re-testing against the new criteria.

The deadline that changes the stakes: the European Accessibility Act has applied since 28 June 2025, requiring digital products and services sold into the EU, including e-commerce sites, banking portals, and transport ticketing, to meet accessibility standards aligned with WCAG 2.2 AA. That is a legal enforcement date, not a best-practice recommendation, and it applies regardless of where the company maintaining the website is headquartered.

Most teams we talk to treat accessibility as a one-time audit from the original build. It should be a maintenance line item, checked whenever a component library updates or a headless CMS template changes, because that is exactly when new controls slip in unaudited. In practice, protecting conformance costs less than a post-launch remediation project once a client, regulator, or procurement review flags a gap.

Netguru's WCAG 2.2 audits fold into the same quarterly cadence as dependency and performance reviews rather than running as a separate compliance track.

Dependency and supply-chain security: SBOM, Dependabot, Renovate, Snyk

Supply-chain security on a custom site means knowing what is in your dependency graph before an attacker does. A software bill of materials, exported in CycloneDX or SPDX format, is the baseline artifact security reviews now ask for.

Dependency drift is the quiet failure mode here: a package.json that hasn't been touched in eight months usually means dozens of transitive packages are carrying known vulnerabilities, not just missing minor patches. npm audit catches the obvious cases but reports on what's already installed, it doesn't open pull requests or handle version compatibility across a React or Next.js upgrade path.

That's the gap Dependabot and Renovate close. Dependabot, built into GitHub, opens automated pull requests against vulnerable or outdated packages and can be scoped to security-only updates for teams wary of breaking changes. Renovate does the same job with finer-grained scheduling and grouping rules, which matters once a monorepo has 200+ dependencies and a single bulk PR becomes unreviewable.

Snyk sits a layer above both: it scans for vulnerabilities across dependencies, containers, and infrastructure-as-code, and maps findings against OWASP Top 10 categories, which is the framing most security audits expect.

On dependency-remediation passes we've run for clients coming off multi-year-old Node or Python backends, combining Snyk scanning with Renovate automation typically clears the majority of open critical and high-severity vulnerabilities within a single sprint, mostly by resolving major-version debt nobody had budgeted time to address.

None of these tools replace judgment. A Renovate PR that bumps a major version can still break a build silently if there's no CI pipeline and no staging environment to catch it, which is why dependency automation and regression testing have to ship together, not separately.

FAQ: Website maintenance

Protect the value of your build: Get a maintenance audit

A maintenance audit shows exactly what is decaying in your build, dependency drift, Core Web Vitals regression, an accessibility gap, before it costs you traffic or a failed security check. We recommend running one before committing to a maintenance model, not after.

It's how we surface the real vulnerability counts and INP regressions that internal teams miss on their own stack, and it's what separates sustained ownership discipline from a fix that only holds until the next release.

Once the foundation is protected, the next question is usually what to build on it. If that means AI personalization, real-time analytics, or a new payment model, Add AI to your product with a team that treats your website as an asset worth protecting, not a line item.