Website launch versus website handover
A launch review asks, “Does the public website work?” A handover asks, “Can the business manage, maintain, and recover the site after the original team leaves?” Both questions matter. A visually complete website can still depend on a contractor’s private domain login, an undocumented email integration, or backups nobody has tested.
Complete a practical pre-launch website checklist and then use the ownership checks below. For each system, record who owns it, where its documentation lives, and the evidence that it works. Never place passwords in a shared public spreadsheet.
Part 1: Ownership and accounts — checks 1–5
1. Domain ownership. Record the registrar, responsible account owner, renewal date, and recovery contact. The business needs a durable way to renew and recover its domain.
2. DNS and connected services. Record where DNS is managed and the records required for the website, business email, and verification services. Make a secure backup before changes.
3. Hosting, CDN, and deployment. Identify the hosting account, deployment process, billing owner, and any content-delivery service. Confirm access works without depending on an individual developer.
4. Editor and administrator roles. Demonstrate an authorised login, a routine content change, and user-management permissions. Grant access based on need, not a shared administrator password.
5. Third-party services and subscriptions. Inventory forms, email delivery, calendars, analytics, booking, payments, and integrations. Write down who pays, who owns the account, and what expires.
The purpose is not to collect every possible login. It is to confirm that the appropriate people have access, recovery information, and clear responsibility.
Part 2: Content and design assets — checks 6–9
6. Approved content inventory. Keep a final list of public pages, approved copy, essential downloads, and anything still awaiting approval or a legal check.
7. Brand assets and licences. Provide approved logo files, fonts where licensing permits, photos, icons, and usage records. Buying a stock image does not always transfer unlimited rights.
8. Editable layouts and source files. Confirm the contract’s scope for design source, website repository, templates, and configuration documentation. Test access where source transfer was agreed.
9. Mobile page and navigation review. Recheck key pages on a real phone and desktop, including the menu, contact options, and any downloadable resources.
A project often goes more smoothly when those deliverables are defined during website design planning, rather than negotiated after launch.
Part 4: Quality, security, and recovery — checks 15–18
15. Mobile, speed, and browser testing. Test typical pages in common browsers and phone sizes. Record real issues and their owners instead of promising one permanent performance score.
16. Accessibility basics. Check keyboard navigation, readable contrast, meaningful alternatives for important images, and visible labels for forms. The W3C form-label guidance explains why placeholders alone are not enough.
17. HTTPS and account protection. Confirm the site uses HTTPS, recovery access is documented, permissions are limited appropriately, and software or dependent services have a maintenance plan.
18. Backup and restore instructions. Document backup scope, schedule, storage location, restoration owner, and a safe test procedure. A backup that nobody can restore is not a reliable recovery plan.
Part 5: Support and acceptance — checks 19–22
19. Technical dependencies and renewals. List the platform, critical services, subscription deadlines, and dependencies that keep the website running.
20. Routine maintenance. Assign content updates, technical monitoring, security reviews, and annual renewals to an owner. Identify which tasks the business can perform independently.
21. Open issues and support terms. Maintain a list of unfinished items, severity, owner, and agreement for resolution. Define support duration and what counts as additional work.
22. Training and final sign-off. Demonstrate a routine update, share the agreed documentation, and record the final accepted version and outstanding actions.
These four checks are easy to overlook because they come after the design is approved. They prevent routine maintenance from becoming an emergency.
Free 22-point website handover tracker
Use the free 22-point website handover tracker (CSV) in a spreadsheet. It contains every check in this guide with columns for responsibility, evidence, status, and comments. It is a reusable resource for business owners, freelancers, and internal teams.
Sample website handover record| Item | Responsible owner | Evidence | Status |
|---|
| Domain and DNS | Business | Registrar and DNS backup | Pending |
| Form delivery | Business / provider | Test enquiry confirmation | Pending |
| Sitemap and redirects | Provider | Validated URLs and sitemap | Pending |
| Backups | Business / provider | Backup and restore notes | Pending |
| Client acceptance | Business | Accepted version and issue list | Pending |
Treat the tracker as an operational record, not a place for live passwords, secret keys, customer data, or other sensitive details.
Copyable client sign-off note
We have reviewed the website handover checklist for [business/project], covering accounts, content, enquiries, search settings, accessibility, security, backups, and support. Remaining items are recorded separately with owners. Accepted website version: [version]. Review date: [date]. Client representative: [name]. Provider representative: [name].
Adapt this example to the actual contract and applicable requirements. It is a documentation aid, not legal advice.
Three red flags to resolve before sign-off
Access is promised but not demonstrated. Request a supervised sign-in or transfer confirmation. Avoid exchanging passwords through ordinary emails.
Billing and renewals belong to an unknown account. Record whose payment method and recovery details control important services. Domain and subscription lapses can interrupt an otherwise healthy website.
“SEO finished” has no agreed definition. Confirm which technical checks were completed and which remain open. Google recommends people-first helpful content; neither a sitemap nor a service contract guarantees rankings.
Frequently asked questions
Who should own a small-business website? Ownership depends on contracts and platforms, but a business should know who controls its domain, hosting, content, billing, and recovery process. Separate contract rights from everyday account access.
Is handover the same as launch testing? No. Launch testing reviews the public experience. Handover also confirms who can update, pay for, recover, and support the site after launch.
Can this checklist be used for a website redesign? Yes. Add checks for redirects, old URLs, migrated content, analytics continuity, existing integrations, and any legacy provider access.
Does a website handover checklist automatically earn backlinks? No. Other websites must choose to link to it. Providing a reusable, accurate tracker makes the resource easier to cite, but no links or search rankings are guaranteed.
Final takeaway
The strongest website handover is one the owner can operate independently. Give each system a responsible person, collect evidence of testing, document the remaining work, and keep a reliable recovery path.
You are welcome to reference this checklist in an educational guide, training material, or project brief with attribution to Neloy Digital Solutions. Businesses planning a new website can explore website design and development services to define deliverables and ownership expectations early.