The short version

The key ideas.

  • Assign one accountable launch lead and named owners for every critical check.
  • Test complete journeys, including message delivery and changed URLs, on the live setup.
  • Prepare recovery and post-launch monitoring before changing the production website.

Create a launch record the whole team can use

Start with one shared record containing the release date, launch lead, technical contact, content approver and the person authorized to make a go or no-go decision. For each check, include its owner, evidence, status and any unresolved issue. “Forms tested” is ambiguous; “Test enquiry received in the monitored inbox at 10:15, including the expected fields” is useful.

Agree on launch blockers in advance. A broken enquiry path, exposed draft content or missing critical redirect may prevent release. A minor spacing issue might enter a scheduled follow-up list. The distinction should reflect the business and visitor impact, with accepted exceptions written down.

Choose a time when the responsible people can observe the change and respond. Plan a short content freeze if needed, including how urgent corrections will be handled. Record the exact version being released. A moving preview with last-minute edits is difficult to approve and harder to recover when nobody knows which version passed review.

Approve the content and walk the important journeys

Content approval should include names, offers, prices, dates, contact details, image rights and the destination of every important call to action. Review page titles, descriptions and social sharing images alongside the visible page. Remove placeholder copy and unpublished claims. Confirm that required business policies reflect the actual services and data collection in use.

Then follow the website as a visitor. Enter through a service page, read a project, find an answer and make an enquiry. Test navigation, downloads, search and booking links on the agreed browsers and representative screen sizes. Include long titles, empty results and error states that a curated demonstration may avoid.

Give the business approver realistic tasks instead of asking whether the site “looks good.” For example: find the service most relevant to a new location, determine the next step and contact the team. Record points of uncertainty. A launch review should reveal missing information as well as broken controls, because both can prevent the website from doing its job.

Verify the full path from action to receipt

Test forms beyond the success message. Confirm validation, submission, storage where applicable, email delivery and any customer relationship management entry. Use clearly labelled test data and remove it from operational queues afterward. Check that the person expected to respond can actually see the submission and understands the promised response process.

Run tests against the production configuration before opening the launch announcement. Preview environments may use different keys, recipients or allowed domains. A payment or booking integration may also require a specific live configuration; use the provider's appropriate verification procedure and document the outcome.

Check failed and repeated submissions too. What does someone see if the service is unavailable? Does the page preserve their input? Are internal details kept out of public errors? Assign an owner to monitor the first real submissions. A website that displays “Thank you” while messages disappear into an unmonitored inbox has a business process failure even if its front end behaves exactly as designed.

Protect the paths that already lead to you

For a replacement site, inventory existing URLs before changing them. Map valuable old pages to the most relevant new destinations. Google recommends server-side permanent redirects for mapped URL changes. Test the redirect itself and the destination; sending every old page to the homepage is rarely a useful experience for someone seeking a specific answer.

Verify the preferred domain, canonical URLs, sitemap, internal links and missing-page behaviour. Check that public pages intended for search are not carrying a staging noindex directive. At the same time, protect preview environments appropriately. Google explains that a noindex directive must be accessible to its crawler to be seen; blocking crawling and preventing indexing are different mechanisms.

Confirm access to the relevant search reporting account and submit the appropriate updated sitemap. Keep a record of important old URLs for post-launch checks. Search engines need time to process changes, so do not promise an immediate or unchanged search position as a result of the checklist.

Review access, speed and measurement with context

Run an accessibility review that includes keyboard use, visible focus, readable contrast, form errors and relevant assistive technology. Automated checks add useful coverage, but W3C cautions that tools cannot determine accessibility by themselves. Resolve serious barriers and record the scope and limitations of the review.

Check performance on representative templates and a realistic mobile setup. Document the conditions so later results can be compared. A new website may not yet have enough field data to establish its real visitor performance; use the prelaunch tests as a baseline and plan to review actual usage after release.

Verify analytics with purposeful events. Confirm that a page view, enquiry completion or booking handoff means what the report says it means. Avoid recording entered form content in analytics. Test the consent behaviour the business has specified, including what runs before a choice and after a refusal. Give someone responsibility for checking the first reporting period rather than assuming that an installed tag proves correct measurement.

Make access and recovery part of readiness

Confirm that the business controls its domain, hosting, CMS and essential service accounts. Record authorized users and recovery arrangements in the appropriate secure system. Check renewals, billing contacts and multi-factor authentication. Remove temporary project access that is no longer needed, while preserving the agreed maintenance team's access.

Prepare a recovery procedure suited to the change. Identify the previous working release, the content backup and the person able to restore them. Agree on the symptoms that justify rollback and how new submissions or content changes would be preserved. Restoring code is not always the same as restoring a database or reversing an external service change.

Review domain and email records before altering DNS. Website hosting changes should not accidentally remove mail delivery settings. Make the required changes explicit, with a second check where practical. A short rehearsal of the release and recovery steps can expose missing access while there is still time to fix it calmly.

Make inquiry delivery a release gate

Write down the expected path from a visitor’s action to the person who handles it. If the interface prepares an email draft, the visitor still has to send it. If it submits to a service, the browser needs an honest accepted or failed result. If the business depends on a notification, someone should separately verify that the intended mailbox received a clearly identified test.

Include a deliberate failure in the review: unavailable service, invalid field or interrupted connection. Entered details should remain available and the alternative contact route should be clear. Retest the real public origin after deployment, since a working preview does not prove that the final domain has the same configuration.

Record the destination, test time, observed result and person who checked it. Keep test details out of public logs and use only information appropriate for the test. This is a stronger release record than a screenshot of a thank-you message. Use the inquiry accessibility walkthrough for the front-end experience and the care plan to assign future checks.

Treat the first week as part of the launch

Immediately after release, check the live domain from outside the development session. Confirm certificate behaviour, key pages, navigation, redirects and a complete enquiry. Verify that caches and connected services are showing the intended version. Record the result in the launch log and let the agreed launch lead authorize the announcement.

During the following days, review errors, missing pages, form delivery, reporting and feedback. Assign dates to the accepted follow-up items. Give the business a short handover covering publishing, support contacts, renewal responsibilities and how to report an urgent issue.

The final launch record should make six answers easy to find: what changed, who approved it, what was tested, what remains open, who is watching it and how to recover. Those answers make a checklist operational. They also allow the team to move from launch anxiety to measured improvement, with the first visitors' actual experience informing what happens next.

Sources & further reading

From perspective to practice

Prepare the whole experience for launch

We can plan the content, implementation and review steps that turn a finished design into a dependable public website.

Discuss your website project Explore services & pricing