Spectre Insights
What a website handoff should include: a business-owner checklist
An owner should be able to understand and maintain a finished website without guessing which accounts, licenses or responsibilities were left behind.
A useful website handoff explains how to access, edit, maintain and recover the site. It separates client-owned accounts and project deliverables from third-party software, licenses and continuing services.
The exact contents depend on the contract and the website, but the owner should not have to reverse-engineer who controls the domain, how an inquiry arrives or what happens when a plugin renewal expires.
Account control comes first
Identify the domain registrar, hosting account, website administration and any essential connected services. Record the authorized roles and the people responsible for them.
Access is not the same as ownership. Someone can have administrator permissions to an account owned by another party. A responsible handoff makes the distinction clear and uses secure access arrangements rather than placing shared passwords in an ordinary document.
Clarify what was delivered
Keep an agreed page and functionality list. It should be possible to distinguish the completed website from optional future work.
For example, a business site may include service pages, a contact form and a basic editing guide without including continuing article production, advertising management, a CRM subscription or indefinite redesigns. Those can be useful services, but they are not implied by the existence of the website.
Make routine editing understandable
The handoff should explain where the owner changes the content that will actually need updating: services, contact details, project images, opening information and articles.
Reusable design controls matter here. A global header or button style should not require manually repairing many disconnected pages. Explain which settings are global, which are page-specific and which changes are safer to make with technical help.
Document the inquiry path
Identify where each form appears, what information it collects and where accepted requests are sent. Include the confirmation behavior and the process for investigating a missing inquiry.
A test record should be precise. “The form worked” may mean only that the browser displayed a success message. A better record distinguishes accepted submission, notification receipt, duplicate checks and any relevant analytics event.
List the ongoing services and licenses
Hosting, email, premium plugins, stock images, booking tools and tracking services can have separate owners and renewal terms. The handoff should identify which are included in an ongoing agreement and which the client must renew directly.
Do not assume every file or tool in a delivered website can be freely redistributed. Custom work, open-source components and licensed third-party assets have different terms. Resolve those questions in the agreement instead of using “you own everything” as a substitute for detail.
Explain backups and recovery
Record what is backed up, where the backup is retained, who can restore it and which restoration steps have actually been tested. Files and the database may both be needed for recovery.
A downloaded Elementor template can help recover a layout, but it is not necessarily a complete copy of the site, plugins, uploads, submissions and configuration. A backup plan should match the recovery need.
Preserve the search and measurement records
Keep the intended public URL list, important redirects, sitemap location and the relevant analytics account details. A redesign should not leave the owner uncertain about which page addresses are final.
Search engines select canonical URLs using several signals. The Google canonical documentation is useful background for why the preferred URLs, links and redirects should agree.
State what support covers
A clear handoff distinguishes defect correction, routine maintenance, content updates, new features and urgent support. The agreement should identify the actual support arrangement rather than relying on “just contact us” for every future event.
Unless the agreement says otherwise, do not assume a set response time, unlimited revisions, or around-the-clock monitoring.
Owner's final review
Before closing a website project, confirm that you can answer these questions:
- Who owns and controls the essential accounts?
- Which pages and functions were included?
- How are routine content changes made?
- Where do inquiries go, and what was tested?
- Which tools require renewal or separate payment?
- What backup exists, and how would recovery work?
- Which search and measurement settings matter?
- What continuing support is included—and what is not?
A handoff does not have to become a technical encyclopedia. It needs to make the website operable and the responsibilities understandable.
Illustrative example: a handoff responsibility matrix
| Item | Owned by | Who can change it | Where it is documented |
|---|---|---|---|
| Domain registrar account | Business owner | Owner | Access record |
| Hosting and backups | Business owner’s account | Owner; care provider by delegated access | Care agreement and recovery notes |
| WordPress administrator | Owner (admin) | Owner; provider via a separate named login | Access record |
| Form notification recipients | Business owner | Provider on request | Inquiry-path test record |
| Analytics and tag manager | Business owner’s Google account | Owner; provider as a user | Measurement notes |
| Third-party licences | License holder named in the agreement | License holder | License list with renewal dates |
Build with the handoff in mind
Spectre Stacks treats website design and development as an independent service, with the agreed editing, access and documentation needs considered during the project. Explore website services or start a project conversation.
For the broader account-ownership questions beyond a website build, read what a business owner should own, or explore the Insights library.