How to check your website before approving launch

Review the working website against the agreed job

Your provider should give you a working preview of the website before launch. This is often called staging: a private version you can use before the public site changes.

Review that version against the accepted pages, content, functions and approved changes. Keep the outstanding-items list beside it, so a feature discussed early on does not quietly become an assumed inclusion.

Looking over the design is part of this review. You also need to know whether a customer can understand the offer, make contact and reach the right person.

Agree who checks each part. Your team can confirm the service facts, prices, project descriptions and intended customer response. The provider remains responsible for the technical work it contracted to deliver.

You should not need to inspect code to approve your website. You do need clear evidence that the agreed work has been checked.

Turn the checklist into tasks someone can complete

“Form checked” leaves several questions unanswered. Was it submitted? Did the right person receive it? Could they reply using the details supplied?

For each important task, record:

• Where the person starts, including the page and device.
• What they do, using a realistic request and safe test details.
• What should happen, both on the website and inside the business.
• Who confirms the result and what evidence they keep.

Identify the preview version being tested. A link, review date and provider's version reference can be enough; use whatever reliably identifies that build.

Include the routes customers actually use. Someone following a service-page link from an advertisement may never see your homepage. Someone returning from an old email may use an address the new menu no longer shows.

Example launch review: a commercial flooring company

This fictional company supplies and installs commercial flooring. Its new website should help property managers assess the work, send a project enquiry and reach the estimating team.

For this example, customers arrange furniture removal before installation. The scope includes project editing for staff and redirects from changed service-page addresses.

A customer checks what the flooring work includes

Start on the installation service page using a phone, without visiting the homepage first. Find the types of premises covered, how the work is arranged and what the customer must prepare.

The page should make the furniture-removal responsibility clear before the customer sends a request. Open a relevant project example and check that its description supports the offer without claiming work the company did not perform.

The operations manager confirms the service facts and responsibilities. The person responsible for the project material confirms that the description and photographs are approved for use.

A page loading successfully would not establish either result. If the service explanation implies furniture removal is included, correct it before approval.

An enquiry reaches the estimating team

From that service page, follow the contact action on the same phone. Enter safe test details and a realistic project description.

First omit a required field. Check that the error explains what needs correcting and that the rest of the message remains available. Complete the field and submit once.

The confirmation should describe the actual next step. In this example, the estimating team will review the request; submission does not book an installation or confirm a price.

The estimator then confirms receipt, checks the project details are readable and verifies that the reply route works. The developer checks the website's sending and error behaviour.

If the page says “thank you” but the estimator has no request, keep the enquiry route open as a launch blocker. Investigate the cause and repeat the test after the fix.

Our enquiry-form planning guide covers choosing the questions. Here, the task is to verify submission, receipt and a usable reply route. Test other agreed forms and connections separately.

An existing customer follows an old link

Start with an important old service-page address from the preservation plan. On a phone, review its intended destination in the preview and confirm that it answers the same need.

Before launch, the developer checks the redirect configuration and demonstrates what can be tested in the preview environment. The operations manager confirms the intended destination is appropriate.

The public old address may still reach the old website until the switch. Record that distinction rather than marking the live redirect as passed prematurely.

Name the person who will test the real old link immediately after launch. A failed live redirect needs prompt attention through the agreed launch procedure.

The website rebuild checklist covers deciding what survives. Here, check the agreed transfer rather than reopening the whole inventory.

A staff member updates an included project

If staff editing is included, ask the intended editor to perform a representative task on their usual computer, using their own assigned access.

For this company, that means updating a project photograph and description on the test version. Check the preview, then follow the agreed approval and publishing process.

The editor confirms they can complete the task. The developer checks that the changed material appears in the intended places without damaging the layout.

This is a test of the editing capability agreed for this website. It does not imply that every page or design setting should be editable. Our editing requirements guide helps define that scope earlier.

Decide what passes, what blocks launch and what can wait

Give each issue a decision based on the agreed job and its consequence. Avoid a single “mostly done” label covering both a misplaced comma and a missing enquiry.

The calculator row applies only where that function is required. Test representative inputs and changes against results the responsible business person has confirmed. Its appearance is not evidence that the calculation is right.

An optional future calculator does not need to delay a website that fulfils its agreed launch purpose. Equally, deferral should not disguise a missing function the business needs on day one.

Check content and permissions through the website content checklist. An extra project can wait; an unapproved claim or photograph already displayed needs resolution.

For a failed check, record the page, device, steps, expected result and observed result. Add a screenshot or short recording when it makes the problem clearer.

Keep the issue open until the responsible person confirms the fix and the affected task passes again. If a change affects other pages or functions, have the provider check those too.

Ask for the provider's technical QA results

Your owner review sits alongside the provider's quality assurance, often shortened to QA. Ask what was tested, on which version, what failed and what remains unresolved.

The applicable checks should cover the agreed devices, forms, links, layouts and functions. They should also address the project's performance, accessibility, security, search-readiness and measurement requirements, with the responsible specialists involved where needed.

Ask for a plain-English explanation of material limitations. An unexplained speed score or “SEO done” note gives you little basis for approval.

You can flag an unreadable label or a contact action that is difficult to use. Those observations do not make you responsible for certifying accessibility. W3C's preliminary-check guidance explains that basic checks cover only some issues and cannot establish comprehensive accessibility.

Search readiness needs a similar distinction. Your provider should check the intended public pages can be accessed and indexed. Google's technical requirements make clear that meeting those requirements does not guarantee indexing.

Approval cannot establish future rankings, traffic or sales. The immediate question is whether the agreed website is ready to release, with material risks and responsibilities understood.

Approve a version, then check the live website

Record the version you approve, any agreed non-critical deferrals and who is authorised to release it. Confirm the launch owner, recovery route and applicable payment or access requirements before the switch.

Material changes after review need the affected checks repeated and approval of the revised version. Keep the decision tied to what will actually go live.

Some checks must then run on the public site. Confirm who will check the real domain, old links, enquiry receipt and any other release-dependent functions immediately after launch.

The provider should record the result and handle failures through the agreed launch procedure. Preview approval alone cannot prove that the public version works.

Before closing the project, agree where to report a defect and who owns ongoing updates, hosting and support. Those responsibilities follow the accepted arrangement rather than an assumption that someone will keep an eye on everything.

Later, review whether the website is bringing the right work. That business review is separate from launch acceptance and belongs in the wider website plan.

With SOL, QA, launch and the selected handover are part of the website development process. We agree the required pages and functions, provide a working review stage and resolve launch-critical issues before release.

Tell us what customers need to do on your website and who in your team takes over from there.