Websites / A practical guide
What should you test before launching a business website?
A useful launch review follows a visitor from understanding your offer to reaching the right person in your business, then checks who will keep that journey working.
Start with the job the website must do
A website can look finished while its most important task still fails. A contact button might open the wrong address, a form might accept an enquiry that nobody receives, or a visitor might struggle to understand which service fits. Review the journey you expect a prospective customer to complete, rather than approving screenshots alone.
For an illustrative service business, that journey might be: understand the offer, find a relevant service, submit an enquiry, receive accurate confirmation, and reach a named person who can respond. This is a planning example, not a client result. Turn each step into an observable acceptance check and agree which failures would stop launch.
Follow a test enquiry all the way into the business
Use clearly marked test details and check the destination inbox or customer system yourself. Confirm that the message contains the fields your team needs, reaches the intended owner, and can be answered using the correct reply address. A successful browser message proves only what the browser displayed.
If the site opens an email application instead of sending a form, make that distinction clear to visitors. Opening a draft does not send it. For submitted forms, the confirmation should describe the actual outcome and an agreed next step without promising a response time the team cannot support.
| Test case | Evidence to request |
|---|---|
| A complete enquiry | The intended recipient receives the correct details and knows who handles it. |
| Missing or invalid information | The form explains the problem and lets the visitor correct it. |
| A slow or failed submission | The visitor sees an accurate state and a useful recovery option. |
| A repeated click or retry | The outcome is understandable; duplicate enquiries are prevented or identifiable. |
| The usual owner is unavailable | An agreed backup process keeps enquiries visible. |
Check that people can complete the form
W3C's forms guidance recommends asking only for information needed for the task, providing labels and instructions, and explaining errors and successful completion. Apply that to your own enquiry form: can a visitor tell which fields are required, what format is expected, and what to do after an error?
Try the main journey with a keyboard, without relying on a mouse. Check that the current focus is visible, menus and controls work, and the visitor can leave an opened menu or dialog. Enlarge the text and inspect whether important content or controls disappear. Ask your supplier to explain how labels, error messages, contrast, and assistive-technology support were assessed.
W3C explicitly describes its easy checks as preliminary. Passing a short checklist or an automated scan does not establish comprehensive accessibility. Agree the depth of evaluation your project needs, record unresolved barriers, and avoid presenting a quick launch review as a certification.
Use the site on a phone, not only a narrow preview
On a real phone, open the navigation, read a service page, and complete the enquiry journey. Check whether the on-screen keyboard hides instructions or the submit button, whether long text fits, and whether a banner covers the next action. Repeat the important steps on the browsers and devices agreed in the project scope.
Google's Web Vitals guidance separates loading, interaction responsiveness, and visual stability. Ask for performance evidence for important page types, not only a homepage score. A large image that loads slowly and a button that moves as content appears create different problems and need different fixes.
Controlled tests help identify issues before release, while real-user measurements describe experience after launch. Keep that distinction visible in the report. A single fast test on the developer's connection is not evidence that every visitor will have the same experience.
Make the intended public pages discoverable
Ask the supplier to check the final public URLs, not just the preview site. Important service and contact pages should be reachable through working links. Review page titles and descriptions for accuracy, check that old URLs have an agreed destination when replacing a site, and open links from any existing campaigns you plan to keep using.
Google's technical requirements distinguish a working, publicly accessible page with indexable content from a guarantee of indexing. Confirm that intended public pages are not accidentally left behind a login or a development indexing restriction. Keep genuinely private material protected; search settings are not access control.
A sitemap can help search engines discover URLs, but Google states that it does not guarantee crawling or indexing. Check that it lists the intended live pages rather than preview addresses or removed content. Treat search readiness as a launch foundation, not a promise of rankings or enquiries.
Ask for a small evidence pack
Use one shared launch record so open issues do not disappear into chat. For each check, record the page or journey, expected outcome, actual result, environment, date, and person responsible. Include enough evidence to repeat the test after a fix. Agree in advance how unresolved issues will be assessed and who can approve the release.
- Business journey: a test enquiry received and assigned, with failure handling checked.
- Content: correct offer, contact details, links, and permission to use supplied images or testimonials.
- Usability: agreed mobile, keyboard, form, and accessibility checks with known limitations.
- Technical release: final URLs, search settings, deployment checks, and a recovery procedure.
- Ownership: named account owners, editing instructions, support route, and review date.
Finish with ownership and a post-launch check
Have someone in the business make a routine content change using the handover instructions. Confirm where the website, domain, hosting, form destination, and source or platform configuration are managed, and who handles renewal or access problems. Agree what support includes instead of assuming the original builder will always be available.
Repeat the critical journey on the live domain after deployment. Keep a record of the released version and the steps for restoring service if a release fails. Schedule a review of missed enquiries, user difficulties, and operational issues after launch, using evidence that is appropriate for your site and visitors.
Bring your enquiry journey and this acceptance checklist to a website scoping conversation with KazeZeus. They help Udbhav define a reviewable delivery scope, including the checks and handover your business needs, before choosing a platform or expanding the design.