Website Client Handoff Checklist
40 items in 6 sections · progress saved in your browser · export as PDF · copy summary
The last step before you launch a client site should feel clean, not chaotic. This free checklist walks you through everything – from performance and SEO basics to forms, analytics, and final delivery. Check it off, export it, and hand over with confidence.
What Is a Website Handoff Checklist?
A website handoff checklist is a structured list of everything a freelance web designer should verify before officially delivering a completed website to a client. It covers the technical, visual, and administrative steps that ensure the site is ready to go live – and that nothing important is forgotten in the rush to close the project.
The handoff moment is often rushed. You've been working on a project for weeks, the client is eager to launch, and the pressure to wrap up is real. Without a checklist, small but important things fall through the cracks: a broken form, a missing favicon, Google Analytics not connected, or the client not having their own login credentials. These aren't catastrophic issues on their own, but they add up – and they're the kind of things that lead to late-night messages from clients after launch.
A good handoff checklist is also a professional signal. Handing over a completed site alongside a documented checklist tells the client you're thorough, organized, and take your work seriously. It reduces the chance of scope creep post-launch, because you've clearly documented what was delivered and verified.
Why Freelancers Need a Structured Handoff Process
Most freelancers learn the value of a handoff checklist the hard way – after forgetting something important. The problem isn't competence, it's context-switching. By the time you're finishing a project, you're often already thinking about the next one. The last 5% of a project gets less attention than it deserves.
A structured handoff process does three things: it protects you, it protects the client, and it makes the entire project feel more professional.
It protects you because it creates a record of what was delivered and tested. If a client comes back three months later and says "the contact form wasn't working at launch," you have documentation that proves it was tested and signed off. It protects the client because it ensures they're actually getting everything they paid for – not a site that looks finished but has three broken links and no analytics. And it makes the project feel professional because a clean handoff is the last impression you leave. Clients remember the end of projects more than the middle.
Beyond individual projects, having a reliable handoff process builds reputation. Freelancers who consistently deliver clean, documented handoffs get better reviews, more referrals, and clients who come back. It's one of the lowest-effort, highest-return habits you can build.
The Complete Website Handoff Checklist Explained
Let's break down what each category in this checklist is checking for – and why it matters.
Design & Content is where you verify the obvious things that somehow still get missed. Placeholder text. A favicon that's still the platform default. A 404 page that looks nothing like the rest of the site. These are small, but they're what clients notice first.
Performance & Speed matters more than most designers think at handoff. A site that scored 40 on PageSpeed Insights is a site the client will complain about – even if they can't articulate why. Compress images, check load times on mobile, and run a quick PageSpeed report before you hand anything over. A score above 80 on mobile is a reasonable target for most projects.
SEO Basics is often the most skipped category, and the most consequential. Missing title tags, no meta descriptions, and an unconfigured sitemap means the client's site starts its life invisible to search engines. You don't need to do full SEO work – but the basics take 30 minutes and make a real difference. Setting up Google Search Console is especially important and often forgotten.
Functionality & Forms is where bugs tend to hide. Forms look fine in design but break in production. Always test every form by actually submitting it and checking that the email lands in the right inbox. If there's a newsletter signup, subscribe with a test email and verify it reaches the correct list.
Cross-Device & Browser Testing catches the layout issues that are invisible on your development machine. Safari on iOS renders things differently than Chrome on desktop. Test on a real phone if you can – not just a browser resize.
Analytics & Handover is the administrative close-out. The client should leave the project with access to their own analytics, their own CMS, and a basic understanding of how to use it. If they have to ask you for their own login credentials six months later, something went wrong at handoff.
Common Mistakes Freelancers Make at Handoff
Handing over too quickly. The client is excited, you're excited, and you both just want to be done. But a site launched with a broken form or missing analytics is a site that will require unpaid follow-up work.
Not testing forms in production. Forms that work in staging sometimes break when the domain changes or the backend environment is different. Always test after going live, not before.
Forgetting to transfer ownership. The site should belong to the client – their Google Analytics account, their hosting login, their domain. Freelancers who hold onto these "for convenience" create dependency, and that's a bad dynamic for everyone.
Skipping the client walkthrough. Even a 10-minute Loom video explaining how to log into the CMS, update a text field, or add a blog post saves dozens of future support messages. Clients who understand their own site feel more confident and require less hand-holding.
No documentation of what was delivered. Without a written record of what was tested and handed over, scope creep post-launch is hard to push back on. A completed checklist is your paper trail.
How to Present the Handoff to a Non-Technical Client
Most clients don't know what a sitemap is. They don't care about PageSpeed scores or robots.txt. What they care about is whether the site looks right, works correctly, and is ready for people to see.
The best handoffs for non-technical clients are visual and structured. Instead of sending a technical report, send them a short message with three things: what you've delivered, what you've checked, and what they need to do next (if anything). Attach the completed checklist as a PDF – not to overwhelm them with technical items, but to show them you've been thorough.
Then give them one final thing to do: review the live site one last time and give you the green light. This is where a tool like dotts comes in – instead of asking them to write feedback in an email, you send them a link and they can click directly on anything they want to change. One round of final feedback, pinned to the exact element, before you officially close the project.
Before you hand over: run one last feedback round.
Send your client one link to the live site. They click where something should change and leave a comment. You work through the list and mark each point as resolved. No email, no screenshot with a red arrow, no "the thing on the left on the third page".
Free plan available. No credit card.
Handing a website over to a small business owner
A small business owner is not a marketing department. Nobody there manages DNS records or knows what a CMS collection is, and in a year the person you trained may have left. Six things make the difference between a handover that holds and one that ends in a support call:
- Every account in the client's name. Domain, hosting, CMS, analytics and the email provider should be registered to the client's own address, with you added as a user. An account in your name is a hostage, even when nobody means it that way.
- Invoices go to the client. Domain and hosting renew automatically. If the card on file is yours, you are the one who finds out at renewal, usually while the site is down.
- One page of "who to call for what". Domain registrar, host, CMS, form provider and you, each with what they are responsible for. One page, not a manual.
- A short guide for the two or three changes they will actually make. Opening hours, a phone number, a new team photo. Screenshots or a three-minute screen recording beat a written handbook nobody opens.
- Say what is not included. Updates, backups, plugin maintenance and new content are either yours to do or theirs. Write down which, before the first request arrives.
- One last review round on the live site. Let them click through the finished site and say what still bothers them, before you call the project closed.
Before you get there, run the pre-launch QA checklist so the handover conversation is about training, not about a broken form.
Handoff Notes by Platform
The checklist above applies to every project. What follows is what each platform's own documentation says about moving a site into the client's account, checked on 15 September 2026.
Transfer the site to the client's own Workspace. They need a Webflow account and a Workspace first; they then get an email and a banner in their dashboard to accept, and the site plus its Site plan and connected custom domains move across. Depending on the Workspace plans involved, Webflow asks you to downgrade the site to the Starter site plan before transferring. Source: Webflow Help Center, "How do I transfer a site or plan to another workspace?".
Project menu, File, Transfer Project. Only the project owner or a workspace admin can start it. The site stays live and a connected custom domain stays connected; the new owner picks and pays for the Site plan, your old plan is cancelled and the unused time becomes account credit. You can stay on as an editor during the transfer, so nobody has to re-invite you. Source: Framer help, "Transfer a project to another user".
Create a separate administrator account for the client with their own email, and never share your login. The administrator role is the one that can create and manage users and, on a single site, do everything else. Decide in writing who runs updates and backups after handover. Source: WordPress.org documentation, "Roles and Capabilities".
Invite the client as a contributor and let them accept, then open Permissions and Ownership, click your name under Owner and choose Transfer Ownership. Subscriptions, Squarespace domains and an Acuity subscription attached to the site move with it, so update the billing details afterwards and remove yourself as contributor when you are done. Source: Squarespace Help Center, "Change the site owner".
Site dashboard, Site Actions, Transfer site, then the email address of the client's Wix account. The premium plan can move with the site, you can choose to stay on as Co-Owner, and the invite expires after three days if they do not accept. Some subscriptions cannot be transferred and have to be unassigned first. Source: Wix Help Center, "Transferring a Premium Site to Another Wix Account".
Only the store owner can transfer ownership: Settings, Users, the current owner, Change ownership, or "Transfer store to a new owner outside your business". After the transfer, billing and payment areas of the admin are closed to you, so export anything you still need first. Stores using Shopify Capital or Credit cannot be transferred, and a Shopify Balance account has to be emptied first. Source: Shopify Help Center, "Change or transfer ownership".
Whatever the platform, the last step is the same: collect the final round of feedback in one place instead of in five messages, and check the other free tools if you need a price or a QA pass first.
Frequently Asked Questions
Everything you need to know about handing off a client website. Something missing? Email us at tobi@dotts.se
A complete website handoff includes verification of design accuracy, performance testing, SEO basics (title tags, meta descriptions, sitemap), form testing, cross-device and browser checks, analytics setup, and administrative handover (client login access, domain, CMS walkthrough). Using a structured checklist ensures nothing is missed.
Transfer the project to the client's Webflow account, add them as an Editor for CMS access, connect their custom domain, and ensure SSL is active. Provide a short walkthrough of how to edit CMS content. Make sure they have their own Webflow account before the handoff call.
A launch checklist focuses on technical readiness – is the site live, fast, and functional? A handoff checklist is broader and includes the administrative and communication steps of officially delivering the project to the client, including access transfer, documentation, and client training.
A thorough handoff for a standard 5–8 page website typically takes 2–4 hours: 1–2 hours for testing and verification, and 1–2 hours for documentation, access transfer, and a client walkthrough. Rushed handoffs lead to follow-up issues that take far longer to resolve.
Yes. Handoff work – testing, documentation, access transfer, client training – is real work and should be scoped into your project quote. A common approach is to include a fixed "project close-out" fee in your contracts that covers the handoff process.
A PDF works well for most clients – it's professional, can be opened anywhere, and doesn't require any account. Export the completed checklist from this tool and attach it to your final delivery email. For more technical clients, a Notion page or Google Doc also works.
This is where a clear contract matters. Define in writing what's included in post-launch support (typically a 2-week warranty period for bug fixes) and what falls under a new scope of work. A completed and signed-off checklist is evidence that the site was delivered correctly at handoff.
It's best practice to set up analytics under the client's own Google account, not yours. If you set it up in your own account and the client relationship ends, they lose their historical data. Help them create a Google Analytics property, then install the tracking code on their site.
Ideally, all design revisions are completed before the site goes into development. By the handoff stage, the client should only be doing a final visual review – not requesting design changes. Scope this clearly in your contract: "X rounds of revisions during the design phase; handoff review is for sign-off only."
Yes – the checklist is designed to work across project types and platforms. Some items may not apply to every project (e-commerce items for a simple brochure site, for example), and you can simply skip those. The core categories – design, performance, SEO, forms, testing, and handover – apply to virtually every web design project.
More free tools for freelancers