Website Handover Checklist: 43 Items to Hand Over at Launch (Free Template)

A website handover checklist is the list of everything a client should receive when their new site goes live, so that a year later nobody is hunting for the hosting login or discovering that the domain renewed on the agency's card. Many problems after launch aren't bugs at all: an account nobody owns, a license that lapsed, a backup that was never tested. The 43 items below are grouped into ten areas, and the free templates turn them into an Excel tracker and a Word handover document that both sides sign.

What is a website handover?

A website handover is the point at which the agency or freelancer who built a site transfers its ownership, access and know-how to the client, so the client can run the site without them. It has three parts: the accounts move into the client's name, the knowledge moves into a document, and the responsibilities for what happens next are written down.

It isn't the same as approval. Client website approval confirms the site is right; the handover confirms the client can run it. Approval usually comes first, at the end of the review on staging, and the handover happens at launch or in the days after.

A handover protects the agency as much as the client. When every account is in the client's name and the support terms are signed, a call about an expired SSL certificate two years later is a quick question, not an argument about who should have renewed it.

What should a website handover checklist include?

Ten areas: access and ownership; domain, DNS and email; hosting and environments; code and CMS; backups and security; content and SEO; analytics, tracking and legal; third-party services; training and documentation; and support and warranty. Each one prevents a specific problem that usually shows up months after launch, when nobody remembers how things were set up.

The checks below are the same ones in the Excel file, where each item also says who usually does it: the agency, the client or both.

1. Access and ownership

• Domain registrar account in the client's name, with the client's email as the contact
• Hosting or server account owned by the client, or a written hosting agreement if you host the site
• CMS administrator account created for the client, with their own email address
• Agency accounts reduced to what the support plan needs, or removed
• Passwords shared through a password manager, never by email or in the handover document
• Two-factor authentication on the client's own accounts, with the recovery codes kept by the client

2. Domain, DNS and email

• Domain renewal date and auto-renew setting recorded
• DNS records documented (A, CNAME, MX, TXT), and where they are managed
• SSL certificate working on www and non-www, with the renewal method noted
• Emails sent by the site arrive (SPF, DKIM and DMARC records in place)

3. Hosting and environments

• Live, staging and local environments listed with their addresses
• Staging site password-protected and hidden from search engines, or deleted
• Hosting plan, server software and versions recorded
• Scheduled tasks (cron jobs) and server settings documented
• Feedback or testing scripts pointed at the live domain, or removed

4. Code and CMS

• Source code delivered: repository transferred, or an archive handed over
• Theme, plugins and extensions listed with versions and why each one is there
• Premium licenses registered to the client, or a renewal plan agreed
• Custom code and settings that must not be changed are documented
• Debug mode off; test orders, demo content and test users removed

5. Backups and security

• Automatic backups running, stored away from the server, with the retention period noted
• One restore tested, with the date recorded
• Security settings (firewall, login protection, security plugin) documented
• User accounts reviewed: no shared logins, no unused accounts, the right roles

6. Content and SEO

• Final content approved: texts, images, prices and legal pages
• Redirects from old URLs in place, if this was a redesign
• Search Console verified on the client's account and the sitemap submitted
• No noindex or "discourage search engines" setting left on the live site

7. Analytics, tracking and legal

• Analytics property owned by the client's account, with the agency added as a user
• Conversion events tested on the live domain
• Cookie banner and privacy policy match the tools installed on the site
• Licenses for fonts, images and stock photos recorded

8. Third-party services

• Payment, CRM, newsletter, maps and other service accounts in the client's name
• API keys created on agency accounts replaced with the client's own
• Form submissions go to the client's inbox or CRM, not the agency's

9. Training and documentation

• Editing guide delivered: pages, images, menus, blog posts, forms
• Training session held, and recorded if the client agrees
• Handover document completed, signed and stored with the project files

10. Support and warranty

• Warranty period stated, with its end date
• How to report an issue after launch, and who answers
• What counts as a bug fix and what is a change request, and the rate for changes
• Maintenance plan offered, and accepted or declined in writing
• Open issues listed with an agreed fix date

For the technical checks that come before all of this (forms, links, devices, speed), run the website QA checklist on staging first. The handover assumes the site already works.

What goes in a website handover document?

The handover document is the written record of the site: one file the client keeps, with where each account lives, how the site is built and backed up, what it costs to run and what support comes next. The Word template has these sections:

• Project details: live and staging addresses, contacts on both sides, go-live date, handover date and the end of the warranty period.
• Accounts and access: one row per service (registrar, DNS, hosting, CMS, repository, email sending, analytics, Search Console, tag manager, CDN, backups, payments) with its address, owner, who has admin access and whether two-factor authentication is on.
• Technical summary: platform and version, theme or framework, server versions, environments, how changes are deployed, scheduled tasks and what must not be changed.
• Plugins, extensions and licenses: what each one does, who owns the license and when it renews.
• Backups: what is backed up, how often, where, for how long, the date of the last restore test and how to restore.
• Editing the website: how to change pages, menus and posts, image sizes, where form submissions go, and a link to the training recording.
• Renewals and running costs: domain, hosting, paid certificates, premium plugins, fonts and images, with who pays.
• Support after launch: what the warranty covers and until when, how to report an issue, response time, how bugs and change requests are told apart, and the rate for changes.
• Open issues: anything unfinished, with who fixes it and by when.
• Handover sign-off: a short statement and signature blocks for the client and the agency.

One rule matters more than the rest: no passwords in the document. It gets emailed, printed and forwarded. Record where each account lives and who owns it, and share the credentials through a password manager.

Who should own the domain, hosting and other accounts?

The client, wherever the client pays for the site. Accounts registered by the agency "to save time" cause trouble long after the handover: renewals charged to the wrong card, a client who can't move hosts, or a domain that lapses because the reminder went to a former employee's inbox. Set accounts up in the client's name from the first week of the project, and invite yourself as a user.

Hosting client sites yourself is a valid business model. Just write down what the client gets if they leave, so the question never comes up in the middle of a dispute. Google's help on managing Search Console users and owners shows the pattern most services follow: the client is the owner, everyone else is added as a user and removed when they no longer need access.

How does the website handover process work?

It runs from kickoff to the end of the warranty period, not just on launch day. The meeting itself is short when the checklist was filled in during the build; it's long and stressful when someone tries to reconstruct three months of setup in an afternoon.

1. At kickoff, write in the contract who owns which accounts and the code, how long the warranty lasts and what support costs afterwards.
2. During the build, create each account in the client's name and add it to the access register the day you set it up.
3. Before launch, run QA on staging, get the client's approval and agree the go-live date.
4. On launch day, switch the DNS, re-test the forms on the live domain, check SSL on www and non-www, submit the sitemap and take a backup.
5. At the handover meeting, go through the document and the CMS with the client, and record the session if they agree.
6. After the meeting, the client changes the passwords the agency set, and the agency keeps only its own named user.
7. Both sides sign the handover document, and each keeps a copy.
8. During the warranty period, collect every issue in one place. When it ends, close the project or move the site to a maintenance plan.

How do you handle client issues after the handover?

Agree on one way to report them, give the warranty period an end date and keep bugs apart from new requests. The first weeks after launch are when real visitors and the client's team find what the staging review missed, so the reporting channel matters more then than at any other time.

Bugs in the delivered work are covered by the warranty. A new page, a new feature or "can we move this section up" is a change request, quoted and scheduled separately. Saying so in the handover document, before the first request arrives, avoids the awkward conversation later.

The reporting channel is where it usually falls apart: a screenshot in a chat, a voice note, an email that says "the form on the website isn't working". A feedback button on the live site fixes that. With GiveFeedback.io, you add one script to the site's <head> (the install guides cover WordPress, Shopify, Wix, Squarespace, PrestaShop and Google Tag Manager) and a "Give Feedback" button appears. The client clicks it, marks up a screenshot of the page with arrows, boxes, text or numbered markers, and sends it without creating an account, from a computer, a phone or a tablet.

Each report arrives with the page URL, the browser and version, the operating system, the screen resolution and a log of the page's console messages, errors and failed requests. You mark reports open, resolved or archived, and you can invite the client by email to a read-only view of the project's feedback, so they see what was fixed during the warranty without asking. Reports can also go straight to the tool your team uses: Jira, Trello, ClickUp, Asana, monday.com, Wrike, Notion, Slack, Discord or email (all integrations).

If the project was set up on the staging address during the review, change its address to the live domain on launch day; the checklist has a line for it under hosting and environments. The Free plan covers 5 projects and 50 feedback reports; see pricing for the paid plans.

What are the most common website handover mistakes?

Nearly all of them come from leaving the handover until launch day. The rest come from treating it as a technical task, when what the client needs is to be able to run the site and to know who to call.

• Registering the domain or the hosting on the agency's account and becoming the client's renewal reminder for years.
• Sending passwords by email, or pasting them into the handover document.
• Handing over with half the checklist empty and promising to "send the rest later".
• Leaving the staging site open and indexable after launch.
• Never testing a restore, so nobody knows whether the backups work.
• Training only the person who signed the contract, not the people who will edit the site.
• No written support terms, so every "can you just..." after launch becomes free work or a dispute.

Start the checklist at kickoff and fill it in as you build. On launch day, the handover is then one meeting and two signatures, and the client walks away with a site they own and know how to run.