Ongoing website maintenance should keep the published website accurate, available, recoverable, secure enough for its risk profile, and able to complete its important customer journeys. A useful maintenance scope names the systems covered, the work that is routine, the events that trigger action, who owns each decision, what evidence is retained, and which changes require a separate project.

“Hosting and updates included” is not enough. It does not say who renews the domain, whether backups can actually be restored, how a broken quote form is detected, what happens when a software vulnerability is actively exploited, or whether a new service page counts as an update. Those gaps usually appear when the business needs help quickly.

This guide owns that operational scope decision. The separate guide to monthly website plans versus one-time projects owns the commercial-model comparison. Use this one to turn maintenance language into a service catalogue, responsibility matrix, and acceptance record.

Separate maintenance from support, incidents, and projects

Begin by classifying work. One request can contain several classes, so the provider should split it before promising a target.

| Work class | Practical definition | Example | | --- | --- | --- | | Routine update | A bounded change using the existing design, content model, and integrations | Correct hours, replace an approved photo, or update a staff bio | | Preventive maintenance | Planned work intended to reduce failure or degradation | Apply a supported dependency update and verify the release | | Incident | An unplanned loss or material degradation of an existing capability | A production form stops creating CRM records | | Defect correction | Existing behaviour does not match an accepted requirement | The mobile navigation cannot reach a published service page | | Enhancement | A new or materially expanded capability | Add customer login, a new quoting workflow, or a multilingual section | | Project | Coordinated work with new requirements, dependencies, and acceptance criteria | Redesign the site, migrate platforms, or restructure URLs |

The distinction is about scope, not blame. A broken integration can be an incident even when a third-party provider caused it. A two-line request can be an enhancement if it changes data handling, consent, permissions, or business rules. A content correction can become a project when it requires research, interviews, photography, legal review, or a new page template.

A maintenance agreement should say who classifies a request, how the business can challenge that classification, and whether assessment time is included. Without that rule, “unlimited updates” can mean unlimited submissions while both parties disagree about what the service covers.

Define the service catalogue

A service catalogue connects each maintained area to a trigger, an owner, and evidence. Not every website needs every row, but an omitted row should be an intentional decision.

| Maintained area | Minimum scope questions | Useful evidence | | --- | --- | --- | | Hosting and availability | Which environment, host, and public journeys are monitored? Who responds to an outage? | Monitor record, incident timeline, production response | | Domain, DNS, and TLS | Who controls the accounts, renewals, records, and certificate behaviour? | Ownership record, renewal status, HTTPS and redirect test | | Software and dependencies | What is inventoried, supported, updated, tested, and retired? | Version record, change log, build and release results | | Security | How are vulnerabilities prioritized, access reviewed, and suspected compromise escalated? | Risk decision, access review, incident record | | Backups and recovery | What is copied, how long is it retained, and how is restoration proven? | Dated restore test and recovery notes | | Published content | Who authorizes factual, legal, offer, personnel, and proof changes? | Request, approval, changed URLs, before-and-after record | | Lead journeys | Which forms, calls, calendars, chats, notifications, and CRM actions are tested? | Synthetic test record and destination receipt | | Accessibility | Which templates and journeys receive automated and manual regression checks? | Issues, severity, correction, and retest | | Performance | Which page types and Web Vitals are checked after material changes? | Field and lab observations with test context | | Search health | Who checks statuses, redirects, canonicals, crawl controls, sitemaps, and structured data? | URL-level release and crawl checks | | Analytics and consent | Which events and consent states must remain accurate? | Event test without personal form data | | Third-party services | Which vendors are dependencies, and who owns their accounts and escalation? | Vendor inventory, owner, status, and contingency |

This table is a starting contract, not proof that work happened. Each row still needs an agreed frequency or event trigger. For example, a dependency review might occur on a defined cadence and after a high-priority advisory, while a lead-flow test might occur after every form or CRM change.

Make routine content updates precise

Routine content maintenance normally means changing approved material inside the existing site structure. It can include:

  • correcting contact information, hours, staff, service details, or operating areas;
  • replacing approved images while preserving appropriate optimization and text alternatives;
  • updating an existing call to action, offer, notice, or frequently asked question;
  • removing expired claims, people, promotions, or proof;
  • correcting broken internal links; and
  • publishing a supplied, approved correction through an existing component.

The business remains responsible for the accuracy and authority of what it supplies. The maintenance provider should not quietly invent prices, qualifications, guarantees, customer results, legal terms, or service coverage to complete a request. Sensitive changes may need a named business, privacy, compliance, or legal reviewer before publication.

Define what makes a request usable. At minimum, it should identify the destination, the exact approved change, required assets, authorization to use them, and a person who can resolve ambiguity. A turnaround target should start when those inputs are complete, not when an email saying “update the site” arrives.

Nexxen’s current Essentials scope includes managed hosting, domain setup, and unlimited routine content changes. It targets completion of usable routine update requests within 72 hours; larger changes and third-party dependencies are scoped separately. That is a target for eligible work, not a guarantee that every incident, external approval, vendor outage, or new feature will be resolved in 72 hours. The current commercial owner is the Nexxen services overview.

Set request priorities without making every change an emergency

Priority should follow customer and business impact, not message volume.

| Priority class | Example trigger | First decision | | --- | --- | --- | | Critical incident | The production site is unavailable, visibly compromised, or sending leads to the wrong business | Contain, preserve evidence, invoke the incident owner | | High-impact failure | A primary quote or booking path fails with no workable fallback | Confirm scope, provide a fallback, repair or escalate | | Urgent correction | A dangerous, materially false, or unauthorized public statement is live | Verify the authorized replacement or removal | | Routine request | A complete content change fits the existing system | Schedule against the routine target | | Planned maintenance | A supported update or review is due | Test, release, verify, and record | | Enhancement | The request changes capability, structure, data, or workflow | Create a separate scope and acceptance criteria |

The agreement should distinguish acknowledgement, assessment, workaround, and completion. Those are different events. A provider can acknowledge an incident quickly while the root cause depends on a registrar, hosting vendor, CRM, messaging carrier, or account owner. Reporting all four timestamps makes performance clearer than one ambiguous “response time.”

Provide one intake path that creates a durable record. Phone or chat can be appropriate during a severe incident, but the final scope, approval, and result should still be captured. Include affected URL or journey, observed behaviour, urgency reason, desired outcome, approved copy or assets, and the requester’s authority.

Maintain hosting and availability as a customer journey

An availability check that requests only the homepage can miss the failure that matters. Monitor or test the journeys that create business value: a service page response, navigation, quote or contact submission, confirmation, and required downstream receipt.

Define:

  • the production host and preferred HTTPS hostname;
  • the pages or endpoints checked;
  • the expected status and response characteristics;
  • maintenance windows and known exceptions;
  • the alert destination and on-call responsibility;
  • when a public fallback or notice is appropriate;
  • the escalation path to the hosting provider; and
  • the evidence retained after recovery.

Do not convert monitoring into an unsupported uptime guarantee. Monitors can fail, internet routes differ, and external systems may be outside the maintenance provider’s control. The scope should say what is observed and what action follows.

For a confirmed outage, preserve the time detected, affected components, customer effect, actions, vendor references, time restored, verification results, and follow-up work. Avoid placing secrets, customer-submitted form data, access tokens, or unnecessary personal information in incident notes. OWASP’s logging guidance emphasizes consistent event information while excluding data that should not be recorded directly.

Keep domain, DNS, and certificates under named ownership

A maintained site can still disappear when the domain expires, a DNS record changes, or nobody can access the account protected by an old employee’s multi-factor authentication.

Record:

  • the registered domain holder and registrar;
  • the business and technical account owners;
  • the renewal method and payment responsibility;
  • recovery contacts and multi-factor authentication custody;
  • the authoritative DNS provider;
  • the purpose and owner of important records;
  • the preferred host and redirect rules;
  • certificate provisioning and renewal behaviour; and
  • the approval and rollback process for DNS changes.

Maintenance does not require transferring the domain to the website provider. The important outcome is durable business control and a documented operational path. A provider can manage configuration while the business retains ownership and recovery authority.

After a DNS, hosting, certificate, or domain change, verify the apex and www behaviour, HTTPS, redirects, public pages, email-related records affected by the change, and critical customer journeys. Do not assume that a browser displaying the homepage proves the full change succeeded.

Treat software updates as preventive maintenance

NIST describes enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. That sequence is useful for a small business website too: “automatic updates enabled” does not prove inventory, compatibility, successful installation, or production verification.

Maintain an inventory of the deployable application, runtime, framework, packages, themes or plugins where applicable, build tools, hosting components, and business-critical third-party integrations. For each item, record its source, version or release identifier, update method, owner, and support status.

An update workflow should:

  1. identify the affected component and exposure;
  2. assess vendor guidance and credible vulnerability information;
  3. prioritize based on exploitation, reachability, impact, and available mitigations;
  4. prepare a backup or rollback path appropriate to the change;
  5. test the build and important journeys;
  6. release through controlled access;
  7. verify the installed version and production behaviour; and
  8. record the decision, result, and any deferred risk.

CISA’s Known Exploited Vulnerabilities catalogue can help distinguish vulnerabilities with evidence of active exploitation from an undifferentiated list of severity scores. It is not a complete vulnerability list and does not remove the need to assess whether a listed product or vulnerable path exists on the site.

OWASP identifies vulnerable and outdated components as a common application-security risk. Maintenance should therefore include removing unused components, avoiding unsupported versions, watching authoritative advisories, and verifying dependencies from trusted sources. None of those actions makes a site “unhackable.” The defensible promise is a documented risk-reduction and response process.

Make backups prove recovery

A backup is useful only if it contains the required assets, can be accessed by an authorized owner, and can be restored within the business’s needs.

Define what must be recoverable:

  • application source and deployable release;
  • content and database records, where applicable;
  • uploaded media and configuration;
  • infrastructure or hosting configuration that cannot be recreated safely from source;
  • DNS and integration configuration records; and
  • the instructions and credentials custody needed to restore service.

Then define retention, location separation, encryption and access controls, failure alerts, and deletion rules. Do not invent a recovery point objective or recovery time objective after an incident. The business and provider should agree what amount of data loss and recovery delay are tolerable, then choose the backup and deployment design accordingly.

Run a restoration test against a controlled destination. Record the backup identifier, restore point, components restored, test environment, result, duration, missing dependencies, and corrective work. A green “backup completed” notification is evidence that a copy job ran, not that the site can recover.

Maintain lead capture end to end

A working form interface can still fail after submission. The server may reject the request, a webhook may time out, the CRM may create a duplicate, the notification may be suppressed, or the confirmation may contain the wrong information.

For each important journey, maintain a written contract:

  • the public entry point;
  • the minimum data collected and stated purpose;
  • server-side validation and abuse controls;
  • the destination system and required fields;
  • identity and duplicate-handling rules;
  • notification recipients;
  • customer confirmation;
  • consent and suppression behaviour where messaging is involved;
  • retry, reconciliation, and failure ownership; and
  • a safe production test method.

Test to the destination, not merely to the success screen. A quote-form test should confirm the customer-facing result, the canonical CRM record, the correct business notification, and any authorized automation. Use clearly marked test records and remove or retain them according to the agreed data process. Never put real customer details into screenshots or maintenance logs unnecessarily.

The detailed contractor quote-form checklist owns form-to-CRM implementation. The maintenance scope should identify which accepted behaviours are rechecked after releases, vendor changes, credential rotation, or an observed failure.

Check accessibility after changes

Accessibility is not a one-time launch badge. A new heading, link label, image, colour, form field, modal, document, or third-party widget can introduce a regression.

Automated tools can find some machine-detectable issues, but W3C notes that tools cannot determine accessibility on their own and that knowledgeable human evaluation is required. A maintenance routine should combine automation with focused manual checks of the changed component and affected journey.

Depending on the change, verify:

  • semantic heading and landmark structure;
  • keyboard reachability, order, focus visibility, and escape behaviour;
  • accessible names and instructions;
  • errors, recovery, and status announcements;
  • text and control contrast;
  • reflow and zoom behaviour;
  • appropriate image alternatives;
  • captions, transcripts, and media controls; and
  • the accessibility of linked documents and embedded third-party tools.

Record the standard or internal acceptance criterion used, test method, issue, severity, owner, correction, and retest. This is quality evidence, not legal certification. Canadian businesses should separately identify the accessibility rules and review authority that apply to their organization and jurisdiction.

Watch performance as a regression risk

Performance maintenance should protect representative page types and customer journeys, not chase a perfect score from one test.

Google’s current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Field data reflects real visits when enough data exists; lab tests provide controlled diagnostics. Record which one is being used, along with page, device, network, location, cache state, and release context.

Set a performance review trigger for changes such as:

  • new hero images, galleries, video, fonts, or embeds;
  • chat, scheduling, analytics, advertising, or consent scripts;
  • template and navigation changes;
  • major dependency or hosting changes; and
  • unexplained field-data regression.

Compare the changed journey before and after when possible. Diagnose the actual cause before removing a feature or trading one metric against another. The Core Web Vitals guide for contractor websites owns the detailed measurement and remediation framework.

Maintain search and crawl controls

Search maintenance does not mean changing headings every month. It means keeping the technical and editorial signals aligned with the site’s intended canonical pages.

For a release or URL-affecting change, verify:

  • the public URL returns the intended HTTP status;
  • redirects are direct and point to the correct final destination;
  • indexable pages do not carry accidental noindex;
  • canonical links identify the intended HTTPS URL;
  • internal links use canonical destinations;
  • robots.txt does not block required assets or pages;
  • the XML sitemap contains current canonical pages and omits redirects and errors;
  • page titles, descriptions, H1s, and structured data still match visible content;
  • deleted or merged content has the planned response or redirect; and
  • analytics and webmaster tools can distinguish the changed URLs.

Google documents that successful 2xx responses can be considered for indexing but do not guarantee it, while persistent client and server errors affect crawling and indexing differently. It also treats permanent redirects and rel="canonical" as strong canonicalization signals and sitemap inclusion as a weaker signal. A maintenance check should test those mechanisms together rather than assuming sitemap submission overrides a conflicting response or canonical.

Content maintenance should follow the same ownership discipline. Correct outdated facts, add genuinely useful evidence, and consolidate overlapping pages. Do not create thin city variants or publish another article simply because a query wording changed.

Maintain analytics without collecting unnecessary data

Measurement maintenance should verify that agreed events still fire once, carry the intended non-sensitive context, and respect the configured consent state. It should not copy form contents, free-text messages, phone numbers, email addresses, or other unnecessary personal data into analytics.

Maintain an event dictionary with:

  • event name and business question;
  • trigger and exclusions;
  • page or component;
  • permitted parameters;
  • consent requirement;
  • destination;
  • test method; and
  • owner.

Recheck events after navigation, form, consent, tag-manager, domain, or analytics-platform changes. Distinguish a button click from a submitted form, accepted provider request, qualified lead, booked appointment, and completed sale. Calling all of them “conversions” makes the maintenance report look simpler while making business decisions worse.

Control third-party dependencies

Calendars, CRMs, chat tools, map embeds, review platforms, analytics, email, SMS, payment services, CDNs, and registrars can affect the customer journey without being controlled by the website provider.

For every critical vendor, record:

  • business and technical account owners;
  • plan or entitlement relied upon;
  • authentication and recovery ownership;
  • data exchanged and purpose;
  • production identifiers;
  • webhook or API dependency;
  • status and support destinations;
  • renewal or billing owner;
  • documented fallback; and
  • what happens at offboarding.

“Third-party dependencies scoped separately” should not mean “ignored.” It means the maintenance provider can observe, document, provide a safe fallback, and coordinate within the agreed scope while avoiding a promise to control another vendor’s availability, approvals, pricing, or resolution time.

Define exclusions before work begins

Common exclusions or separately scoped work include:

  • a redesign, new design system, or new page template;
  • a new custom feature or materially changed business workflow;
  • platform, hosting, domain, CRM, or analytics migration;
  • large-scale copywriting, photography, video, translation, or data entry;
  • legal, privacy, accessibility, tax, or regulatory advice;
  • account recovery when the authorized owner and proof are unavailable;
  • third-party subscriptions, usage fees, penalties, or expedited support;
  • emergency after-hours coverage unless explicitly included;
  • remediation of pre-existing systems outside the maintained boundary; and
  • work delayed by missing approval, access, content, permission, or vendor action.

An exclusion should state the next path. “Not included” is more useful when followed by who assesses it, what discovery is required, whether a temporary fallback is possible, and how a separate proposal is approved.

Assign responsibilities and acceptance evidence

A responsibility matrix prevents maintenance from becoming a shared assumption.

| Decision or task | Business owner | Maintenance provider | External party | | --- | --- | --- | --- | | Approve public facts, offers, proof, and legal text | Accountable and final approval | Implement supplied approval; flag ambiguity | Specialist reviewer where required | | Maintain technical inventory and release process | Informed | Responsible within maintained stack | Platform or package publisher supplies advisories | | Control domain and core business accounts | Accountable; retain recovery authority | Configure where authorized | Registrar or vendor operates service | | Classify and respond to website incidents | Escalation contact | Triage maintained components and preserve evidence | Vendor resolves its own service | | Approve new capability or material scope change | Accountable for business requirements and budget | Assess and propose acceptance criteria | Vendor may confirm feasibility or entitlement | | Verify completed work | Confirm business facts and journey | Provide technical and publication evidence | Destination system may provide receipt |

Acceptance should be proportionate to risk. A routine text correction can have a small record: request, authorization, changed URL, visual check, and completion time. A dependency release may require build results, tests, version evidence, production checks, and rollback status. A form change needs an end-to-end transaction record. A DNS change needs resolution, HTTPS, redirect, email-impact, and journey checks.

Keep one maintenance log with request identifier, classification, requester, authorization, affected systems and URLs, start condition, changes, release identifier, verification, exception, completion state, and follow-up. The log should be useful without storing secrets or unnecessary customer data.

Plan offboarding while the relationship is healthy

Maintenance is sustainable when the business can change providers without losing its identity or operating history.

Define which materials transfer:

  • domain and DNS control;
  • current source or export and deployable release;
  • content and media rights;
  • hosting, analytics, webmaster, CRM, and integration ownership;
  • configuration and environment-value handoff method;
  • redirects and canonical URL inventory;
  • maintenance, incident, backup, and restore records;
  • licences that can and cannot transfer; and
  • the final verification and credential-rotation responsibilities.

Do not place secrets in an ordinary handoff document. Use an approved secure transfer process and record only that custody changed. Revoke obsolete access after the receiving owner confirms control and a safe rollback window has passed.

Use a maintenance acceptance checklist

Before accepting an ongoing website maintenance scope, confirm:

  • [ ] The maintained website, environments, accounts, and third parties are listed.
  • [ ] Routine updates, preventive work, incidents, defects, enhancements, and projects are distinguished.
  • [ ] A usable request has defined inputs and authorization.
  • [ ] Acknowledgement, assessment, workaround, and completion targets are not conflated.
  • [ ] Hosting, domain, DNS, TLS, software, security, backups, and recovery have named owners.
  • [ ] Critical forms, calendars, CRM actions, notifications, and fallbacks have production-safe test cases.
  • [ ] Accessibility, performance, analytics, and search regression triggers are defined.
  • [ ] Vulnerability prioritization and supported-version decisions are documented.
  • [ ] Backup restoration is tested, not inferred from a job notification.
  • [ ] Third-party limits and escalation paths are explicit.
  • [ ] Exclusions lead to a clear assessment or project path.
  • [ ] Every material change has proportionate acceptance evidence.
  • [ ] The business retains durable control of its domain, content, accounts, and handoff materials.

The right maintenance plan is not the one with the longest feature list. It is the one whose boundaries match the website’s real customer journeys and whose owners can prove that important work was completed. Use the Nexxen services page to compare the managed capabilities, then confirm the exact catalogue, targets, dependencies, and acceptance evidence for the website in scope.