A WordPress project is not finished when the homepage looks right. It is finished when the client can safely own the website, understand what controls the important functions, and recover if something breaks.
That is the difference between a design handoff and an operational handoff.
A professional handoff should answer simple questions without forcing the client to reverse-engineer the site later: Who owns the domain? Where are backups stored? Which plugin controls SEO metadata? Who receives form submissions? What happens if the checkout webhook fails? Which user accounts should remain? What can the client safely edit?
Automattic’s own site-audit checklist emphasizes hosting, SSL, backups, staging and environment review when taking over a WordPress site. That same discipline belongs at the other end of a project too. Before the site changes hands, verify the technical foundation and document the ownership model.
Start with an operational inventory
Do not begin the handoff with a tutorial video. Begin with a map of the system.
Record:
- domain registrar and DNS provider;
- hosting provider and plan;
- WordPress administrator accounts;
- active theme and child theme;
- active plugins and what each important plugin owns;
- CDN and cache layer;
- backup system and storage destination;
- transactional email provider;
- analytics and Search Console ownership;
- form, CRM, payment and automation integrations;
- license ownership for premium themes and plugins.
This is not busywork. It prevents the common post-handoff situation where a client discovers six months later that an essential license belonged to a freelancer’s personal account or that the only backup system stopped when an agency subscription ended.
Verify access before you remove your own access
Agencies often rush to clean up user accounts at the end of a project. The cleanup is important, but the order matters.
Before removing agency or temporary users:
- confirm the client has at least one working administrator account;
- confirm the recovery email belongs to the client;
- test login from a private browser session;
- confirm hosting and registrar access separately from WordPress access;
- review two-factor authentication and recovery methods;
- remove accounts that are no longer required.
The principle is least privilege: people should have the access they need and no more. Our WordPress user roles and least-privilege guide explains how to assign editing and administrative permissions without giving every user full control.
Run a final health audit before handoff
A handoff is the wrong moment to discover that cron is failing, the memory limit is unusually low, or a plugin conflict has been quietly present since staging.
Run a final diagnostic pass and save the result with the project records. At minimum, review:
- WordPress and PHP versions;
- pending core, theme and plugin updates;
- debug exposure;
- REST and loopback health;
- scheduled tasks;
- cache layers;
- inactive plugins and themes;
- internal broken URLs and redirects;
- obvious plugin responsibility overlap.
TopNotch Site Health Pro can provide a repeatable local audit for this stage, covering compatibility, maintenance, performance, content structure and internal URL checks. The purpose is not to produce a decorative score for the handoff PDF. It is to make unresolved risks visible before responsibility changes.
Confirm the backup belongs to the client
A backup is part of operational ownership.
Verify the client knows:
- which system creates backups;
- how often backups run;
- how many copies are retained;
- whether a copy exists outside the production server;
- how a restore is started;
- who is responsible for restoring the site in an emergency.
If your agency backup service will end after handoff, replace it before the project closes. Do not leave the client with a recovery gap simply because the site was healthy on launch day.
For a deeper recovery framework, see WordPress Backup and Restore Planning: What a Real Recovery Plan Includes.
Test every conversion path, not just the front-end design
A site can look perfect and still fail commercially.
Before handoff, test the journeys that create value:
- contact form submission;
- quote or audit request;
- newsletter subscription;
- booking request;
- product purchase;
- payment confirmation;
- license or download delivery;
- CRM creation;
- transactional email.
Do not stop when the browser shows “Thank you.” Verify the downstream result. If a form should send an email, check the inbox. If it should create a CRM lead, confirm the record. If a purchase should trigger a license, verify the entitlement.
If form messages are unreliable, use our WordPress form email deliverability checklist before the project changes hands.
Document which component owns each major function
This is one of the most valuable handoff notes you can give a client.
Create a short responsibility table:
- SEO metadata: plugin or theme responsible;
- Page cache: host, server or plugin;
- Object cache: Redis/Memcached/plugin if present;
- Image optimization: service or plugin;
- Redirects: plugin, server config or custom code;
- Email delivery: SMTP/API provider;
- Forms: form plugin and destination;
- Analytics: tag owner and consent system;
- Payments: gateway and webhook owner;
- Updates: automatic, managed, or manual.
This prevents future plugin stacking. If the client later sees a speed warning, they can see immediately that server caching already exists instead of installing another page-cache plugin.
Check the SEO handoff separately
A WordPress handoff should include search ownership, not just WordPress ownership.
Confirm:
- Search Console access belongs to the client;
- analytics ownership is correct;
- XML sitemaps are available;
- the live site is indexable;
- canonical tags are present on representative pages;
- robots rules are intentional;
- staging is blocked from indexing;
- redirects from old URLs are documented;
- important pages have internal links;
- no temporary launch settings remain active.
Google recommends normal crawlable HTML links and descriptive anchor text, and says important pages should have links from other pages on the site. A handoff is a good time to check that the final navigation and content structure still exposes the pages the business cares about.
Test editing permissions from the client’s point of view
The developer account is a poor test of the editorial experience because administrators can do almost everything.
Log in with the same role the client’s editor will use and test ordinary tasks:
- edit a service page;
- publish or update a post;
- replace an image;
- edit menu content if that is part of their role;
- update SEO fields;
- use reusable blocks or patterns;
- preview mobile and desktop.
If the client can accidentally destroy a template while performing a routine content edit, the editing model still needs work.
Record custom code and non-obvious behavior
Custom code is not a problem. Undocumented custom code is.
Document:
- custom plugin names;
- child-theme functions;
- code snippets and where they run;
- custom cron events;
- webhook endpoints;
- custom database tables if any;
- server rules that WordPress administrators cannot see;
- environment variables or secret-management locations.
Never put live passwords or API secrets into the handoff document. Document where credentials are managed and who owns access.
Give the client a maintenance schedule, not a vague warning
“Keep WordPress updated” is not a maintenance plan.
Give the client a clear cadence. A simple version might be:
- Weekly: review updates, uptime and critical errors;
- Monthly: full backup verification, plugin/theme updates, form test, health audit, broken-link review, performance spot check;
- Quarterly: user access review, plugin stack review, content cleanup, restore test, analytics/SEO review;
- Yearly: hosting, domain, SSL, major licenses and architecture review.
Our WordPress maintenance tasks that actually prevent problems article gives a practical framework for ongoing care.
Separate project completion from support responsibility
A professional handoff states what happens next.
Clarify:
- the date the project support period ends;
- what qualifies as a bug from the original build;
- what counts as new work;
- whether ongoing maintenance is included;
- who handles hosting incidents;
- who handles third-party plugin support;
- the escalation route for a critical outage.
This protects both sides. The client knows where to go, and the agency avoids becoming an undocumented permanent help desk.
A practical WordPress handoff checklist
- Client administrator login tested
- Registrar and hosting ownership confirmed
- Premium license ownership documented
- Latest backup verified
- Restore responsibility documented
- Final health audit saved
- Critical forms and checkout tested end to end
- Email delivery verified
- SEO ownership and indexability checked
- Plugin/theme ownership map documented
- Cache layers documented
- Custom code documented
- Editorial role tested
- Temporary/staging accounts removed
- Maintenance schedule delivered
- Support boundaries explained
The handoff should reduce dependence, not create it
A good WordPress project leaves the client with a website they can understand and operate at the level appropriate to their role. That does not mean they need to become developers. It means important ownership, recovery and maintenance information should not live only in one developer’s memory.
A final diagnostic snapshot is part of that transfer. TopNotch Site Health Pro can help agencies and site owners document the state of the WordPress installation before responsibility changes, while leaving remediation decisions under human control.
For more WordPress operations, SEO and maintenance resources, browse the TopNotch Agency resources library.