.png){kind=small}
Published:
6/8/2026
Updated:
What Should a Webflow Handoff Package Include?
TL;DR: A Webflow handoff package is the document set that lets someone other than the original developer run the site. A complete package contains six artifacts: an access and ownership record, a structure and CMS guide, an integrations register, a publishing and recovery runbook, a recorded walkthrough, and a written support boundary. Each artifact needs an acceptance test, meaning one specific task the client can finish without calling you. Webflow's legacy Editor became unavailable on August 4, 2026, so the access record now describes client seats and site roles rather than Editor logins (Webflow Help Center).
- The access and ownership record names the Workspace owner, the domain registrar and every seat holder by name.
- The structure guide documents the class naming convention, the components and every CMS Collection.
- The integrations register lists each form destination, analytics property and third-party script with the account that owns it.
- The runbook covers publishing, 301 redirects and how to restore a backup.
- A recorded walkthrough short enough to watch in one sitting deflects more support tickets than any written page.
- The support boundary states what the retainer covers and what counts as a new project.
What is a Webflow handoff package?
A Webflow handoff package is the set of documents and recordings an agency delivers alongside a finished site so the client can operate it independently. It is a deliverable with a definition of done, not a folder of leftovers, and it is distinct from the handoff process itself, which covers billing, site transfer and seat assignment and which I set out in my guide to the Webflow client handoff for agencies. In the white label builds I run for agencies, a transfer can go perfectly and the project still generates support tickets for a year, because access moved and understanding did not. If your statement of work says "documentation provided" without naming the artifacts, replace that line with the six below and quote for them.
What are the six artifacts in a Webflow handoff package?
A complete Webflow handoff package contains six artifacts, and each one answers a different question the client will eventually ask under pressure. On the projects I lead, an artifact counts as delivered only when the client has completed its acceptance test in front of me. If you cannot name the acceptance test for an artifact, that artifact is not finished.
What must the access and ownership record contain?
The access and ownership record has to name a human being for every system the site depends on, never a role and never a company. That means one named person against the Webflow Workspace, the billing account, the registrar, the DNS provider and each seat. Webflow gives you room to be generous here, since every Workspace includes one full seat for the owner plus up to 100 free Reviewer seats (Webflow Help Center), so a stakeholder who only needs to look at the site never has to share someone else's login. The seat and role matrix itself, including how many client seats each Workspace plan carries, is set out in my Webflow client handoff guide. If any line in this record names an agency inbox rather than a person at the client, rewrite that line before handoff day.
What must the record say about the domain and DNS?
The domain entry is the single most valuable line in a Webflow handoff package, because it is the one that becomes an emergency years later when nobody remembers whose personal email the registrar account sits under. The record needs the registrar name, the account holder, where DNS is hosted if it is not the registrar, and the renewal date. When I take over an inherited site, this is the first thing I ask for and the thing most often missing. If the domain still sits in an agency account after handoff, nothing else in the package matters.
What belongs in the structure and CMS guide?
The structure and CMS guide documents how the build is organised so the next developer does not have to reverse-engineer it. It covers the class naming convention, which elements are components, and for every CMS Collection the required fields, the expected image dimensions and which template it powers. Webflow's dynamic content limits belong in this document too, because they constrain what the client can ask for later: 40 Collection lists per page, 10 nested Collection lists per page, and 100 items per list without pagination (Webflow Help Center). What I see agencies get wrong here is documenting the design system beautifully and the CMS not at all, when the CMS is the only part the client touches daily. If a client cannot tell which fields are mandatory without trial and error, the guide is incomplete.
What must the integrations register list?
The integrations register names every external service the site talks to and, critically, the account that owns each one: the destination for each form, the analytics property ID, the CRM connection, any embedded scheduling or chat widget, and any custom script in Site settings. Worth recording alongside it is that merging a page branch in Webflow permanently deletes all comments on that branch, so review decisions living only in comments do not survive a merge (Webflow Help Center). When I audit an inherited Webflow site, the integrations register is the document missing in roughly every case, and the client finds out when a form silently stops delivering. Write it during the build, because by the end nobody remembers which analytics account was used in week two.
How do you document publishing and recovery?
The publishing and recovery runbook explains three things: how to publish, where redirects live, and how to undo a mistake. Webflow creates restore points automatically on every 50th auto-save, and only Site managers can access site backups (Webflow Help Center). Redirects earn their own entry, because adding a 301 redirect requires a paid Site plan or a site inside a paid Workspace, and Webflow recommends a maximum of 1,000 redirects as best practice even though no hard limit is enforced (Webflow Help Center). The rule I apply on client projects is that at least one person on the client side holds the Site manager role before the project closes. If nobody does, the client cannot restore a backup without calling the agency, which is a support cost nobody priced.
What is the acceptance test for a Webflow handoff package?
The acceptance test for a Webflow handoff package is a short live session in which the client performs each task themselves while the developer stays silent. Reading a document proves nothing; completing the task proves the document works. I run it on a call rather than by email so a failure is visible immediately.
| Artifact | The client must be able to | Fails when |
|---|---|---|
| Access and ownership record | Log in to Webflow and the registrar on their own device | The invite went to a shared inbox nobody monitors |
| Structure and CMS guide | Publish one real CMS item with all required fields filled | Required fields and image sizes are undocumented |
| Integrations register | Send a test form and locate the submission | The destination account is owned by the agency |
| Publishing and recovery runbook | Publish a copy change and describe how to roll it back | No client-side user holds the Site manager role |
| Recorded walkthrough | Hand the recording to a colleague who was not on the project | The recording lives only in the agency's drive |
| Support boundary | Say which of three sample requests are billable | Scope is described as "reasonable support" |
How long should a Webflow handoff package take to build?
A Webflow handoff package should take under one working day for a typical marketing site, provided it was written during the build rather than reconstructed afterwards. Retroactive assembly is where the cost explodes, because the integrations register depends on decisions made months earlier by people who have moved on. On the projects I lead, the structure guide and integrations register are updated at the end of each sprint, which turns handoff week into a review rather than an excavation.
One entry is easy to forget: Webflow has a native Schema markup field in Page Settings for static and Collection pages, on any paid Site plan or paid Workspace (Webflow Help Center). Record which pages already have schema so the client's next SEO consultant does not duplicate it. The pre-launch checks feeding all of this are in my Webflow QA checklist for agencies.
If your handoffs keep producing support tickets months after launch, the gap is almost always one of these six artifacts. Tell me how you hand over projects today and I will tell you which one is missing.
FAQ
What should a Webflow handoff package include?
A Webflow handoff package should include six artifacts: an access and ownership record naming a person for every system, a structure and CMS guide covering class naming and every Collection, an integrations register listing each external service and its owning account, a publishing and recovery runbook, a recorded walkthrough, and a written support boundary. Anything less leaves the client dependent on the original developer.
What is the difference between a Webflow handoff and a Webflow handoff package?
A Webflow handoff is the process of moving billing, ownership and access to the client. A Webflow handoff package is the deliverable that travels with it: the documents and recordings that explain how the site works. The process can complete perfectly while the package is missing, which is exactly how an agency ends up answering support questions for a year after launch.
How do you know a Webflow handoff package is complete?
A Webflow handoff package is complete when the client passes an acceptance test for every artifact, performed by the client while the developer stays silent. The client should log in on their own device, publish one real CMS item, send a test form and locate the submission, publish a copy change, and correctly classify sample requests as billable or covered. Reading a document proves nothing; completing the task proves the document works.
Who should write the Webflow handoff package?
The developer who built the site should write the Webflow handoff package, incrementally, during the build rather than at the end. The integrations register in particular depends on decisions made months earlier, and reconstructing it after launch means chasing people who have moved on. Updating the structure guide and integrations register at the end of each sprint turns handoff week into a review rather than an excavation.
What do agencies most often leave out of a Webflow handoff package?
The integrations register is the artifact most often missing from a Webflow handoff package. Agencies document the design system carefully and never write down which account owns each form destination, analytics property, CRM connection or third-party script. The client usually discovers the gap when a form silently stops delivering leads, often more than a year after the project closed.
Why does the domain and DNS entry matter so much in a handoff package?
The domain entry is the most valuable line in a Webflow handoff package because it becomes an emergency years later when nobody remembers whose personal email the registrar account sits under. The record needs the registrar name, the account holder, where DNS is hosted if it is not the registrar, and the renewal date. If the domain still sits in an agency account after handoff, nothing else in the package matters.