A website handover checklist closes a project in a way both sides can come back to. It has three parts: a checklist verified against the agreed scope, a list of defects with priority and due date, and a sign-off decision confirmed by the client. Without it, "launch" means something different to everyone. You think the job is finished, and a week later the client discovers they cannot log in to their own domain.
This guide covers one moment: handing over a finished site. Feedback on the design stage belongs to the separate guide on review rounds, and ongoing care after launch is covered in the guide to client requests after a website launch. The examples follow a fictional studio handing a site over to a fictional physiotherapy practice.
What a handover document contains
The document does not need to be long. It answers three questions: what you checked, what still does not work, and whether the client accepts the site. Each part has a different owner, so keep them separate in your template from the start.
Scroll the table sideways to see all columns.
| Part | What it contains | Who confirms |
|---|---|---|
| Checklist | Items from the scope with a result: passed, failed, not applicable | You check, the client can repeat the test |
| Defects | Description, priority, due date and the person responsible | You accept them, the client reports and verifies |
| Decision | Accepted, accepted with listed defects, or rejected with a reason | The person named by the client |
Add the date, the version of the site you checked and the address where it was available. A result from a staging copy does not carry over to the live domain automatically, so check the important items again after publishing.
Build the checklist from the scope, not a template
Ready-made launch checklists run to dozens of points, and half of them do not apply to your project. Start from the proposal or contract and turn each agreed item into a condition you can test. If a contact form was in scope, the item reads "a message from the form arrives in the practice inbox", not "there is a form". The items below come up in almost every small business project.
- Access and accounts: domain, hosting, site admin and analytics tools sit on the client's accounts, or the client holds the owner role.
- Files: a backup, source graphics, logo and photos delivered to the agreed location.
- Editing guide: a short note on changing a text, a photo and opening hours, tried out by someone on the client's side.
- Forms: every test submission reaches the right inbox and the visitor sees a confirmation.
- Contact and chat: the phone number is tappable on mobile, the email address is correct, the chat window opens and messages reach the team.
- Measurement: the analytics or widget code is installed and a test visit shows up in the dashboard.
- Mobile view: key pages and the form checked on a phone, with no clipped text or overlapping elements.
Write each item so two people would judge it the same way. The guide to task acceptance criteria shows how to build such a condition from context and observation. If the client asks for something outside the scope during sign-off, record it separately as a new request, not as a failed item.
Hand over access by invitation, not a password in chat
A common problem years later is a site whose domain or analytics account belongs to a former contractor. The safest setup is for the client to create accounts with their own business address and invite you as a user. At handover nobody has to pass on a password; you simply change or remove your role. Never send passwords by email or chat. If an account had to be created on your side, transfer it through the client's password manager and ask them to change the password once they take over.
Google's Search Console help describes verified and delegated owners, states that a property must have at least one verified owner, and warns that a removed owner can re-verify as long as their verification token stays on the site. When you take over a site, remove previous owners' tokens as well. It covers that tool only, not domains or hosting: Managing owners and users in Search Console.
List the accounts in a table: tool, owner, your role after handover and the date checked. Write account and role names only, never passwords. Before signing off, the client should log in to each one personally.
Log defects as tasks with a priority and a due date
A defect is a checklist item that failed its test. "Something is off with contact" cannot be fixed; "on mobile, the cookie banner covers the form's submit button" can. Each defect gets its own task so its status stays visible independently of the rest.
- Describe the symptom.State the page, the device, the action taken and what happened instead of the expected result.
- Set a priority.Separate defects that block launch, such as a broken form, from those that can wait, such as spacing under a photo.
- Agree a date and an owner.Record a fix date for every defect and one responsible person on your side.
- Close after a recheck.A defect is fixed only when someone has repeated the test and recorded the result, not when its author marks it done.
Order fixes by impact on the client rather than by what is quickest; the distinction between bug priority and severity helps here. When closing a defect, keep short task completion evidence: version, device and observed result. In Meetlead Projects a defect can be a task or a bug with a priority, an assignee, a status and comments; put the due date in the task description.
A sign-off decision the client confirms
The decision has three possible outcomes: accepted without remarks, accepted with a list of defects to fix by a date, or rejected with the items that failed. The second is the most common and lets the site go live while small issues remain. Confirmation should come from the person the client named, in a channel you can find again later.
"Attached is the handover document for the site version dated [date]. Every checklist item passed except two defects: [defect 1] due on [date] and [defect 2] due on [date]. Please reply by [day] with one of three options: accepted, accepted with these defects, or a list of the items you consider not met."
The consequences of sign-off, such as the final payment or the transfer of rights to the design, are set by your contract. This article is not legal advice; if the contract is silent on them, settle them with a lawyer before launch. Do not assume what a client's silence means: in some legal systems, for example German law on contracts for work (Section 640(2) BGB), failing to refuse within a set deadline can count as acceptance, so check your contract and the law that governs it.
Who handles what after launch, and the 30-day review
The last part of the document assigns roles. Name the site owner on the client's side, the person who answers form and chat messages, and the channel the client uses to report problems after handover. The rules for that ongoing care, request types and response times have their own guide; the handover document only needs one sentence naming the channel.
Schedule a review after roughly 30 days. Check whether real messages arrive through the form and chat, and compare the data with the period before launch if the site replaced an old one; the guide to a website rebuild and tracking explains what to watch for. If the Meetlead widget runs on the site, heatmaps and session recordings on a plan that includes them show whether visitors actually reach the form and contact paths. Report findings from the review through the same channel as any other post-handover request.
Questions about website sign-off
Does a minor defect block sign-off? Usually not. If it does not get in the way of contact or mislead visitors, list it with a due date and choose acceptance with defects. Blocking items are those without which the site cannot do its job, such as a broken form or the client having no access to the domain.
What if the client reports a defect a month after sign-off? Compare it with the checklist and the version you tested. If the item was in scope and stopped working, it is a fix under the terms of your contract. If it is a new expectation, treat it as a change and assess it separately, without quietly adding it to the old document.
