Website maintenance in 2026 is the ongoing work of keeping a site compatible, secure, recoverable, and fast as its technology changes. A sound plan combines regular testing, continuous monitoring, clear ownership, and evidence that updates and backups work. Installing WordPress or Drupal updates is only one part of the job. Maintenance must also protect mobile content, browser behavior, accessibility, third-party integrations, security controls, real-user performance, and recovery procedures.
Table of Contents
- What compatibility testing must cover
- How should security maintenance work?
- Which performance evidence matters?
- Can the site be restored after a failure?
- What should a maintenance agreement require?
What compatibility testing must cover
Compatibility means more than checking a homepage in one browser. Tests should cover important templates, forms, menus, account functions, payment paths, campaign pages, keyboard controls, and the content management workflow. web Platform Baseline labels a feature "newly available" only after Chrome, Edge, Firefox, and Safari support it. It does not become "widely available" until 30 months later, according to the WebDX Baseline guidance. When a site uses features outside Baseline, ask which browsers receive fallbacks and how those fallbacks are tested.
Mobile testing must also compare content, metadata, structured data, and crawlable resources with the desktop version. Google uses smartphone-crawled content for indexing and ranking, and warns that reduced primary content on mobile can cost traffic in its mobile-first indexing documentation. Accessibility belongs in every regression cycle. WCAG 2.2 became a W3C Recommendation on October 5, 2023 and added nine criteria to WCAG 2.1. After an update, test keyboard navigation, focus behavior, labels, error messages, contrast, and touch targets on affected pages.
How should security maintenance work?
security maintenance should address permissions, configuration, dependencies, and recovery—not merely scan for malware. The OWASP 2025 Top 10 ranks broken access control first, security misconfiguration second, and software supply-chain failures third. Maintain an inventory of the CMS core, plugins or modules, themes, server software, build tools, libraries, and externally loaded scripts. Record each component's owner, version, purpose, update route, and removal procedure. An unknown dependency cannot be patched or assessed reliably.
CISA's Known Exploited Vulnerabilities Catalog identifies vulnerabilities exploited in the wild and recommends that all organizations prioritize them. Ask how often maintainers compare the site's components with that catalog, who evaluates a match, and what emergency update window applies. Security headers need deliberate configuration. MDN says Content Security Policy can restrict loaded resources and help mitigate cross-site scripting, while `upgrade-insecure-requests` does not replace HSTS for external links. Ask which policies are enforced, where violation reports go, and who investigates them.
Which performance evidence matters?
A fast test on one laptop does not establish a good experience for actual visitors. google defines Core Web Vitals as real-user measures of loading, responsiveness, and visual stability, with good targets of LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 in its Core Web Vitals documentation. Request field-data monitoring alongside controlled lab tests. Field data can reveal whether a release affected real visits, while lab tests help reproduce problems before deployment.
Reports should identify the affected template, device group, release, and likely cause rather than provide only a site-wide score. Performance reviews should examine changes to images, fonts, scripts, stylesheets, caching, templates, and third-party tags. For example, a marketing tag may leave loading unchanged while making interaction slower. A layout change may look correct yet shift when an image or advertisement appears. Ask these questions:.
- Which pages and user journeys receive performance monitoring?
- Are results based on field data, lab tests, or both?
- What thresholds trigger investigation?
- Who can remove or defer a slow third-party script?
- How is a regression tied to a particular release?
Can the site be restored after a failure?
A backup is useful only if the required data is present, protected, and restorable. NIST CSF 2.0 calls for verifying backup integrity before restoration and treats cybersecurity functions as concurrent activities rather than isolated phases. Define what must be recovered: files, databases, media, configuration, DNS details, certificates, deployment settings, and integration credentials where appropriate.
Record backup frequency, retention, access controls, storage separation, restoration responsibility, and acceptable data loss. Every maintenance plan should include: Restore tests should verify important pages and functions, not merely confirm that an archive extracted successfully. A recovered site with missing uploads, broken forms, or unusable administrator access is not a completed recovery.
- A named incident lead and current contact route.
- A written restore procedure with required access.
- Scheduled restore tests in a safe environment.
- Recorded results, failures, and corrective actions.
- A rollback decision for failed deployments.
What should a maintenance agreement require?
The agreement should define the covered environments, components, hours, response targets, approval rules, and exclusions. It should also separate routine work from emergency response and larger development projects, so each request has a clear route.
Require evidence that can support decisions: Warning signs include vague promises to "keep everything updated," reports listing activity without outcomes, and backups that have never been restored. Another warning is shared responsibility without named owners, because urgent work can remain unassigned. Before signing, ask the provider to walk through a recent maintenance report and a restore-test record, then identify who would act if tomorrow's release broke checkout, publishing, or lead collection.
- An asset and dependency inventory.
- Update and deployment records.
- Compatibility, accessibility, and performance results.
- Security findings with priority and ownership.
- Backup and restore-test records.
