How to hand over a website so your team can run it
A website project isn't finished at launch. It's finished when your team can run the site without the person who built it. Here's what a good handover includes, and what to check before you sign it off.
The short answer: everything should be in your name, your team should know how to make everyday changes, and the design should be built so those changes can't break it. If any of the three is missing, you'll be calling the designer for every new blog post.
Who should own the accounts?
You should. The website platform account, the plan, the domain, analytics and any connected tools should be set up in your company's name, paid with your company's card, from the start. The designer works in them as an invited collaborator. Then handover is simple: you remove their access the day the project ends, and nothing moves.
- The website platform account and plan, in your name.
- The domain, registered to your company, with a login someone on your team holds.
- Analytics and search console access, with your team as owner.
- Any form, CRM or email tools the site connects to.
The domain is the one that causes the most trouble. It is often registered years ago by a former employee or an old agency, on a personal email address nobody checks. If that registration lapses, your site and your company email can both stop working. Before the project starts, find out who holds the domain, move it into a company account if needed, and turn on auto-renew. In Search Console, add a second owner from your own team, so access doesn't depend on one person (Search Console Help explains owners and users).
What should be on the handover list?
| Item | Why it matters |
|---|---|
| Every login, in a shared password manager | Nobody on your team gets locked out when one person leaves |
| A walkthrough video | New editors can learn the site without a meeting |
| A list of reusable sections | Your team builds new pages from parts that already work |
| The redirect list | You can check old links still land on the right page |
| Where forms and tracking go | Leads keep reaching the right inbox or CRM |
How can your team edit without breaking the design?
The answer is in how the site is built, not in how careful your team is. Pages should be made from sections that can be reused: a hero, a case-study grid, a quote, a call to action. Content that repeats, like blog posts, case studies or job ads, should live in a CMS, where editors fill in fields and the design stays put. Most platforms also let you give editors a role that changes content but not layout. In Webflow that's a content editor role; in Framer designers can lock layers so they aren't moved by accident.
Why record a walkthrough video?
A live training session is forgotten in a week, and the person who attended may leave. A short recorded walkthrough of the real site, showing how to add a post, swap an image, create a page from sections and publish, stays useful for years. Ask for it as part of the project, not as an extra.
What should you check before signing off?
- Log in to every account yourself, from your own device.
- Have the person who will edit the site make a change and publish it.
- Open a few old links and check they redirect to the right new page.
- Send a test enquiry through each form and check it arrives where it should.
- Remove the designer's access, or agree a date to do it.
What should the written handover notes cover?
The video shows how to do things; a short written page records why the site is set up the way it is. Keep it to one page your team can search, not a manual nobody opens. A useful page answers the questions people will ask in six months, when the person who ran the project may be gone.
- Which pages are built from the CMS and which are one-off layouts.
- Which sections exist, and an example page where each one is used.
- Where each form sends its entries, and who receives them.
- Which tracking and cookie tools are installed, and why.
- Which fonts, images and icons are licensed, and where the files live.
- Who to call for what: platform support, the domain registrar, the designer.
What should your team do in the first 90 days?
The first three months decide whether the site keeps improving or slowly goes stale. Treat it as a short plan with an owner, not as something that happens when someone has time. Most of it is small: publish regularly, watch what visitors and search engines do, and fix what you find while it's still fresh.
| When | What to do |
|---|---|
| Week 1 | Check forms, redirects and analytics daily; note anything that looks wrong |
| Weeks 2 to 4 | Publish the first new post or case study without help |
| Month 2 | Look at which pages get visits and enquiries, and which get none |
| Month 3 | Update the pages that underperform, and review who still has access |
What happens if something breaks after launch?
Small issues often show up in the first weeks, once real visitors and real editors use the site. Agree up front who fixes them and for how long. On my projects, anything off in the first 30 days I fix free. After that, monthly care is optional. And because the site is on a mainstream platform with a visual editor, any designer who knows that platform can pick it up later.
Moving from another platform? Read how to move platforms without losing rankings. If you'd like a site your team can run on its own, tell me about your project.