Home › Blog › Website Maintenance Onboarding Checklist for Agencies

Website Maintenance Onboarding Checklist for Agencies

August 8, 2026 · 9 min read

Onboarding a website for maintenance means accepting operational responsibility for a system your agency may not have built, on infrastructure it may not own, with dependencies spread across several vendors. The safe sequence is to define responsibility, inventory the system, secure access, establish a baseline, test recovery, map business-critical journeys, and only then make changes.

The onboarding is complete when both parties can answer five questions: what is covered, who owns each dependency, how the website can be recovered, what “working” means, and who is alerted when it is not working.

At a glance

Before the maintenance start date:

name operational and emergency contacts on both sides;
assign ownership for domain, DNS, hosting, CDN, CMS, email, payments, and integrations;
receive access through a secure, auditable process;
revoke or reduce obsolete supplier accounts after approval;
record the website's baseline condition before changing it;
verify that a backup can be restored, not merely that a backup job is green;
test the lead, order, payment, login, or booking journeys that make the website valuable;
create a known-issues and accepted-risks register;
configure monitoring, escalation, maintenance windows, and fallback contacts;
obtain written acceptance of the baseline and support boundaries.

Why agencies should not begin with updates

The first impulse is often to update the CMS, remove suspicious plugins, or clean an error log. That creates unnecessary risk. Before the baseline is recorded, the agency cannot reliably distinguish a pre-existing defect from a change it introduced.

Start with observation. Change only what is required to make the assessment safe, and record every emergency change.

Step 1: define the service boundary

“The client handles the domain” is too vague. Record an accountable role, an authorised contact, and the fallback if that person cannot be reached.

Component	Legal/contract owner	Pays vendor	May change it	Monitors it	Emergency contact
Domain registration	Client	Client	Named client admin	Agency/client	Named role
DNS	Client or hosting provider	Client	Agency with approval	Agency	Agency on-call
Hosting/cloud	Client	Client	Agency/hosting provider	Agency	Provider + agency
CDN/WAF	Client	Client	Agency	Agency	Agency on-call
TLS certificate	Client/provider	Contract-dependent	Agency/automation	Agency	Agency on-call
CMS and extensions	Client	Contract-dependent	Agency	Agency	Maintenance lead
Transactional email	Client	Client	Named admin	Shared	Client + agency
Payments	Client	Client	Client with agency support	Shared	Client finance/ops
CRM/ERP/PIM/OMS	Client	Client	System owner/integrator	Shared	Named integration owner
Analytics/tag manager	Client	Client	Marketing owner	Client	Marketing lead

The services agreement and SLA should state what the agency controls, what it coordinates, and what it only observes. Have local counsel review contractual language; this checklist is an operational aid, not legal advice.

Step 2: create a website passport

The passport is a concise operational record. It should let an on-call engineer understand the service without searching old chats.

# Client website passport

Client: [organisation]
Production URL: [canonical URL]
Purpose: [leads / ecommerce / booking / account / publishing]
Business criticality: [high / medium / low]
Support tier and hours: [reference]

## Contacts
- Client service owner: [role, channel]
- Client emergency approver: [role, channel]
- Agency service owner: [role]
- Technical escalation: [team or role]
- Security escalation: [role and out-of-band channel]

## Ownership and infrastructure
- Domain registrar and account owner: [value]
- Renewal date and renewal method: [value]
- DNS provider: [value]
- Hosting/cloud account: [value]
- CDN/WAF: [value]
- TLS issuance and renewal: [value]
- Repository and production branch: [links]
- Deployment process: [pipeline/runbook]
- Staging environment: [URL or none]

## Application
- CMS/framework and version: [value]
- Runtime and database: [value]
- Critical plugins/modules: [list]
- Scheduled jobs and queues: [runbook link]
- Email provider: [value]
- Integrations: [payments, CRM, ERP, PIM, shipping, tax, identity]

## Recovery
- Backed-up components: [files, database, configuration, media]
- Frequency and retention: [value]
- Separate storage location: [reference, not secret]
- RPO / RTO target: [value]
- Last successful restore test: [date, evidence]
- Recovery owner: [role]

## Critical user journeys
1. [journey and measurable success condition]
2. [journey and measurable success condition]
3. [journey and measurable success condition]

## Operational channels
- Routine work: [help desk/project tracker]
- Incidents: [channel]
- Status page: [URL or none]
- Planned maintenance notice: [channel and notice period]

Do not place passwords, private keys, recovery codes, or API tokens in the passport. Store a reference to the relevant secret-manager entry.

Step 3: accept access safely

Typical access includes the registrar, DNS, cloud or hosting account, CDN, CMS, SSH/SFTP, database, repository, CI/CD, backup storage, mail provider, payment platform, CRM, analytics, and monitoring.

Use these rules:

prefer named agency accounts to a shared client login;
grant the least privilege required for the actual task;
enable MFA and verify that recovery belongs to the right organisation;
keep production write access separate from read-only monitoring;
record owner, purpose, approval, and expiry for privileged access;
keep break-glass access controlled, logged, and tested;
revoke former supplier and departed employee access through an approved process;
never request credentials in a normal email thread or group chat.

OWASP recommends centralised secret storage, fine-grained access, auditable use, rotation, revocation, expiration, and tested break-glass procedures. The precise implementation depends on the client's environment.

Step 4: record the baseline

External checks

canonical redirects between HTTP/HTTPS and host variants;
TLS validity and chain;
DNS resolution from important audience regions;
unexpected redirects, injected content, or defacement;
representative response times and phase timing;
robots.txt, sitemap, canonical, and accidental noindex state;
important pages rather than only the homepage;
CDN error pages that can hide an unhealthy origin.

Application checks

CMS, runtime, database, and critical extension versions;
unsupported components and known compatibility constraints;
unknown administrative accounts;
application, web-server, queue, and scheduled-job errors;
mail delivery configuration;
storage capacity and database health;
existing monitoring and security controls.

Business checks

submit each revenue-critical form and confirm where the lead arrives;
place a controlled test order and verify payment mode, confirmation, inventory, tax, shipping, and downstream records;
test account creation, login, reset, and MFA where relevant;
test booking availability and confirmation;
confirm analytics and conversion events without collecting unnecessary personal data.

Use synthetic data and documented test accounts. Do not create real charges, shipments, or customer records accidentally.

Step 5: prove recovery

A successful backup job proves that a file was created. It does not prove that the website can be restored.

Record:

the components covered by backup;
encryption and access restrictions;
storage separation from production;
retention and point-in-time options;
the selected recovery point;
restore duration;
data freshness compared with the RPO;
application checks completed after restore;
remaining manual steps and single-person dependencies.

Restore to an isolated target whenever possible. AWS Well-Architected guidance likewise recommends periodic recovery to a new location, validation of usable data, and measurement against RTO and RPO.

Step 6: create the known-issues register

Do not bury baseline defects in an audit PDF. Turn them into an agreed register.

ID	Condition	Evidence	Business effect	Risk	Owner	Decision
K-01	Domain owned by former employee	Registrar record	Renewal risk	High	Client	Transfer by date
K-02	Checkout email intermittently delayed	Test records	Support/order delay	Medium	Agency	Investigate in sprint
K-03	Plugin is unsupported	Version evidence	Security/change risk	High	Shared	Replacement proposal

Possible decisions are: fix before start, include in the first maintenance cycle, accept temporarily, exclude from scope, or stop onboarding until resolved.

Step 7: configure monitoring and escalation

At minimum, monitor:

the canonical URL and one or more critical pages;
TLS and domain expiry;
form submission and, where permitted, delivery to the destination mailbox;
critical scheduled jobs or integration heartbeats;
unexpected redirects and selected security signals;
WordPress or application health where a safe integration exists.

Define confirmation rules, alert owner, fallback channel, maintenance windows, time zone, and closure conditions. A monitor without an owner is only a future ignored notification.

Step 8: sign off the operational baseline

The onboarding record should include:

Website: [URL]
Baseline recorded: [UTC timestamp]
Support starts: [UTC timestamp]
Scope reference: [document/version]
Known issues reference: [document/version]
Recovery status: [tested / untested / partial]
Critical journeys accepted: [list]
Monitoring active: [checks and owners]
Client acceptance: [name/role/date]
Agency acceptance: [name/role/date]

Example: taking over a WooCommerce store

An agency receives WordPress administrator access and a hosting login. It pauses planned plugin updates, identifies that DNS is in a former employee's account, and records that transfer as a high risk. A test order succeeds, but the fulfilment record does not reach the warehouse system. The backup restores successfully to staging in 74 minutes, which exceeds the draft 60-minute RTO.

The agency starts maintenance with three accepted actions: transfer domain/DNS ownership, repair fulfilment reconciliation, and improve restore time. None of these pre-existing issues can later be confused with a defect introduced by routine maintenance.

Common onboarding mistakes

treating possession of a CMS password as complete handover;
changing production before recording the baseline;
accepting a backup icon instead of testing a restore;
monitoring only the homepage;
storing all client secrets in one shared document;
leaving payment, email, or integration ownership undefined;
promising a resolution target for systems the agency cannot change;
failing to obtain written acceptance of known defects.

FAQ

How long should website maintenance onboarding take?

A small brochure site may take several hours; a transactional website with several integrations can take days. Completion should depend on evidence, not a fixed duration.

Should an agency require full server access?

No. Access should match scope. External monitoring may require no inbound production access, while incident recovery may require controlled, temporary privilege.

Can onboarding continue if a restore has not been tested?

Only if the parties explicitly accept the risk and define a deadline and owner. Do not describe recovery as verified.

Who should own the domain?

Normally the client organisation or another explicitly authorised entity, not an individual agency employee. Confirm this with the client's legal and operational requirements.

Sources and further reading

Reviewed: 8 August 2026.

Next: Client website monitoring policy template and agency access control matrix.

Pingvera can provide the external layer of the onboarding baseline: availability, timing, TLS and domain checks, forms, lead delivery, selected security signals, and CMS-specific health checks. Define the process first; automate the accepted checks second.

Know about problems before your customers do

Pingvera watches whether an online business actually works — uptime, checkout, orders, domain, SSL and server — and alerts you in Telegram, email or a webhook before a customer has to tell you.

Start free

← All articles · Privacy policy · pingvera.com