How Do You Hand Off a Webflow Site to a Client?

What happens to a Webflow site after the studio hands over the keys?

Usually one of two things. Either the client updates it confidently for years, or it slowly degrades until someone decides it needs rebuilding. The difference is almost never the design. It is whether the handoff gave the client a site they can actually operate without calling anyone.

We have delivered many projects, and the handoff is the part we have changed most over time. Early on we treated it as an admin step at the end. Now we treat it as a deliverable in its own right, planned from the first week of the build.

This is a look at how we do it and why. If you are a studio, take what is useful. If you are a client about to receive a site, this is the standard you should be holding your agency to.

What does handing off a Webflow site actually involve?

Four things, in order. Moving ownership of the site and its plan, setting the right access for the client's team, making the build understandable to whoever comes next, and teaching the people who will edit it. Skip any one of them and the client is dependent on you forever, which sounds like good business and is not.

Most agencies do the first and call it done. The client owns a site they do not understand, cannot safely change, and are afraid to touch. That fear is why so many companies rebuild a perfectly good site every three years.

Our view is blunt. A handoff that leaves the client dependent on us is a failed handoff, even if it produces more retainer revenue. We would rather be called back for the next project than be a permanent tax on the last one.

How do you transfer a Webflow site to a client?

Through a site transfer between Workspaces. Webflow's Help Center documents this as the route for freelancers and agencies handing a site to a client's Workspace. Once the recipient accepts the transfer request, the site moves out of your Workspace and into theirs, along with the Site plan and any connected custom domains.

The detail people miss is that this is a real transfer, not a sharing arrangement. The site leaves your Workspace. If you need continued access afterwards, that has to be arranged from the client's side rather than retained from yours.

Webflow supports that too. According to its Help Center, clients can add an agency or freelancer back as a Workspace guest, provided you hold an Agency or Freelancer Workspace plan. So the sequence is transfer first, then be invited back, not the other way around.

We set the client's Workspace up before transfer day rather than during it. Sorting out billing, seats, and who owns the account while a live domain hangs in the balance is a bad afternoon that is entirely avoidable.

What access should the client's team actually have?

The least that lets each person do their job. Webflow's site roles cover Admin, Designer, and Content Editor. A Content Editor works in the Editor to update text, images, and CMS content without touching design, which is exactly right for a marketing hire who should never be able to break a layout.

We push hard for this split, and clients often resist it at first because giving everyone full access feels generous. It is not generous. It is how a carefully built page gets flattened by someone who dragged a section while trying to fix a typo.

Webflow also has a Guest role, which lets you invite a collaborator to specific sites rather than the whole Workspace. That is the right shape for a contractor who needs to work on one site, and it is the role we ask to be given after a transfer.

Decide these before handover and write them down. Access decided in the moment, by whoever is in the room, is how a company ends up with six admins and no idea who owns the account.

Getting that access right at the moment of invitation is much easier than auditing it back down later. We go through every site role, the guest option, and the Enterprise controls in our guide to managing team roles and permissions in Webflow.

Why does naming decide whether a handoff works?

Because a class called "Div Block 47" tells the next person nothing, and a site full of them cannot be safely changed by anyone who did not build it. Naming is the difference between a site a client can maintain and a site only its author understands. It is the least glamorous part of the craft and the highest leverage.

This is why we build on a naming convention rather than inventing one per project. Finsweet's Client-First is the one we use, and its whole purpose is making a Webflow build legible to someone who arrives later. We wrote about how that plays out in practice in our piece on how Client-First makes Webflow projects better.

The same discipline applies to structure. Components keep repeated elements in one editable place, so a client changing a footer changes it once rather than on nineteen pages. Our guide to Webflow components covers where that pays off most.

None of this is visible in the finished site. All of it determines whether the site is still good in two years.

What should you document before you hand over?

Less than you think, and more specifically than you think. Nobody reads a fifty page manual. What clients actually use is a short document that answers the questions they will hit in their first month, written in the words they use rather than the words we use.

We cover how to add a new item to each CMS Collection, which fields are required and why, where images should be sized before upload, how to publish, and what to do if something looks wrong after publishing. That last one matters more than any of the others.

The CMS structure deserves its own explanation, because it is the part clients most often misuse. A Collection built for one purpose gets repurposed for another, fields get left blank, and the templates that depend on them break quietly. The habits in our guide to Webflow CMS best practices are worth walking a client through directly.

We record the walkthrough as well as writing it. The person in the training call is rarely the person still doing the job a year later, and a recording survives staff turnover in a way a live session does not.

How do you train a client without overwhelming them?

Teach the tasks they will actually do, not the tool. A marketing manager does not need to understand the Designer. They need to add a blog post, swap a hero image, update a pricing number, and publish. Teach those four things properly and confidence follows.

We run the session inside their own site with their own content, never a demo. People remember doing the real task once far better than watching someone narrate a generic one.

We also tell them plainly what they should not touch and why, which is more respectful than quietly hoping. Adults respond well to "this section is fragile, here is what happens if you change it, call us instead". They respond badly to discovering the fragility on their own.

What usually breaks after a handoff?

Images and CMS discipline, almost every time. Someone uploads a photo straight from a phone camera, and a page that scored well on speed suddenly does not. It is the single most common way a fast site gets slow after we leave.

The second is CMS fields left empty. A template designed around a field expects that field to exist. Blank it, and the layout does something ugly on a page nobody is looking at until a customer finds it.

The third is unmanaged third-party scripts. A new tool gets added, then another, and nobody removes the ones that stopped being used. Site speed degrades a little at a time, and no single change looks like the culprit. These are also the first things we look for from the other side of the handover, which our guide to auditing an inherited Webflow site covers in detail.

All three are predictable, which means all three belong in the training rather than in a post-mortem. We name them explicitly, because a warning given in advance is advice and the same warning given afterwards is an excuse.

Should the studio stay involved after handoff?

Only if the client wants it, and never as the price of owning their own site. We keep the door open and respond to anything that comes up, but the site is theirs and it should work without us. Dependency dressed up as a support retainer is not a service.

What we do recommend is a check-in after a few months. Sites drift. Content gets added in ways nobody planned for, and it is much cheaper to correct a pattern early than to unpick a year of it.

That check-in is also where we learn what we got wrong. Every recurring client question is a documentation gap or a build decision that was clearer to us than to them, and it goes into how we scope the next project.

What should a client ask for before accepting a handoff?

Ownership, access, and understanding. Ask for the site to be transferred into a Workspace your company controls, with billing in your name. Ask who holds admin access and make sure it is someone still working there next year. Then ask to be shown how to make a real change, and actually do it yourself in the session.

If an agency cannot explain their own class naming, or the site cannot be edited without them, that is worth knowing before the final invoice rather than after. A good build survives its builder leaving. That is the test. This is also where the question of code export usually comes up, and we answered it directly in our piece on whether you should export your Webflow site's code. Part of a clean handover is also knowing which Site plan the project sits on and what it includes, which we break down in our guide to Webflow's plan limits. It is also worth walking the client through restore points before you leave, which we cover in our guide to backing up and restoring a Webflow site.

If you are inheriting a site you did not commission and are not sure what you have got, or you are a studio trying to make your own handoff better, we are happy to talk it through. Let's talk. You can reach our team at phoenix.studio.