A website can look finished while its phone number is wrong, its form notification is lost, its canonical points to staging, or its owner cannot renew the domain. Launch acceptance should test the working system the customer and business will use, not only the visible design.
Use this checklist before approving a new site, migration, or major rebuild. Adjust it to the real project scope and record evidence for every critical item.
Freeze the agreed scope
- List every production URL and its purpose.
- Confirm who supplied and approved prices, hours, services, policies, credentials, photos, reviews, and legal language.
- Mark what is included, deferred, excluded, or waiting on a third party.
- Separate defects from new features and from content that still needs business approval.
The website package guide explains why page count alone is not enough to define the deliverable. Acceptance is easier when the proposal names the pages, inputs, flows, tests, ownership, and limits.
Review content and page purpose
Read each important page as a customer who does not know the business. Can the visitor identify the audience, service, scope, service area, proof, price or pricing context, next action, and response expectation? Confirm that every factual statement has an accountable source.
Check titles, descriptions, headings, canonical URLs, meaningful link text, image alternatives, dates, author details, and any structured data against the visible page. Remove placeholder copy, duplicate sections, invented claims, and stale offers. A page that exists only to meet a page count should not be accepted as a useful page.
Run end-to-end customer tests
| Path | Test | Evidence |
|---|---|---|
| Phone | Tap on a real phone and compare the displayed number with the staffed destination | Device, time, number, and owner confirmation |
| Form or quote | Submit labeled test data, trigger validation, and verify delivery and confirmation | Submission ID, inbox or CRM receipt, customer-facing result |
| Booking | Choose a real test slot, confirm reminders, and exercise cancellation or rescheduling | Calendar record, confirmation, owner handoff |
| Checkout | Test the configured payment path and success, failure, refund, or cancellation states | Test transaction or sandbox record and fulfillment signal |
| Navigation | Open primary routes, internal links, downloads, maps, and external handoffs | URL list and result record |
Use a clearly labeled test identity and remove it from reporting. A green confirmation message is not enough if the owner never receives the request.
If the site links to a gift-card provider, use the gift-card purchase-link test to check the handoff, issued card, recipient delivery, redemption and repair owner separately from an ordinary checkout.
Check real devices and input methods
Review the homepage, highest-traffic landing page, primary service page, contact path, and any booking or checkout page on a narrow phone viewport and a wide desktop viewport. Test long business names, large text, zoom, keyboard focus, menus, forms, tables, error messages, and embedded tools.
The W3C WCAG overview organizes accessibility around perceivable, operable, understandable, and robust content. Automated checks can identify some issues, but acceptance should also include manual keyboard and content review. Record third-party limitations instead of claiming universal conformance.
Verify search controls and measurement
Confirm that production pages use the intended canonical host, important pages are crawlable, future or private routes are controlled, redirects map replaced URLs, and sitemaps contain only the intended indexable pages. Google’s Search Console documentation explains ownership, indexing reports, sitemap submission, URL inspection, and Search performance checks.
Verify that calls, forms, bookings, checkouts, and purchases have named events or a documented measurement alternative. The website measurement guide separates acquisition, action, delivery, qualification, and business outcome so a page-view report does not hide a broken handoff.
Confirm accounts and recovery
Before launch, inventory domain, DNS, hosting, content platform, source, analytics, Search Console, Business Profile, form, booking, payment, email, consent, and third-party accounts. Confirm the business controls the owner or recovery role and the provider has only the access required for its work.
Record billing, renewals, recovery, exports, backup location, restore steps, and provider removal. The website account ownership guide provides a fuller handoff table, while the ICANN registrant guidance explains why the intended business registrant should control domain management.
Check production safety
Confirm HTTPS, headers, access roles, software and dependency status, form abuse controls, privacy notices, backup evidence, and an incident contact. If WordPress is used, its official update documentation recommends current software and a backup before updates; its backup guidance explains why files and database both matter.
Ask who can roll back the release and what “rollback” means for content, orders, form submissions, and database changes. A screenshot of a backup setting is not restore evidence.
Use an acceptance record
For each item, record status, evidence, owner, severity, due date, and whether it blocks launch. A useful rule is:
- Block: critical path unavailable, unsafe, inaccurate, inaccessible in a material way, or impossible to recover.
- Accept with owner: noncritical issue documented with a realistic fix date and no misleading claim.
- Complete: requirement tested in production or the agreed release environment with evidence attached.
Do not sign “approved” while the record still hides open critical items. If the launch date is fixed, write down the tradeoff and obtain the business owner’s explicit decision.
Approve a working, owned system
Launch when the agreed content is accurate, customer paths complete, search and measurement controls are intentional, accessibility and mobile checks have evidence, accounts are owned, and recovery is possible. Defer only what is documented, noncritical, and assigned.
A launch acceptance checklist is valuable because it makes the final decision explicit: the business is not accepting a pretty page; it is accepting a system customers can use and the owner can operate.