The "what you own" page of a handover pack

A bakery owner sells the business after eleven years. The buyer asks a simple question: who owns the website? The owner doesn't know. The designer who built it moved away. The domain renews on a card that expired last spring, the booking page belongs to an account nobody can log into, and the only record of any of it is an email thread from 2019.

Nothing went wrong on the day the site was launched. What was missing was one page, written at handover, that said what the bakery owned.

That page is the most useful part of any website handover document. It lists every account the business owns, whose name it is in, who can log in, what it costs, when it renews and who to call. It's short, it's written for the owner rather than for you, and it stays useful long after the launch email is forgotten. Here is how to write it, with a template you can copy.

What should a website handover document include?

A full handover pack usually has three parts:

1. What you own. Every account, in plain words. This article is about this page.
2. How to do the common jobs. Changing opening hours, adding a photo, reading the monthly numbers.
3. What happens next. What you still look after, what the care plan covers if there is one, and how to reach you.

Most packs spend their pages on part two, because it feels like the work. Part one is the one the client will reach for in a crisis: when they change designers, sell the business, lose a login, or get a renewal email they don't recognise. It is also the page that shows you did the job properly, because it proves nothing was left in your name by accident.

If you check the site before handing it over, the website QA checklist is a good place to confirm every account on this page actually works before you write it down.

Why does the "what you own" page matter so much?

Because ownership is decided by whose name is on an account, not by who paid for it or who built it.

Domains are the clearest case. ICANN, the body that sets the rules for web addresses, says in its Transfer Policy that the registered name holder is the only party with the authority to approve or deny moving a domain to another registrar. If the registered name holder is you, the client can't move their own web address without you. If they don't know that, they find out at the worst possible moment.

The same pattern repeats across other accounts. Google's help page for Business Profiles says a profile can have several owners but only one primary owner, and that managers can do almost everything except add or remove people or delete the profile. Google Search Console, the free tool that shows how a site appears in Google, says every site in it must have at least one verified owner, or nobody can see its data.

So the page has one job: make it obvious who holds each key.

Which accounts belong on the page?

Start with the ones the business can't run without, then add the rest. A typical local business site has most of these:

• Domain name. The web address, and the company it's registered with.
• Domain settings (DNS). The settings that point the address at the website and the email. Often in the same account as the domain, sometimes not.
• Hosting. Where the website's files live.
• Email. The mailboxes on the business's own address.
• Google Business Profile. The listing on Google Search and Maps.
• Search Console and visitor stats. How the site appears in search, and who visits.
• Payments. Card payments, deposits or online orders, if the site takes them.
• Booking, forms and phone tools. Anything customers use to reach the business through the site.
• The website itself. Where the latest copy of the site is kept, and how the client gets it.

If you've resold a receptionist or phone service to the client, add that too, including whose account the number sits in. Phone numbers are among the hardest things to move later.

What does the template look like?

One row per account. Keep the columns the same every time so any client can read any pack.

Account	Whose name it's in	Who can log in	What it costs and who pays	Renews	Who to call
Domain: bakery.example	The bakery	Owner; designer as a user	Yearly, on the bakery's card	14 March	The registrar's support
Domain settings	The bakery	Owner; designer as a user	Included with the domain	With the domain	The registrar's support
Hosting	Designer (part of care plan)	Designer	Included in care plan	Monthly	Designer
Email	The bakery	Owner, two staff	Monthly, on the bakery's card	Monthly	The email provider
Google Business Profile	The bakery (primary owner)	Owner; designer as manager	Free	None	Google support
Search Console	The bakery (verified owner)	Owner; designer as full user	Free	None	Designer
Online orders	The bakery	Owner	A fee on each payment	None	The payment company
Website copy	The bakery	Owner	Included	None	Designer

Two rules make the table honest:

• Write your own name where it's true. If hosting sits in your account as part of a care plan, say so, and say what happens if the plan ends. Whether to host client websites yourself is a fair choice either way; hiding it is not.
• No passwords. The page says where each login lives and who has one. Passwords go in a password manager, and wherever the service allows it, each person gets their own login.

What else goes on the page?

Three short sections under the table do most of the remaining work.

What happens if we stop working together. Two or three sentences: the client keeps every account in their name, you remove your access within an agreed time, and they get a copy of the site in a form another designer can use. If hosting is yours, say how long you'll keep the site running while they move. If you have ever moved a website to a new host without downtime, you know how much easier that goes when this paragraph already exists.

Dates to watch. Pull every renewal date out of the table into a short list in date order. The domain renewal is the one that matters most, because an expired domain can take the website and the email offline together.

Who to call first. Your details, and for each outside company, where to find their support. A shop owner at 7am with a broken booking page needs a name, not a URL buried in a table.

How do you get the accounts into the client's name?

Ideally before handover, not after. The simplest order:

1. Set up accounts in the client's name from the start. Ask the client to create the domain, email and Google accounts, then invite you as a user. This is what owner-held accounts means in practice.
2. Where you had to create an account yourself, transfer it. Most services have a way to change the owner. For a Business Profile, add the client as an owner, then transfer primary ownership to them. For Search Console, add them as an owner, then decide whether you stay on as a full user.
3. Check each one with the client watching. Ask them to log in to each account on their own device. A login that only works on your computer is not handed over.
4. Fill in the table last. Write down what is true after the transfers, not what you intend.

Keep a copy of the finished page with the client's details, and update it whenever something changes hands.

Where Volant fits

Volant is built on the same rule for your own agency: your phone numbers, domains, mailboxes and Stripe stay in your name, and so do their bills. It keeps the list of what each client owns next to their details and requests, so the "what you own" page is written from records you already keep rather than from memory. How ownership works in Volant sets out which accounts are yours and which stay with the people who pay for them.

Whatever your AI agency uses, write the page at every handover. It takes little time on the day and saves a bakery owner a very bad week years later.