A website handoff checklist covers five things: full access and ownership of every account, a written document explaining what was built, proof the site is backed up and secure, a short training session, and a written support window. Skip one and the first thing that breaks is your unpaid problem.
Launch day feels like the finish line, and that’s the mistake. The site goes live, everyone’s happy, and three weeks later the client can’t find their WordPress login or figure out who owns the domain. None of that is a technical problem. It’s a handoff problem, and it’s avoidable.
I’ve done WordPress work for over 15 years, and a fair share of it has been cleaning up after a launch someone else handed off badly. The pattern’s always the same: the build was solid, the handoff was an afterthought. If your team runs a structured website project workflow, this is the part right after it: what to give a client when handing off a WordPress site.
What access does a client actually need when a website goes live?
Every account tied to the site needs a named owner, and unless you’ve agreed otherwise, that owner should be the client, not you. Access isn’t a courtesy you extend after the invoice clears, it’s what makes the site actually theirs. Here’s every account that needs to change hands, and why leaving it in the agency’s name causes problems later.
| Item | Who owns it after handoff | Why it matters |
|---|---|---|
| Domain registrar | Client | Controls where the site points, including away from you if the relationship ends |
| Hosting account | Client (agency granted admin) | An agency-owned host gives one side too much control once the project’s over |
| WordPress admin | Client, plus a scoped agency login | A locked-out client can’t approve changes or bring in another vendor |
| DNS records | Client, or documented if elsewhere | Undocumented changes are a common cause of a “the site’s down” call months later |
| Email/SMTP provider | Client’s own account and API key | A key left in the agency’s name can quietly stop forms from delivering the day it’s revoked |
| Analytics and Search Console | Client’s own Google account | Historical data stays with the client, not an agency account they’ll lose access to |
| Third-party integrations | Client’s own accounts and keys | Connections tied to the agency break when that account closes |
| Premium plugin and theme licenses | Client, registered to their own email | An unrenewed license stops receiving security updates, and outdated software is still the most common opening: 39.1% of CMS installations studied were outdated at the point of infection, across all CMS platforms, not WordPress specifically |
Source: Sucuri, 2023 Hacked Website Report.
What belongs in the website handoff document?
Access gets a client into the site. A handoff document is what lets them run it without calling you every time something looks unfamiliar, and it needs to exist in writing, not on a call nobody recorded. It covers:
- What was built. A short summary of the theme or page builder, the templates, and any custom functionality that isn’t obvious from clicking around.
- Where content actually lives. Which pages sit in the page builder versus a static template, and where custom fields show up in the editor.
- How to edit the common things. Swapping an image, updating a phone number, adding a post, editing a menu. Write it down once, or field the request for free forever.
- What not to touch. Custom code, a template tied to a plugin setting, text that’s actually a shortcode, flagged so a two-minute “fix” doesn’t become a support ticket.
- A plugin inventory. Every active plugin, what it does, and why it’s there. If nobody knows why one’s installed, it eventually gets deleted and something breaks for a reason no one can trace.
What technical state should the site be in before you hand it over?
A handoff document describes the site. This is proof it’s actually in that condition. Confirm before you close the project:
- A current backup, with a named location. A specific answer to “where’s this week’s backup, and who can pull it.” Without one, there’s an assumption, not a backup.
- Everything updated. Core, theme, and every plugin on the latest stable version, staging-tested first. Outdated software starts a client a step behind.
- A clean security scan. Run one, keep the result: confidence, not assumption.
- Redirects verified, not assumed. Every old URL that’s supposed to forward somewhere actually does, checked by clicking through.
- Every form tested end to end. Confirm the notification lands, not just that the form shows success. A silent failure is invisible until a client tells you they lost a lead.
- A performance baseline recorded. A load time and Core Web Vitals snapshot, taken at launch, so “the site feels slower” later is a comparison, not an opinion.
How do you train a client who’s never logged into their own site?
A document answers questions a client hasn’t thought to ask yet. Training answers the ones they’ll have in the first week. It doesn’t need to be a course, just a screen recording, fifteen minutes or less, covering logging in, editing a page, publishing a post, and finding the handoff document.
Record it once and it becomes a standing asset, not a call you repeat for every client. Set up editor-level logins for whoever will actually touch the site day to day, separate from the Administrator account, so the person updating blog posts isn’t working with the same permissions as whoever manages plugins and users. Walk through the handoff document live at least once, too.
What happens after handoff: the support window and the next decision
Launch isn’t the end of the relationship, even on a one-off project, and pretending otherwise is how free work sneaks in. Define, in writing, before handoff:
- The support window. A number of free days for bug fixes tied to the original build, with a date where that ends. Open-ended “let me know” is an invitation, not a support window.
- How to request a change. One channel, a ticket system, a form, or an email you actually check, not “just text me,” which stops scaling past one client.
- What happens once the window closes. Does the client go without care, or does the relationship continue on a plan. Our breakdown of WordPress maintenance plans covers what belongs in one, and if you’d rather not staff it yourself, a white-label care plan is the natural next step.
Put the decision in the handoff document. A support window that only exists in someone’s memory isn’t one by the time it gets tested, which is the real difference between a clean client website handoff and one that quietly turns into unpaid support.
Which handoff mistakes turn into unpaid work later?
Most handoff problems that cost agencies money later trace back to a handful of repeat offenders:
- Admin credentials that only exist in someone’s inbox. A login emailed once, months ago, nobody can find when it’s needed. Undocumented access doesn’t really exist.
- Licenses registered to the agency’s personal account. Convenient at setup, expensive later. Once the agency’s out of the picture, the client re-buys something already paid for, and it’s your name they remember.
- No backup stored off the server. A backup plugin on the same server it’s backing up protects against nothing if that server fails or gets compromised.
- No written support window. Without one, every post-launch bug becomes a negotiation instead of a known answer.
Each one is a five-minute fix at handoff and an hours-long argument later.
- A real handoff hands over full ownership of every account, domain, hosting, WordPress admin, and licenses, instead of a login the agency still controls.
- A written handoff document beats a verbal walkthrough: what was built, how to edit it, what not to touch, and why each plugin is there.
- Backups, updates, a clean security scan, and tested forms should be verified, not assumed, before a project is closed.
- A written support window, not an open-ended “let me know,” keeps the first post-launch bug from turning into free work.
The website handoff checklist, ready to copy
Paste this into your handoff process and check it against the site before you close the project.
WEBSITE HANDOFF CHECKLIST Project: [Project or site name] Handoff date: [Date] 1. ACCESS AND OWNERSHIP [ ] Domain registrar in client's name [ ] Hosting account in client's name, agency has admin [ ] WordPress Administrator account for the client [ ] DNS records documented or access confirmed [ ] Email/SMTP under the client's own account [ ] Analytics and Search Console under client's Google account [ ] Integrations connected with the client's own keys [ ] Licenses registered to the client's email 2. HANDOFF DOCUMENT [ ] Summary of what was built [ ] Where content lives, by page [ ] How-to steps for common edits [ ] What not to touch, and why [ ] Plugin inventory with a reason for each 3. TECHNICAL STATE [ ] Current backup confirmed, location documented [ ] Core, theme, plugins updated and staging-tested [ ] Security scan run, result saved [ ] Redirects verified by clicking through [ ] Every form submitted, delivery confirmed [ ] Performance / Core Web Vitals baseline recorded 4. TRAINING [ ] Recorded walkthrough delivered [ ] Editor-level logins set up for day-to-day users [ ] Handoff document walked through live once 5. WHAT HAPPENS NEXT [ ] Support window defined in writing, with an end date [ ] Change request process and contact point documented [ ] Ongoing care decision made: none, in-house, or a care plan
If you’d rather the post-launch care run under your brand without you staffing it, send us the details and we’ll come back with a fixed quote, usually within two business hours.
If the handoff audit turns up signs of a compromise, here is how to clean up a hacked WordPress site before you take on responsibility for it.
Frequently asked questions
What’s the difference between a website handoff checklist and a handoff document?
A checklist confirms tasks before a project closes. A handoff document, sometimes called a website handover document, is the written explanation the client keeps: what was built, where things live, what not to touch.
Who should own the domain and hosting after a website project ends?
The client, in nearly every case. An agency’s name on a client’s domain or hosting account is a common source of disputes if the relationship ends. Grant your team admin access instead.
What should I include in a website handover document?
What was built, where content lives, how to make common edits, what not to touch, and a plugin inventory explaining why each one is installed. Skip the jargon and write it for the person who’ll be logging in.
How long should a post-launch support window last?
There’s no universal number, but it needs a start and end date, written down, covering bug fixes tied to the original build. Open-ended “reach out if anything comes up” is an unpriced obligation, not a support window.
Should a client get full admin access to their WordPress site?
Yes, one Administrator account in their own name. Withholding full access to protect the relationship usually backfires: it reads as control, not partnership.
Get a free consultation and a fixed quote, usually within one business day, delivered under your agency's brand.