Website handover template for agencies and freelancers
Eleven sections, the fields that belong in each one, and a plain-text skeleton you can paste into whatever tool you already use. Nothing here is behind a signup, and there is nothing to download.
The short answer
A website handover template has eleven sections: project overview, website and stack, domain and DNS, hosting and email, accounts and ownership, editing instructions, maintenance schedule, support and retainer, files and assets, emergency contacts, and handover confirmation. Each section records facts and named people. None of them records a password.
That order is deliberate. It runs from what the thing is, through where it lives and who owns it, to what happens next — which is roughly the order a non-technical reader asks the questions in. The skeleton below is the whole template; the section after it explains what belongs on each line.
The template, in full
Copy this into a document, a wiki page, a Markdown file, or the tool you already bill through. Replace the bracketed prompts. Delete any section that genuinely does not apply to the project rather than leaving it empty — an empty heading reads to a client as something you forgot.
WEBSITE OWNER'S MANUAL — [Client name]
Prepared by [Agency] · Handover date [date] · Last updated [date]
1. PROJECT OVERVIEW
What the site is for [one or two sentences]
Launched [date]
Primary contact, client [name, role, email]
Primary contact, agency [name, role, email]
Languages / regions [if relevant]
2. WEBSITE AND STACK
Live address [https://…]
Platform [WordPress / Webflow / Shopify / custom]
Theme or framework [name, and whose licence]
Key plugins or apps [the handful that matter]
Custom work [child theme, custom code, build step]
Where the code lives [repository / server only]
Staging site [address, or "none"]
3. DOMAIN AND DNS
Domain(s) [example.com, plus redirects]
Registrar [provider]
Registered owner [organisation on the registration]
Who can sign in there [name / organisation]
Expiry [date] Auto-renew [on / off]
DNS managed at [provider — often not the registrar]
Nameservers [ns1…, ns2…]
Changed at handover [nameservers / records only / nothing]
Mail hosted elsewhere [yes / no]
4. HOSTING AND EMAIL
Host [provider] Plan [tier]
Account holder [client / agency / third party]
Renewal [date] Auto-renew [on / off]
SSL certificate [issuer, renews automatically? ]
Email provider [Google Workspace / Microsoft 365 / host]
Email support handled by [who the client calls]
5. ACCOUNTS AND OWNERSHIP
For each service — one row, no credentials:
Service | What it controls | Owner | Admin contact | Access managed at
e.g. Analytics | Traffic reporting | [Client Ltd] | [ops@client.com] | [account name]
6. EDITING INSTRUCTIONS
How to [the change they will actually make] [3–6 short steps]
How to [second change] [3–6 short steps]
How to [third change] [3–6 short steps]
Please don't edit [short, specific list]
7. MAINTENANCE SCHEDULE
Task | How often | Who does it
e.g. Full backup | Weekly | [Agency]
Plugin updates | Monthly | [Agency]
Check enquiries arrive | Monthly | [Client Ltd]
Renew domain | Annually | [Client Ltd]
8. SUPPORT AND RETAINER
What's included [plain sentences]
What's billed separately [plain sentences]
Response times [and the hours they apply to]
Warranty / bug period [start and end date]
How to raise a request [one channel]
9. FILES AND ASSETS
Asset | Where it lives | Owner
e.g. Logo (SVG, PNG) | [location] | [Client Ltd]
Brand guidelines | [location] | [Client Ltd]
Licensed images | [location] | [licence terms]
10. EMERGENCY CONTACTS
Site is down [who, how, expected response]
Domain or DNS problem [who]
Email problem [who — usually not the agency]
Out of hours [what is and isn't covered]
11. HANDOVER CONFIRMATION
Handover completed on [date]
Gone through with [name, role]
Items transferred [domain / hosting / analytics / …]
Credentials transferred [separately, via [channel], on [date]]
Notes [anything outstanding]
Nothing above is a password field. Section 5 records that an account exists and who owns it. Section 11 records that credentials moved, and how — not what they were. That distinction is the whole security design of a handover document, and how to hand over website passwords covers what it means in practice.
What each section records
The skeleton is deliberately terse. Here is what each section is for, and the mistake it exists to prevent.
1 Project overview
Two or three sentences on what the site is for, the launch date, and a named contact on each side. It is the only section a reader will read in full, and it sets the tone: this is a document about a business, not a technical inventory.
- Name people, not roles. “Contact your account manager” is useless in eighteen months.
- Put a last-updated date at the top. It tells the reader how much to trust what follows.
2 Website and stack
Enough for a developer who has never seen the site to orient themselves in ten minutes. Platform, theme or framework, the plugins that actually matter, and anything custom that a careless update would destroy.
- Say whose licence it is. A commercial theme bought on the agency account stops updating the day the relationship ends.
- Name the custom work explicitly. A child theme nobody mentioned is a child theme somebody overwrites.
3 Domain and DNS
The most valuable page in the document on the worst day. Registrar, registered owner, who can sign in, expiry, where DNS is actually managed, and what you changed at handover.
- Registered owner and account access are two fields. They are frequently different people.
- DNS is often not managed at the registrar. Record where it really is, or the next person edits records that nothing is reading.
- Say whether email is hosted elsewhere. It changes what a nameserver move does. The domain and DNS guide covers this in detail.
4 Hosting and email
Provider, plan, renewal date, and whose account it sits in. Then the email provider, which is nearly always separate and nearly always assumed to be the same.
- Say who the client calls about email. For most agencies the honest answer is “not us”, and that is far better learned now.
- Record whether hosting is resold through your account. Reselling is normal; discovering it during a dispute is not.
5 Accounts and ownership
One row per service, with what it controls, the owner, an administrative contact address, and where access is managed. Payment gateway, CRM, email marketing, analytics, Search Console, booking system, CDN, font licence.
- Include the accounts you created on the client’s behalf. Analytics and Search Console are the two that most often stay in an agency account forever.
- Record who pays. A recurring cost nobody has claimed is a service that will be cancelled by accident.
6 Editing instructions
Not a CMS manual. Three to six short procedures for the changes this particular client will actually make — update the phone number, add a team member, publish a post, change opening hours — plus a short list of what they should leave alone.
- Write it for their site. Name their menu items and their page titles, not generic ones.
- Keep “please don’t edit” short. A long list reads as a warning to touch nothing at all.
7 Maintenance schedule
Recurring work grouped by how often it happens, with a named party against every row. This is the section that turns a description of a website into an agreement about who keeps it working.
- Write the client’s company name, not the word “client”. A client reading their own name beside six tasks understands what they have taken on. A client reading “client” reads a template.
- Include the annual rows. Renew the domain, renew hosting, renew licences, review who still has access.
8 Support and retainer
What the ongoing arrangement covers, what is billed separately, response times and the hours they apply to, and the one channel a request should arrive through.
- Only publish response times you intend to honour. An aspirational SLA in a client-facing document is a complaint waiting to be quoted back at you.
- State the warranty period’s end date. “30 days after launch” requires arithmetic; a date does not.
9 Files and assets
Logo files, brand guidelines, source design files, licensed photography and the terms it was licensed under. Record where each lives and who owns it.
- Record the location, not always a link. Share links from Dropbox, Drive and Figma often carry an access token, which makes the link itself a credential.
- Note stock licence limits. “Web use only” matters the first time the client prints a brochure.
10 Emergency contacts
Who to contact when the site is down, when the domain or DNS misbehaves, and when email stops — with an honest note about what is and is not covered out of hours.
- Separate urgent from ordinary. “The site is down” and “the logo looks small on my phone” should not arrive through the same channel.
11 Handover confirmation
A short dated record: what was handed over, on what date, and who you went through it with. Keep it a record rather than dressing it up as a signature — a page with no login behind it cannot tell you who typed the name.
- “Transferred” means accepted, not invited. Verify the client actually accepted the ownership transfer before you tick it.
- Note anything still outstanding. An honest open item is worth more than a document that pretends there are none.
Instead of maintaining this template by hand
Handover turns the same eleven sections into a branded live manual for each client — one URL, a printable PDF, your logo and colours, English or Spanish. Save your version once as a template and every new manual starts from it.
Create your first manual freeThe one rule: no passwords, API keys or recovery codes
A handover document records which accounts exist, what each one controls, who owns it and where access is managed. The credentials themselves are transferred separately, through a password manager or another channel with an expiry, and the document notes only that the transfer happened.
The reasoning is about where the document ends up rather than how carefully you write it. A handover document is designed to be forwarded — to a bookkeeper, to a new marketing hire, to whoever inherits the site in three years. It gets printed. It sits in an email thread for the life of the business. Every one of those copies is a copy you cannot revoke, and every credential inside one is a credential you no longer control.
There is also a version that survives the rule and catches people out. A share link from Dropbox, Google Drive or Figma frequently carries an access token in the URL, which means the link is the secret. A document with no passwords in it can still hand a stranger your client’s brand assets. If a file should not be opened by anyone holding the URL, write down where it lives rather than linking it.
The sentence worth being able to say: nothing in this document can be used to sign in as you. If it is true, a leaked handover document is embarrassing. If it is false, it is a breach of your client’s business.
Which tool to build it in
Any tool that produces something the client can open without an account will do. The choice matters less than whether the document can be corrected cheaply, because a template that is expensive to update becomes a document nobody updates.
- A document or slide file. Free, yours forever, and frozen the moment you export it. Workable if you hand over two sites a year and will genuinely re-export.
- A shared doc or wiki page. Easy to correct, hard to brand, and it usually looks like an internal note rather than a deliverable. Watch the sharing settings: “anyone with the link” is how these end up indexed.
- A page inside a client portal. Current while the relationship lasts, but the manual is a tenant — offboard the client and the document goes with them.
- A hosted manual. One page per client at its own address, in your branding, printable whenever the client wants a permanent copy.
Whatever you choose, tell the client to save a PDF at handover and again when something significant changes. That is the copy that survives a cancelled subscription, on either side.
Keeping it true after the first change
Put a visible last-updated date on the document and give it one address that never changes, so a correction is a two-minute edit rather than a new file to produce, email and explain. A document nobody can cheaply correct will be wrong within a year.
The failure is never a decision. Nobody chooses to let a handover document rot. It rots because updating it means finding the source file, exporting it, writing a covering email, and hoping the client files the new copy over the old one — twenty minutes of friction against a two-line change. So the change does not get made, the document quietly becomes wrong, and the client stops trusting the parts that are still right.
Three changes are worth a diary note rather than good intentions: the domain or hosting renewal date, a change of the person named as a contact on either side, and any move of DNS, hosting or email. Those three account for most of the drift.
Hand over your next website properly
One form in. A client-ready manual out — live link, printable PDF, your branding, English or Spanish.
Start free — 1 active manual, no card
Drafts are unlimited on every plan. Archived manuals stay online and don’t count.