The Website Handover Checklist: What to Document Before You Hand Off a Site

For an agency or freelancer, the project isn't actually finished when the site goes live - it's finished when the client can operate it without you. Most of the support tickets and awkward "can you just quickly..." emails that show up months later trace back to a handover that covered the launch but not everything the client would need after it.

Access and Credentials

The domain registrar, DNS provider, hosting or server account, CMS admin login, and every connected third-party service (analytics, email delivery, payment processor) each need to actually be transferred to the client's own ownership - not shared as a password the agency continues to control indefinitely. A client who doesn't own their own domain registration has effectively no leverage if the relationship ever ends badly. Use a shared vault in a password manager built for this, not a plaintext document emailed once and then lost in someone's inbox for the next three years.

What Was Actually Audited and Fixed

A dated record of what was checked before launch - performance, security headers, accessibility, broken links - and which findings were resolved versus knowingly deferred, is worth far more to a client than a verbal "everything looks good." It's also exactly the kind of thing that becomes useful evidence later, whether that's a client's own compliance requirement or simply a record to point back to when someone asks "wasn't this already checked?" six months from now. A scan history that's automatically timestamped and kept over time is strictly better than a one-off PDF from launch week that nobody can find anymore.

Ongoing Maintenance the Client Needs to Know About

• CMS and plugin updates. Who is responsible for applying them, and on what cadence - an unpatched CMS plugin is one of the most common ways a site gets compromised long after the agency that built it has moved on.
• SSL renewal, if it isn't fully automated - and confirmation, in writing, of whether it actually is.
• Backup schedule and location. Where backups live, how often they run, and - critically - whether anyone has actually tested restoring from one.
• Who to call.A specific, named point of contact for when something breaks, not a general "reach out if you need anything" that nobody remembers six months later.

Documentation Beyond "It Works"

• A sitemap of pages and what each one is actually for, especially anything not obvious from the CMS navigation.
• Any custom functionality that isn't self-explanatory from the admin UI - a custom form handler, a scheduled job, an integration with an external API.
• Every environment variable and API key in use, and which service each one belongs to - invaluable the day one of them needs to be rotated and nobody remembers what it was for.
• A short change log distinguishing what was actually built from what's still on a future roadmap, so a client doesn't assume a discussed-but-unbuilt feature already shipped.

The One-Page Summary Clients Actually Read

A thorough handover document and a document a client will actually read are usually two different artifacts. Most clients won't work through twenty pages of technical detail, however well organized. A one-page summary up top - access is here, here's what to maintain and how often, here's who to call - with the full detail linked below for whoever eventually needs it, gets read far more reliably than either a single dense document or an assumption that a quick verbal walkthrough was enough.

Running a final website audit and security audit right before handover, and attaching both reports, gives a client a concrete baseline to compare against if something changes later - and gives you a clean, dated record of the site's state the day it left your hands. See our guide to how often a site should be re-audited for what to recommend the client do next.