A good website handover document names who owns every account, lists what software runs the site and where, explains how updates and restores work, and says who to contact when something breaks. It should be short enough that a new person can use it on their first day.
Agencies often hand over a site with a login and a smile. Six months later the client changes provider and nobody knows where the domain is registered, which plugins are licensed, or how the site was built. This post gives you an outline you can reuse.
The six sections that matter
| Section | What to record | Why it matters |
|---|---|---|
| Ownership | Registrar, DNS host, web host, code repository, email provider, and which legal entity owns each | A client who cannot prove ownership cannot move or recover the site |
| Inventory | CMS and version, theme, plugins, build tools, PHP version, database type | Anyone can check the list against advisories later |
| Access | Named accounts and roles, not shared passwords | Removing one person must not break everyone else |
| Operations | How updates are applied, where staging is, how deploys happen | Stops "it worked on my machine" arguments |
| Recovery | What is backed up, how often, where copies live, who tested a restore and when | A backup nobody has restored is a guess |
| Contacts | Who to call for hosting, for the site, and for security issues | Saves hours during an incident |
Record the software, not just the site
The WordPress hardening guide separates the host's job from the site owner's: hosts are often responsible for the infrastructure, but not for the application you choose to install. Your handover should make that line visible. Write down the CMS version, every active plugin and theme, and anything installed by a package manager.
If the project uses Composer or npm, add the lockfiles to the list and say where they live. Composer's own documentation recommends committing the lock file so that your CI server, production machines and teammates all run the same dependency versions. The handover should say that this is the case, and where the repository is.
Write down the update routine
Say plainly who applies updates, how often, and what happens first. A sentence like this is enough: "Plugin and theme updates are applied on staging first, then to production within seven days of release; critical advisories within two days." Pick numbers you can keep.
Also record any auto-update settings. WordPress core applies minor updates automatically by default, while plugin and theme auto-updates are off until an administrator turns them on, according to the WordPress core team's note on the 5.5 release. Whichever way you chose, put it in the document so the next person does not assume.
Cover recovery honestly
The WordPress handbook says a typical site needs both files and database in a backup set, because the database lives outside the WordPress directory. State which of the two you back up, where the copies are kept, and the date of the last restore test. If you have never tested one, write that down and schedule it. An honest gap is better than a false assurance.
Keep secrets out of the document
The handover itself should not contain passwords. Point to the password manager vault or the account owner, and list roles. If credentials must change hands, move ownership of the vault item, then rotate the password afterwards.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory lists packages and versions; that is the kind of list the Inventory section should hold.
If a project keeps its manifests in a repository, Safeguard can generate an SBOM and scan dependencies, and the free scan is a quick way to produce a first inventory for the handover.
Quick check
How long should a handover document be?
One to three pages. If a new maintainer cannot find an owner, a login route and a restore path in five minutes, it is too long or too vague.
Should the client or the agency hold the domain?
The client should be the registered owner, with the agency added as a delegated user where the registrar allows it. That keeps the client able to move providers.
Sources
- Hardening WordPress, WordPress Advanced Administration Handbook
- Backing up your WordPress site
- Controlling plugin and theme auto-updates UI in WordPress 5.5
- Composer basic usage
Last reviewed: 19 October 2026.
