Then the website launches.

A visitor follows an old link and reaches a missing page. Another fills out the contact form, sees a success message, and assumes the business received the request. The message never arrives. Meanwhile, the analytics dashboard records button clicks as if they were completed enquiries.

None of these problems necessarily appears in a design review.

A website is ready when its important journeys work from beginning to end. For a service business, that usually means someone can find the right service, understand it, assess the company, and make contact successfully.

This article outlines a practical way to test those journeys before launch and verify them again in production. The approach works whether you are building with a content management system, a static site generator, or a custom application.

1. Define the journeys that matter before testing pages

A page-by-page review is useful for finding layout problems. It is less effective at revealing gaps between pages, tools, and business processes.

Start with three or four realistic customer journeys.

For a hypothetical commercial contractor, those might be:

• A visitor arrives on a service page from search and requests a project discussion.
• A referred prospect opens the homepage, reviews completed work, and calls the business.
• A returning customer follows an old bookmark to find a service.
• A mobile visitor opens the menu, compares two services, and submits an enquiry.

For each journey, record the starting point, the visitor’s goal, and the observable result that means the task succeeded.

Be specific about success. “The form displays a confirmation” is different from “the submission is stored and the assigned team receives a notification.”

This planning connects development work to the website’s purpose. At Bizfront, our website design process⁠ starts with understanding the business and its customers so the pages and functionality support real decisions.

The test plan should reflect those decisions.

2. Check whether the page answers the visitor’s question

A technically functional page can still leave customers uncertain about what the business offers.

Choose an important service page and ask someone unfamiliar with the project to review it. Give them a realistic task, such as determining whether the company handles work at an occupied commercial property.

Ask them to explain what they found and where they would go next.

Avoid guiding them through the answer. Their hesitation is useful evidence.

Check whether the page makes the following information understandable:

• Who the service is intended for.
• What the business handles.
• Which examples demonstrate relevant experience.
• What information is needed to start a conversation.

Record specific misunderstandings. “The visitor thought installation was excluded” is actionable. “The page needs more impact” is harder to translate into a useful change.

Content review belongs in launch testing because the website’s job includes helping people make sense of the offer. A working button cannot compensate for an unclear service explanation.

3. Test navigation without relying on a mouse

Move through the main navigation, service links, accordions, and enquiry controls using a keyboard.

Check that you can see which element has focus and that the order follows a sensible route through the page. Open menus and dialogs, then verify that they can be closed and that focus behaves predictably.

For navigation to another page, use an appropriate link. For actions such as opening a menu or submitting a form, use an appropriate button.

Native controls give developers a useful starting point, although they still require testing in the finished design.

Also check the reading structure. Headings should describe their sections and follow a logical hierarchy. W3C’s page-heading guidance⁠ explains how headings communicate organisation and support navigation with assistive technologies.

These checks are part of accessibility review, rather than proof that the whole website meets every accessibility requirement. Combine automated checks with manual testing of the actual journeys.

4. Test forms beyond the successful submission

A form deserves more than one test with valid information.

Try submitting it with missing required fields, an invalid email address, and a long message. Check whether useful input remains available after an error.

Then test a realistic Canadian phone number and postal code. Avoid validation rules that reject legitimate formats simply because they differ from the developer’s preferred example.

W3C’s form-validation guidance⁠ recommends accommodating valid input formats and validating on the server as well as in the browser. Browser validation can be bypassed.

Next, test the delivery chain:

1. The server accepts or rejects the submission appropriately.
2. The accepted request is stored or passed to the intended system.
3. The notification reaches the correct recipient.
4. The recipient can identify and respond to the request.

Use clearly labelled test data. Confirm the results with the person responsible for enquiries, and remove test records according to the project’s normal process.

A success message should reflect what the system has actually confirmed. If a request is stored but notification delivery is asynchronous, design the wording and monitoring around that reality.

5. Check failure and recovery paths

Customers do not always have a stable connection, and external services do not always respond immediately.

Use a controlled test environment to examine what happens when an enquiry request fails or takes longer than expected.

Does the interface explain the problem? Can the visitor retry? Is the form cleared prematurely? Can repeated clicks create duplicate records?

The implementation should distinguish a confirmed failure from an uncertain outcome. If the server accepted a submission but the response was lost, an immediate retry could create a duplicate.

Where appropriate, handle duplicate submissions on the server and provide a safe recovery path.

The details depend on the application, but the review questions remain useful:

• What does the customer see?
• What has the system recorded?
• What does the business receive?
• How can the situation be investigated?

Document those answers. They help support staff understand reports that are otherwise easy to dismiss as “the form did something strange.”

6. Preserve useful routes into the old website

A redesigned website may change page addresses. Existing links can remain in search results, customer bookmarks, emails, and external websites.

Create an inventory of important old URLs and map each one to an appropriate destination.

When a page has a clear replacement, use a permanent server-side redirect where possible. Google’s site-migration guidance⁠ recommends this approach and warns against sending many unrelated old URLs to the homepage.

That distinction matters to visitors. Someone following a link to a specific service should arrive at a relevant explanation.

Test the final destination, not just the presence of a redirect. Check for loops, unnecessary chains, and destinations that themselves return errors.

Also review canonical URLs, internal links, sitemap entries, and indexing controls before launch. Temporary staging restrictions should not accidentally block the intended production pages.

When search visibility is important to the project, include the people responsible for SEO planning⁠ before changing the structure.

7. Test the mobile journey on an actual phone

A responsive preview helps identify layout problems, but it does not reproduce every aspect of using a real device.

Open the site on a phone and complete a priority task.

Check what happens when the on-screen keyboard appears. Confirm that form fields, error messages, and submission controls remain usable.

Try the menu with one hand. Review whether floating chat widgets or sticky buttons cover important content. Follow phone links and verify that the intended number appears.

Read the page with the text enlarged. Look for clipped headings, overlapping elements, and horizontal scrolling that makes the content difficult to follow.

Use a realistic connection as part of the review. Your development machine and office network may make a page feel more responsive than it does elsewhere.

Record the device, browser, and steps for any issue. A reproducible report is much more useful than a screenshot without context.

8. Verify measurement against real outcomes

Before launch, write down exactly what each important analytics event represents.

A click on “Request a Quote” may indicate interest. A server-confirmed submission indicates that a request was accepted. A booking confirmation indicates a different completed action.

Keep those meanings clear.

Test the event triggers while performing the matching journey. Check whether an event fires too early, fires twice, or is absent when the action succeeds.

If a confirmation page is used, consider what happens when someone refreshes it or visits it directly. A page view alone may not always represent a new submission.

Avoid sending names, email addresses, phone numbers, or free-text enquiry content into ordinary analytics event parameters.

For the launch review, reconcile a small set of labelled test submissions against the corresponding records and measurement events. Investigate mismatches before relying on the dashboard.

The objective is a measurement system the business can interpret accurately.

9. Use a simple release decision

A long list of issues is easier to manage when each item has an owner and a clear effect on the customer.

Classify problems by what they prevent.

A broken form, inaccessible navigation, or accidental indexing block may justify delaying launch. A minor spacing inconsistency may be suitable for a documented follow-up.

Agree on that distinction with the project owner.

For every important issue, record:

• The affected journey.
• Steps to reproduce it.
• Expected and actual behaviour.
• The person responsible.
• The result of the retest.

Then repeat the critical journeys on the production website. Hosting configuration, live credentials, caching, and external integrations can differ from staging.

A staging pass is evidence about staging. Production still needs its own short verification.

10. Give the website an owner after launch

The launch checklist should lead to an operating routine.

Decide who will notice if forms stop arriving, who can investigate a broken integration, and who reviews changes to services or contact details.

Include practical handover information: where enquiries are stored, which accounts control the domain and hosting, and how urgent issues are reported.

Project examples can also help stakeholders see why these details matter. Our client case studies⁠ show how website work supports wider marketing activity. Reliable customer journeys are part of making that activity useful.

Plan a follow-up review based on actual enquiries and observed problems. Record what customers misunderstand and where staff repeatedly need to provide missing information.

At Bizfront, planning, building, testing, and launching a website⁠ are connected parts of the same project.

A finished design is an important milestone. A customer successfully completing the task is the result your testing needs to demonstrate.