Every web project ends with a moment where one person hands the keys to another. It might be you giving a finished site to a client. It might be a new developer inheriting a site that nobody has looked at since the last one left.
Done well, it takes an afternoon and nobody thinks about it again. Done badly, it gets remembered a year later, when the site breaks and three people each assume someone else owned the hosting account.
This WordPress website handover checklist covers both directions. The first half is for handing a site over. The second is for taking one on. Use the parts that fit.
Why a WordPress Website Handover Checklist Matters
A site is more than a theme and some pages. It is a domain, DNS records, a hosting account, email delivery, a dozen plugin licences, analytics, user accounts and a pile of settings that live in someone's head. Handover is where that pile either becomes written down or quietly vanishes.
The common failures are simple:
- The domain is registered in the developer's name, and the developer is unreachable.
- Nobody knows which plugins have paid licences, so updates stop working.
- Three former contractors still have administrator logins.
- There is a backup, but nobody has ever restored one.
- The client assumes you will fix anything that breaks, and you assumed the opposite.
All five are avoidable with a one-page list and a bit of honesty.
Handing a Site Over to a Client
You built it, launched it, and now it belongs to someone else. Work through these in order.
1. Put Ownership in the Client's Name
This is the most important line on the list. The client should be the registered owner of:
- The domain. The registrar account is in their name, with their billing email.
- DNS. They know where the records are managed, and that is not only on your personal account.
- Hosting. Either the hosting account is theirs, or the site is on your hosting under a written agreement that explains what happens if you part ways.
- Third-party services. Email sending, analytics, search console, forms and any CDN.
If you want to stay involved, ask to be added as a technical contact or a team member on their accounts. Do not hold the account on their behalf. Our article on WordPress care plans covers how to keep an ongoing relationship without owning the assets.
2. Sort Out Accounts and Roles
Go through the Users screen with the client and decide who needs what. Most staff need Editor or Author, not Administrator. The official WordPress roles and capabilities documentation lists what each role can do, and our guide to WordPress user roles puts it in plainer words.
Then check:
- Every administrator is a real person the client can name.
- Test accounts, staging accounts and shared logins are gone.
- Your own developer account is removed, or downgraded to the lowest role your support agreement needs.
- Two-factor sign-in is on for everyone who can change content or settings.
3. Transfer Licences and Subscriptions
List every paid plugin, theme and service, with the renewal date and who pays. Then move each licence to a client-owned account where the vendor allows it, or document clearly that you hold it and for how long.
An expired licence is a quiet hazard. The site works fine until the plugin stops receiving updates, and nobody notices until a vulnerability appears.
4. Prove the Backups Work
Nobody really knows a backup works until it has been restored once. Before handover:
- Take a fresh full backup of files and database.
- Restore it somewhere safe, such as a staging copy.
- Check the site loads, forms work and recent content is there.
- Tell the client where backups live and how to ask for a restore.
Our guide on how to back up a WordPress site explains what a good backup includes. With Stack Guard, backups are manual in Free, are verified before they count and restore with one click, staged and checked before anything live changes. After a restore you can keep it or roll back for 7 days. Scheduled backups and Google Drive storage are coming soon, so for now set a recurring reminder.
5. Record a Security Baseline
Write down what "healthy" looked like on handover day. That way, when something changes, everyone can see what.
- All plugins, themes and WordPress core are up to date.
- No abandoned plugins, and no unused plugins or themes left installed.
- Scan results are clean.
- A security score you can compare against later.
Stack Guard Free gives a score out of 100 built from 14 real checks, shown in the admin bar and on the WordPress dashboard. Save a screenshot or note the number in your handover document. The dashboard and security score page shows what it covers.
If you use Stack Guard on client sites, export the settings file as part of the handover package. It records the configuration you chose, and the export and import docs explain what is and is not included. Licence, API keys and the login address are never exported.
6. Check That Email Actually Arrives
Contact forms and password resets are the first things to quietly fail. Before you finish:
- Send a test message from every form and confirm the right person receives it.
- Use an authenticated sending service instead of the server's default mail, so messages are not marked as spam.
- Check that SPF and DKIM records are set up for the domain.
- Make sure the "from" address belongs to the client's domain.
7. Hand Over Analytics and Search Tools
Add the client as an owner on analytics and Google Search Console, not just a viewer. Confirm the tracking code is installed once, and that cookie or consent settings match what the client has agreed to.
8. Document the Site
A short document beats a long one nobody reads. Include:
- Login addresses and where the credentials are stored (never the passwords themselves in the document).
- Hosting, registrar and DNS details.
- List of plugins and what each is for.
- Anything custom: code snippets, scheduled tasks, redirects.
- How to update safely, and how to restore.
- Who to contact for what.
9. Train the Client
A 30 minute walkthrough prevents a hundred emails. Show them how to edit content, add a user, check form entries and where not to click. Record it as a video if you can, so new staff can watch it later.
10. Say What Is In and Out of Support
Put it in writing. Be specific about:
- What is covered: updates, backups, monitoring, small fixes.
- What is not: new features, content changes, hacked-site cleanup, third-party plugin bugs.
- How fast you respond, and how clients reach you.
- When support ends, and what the client gets if it does.
Vague promises cause more relationship damage than any technical fault.
Key takeaway: A handover is complete when the client can log in, restore a backup, pay the renewals and reach someone for help, without you.
Taking Over a Site From Another Developer
Now the other direction. You have been handed a site, maybe by a client, maybe by an agency that is winding down. The golden rule: treat it as untrusted until you have checked it.
Get Access in Writing
Ask the client, not the previous developer, to give you access. Request:
- Registrar and DNS access, or at least the ability to edit records.
- Hosting control panel and SFTP or SSH.
- WordPress administrator access.
- Any plugin and theme licence accounts.
If the old developer will not cooperate, the client can usually recover registrar and hosting accounts through their own verified identity. It is slower, but it is the right route.
Take a Backup Before You Touch Anything
Back up files and database exactly as they are. This is your safety net and your evidence if something goes wrong later. Do it before updates, before cleanup and before changing a single setting.
Audit Every Account
Open the Users screen and list every administrator. Remove or downgrade anything unexplained. Reset passwords for the accounts that stay, and sign out everyone else. Rotating the WordPress security keys is a quick way to end every existing session (our guide to WordPress salts explains how). A user list is also a good moment to look for the signs we describe in 12 signs your WordPress site has been hacked, because a site that changes hands is a perfect time for old problems to surface.
Stack Guard's activity log helps from the day you install it: it records sign-ins, failed attempts, lockouts, user and role changes, password resets and settings changes, with who and from where. Free keeps core events for 7 days, and Pro keeps 90 days with the full catalogue. It cannot show what happened before you installed it, but it makes everything after that transparent.
Scan and Inventory
- Run a malware scan and compare core files with the official copies.
- List every plugin and theme. Mark which are active, which are unused and which are abandoned.
- Delete what is unused. Replace what is abandoned.
- Check the PHP version and the hosting plan against what the site needs.
- Note anything custom: child themes, must-use plugins, custom code in
functions.php.
Stack Guard's malware scanning does the core file check and signature scan in Free. It also gives you a security score right away, so you have a first baseline before you change anything.
Test the Restore
Same as the other direction: do not trust a backup you have not restored. If the previous developer left backups, restore one on staging and see whether it matches the live site.
Set the Expectations
Agree in writing what you are taking on. Many new relationships start with a surprise bill because the site had problems nobody mentioned. A short audit report, with findings and a quote for fixing them, protects both sides.
Security Baseline Items for Either Direction
Whichever way the site is moving, this part of the WordPress website handover checklist should be true by the end.
| Item | Done when |
|---|---|
| Updates | Core, plugins and themes are current |
| Accounts | Only named people have administrator access |
| Two-factor | On for everyone who can change content or settings |
| Backups | A recent verified backup exists and was restored once |
| Sign-in protection | Brute force lockouts and rate limits are on |
| Forms and password resets reach a real inbox | |
| Monitoring | Someone gets an alert if the site goes down |
For a longer list of controls, see the WordPress hardening checklist and the agency security guide.
Showing the Work: Badges and Branding
Some agencies like clients to see that the site is looked after. Stack Guard Free includes an optional "This site is protected by Stack Guard" badge you can place as a footer strip, a floating badge or with a shortcode. Pro lets you change the wording before the name and show it without a link. It is off by default, because it also tells visitors which plugin you run. Decide with the client whether they want it.
On Agency plans, white label puts your plugin name, company name, website and logo on every email Stack Guard sends, so alerts come from the agency the client knows. A branded sign-in page and client-ready security reports are coming soon. The for agencies page covers the full picture.
A Printable WordPress Website Handover Checklist
Copy this into your own template and tick it off.
- Domain, DNS and hosting in the client's name.
- Administrator accounts reviewed; developer access removed or reduced.
- Two-factor on for editors and administrators.
- Licences listed, transferred and renewal dates diarised.
- Fresh backup taken and restore tested.
- Security baseline recorded (updates, scan, score).
- Form and password reset email tested.
- Analytics and Search Console ownership transferred.
- Documentation delivered.
- Training session done.
- Support scope written down and agreed.
- Settings file exported and stored with the project.
If you manage many sites, this list becomes a routine. Our guide to how to manage multiple WordPress sites shows how to fold it into an inventory and a weekly rhythm.
Pro tip: Do the handover review on a call with the client, not by email. Questions like "who else has the password?" get honest answers when someone is looking at the screen.
A good handover is boring on purpose. When nothing dramatic happens for the next three years, the checklist did its job.