Delivering a Webflow website to a client is the part of the project most likely to go wrong, and it has almost nothing to do with how well the site was built. The build is finished. What follows is a review round, a transfer, and a handover — three separate things that most people run as one messy week of messages.
This is the process I use. It assumes you are a freelancer or small agency handing a Webflow site to a non-technical client who will own it afterwards.
The short answer
Deliver a Webflow site in four stages: run a pre-handoff QA pass yourself, share a staging link for one structured review round, transfer the project and hosting to the client’s own Webflow account, then hand over editor access and a short guide. Doing the transfer before the review is the most common mistake — it hands the client a bill and an unfinished site at the same time.
Stage 1: QA it before anyone else sees it
Every issue the client finds costs you a round trip. Every issue you find costs you five minutes. The economics of catching things yourself are not close, and yet most handoffs skip straight to "here’s the link, let me know what you think."
Before you share anything, walk the site at three widths — desktop, tablet, and a real phone, not just the Webflow designer’s preview. Then check:
- Every link goes somewhere. Empty href="#" placeholders are the single most common thing shipped by accident.
- Forms actually submit, and the success and error states both look intentional.
- Page titles and meta descriptions are set on every page, not left as the template default.
- The 404 page exists and has a way back to the homepage.
- Open Graph images are set, so the first person who shares the link does not post a blank card.
- Favicon and webclip are uploaded.
- No lorem ipsum, and no placeholder images from the template.
- CMS collections have real content in every field you bound, including the ones only visible on hover or in a modal.
This list takes twenty minutes and removes most of what a client would otherwise report as "bugs" — which matters, because a client who finds five obvious mistakes starts reading the whole site as unfinished, and their feedback gets harsher for the rest of the project.
Stage 2: run one structured review round
The review is where Webflow handoffs actually fall apart. You send a staging link. The client replies with a paragraph, a screenshot cropped so tightly you cannot tell which page it is, and a phone call about "the spacing." Then their colleague adds three more notes in a separate thread.
The problem is not that clients give bad feedback. It is that you have asked them to describe a visual problem in words, to someone who is not looking at their screen, without the vocabulary for padding or breakpoints.
Client: "The header feels off on mobile and the button is the wrong blue."
A comment pinned to the exact element, on the exact page, at 390px wide, that says "this wraps onto three lines here."
Whatever tool you use, the review round needs four rules:
- 1One channel. Not email plus WhatsApp plus a call. Everything in one place or you will lose half of it.
- 2One deadline. "Send me everything by Thursday" produces a complete list; open-ended review produces a trickle that never ends.
- 3One person collating. If the client has a team, they nominate someone to gather internal opinions before they reach you.
- 4A fixed number of rounds, agreed in writing before the link is sent. Two is normal. Unlimited is how projects die.
The fourth rule is the one people skip, and it is the one that protects the project. "Two rounds of revisions" in a proposal is not a limit anyone remembers. Saying it again when you send the staging link is what makes it real.
If the round-trip on visual feedback is what slows your handoffs down, pinning comments directly onto the live staging page removes the describing step entirely. See how pinned feedback works →
Stage 3: transfer the project and the hosting
Two separate things get transferred in Webflow, and confusing them is the usual source of a panicked message three months later.
Transferring the project
The client needs their own Webflow account. From your dashboard, open the project settings, find the transfer option, and send it to their email. They accept, and the project moves out of your workspace into theirs. You lose access unless they invite you back.
Do this after the review is finished, not before. Transferring early means the client is paying for hosting on a site that is not done, and it means you need their permission to keep working on it.
Transferring the hosting bill
Site plans are billed separately from the project itself. If you paid for hosting during the build, the client needs to add their own card and their own site plan once the project is theirs. Agree who pays for what before you start — "I assumed hosting was included" is a genuinely common argument, and it is entirely preventable with one sentence in the proposal.
The domain
Wherever possible, the client should own the domain registration in their own account, with you added as a user. Registering a client’s domain in your own name is convenient for a week and a liability forever — if the relationship ends badly, or you are simply unreachable, they cannot move their own website.
Stage 4: hand over access, then teach them what not to touch
Webflow has two levels of access, and giving the wrong one is how a client rebuilds your layout by accident.
- Editor access lets someone change text, swap images and manage CMS items on the live site. This is what nearly every client should get.
- Designer access lets someone change structure, styles and interactions. This is what breaks things.
Default to Editor. If a client insists on Designer access, that is their call, but say plainly that layout changes made there are not covered by your support and will be billed as new work.
Then record a short walkthrough — five minutes is plenty. Show them how to edit a heading, how to add a CMS item, how to publish, and one thing they should not do. A five-minute video removes more support requests than a twenty-page PDF nobody opens.
What to include in the handover
Send one message with everything in it, so there is a single place to look in six months:
- 1The live URL and the Webflow project link.
- 2Confirmation the project and site plan are in their account, with the date.
- 3Who owns the domain and where it is registered.
- 4The Editor walkthrough video.
- 5A list of anything they are responsible for renewing — domain, site plan, any third-party tools.
- 6What your support covers after handoff, and for how long.
- 7What counts as new work, with your rate.
The last two lines are the ones that prevent the slow unpaid drift where a delivered project turns into a year of free favours. Writing them down is not unfriendly; it is the thing that makes it comfortable to say no later.
The mistakes that cost the most
- Transferring the project before the review is finished, so the client pays for an unfinished site and you need permission to fix it.
- Giving Designer access by default, then rebuilding a layout for free.
- Registering the domain in your own name.
- Starting the review with no deadline and no round limit.
- Handing over with no written scope for post-launch support.
A handoff is not a file transfer. It is the moment you stop being responsible for something, and that only works if both people agree it happened.
Frequently asked
How do I transfer a Webflow site to a client?
Ask the client to create a free Webflow account, then use the project transfer option in your project settings and send it to that email address. They accept, and the project moves to their workspace. The site plan is separate and needs to be purchased on their account.
Should I give my client Designer or Editor access?
Editor, in almost every case. It covers text, images and CMS content — everything a client actually needs — without exposing the structure and styles that would let them break the layout.
Who should pay for Webflow hosting?
The client, on their own account, from the point of handoff. Some agencies bundle hosting into a retainer, which is fine as long as it is written down. What causes disputes is neither party stating it before launch.
How many rounds of revisions should a Webflow project include?
Two is the common standard, stated in the proposal and repeated when you send the staging link. The number matters less than the fact that a number exists and both people heard it.