seeking data labs

Guide

Client website handover checklist

What an agency should confirm, transfer and write down before a finished site becomes the client's responsibility, and how to check each item.

Last reviewed: 27 September 2026

Handover is the point where problems stop being the agency's to find and start being the client's to discover. Everything below is cheaper to settle before that point than after it.

1. Ownership and access

The domain is registered to the client

The registrant should be the client's organisation, with a contact address the client controls, and auto-renew switched on.

HowLook up the domain in the registrar's account and in a public registration lookup. Write down the expiry date in the handover document.

Every account is in the client's name

Hosting, DNS, the content management system, analytics, the search engine's webmaster tools, the form service and any paid plugin or font licence. An account that sits under an agency employee's personal login becomes a locked door when that person leaves.

HowMake a table of every service the site depends on, with the owner, the billing contact and who holds admin access. Each row should end with a client-owned account.

Access is personal and protected

  • Each person gets their own login. No shared admin account.
  • Two-factor authentication is on for every admin account.
  • Agency access is either removed or reduced to what the support agreement covers, and the client knows which.
  • Passwords are handed over through a password manager's sharing feature, never pasted into email or chat.

Certificates renew on their own

HowCheck the certificate's expiry date in the browser's padlock menu or with the command below, and confirm with the host that renewal is automatic.

echo | openssl s_client -connect example.org:443 -servername example.org 2>/dev/null | openssl x509 -noout -enddate

2. Final content, legal pages included

No draft text remains

Search the live site for placeholder copy, bracketed notes and draft markers. The pre-launch QA checklist has the search to run.

Legal pages read as finished documents

Legal pages are often assembled from a template plus the client's own wording, and the joins show. Each page should name the organisation responsible, carry one date, and say each thing once.

From a Sightline run on our own site

On 17 September 2026 a Sightline run on seekingdatalabs.com flagged our privacy and cookie pages, https://seekingdatalabs.com/privacy/ and https://seekingdatalabs.com/cookies/, for carrying two different "not legal advice" notices on the same page. One comes from the shared page template:

This document is a good-faith template prepared to describe Seeking Data Labs' current practices. It is not legal advice and should be reviewed by qualified Swiss and EU data-protection and commercial counsel before it is relied upon.

The other was written into the text itself:

This document is provided in good faith for transparency; it is not legal advice, and you should have it reviewed by qualified counsel before relying on it.

Each notice is reasonable alone. Together they tell a reader the document was never given a final edit, which is the opposite of what a legal page is for. The finding quoted both sentences and the page URL, so there was nothing to argue about, only a decision to make.

Images and fonts are licensed for the client

Stock images, icons and web fonts bought under the agency's licence may not transfer. List each paid asset with its licence and who holds it.

3. Forms and email delivery

Submissions reach the client

HowSubmit every form on the live domain and confirm the message lands in the client's inbox, not in the agency's test address, and not in spam.

Mail sent from the domain is authenticated

If the site sends email (form notifications, receipts, password resets) from the client's domain, the domain needs SPF, DKIM and a DMARC policy, or those messages will increasingly be rejected.

dig +short TXT example.org | grep -i spf
dig +short TXT _dmarc.example.org

Where form data is stored is known

If submissions are also kept in a database or a third-party form service, the client should know where, for how long, and how to delete an entry when someone asks.

  • No leftover noindex. Request /robots.txt and view the source of a few pages to confirm neither blocks indexing.
  • The sitemap is submitted from the client's account in the search engine's webmaster tools, and the property is verified with a method the client controls.
  • Old URLs redirect. If the site replaced an older one, every old URL with traffic answers a single 301 to its new equivalent.
  • One canonical host. http:// and the www or non-www form each redirect once to the canonical HTTPS URL.

5. Analytics and consent

  • The analytics property belongs to the client, and the agency is a user on it, not the owner.
  • Consent behaves as the banner says. In a private window, before choosing anything, no analytics or advertising requests should appear in the network panel.
  • The cookie list matches the browser. After accepting, compare the cookies the browser holds with the list on the cookie page. Every tag added after launch needs a line there too.

6. Updates, backups and monitoring

Someone owns updates

The content management system, its plugins and the site's dependencies need updates for as long as the site is online. The handover document should say who applies them, how often, and who is called when an update breaks something.

A backup has been restored, not just taken

HowRestore the most recent backup to a separate environment and open the site. Record where backups are stored, how long they are kept, and who can restore them.

Outages reach the client

Uptime alerts, certificate expiry warnings and domain renewal notices should go to an address the client reads, not to an agency inbox.

7. The handover document

One page the client can find again in a year. It should contain:

  • the table of services and accounts, with owners and renewal dates;
  • how to edit the common things: a page, the navigation, a form recipient, the footer;
  • what the support agreement covers and how to ask for help;
  • the known issues the client has accepted, each with the reason.

A short screen recording of the editing workflow saves more support requests than a long manual.

8. A dated baseline and sign-off

Record what the site returned on handover day: the status code of every page, the response headers of the home page, each page's title and description, and a screenshot of the key pages at desktop and mobile width. Keep the evidence with a date.

When the client reports a problem months later, the baseline answers the first question quickly: did this change after handover, or was it already there? It also turns sign-off into a factual statement. The client signs that these pages returned these results on this date, not that the site "works".