A practical website prelaunch checklist

Build realistic visit scenarios

Choose at least five tasks: find a service, understand its terms, inspect evidence, filter a list and send a message. Try them from the home page and from an internal page reached directly. Record the device, browser, URL, action, result and person responsible for any fix.

Include less convenient cases: empty field, no search results, unavailable external link, slow connection, narrow screen and keyboard-only navigation. A journey that succeeds on the designer’s computer alone is not enough.

• A visitor can finish the task without spoken guidance.
• Error messages explain how to recover.
• Returning to the previous page or result remains clear.

Review content and media

Check names, contact details, prices, service areas, opening times, dates and claims. Main images should load, be sharp and fit the topic. Confirm usage rights, useful captions, alternative text and that one photograph is not repeated across a row of cards. Decorative images may have empty alt text.

On key pages, compare the title, opening paragraph and call to action: they should describe the same offer. Review every language that is actually published, including menus, forms, errors and metadata.

• No broken image or missing main photograph.
• Every language explains the same service without forgotten copy.
• Contact information matches approved business details.

Check accessibility and useful performance

Navigate by keyboard and check visible focus, form labels, heading order and zoom. The W3C quick checks offer a starting method; they are not a full accessibility audit. Test pages and filters on a real phone-sized viewport, in portrait and with larger text.

Measure important pages with laboratory tools and, when traffic allows, field data. Inspect the main image, fonts, scripts and layout stability. A single score cannot replace observing whether a real journey responds quickly and remains usable.

• Keyboard access and visible focus.
• Understandable forms, including error states.
• Sized images and priority loading for the main image.

Verify discovery signals

Open final URLs and inspect HTTP status, canonical URL, title, description and internal links. Pages intended for search must not remain noindex or be accidentally blocked. The sitemap should list useful canonical URLs; important old addresses should lead to relevant replacements. The Google Search technical requirements provide the indexing baseline.

For each language, hreflang links should point to available versions and be reciprocal. Structured data must match visible content, with no invented reviews, prices or locations. Google does not require a special GEO tag or an LLM file for its AI search features.

• Canonical URL, sitemap and navigation agree.
• Redirects work without loops or irrelevant destinations.
• Language alternatives are reciprocal and the content is translated.

Make a release decision and monitor production

Sort findings into blockers, significant issues and later improvements. A form that loses enquiries, a missing main page or a wrong redirect blocks release. A small layout detail can sometimes follow if its impact is low and the decision is recorded.

Assign someone to check the live site immediately: contact journey, page status, indexing, measurement and visitor feedback. Repeat critical tests after deployment because production can differ from staging. The website brief gives the original commitments against which to assess the result.

Organise the release decision

Test a complete task for each priority audience and assign findings. Distinguish blocked orders or enquiries from presentation details. A successful automated check does not validate a task.

Retain the tested version, findings and rollback procedure. After release, check test-enquiry receipt, downloads, canonical URLs, languages and intended indexing on the final domain. Staging and production may differ.

Decide in a concrete situation

Fictional example: a presentation page is ready but the form has no confirmed recipient. Distinguish cosmetic issues from a broken journey; a partial launch must not imply that requests can be handled.

Prepare a publication decision with the checked journey, remaining issue, owner and recovery option. For a form, keep authorised evidence of receipt; no on-screen error is insufficient.

• Define and monitor website journey reliability

  Distinguish availability, task completion and delays; define observations, objectives, alerts and decisions without arbitrary promises.

Who can approve a release?

Assign an owner to each unresolved issue. A minor typo may be scheduled; a duplicate payment, lost enquiry or contradictory price requires an explicit decision before release. Establish who can restore the previous version and which checks permit service to reopen.