An automated scan catches response and markup issues, but a launch succeeds when people can complete the important journey. Test the public site from entry page to final confirmation, and verify that the business actually receives the lead, booking or payment information.
Define the two important journeys
Choose the actions that matter most for your site. A service business might need a contact enquiry and a booking; a shop might need product selection and a successful checkout. Write the expected result for each step. Keep the scope concrete enough that a teammate can repeat the test. A vague instruction to check everything makes it difficult to know whether a broken confirmation email or mobile control was ever reviewed.
Run the technical checks first
Use the launch audit for broad coverage, then focused tools for direct evidence. Check noindex and canonicals on the key entry pages, trace public URL variants, sample internal links and inspect the sitemap. Fix confirmed access and indexing blocks before spending time polishing metadata. Save the result and timestamp. A clean automatic result is a helpful baseline, but it cannot submit your business form or determine whether your sales team received the message.
Test mobile interaction on a real device
Open the public site on a phone and follow the primary journey without developer shortcuts. Check menus, input fields, validation messages, buttons and the final confirmation. Try a longer email address and a realistic message. Watch for layout movement that shifts a control just before a tap. Browser emulation can help during development, but a real device reveals keyboard, scrolling and touch behavior that a markup inventory misses.
Verify downstream delivery
Submit a clearly labeled test lead and check the actual destination mailbox or CRM record. Confirm that the sender, reply address and important fields are usable. For payment flows, use the supported test environment and verify the success page, receipt and application entitlement. Do not infer delivery from a success message alone. If an email fails, inspect domain/email health and the sending setup as a separate operational issue.
Prepare a controlled rollback
Before a major deployment, know which prior build you can restore and which settings belong outside the uploaded files. Keep database migrations, secrets and hosted configuration in the release record. A source archive alone may not reproduce a running service. If a release fails, identify whether the problem is static content, a worker route, a binding or a third-party service before restoring unrelated pieces.
Use a checklist as a record
Open the interactive launch checklist and mark items only after observing the expected behavior. Its progress stays in your browser and can be exported for a handoff. Assign unresolved issues to a person and a next action instead of merely leaving an unchecked box. After launch, rerun priority checks and review incoming traffic and enquiries. That closes the gap between a technically live site and a site that people can use reliably.
A practical action checklist
- Write expected outcomes for the two main visitor journeys.
- Run broad and focused checks on public entry pages.
- Test the journey on a real phone.
- Confirm real lead delivery and test-environment purchase behavior.
- Export the checklist and record rollback steps.
NewSiteCheck workflow and examples. Review important production decisions against the applicable official documentation.