A website launch sign-off is a decision record: the critical journeys work, the evidence has been checked, each unresolved risk has an owner, and someone is responsible for proceeding or postponing. Free tools can collect clues. They cannot approve a release or prove that a lead, booking or payment reaches its destination.
Use this page as an operational worksheet. For the detailed page-level search checks, follow the website launch SEO checklist. Keep the technical audit and the release decision connected, rather than run two identical checklists.
Name the launch goal and the release owner
Write the main journey in plain language: visitor reaches the service page, opens the enquiry form, submits it and receives the intended confirmation. List the homepage, service/contact pages and campaign destinations that support it. Include other critical journeys if the site has bookings, accounts or purchases.
Assign one release owner and a person for each specialist check. Agree on the production URL, test window, escalation contact and recovery plan. Staging success is useful evidence, but production DNS, redirects, cache and configuration can differ.
Fill in a launch evidence worksheet
For every row, record the exact URL, environment, test date, device, owner, evidence location and result: PASS, BLOCK or FOLLOW-UP. An empty evidence cell is not a pass.
| Release question | Evidence to retain | Tool or check |
|---|---|---|
| Can a visitor complete the main journey? | Test steps, confirmation and receipt at the intended destination | Manual browser/device test; synthetic inputs clearly marked as tests. |
| Can intended public pages be discovered? | Status, canonical, robots/indexing directive and sitemap checks for critical URLs | Technical SEO checklist plus inspection of the public response; do not use a score alone. |
| Do page identity and markup match the content? | Reviewed title, description, H1 and schema validation result | Page preview and schema validators; confirm live HTML afterward. |
| Is the critical mobile journey usable? | Actual image, navigation, form and button checks at relevant sizes | Real device or responsive browser review; keyboard checks on desktop. |
| Is performance evidence understood? | Test URL/date, lab findings and any available field data | PageSpeed Insights; inspect the actual bottleneck instead of approving on score alone. |
| Can campaigns and outcomes be measured? | Distributed link, landing URL, collection evidence and intended key-event check | UTM Builder plus the site’s established analytics debugging process. |
| Can the release be recovered? | Known backup/recovery reference, owner and escalation procedure | Existing approved operational process; do not experiment with a production restore during launch. |
Use tools for evidence, not automatic approval
The SEO Audit Tool can start a page-level review, but its preview is not proof of a full crawl, analytics collection or successful form delivery. For structured data, use the schema generation and validation guide; valid JSON syntax alone is not a rich-result or policy check.
Keep crawler access separate from indexing directives. Google’s robots.txt guidance explains that crawl blocking is not a reliable way to keep a URL out of search. Record the intended behavior and the actual public response; do not indiscriminately remove private-page protections.
Use PageSpeed Insights on representative public URLs. Core Web Vitals concern loading, interactivity and stability; lab results are not a substitute for field measurements. See the Web Vitals guidance. If the site lacks field data, record that limitation instead of declaring a field pass.
The Image Compressor can help prepare a large asset, but review its published dimensions and quality. Use the UTM Builder for external campaign links, then follow the UTM reporting diagnostic to check the measurement path.
Separate launch blockers from scheduled follow-ups
Blockers prevent the agreed critical task or expose a material risk: a broken primary form, missing booking receipt, inaccessible main action, unintended public-page indexing restriction or an unapproved tracking/privacy setup. Resolve these or obtain a clearly documented decision from the responsible owner before proceeding.
Follow-ups can wait only when the release owner explicitly accepts the impact, names an owner and sets a review point. Cosmetic polish on a secondary page may qualify; a missing lead-delivery check does not become cosmetic because the form shows a thank-you message.
Illustrative failure: a form displays confirmation but the enquiry never reaches the intended inbox or system. Keep both the browser result and destination evidence. A tool score or a working thank-you URL cannot settle that question.
Recheck production and hand over the release record
- Resolve blockers and record accepted follow-ups before the go/no-go decision.
- Release through the existing approved process with recovery ownership clear.
- Repeat the critical journey on the public production URL after redirects and caching apply.
- Recheck intended public status, canonical, indexing directives, sitemap and measurement evidence.
- Assign post-launch review of delivery errors, broken destinations, indexing and analytics anomalies.
Store the sign-off record where the next operator can find it. The finish line is a supported release decision and a working visitor task, not a checklist with every box ticked.






