A WordPress website handover should leave the owner or agency able to access the agreed accounts, make routine edits, receive enquiries and know who handles maintenance. It should also identify unfinished work. Use this checklist to record the evidence and owner for each item, rather than marking a project complete because the homepage looks finished.

This is a planning resource based on the responsibilities described in our development process. Adapt it to your proposal. It is not a promise that every item is included in every build, or a completed test record for your website.

1. Confirm account ownership and access

List the domain registrar, hosting, WordPress administration, business email and any services the website depends on. For each, identify the account owner, billing contact, authorised users and recovery contact. An agency may manage access on the client’s behalf; record that arrangement explicitly.

  • Have the intended owner confirm that they can sign in using their own authorised account.
  • Agree which WordPress role each person needs for their work. Routine content editors should not need shared administrator credentials.
  • Record access to analytics, Search Console, booking, payment or CRM services only where they are part of the scope.
  • Identify temporary development accounts and agree when the responsible administrator will remove access that is no longer needed.

Keep passwords, recovery codes and API keys out of the handover checklist. Use the agreed secure sharing method and record only that access was confirmed.

2. Demonstrate the actual editing tasks

Choose the tasks the owner will perform regularly: changing a service paragraph, replacing an image, adding an article or updating shared contact details. Record where each item lives and let the editor complete an example on an agreed test copy or staging site.

Include a long heading and an empty optional field where the design supports them. Check the saved page on a narrow screen as well as desktop. Explain which settings affect several pages, which fields are required and how to preview a change before publication.

Our own-site ACF editing example shows a real WordPress field and corresponding page previews. It illustrates one editing task on our website; your handover should cover your own content model and agreed tasks.

3. Document backups and the recovery route

Record what the backup covers, where it is stored, who can retrieve it and who is responsible for restoring it. A typical WordPress recovery needs both the database and files, as explained in the official WordPress backup guidance.

A successful export is evidence that a file was created. It does not prove that a restore has been tested. Record the latest restore test separately, including its date, test environment and result, or mark it as pending. Agree a recovery route before risky changes, including what happens to enquiries or orders created after the backup.

4. List licences, renewals and maintenance owners

Separate the build price from recurring services. List hosting, domains, premium plugins, paid fonts or other licensed assets, and external services. Identify who holds each licence, who pays for renewal and any transfer or ongoing agency dependency that needs confirmation with the provider.

  • Assign an owner for WordPress, theme and plugin updates.
  • Agree how updates will be backed up, tested and reviewed before production changes.
  • Identify who checks failures in forms or other important integrations.
  • State which ongoing tasks are covered by a maintenance agreement and which require a separate request.

Do not assume continued updates or support are included because a paid plugin is installed. Record the actual entitlement and responsible account without putting licence keys in the shared checklist.

5. Verify the enquiry journey and measurement

For each agreed form, record required-field behavior, the visitor’s confirmation and the destination where the enquiry must arrive. A thank-you message alone does not confirm inbox or CRM delivery. Use a clearly labelled test, confirm the receipt and keep that test out of genuine lead and sales totals.

Check the form on an actual phone with its keyboard open. Look at labels, validation, the submit button and any floating controls. A desktop browser resized to a phone width is useful layout evidence, but it does not replace that device check.

If analytics is included, identify the approved property and the event that represents a successful enquiry. Keep page visits, button clicks, test submissions, genuine enquiries and won projects distinct. A recorded event does not establish a qualified lead or revenue by itself.

6. Record launch approval and remaining work

Keep one release record with the production URL, release date, agreed acceptance checks, results and named approver. Review important navigation and enquiry routes, the intended search-indexing settings, and redirects for any URLs changed within the project.

For an agency handover, also confirm who communicates with the end client and how the developer is represented. Our white label WordPress development page explains the scoped pilot and review arrangement.

Give each unresolved item an owner, next action and agreed review date. Separate a defect against the accepted scope from a new feature request. Document the support contact, covered work and any agreed support period; avoid assuming an unlimited revision or maintenance commitment.

Copy this handover record

Use one line per item. Mark it confirmed, pending or not applicable, and add the evidence or reason. Keep the completed record private if it contains account details or internal project information.

  • Project and production URL: …
  • Release version, date and approver: …
  • Account access — owner, confirmation date and remaining action: …
  • Editing tasks — task, test URL, result and guidance location: …
  • Backup — coverage, location, owner and export date: …
  • Restore test — environment, date and result, or pending owner: …
  • Licences and renewals — service, account owner and responsibility: …
  • Enquiry test — reference, receipt location and result: …
  • Phone check — device, journey, result and remaining issue: …
  • Measurement — property, agreed event and test exclusions: …
  • Support — contact, agreed scope and applicable period: …
  • Outstanding work — item, owner, next action and review date: …

Illustrative entry: “Homepage service copy — content owner changed one paragraph on staging; desktop preview checked; phone keyboard check pending with the agency reviewer.” This is an example of a useful record, not evidence of a completed client test.

Common handover questions

Is a WordPress login enough for handover?

No. The owner also needs the agreed editing guidance, account responsibilities, backup and recovery information, and a clear route for support. Access should be confirmed by the person who will use it.

Does handover automatically include ongoing maintenance?

No. Maintenance and post-launch support depend on the proposal or a separate agreement. Record the covered tasks and responsibilities before assuming they are included.

When should the handover checklist be agreed?

Agree the expected deliverables during scoping, then complete the evidence during review and release. Start with our WordPress project brief template to settle those responsibilities before development.

Planning an agency build? Share your approved design and handover requirements so we can define a scoped paid pilot.