A PDF or a live page? How to hand a website over to a client

What is a website handover document?

A website handover document is the record an agency gives a client when a build finishes: what the site is made of, where the domain and hosting live, who owns each account, how to make everyday edits, and who to call when something breaks. It is also called a website owner’s manual or a client handoff document.

Without one, everything learned during the build stays with the agency. The client cannot renew their own domain, cannot tell a new developer what the site runs on, and cannot answer “who has access to this?” The document exists so the answers survive staff changes on both sides.

• Who writes it: the agency, at handover.
• Who reads it: a non-technical business owner, usually months later, usually in a hurry.
• What decides its value: whether it is still true when they open it.

Should a handover document be a PDF or a live web page?

A PDF is correct the day it is sent and wrong from the first change onwards. A live page can be corrected in place, so the client always opens the current version. The practical answer for most agencies is a live page that also prints, so the client has both.

The difference is not presentation, it is what happens on the day something changes. Hosting moves. A plugin is replaced. The person who owned the Google account leaves. With a PDF, the agency must remember to produce a new one, email it, and hope the client opens the new attachment rather than the old one already sitting in their inbox. In practice nobody does this, so the document quietly becomes wrong and the client stops trusting it.

The last row is the honest one, and it is the reason a live page should always be printable. A hosted document depends on somebody paying for the hosting. Tell the client to save a PDF at handover and again when something significant changes, and they keep the belt as well as the braces.

Should a handover document contain the client’s passwords?

No. A handover document should record which accounts exist and who owns each one, never the credentials themselves. This is true whichever format you use, and it is the single most common mistake in handover templates.

The reasoning is not squeamishness, it is arithmetic about where the document ends up. A handover document gets forwarded to a bookkeeper, printed for a folder, attached to an email that sits in an inbox for six years, and inherited by whoever takes the job next. Every one of those is a copy you cannot revoke. Credentials inside it are credentials you have permanently lost control of.

What to record instead, for each service:

• The service — registrar, host, CMS, analytics, booking system.
• The account owner, by name and organisation.
• An administrative contact address for access requests.

That is the half that stays true. Passwords rotate; ownership does not. A client who needs access asks the named owner, which is also the conversation that should happen anyway.

One trap that survives the rule: a share link. Dropbox, Google Drive and Figma links frequently carry an access token, which means the link is the secret. A document with no passwords in it can still hand over a file to anyone holding the URL. If a file should not be opened by a stranger, record where it lives rather than linking it.

What should a website handover document contain?

A complete handover document covers eight things: what the site is built on, the domain, hosting and email, the accounts and who owns them, how to make everyday edits, what the ongoing arrangement covers, the recurring maintenance and who does each job, and who to contact in an emergency.

1. Site and stack — platform, theme or framework, and the plugins that matter. Enough for a new developer to orient themselves.
2. Domain and DNS — registrar, expiry date, the legal owner of the registration, nameservers. The most valuable page in the document on the worst day.
3. Hosting and email — provider, plan, renewal date, and the mail provider, which is usually separate and usually assumed to be the same.
4. Accounts and ownership — every connected service with a named owner. No credentials.
5. How to edit — short instructions for the three or four changes this particular client will actually make.
6. What is covered — what the retainer includes, and what is billed separately.
7. Maintenance schedule — recurring work by cadence, each task assigned to the agency or the client.
8. Emergency contacts — who to call when the site is down, and when to expect an answer.

How do you keep a handover document up to date?

Put a visible last-updated date on it and give it one address that never changes, so correcting it is a two-minute edit rather than a new file to produce and re-send. A document nobody can cheaply correct is a document that will be wrong within a year.

The failure is never a decision. Nobody decides to let a handover document rot. It rots because updating it means opening the source file, finding it, exporting it, writing an email explaining what changed, and hoping the client files the new one over the old one. That is twenty minutes of friction against a two-line change, so it does not happen.

A date the client can see also does something a PDF cannot: it tells them how much to trust what they are reading. “Last updated three weeks ago” and “last updated in 2023” are different documents even when the words are identical.

Why does the document need to say who owns the domain?

Because a lapsed domain takes the website and the email down together, and the only person who can renew it is whoever the registration actually belongs to. Most clients do not know which that is until the day it matters.

Domain ownership is also the most common quiet dispute in this industry. An agency registers the domain during the build, in good faith, in their own account. Years later the relationship ends and the client discovers their business address belongs to someone else. Writing the owner down at handover, in front of the client, prevents the entire argument — and if the answer is uncomfortable, that is a conversation worth having on a good day rather than a bad one.

Should a website handover be signed off?

Sign it off, but keep it honest about what it is. A short dated record — what was covered, and who it was gone through with — is worth having, because six months later the argument is never about the document. It is about whether the domain account was ever actually handed across.

What that record should not pretend to be is a signature. Anyone can type a name into a web form, and a page with no login behind it cannot tell you who filled it in. Presenting an unverified click as proof is worse than having nothing, because it invites the agency to rely on it. If a countersigned document is genuinely needed, that is what signature tools are for — and the handover document can be linked from inside one.

The useful middle ground is a record the agency writes: handover completed on this date, covering these items, confirmed with this person. It closes the project cleanly, it tells whoever inherits the site that the transfer was done deliberately, and it makes no claim it cannot support.

What does a maintenance schedule add?

It turns a description of the website into an agreement about who keeps it working. A list of recurring tasks with a name against each one is the difference between a document the client files and a document that justifies a monthly fee.

A useful schedule is grouped by how often the work happens — daily, weekly, monthly, once a year — and every row says who does it. Backups and updates are usually the agency. Checking enquiries actually arrive, keeping prices and opening hours current, and reviewing who still has access are usually the client, and they are the ones that quietly stop happening.

Naming the responsible party rather than writing “agency” or “client” matters more than it sounds. A client reading their own company name beside six tasks understands what they have taken on. A client reading the word “client” reads a template.

Can a live handover manual still be printed?

Yes, and it should be. A live page that prints properly gives the client a current version online and a permanent copy of their own, which is the combination that survives both a stale PDF and an agency that stops paying for hosting.

Printing well is not automatic. A page built for the screen prints with headings stranded at the foot of pages, tables that lose their header rows halfway through, links that read “click here” with the address invisible, and brand colours dropped by the browser’s ink-saving default. Those are all fixable, and worth fixing, because the printed copy is the version that outlives everything else.

Template, client portal, or hosted page?

A template is cheapest and goes stale. A client portal keeps documents current but the client loses access when the relationship ends. A hosted manual sits between them: current while the arrangement lasts, printable so the client keeps something permanent.

• A template — a document or slide file you fill in per client. Cheap, yours forever, and frozen the moment you export it. Fine for an agency handing over two sites a year who genuinely will re-export.
• A client portal — the document lives inside a subscription workspace alongside invoices and files. Current, but the manual is a tenant: when the portal subscription ends or the client is offboarded, so is their manual.
• A hosted manual — one page per client at its own address, in the agency’s branding, printable at any time. Current while it is hosted, and the printed copy is the client’s regardless.

What does a handover document cost to produce?

Written by hand, two to four hours per client, most of it re-typing the same explanations. From a structured form, ten to twenty minutes, because the facts change per client and the explanations do not.

That ratio is the whole argument for tooling here. The parts that differ between clients are facts: a registrar, a renewal date, a list of plugins, a named owner. The parts that take the time are the sentences around those facts explaining to a non-technical reader what a nameserver is and why a lapsed domain takes email down. Those sentences are the same for every client you will ever hand over to.

Handover’s pricing counts active manuals, not documents produced: free for 1 active manual, $19 a month for 3, $39 a month for 10, and $79 a month for unlimited. Drafts are unlimited on every plan, and an archived manual stays online for the client without counting against the limit.

Short answers

In short

• Use a live page for currency, and print it so the client keeps a permanent copy.
• Record accounts and their owners. Never credentials, in any format.
• Put a visible last-updated date on it.
• Name who does each piece of recurring maintenance.
• Write down who owns the domain before it matters.

Going further: the handover checklist is the working list to run through before a project closes, and the handover template is the document structure itself. All guides.

Make one free

One manual free, in your branding. No card.