Website handover checklist: what to give your client before the project closes
A handover is not the last email of a project. It is a short list of facts the client will need on a day you are not available, written down while you still remember all of them. This is that list, grouped so you can work through it in one sitting.
The short answer
A website handover should give the client seven groups of facts: what the site is built on, where the domain and DNS live, where the site and the email are hosted, which accounts exist and who owns each one, how to make everyday edits, what recurring maintenance happens and who does it, and who to contact when something breaks. Record ownership and access as two separate facts. Transfer credentials outside the document.
Everything below is an expansion of those seven groups. If you only have twenty minutes, work through the checklist and leave the reasoning for later — the value is in having written the answers down at all, not in the prose around them.
Ownership is not access, and mixing them causes the arguments
Ownership is who the account legally belongs to. Access is who can currently sign into it. They are frequently different people, and a handover that records only one of them is the reason so many post-project disputes take weeks to resolve.
The most common shape: the domain is registered in the client’s company name, paid for on the client’s card, and sitting inside a registrar account whose only login belongs to a developer who left the agency two years ago. Ownership is clear. Access is a phone call to someone nobody has a number for.
The reverse happens just as often. An agency registers a domain during a build because it was quicker, in good faith, in the agency account. The client believes they own it because they were invoiced for it. Nobody discovers otherwise until the relationship ends.
So every account in the handover gets two lines rather than one:
- Owner — the person or organisation the account belongs to. Usually the client, and if it is not, say so in writing while everyone is still friendly.
- Access — who can actually sign in today, and the administrative email address on the account. This is the line that goes stale, and the one worth reviewing every year.
Neither line is a password. Both are facts about people, and facts about people are safe to write down, forward and print.
The checklist
Seven groups. Work top to bottom; every item is a sentence you write, not a file you attach. Anything that genuinely does not apply to this project gets struck out rather than left blank — a blank line reads as an oversight, and the client cannot tell the difference.
1 · The website itself
- Platform and versionWordPress, Webflow, Shopify, a static build, a custom application. Name it plainly enough that a stranger can act on it.
- Theme or frameworkIncluding whether it is a commercial theme, and whether the licence is the client’s or yours.
- Key plugins, apps or integrationsThe handful that matter, not the full list. A booking system, a payments integration, a translation layer, a form handler.
- Anything customCustom post types, custom code, a child theme, a build step. The next developer needs to know it exists before they overwrite it.
- Where the code livesA repository, a hosting file manager, or nowhere but the server. “Nowhere but the server” is a legitimate answer and worth saying out loud.
2 · Domain, registrar and DNS
The domain & DNS handover guide covers this group in detail.
- The domain, and any others pointing at itIncluding the ones bought defensively and forgotten.
- Registrar, and who can sign in thereThe registrar account is the single most valuable access in the whole handover.
- Registered ownerThe organisation on the registration, which may not be the account holder.
- Expiry date and whether auto-renew is onA lapsed domain takes the website and the email down together.
- Where DNS is managedOften not the registrar. The nameservers tell you where to look.
- What changed at handoverA full nameserver move, individual records only, or nothing at all. All three are normal.
3 · Hosting and email
- Host, plan and renewal dateAnd whose card it renews on.
- Whether hosting is inside your account or theirsReselling is fine. Reselling without saying so is not.
- SSL certificate and how it renewsUsually automatic, occasionally not, and a manual one that lapses is a very public failure.
- Where email is hostedAlmost always a different provider from the website. Write it down even when nobody touched it.
- Who handles email supportMost agencies do not, and the client should learn that now rather than during an outage.
4 · Accounts and ownership
- Every third-party service the site depends onPayment gateway, CRM, email marketing, booking, chat, CDN, a font or icon licence, a stock photo subscription.
- Owner and admin contact address for eachThe two lines from the section above, on every row.
- Analytics and search toolsAnalytics property, Search Console, Business Profile, tag manager. These are usually created by the agency in an agency account and quietly never transferred.
- Who pays for whatRecurring costs the client is now responsible for, and the ones still on your card.
- Admin users on the site itselfRemove the ones that were only ever for the build. Leave a named administrator for the client.
5 · Running the site
- How to make the three or four edits this client will actually makeChange a phone number, add a team member, publish a post, update opening hours. Written for their site, not for their CMS in general.
- What they should not editShort and specific. Template files, DNS, the payment integration.
- Backups — where, how often, how far back, and how to restoreA backup nobody knows how to restore is not a backup.
- Updates — who applies them and how oftenCore, plugins, themes, dependencies. Name the party.
- The recurring maintenance scheduleGrouped by how often the work happens, with a name against every row. Some of those rows are the client’s, and those are the ones that stop happening silently.
6 · The commercial side
- What the ongoing arrangement coversIn sentences a non-technical reader can hold in their head.
- What is billed separatelyNew pages, design work, third-party fees, anything measured in days.
- Response times, and the hours they apply toOnly if you intend to honour them.
- Emergency contact and what counts as an emergency“The site is down” and “the logo looks small on my phone” should not arrive through the same channel.
- Warranty or bug-fix period after launchWhen it starts, when it ends, what it covers.
7 · Closing it out
- Files and assetsLogo files, brand guidelines, source design files, licensed images and the licence terms. Record where they live and who owns them.
- Credentials transferred separatelyThrough a password manager or a channel with an expiry. Not in this document. Not in the covering email.
- Ownership transfers actually completedNot “invitation sent”. Accepted, and verified by you.
- A dated record of the handoverWhat was covered, on what date, with which person.
Print this page for a paper copy of the list. It is laid out to print cleanly — the navigation, sidebar and calls to action drop out.
Doing this by hand for every client?
Handover turns the same seven groups into one branded client manual with a live URL and a printable PDF — your logo, your colours, in English or Spanish. The facts change per client; the explanations around them do not.
Create your first manual freeWhat stays off the checklist
Passwords, API keys and recovery codes do not belong in a handover document. The document records which accounts exist, what each one controls, who owns it and where access is managed. The credentials themselves move separately.
This is not caution for its own sake. A handover document is built to be forwarded — to a bookkeeper, to a new marketing hire, to whichever developer picks the site up in three years. It gets printed and filed. It sits in an email thread for the life of the business. Every one of those copies is a copy you cannot revoke, and a shared password inside one of them is a credential you have permanently lost control of.
This is covered in full in how to hand over website passwords. Watch in particular for the version that survives the rule: a share link. Links from Dropbox, Google Drive and Figma frequently carry an access token in the URL, which means the link itself is the secret. A document with no passwords in it can still hand a stranger your client’s brand assets. If a file should not be opened by anyone holding the URL, record where it lives instead of linking it.
Confirming the handover
Write a short dated record of what was handed over, when, and who you went through it with. Keep it a record rather than presenting it as a signature — anyone can type a name into a form, and an unverified click invites more reliance than it can carry.
Six months later, the disagreement is almost never about what the document said. It is about whether the registrar account was ever actually transferred, and whether anyone talked the client through what they had taken on. A note saying handover completed on 14 March, covering domain, hosting, analytics and the maintenance schedule, confirmed with Sarah Bell settles both, and it costs a minute.
If a genuinely countersigned document is needed — and for most projects it is not — use a signature tool and link the handover document from inside it. Do not build a signature out of a web form with no login behind it.
When to do it
Write the handover before launch, not after. The facts are in your head during the build and gone within a fortnight, and a handover that happens after the invoice is paid is a handover that competes with the next project for your attention.
The wider process this sits inside is covered in the client offboarding checklist. The practical version: start the document at the point you first touch DNS, because that is when the domain, registrar and hosting answers are all in front of you. Fill in the rest as you go. At launch you are reviewing a nearly finished document with the client rather than reconstructing one from memory.
There is a commercial argument too, and it is not a subtle one. A client who can see a written list of the recurring work that still exists after launch — backups, updates, renewals, checking that enquiries still arrive — understands what a care plan is for. A client who never sees that list assumes the website is finished. Both of those are conversations you have at handover or never.
Hand over your next website properly
One form in. A client-ready manual out — live link, printable PDF, your branding, English or Spanish.
Start free — 1 active manual, no card
Drafts are unlimited on every plan. Archived manuals stay online and don’t count.