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.