Practical guide · Website review
Evidence.
Then action.
A practical framework for reviewing a UK service-business website without confusing a long list of observations with a useful decision.
Last reviewed: 15 September 2026. This published framework explains the lenses used in a practical review. It does not mean that every issue listed here is audited on every project; the agreed pages and checks are confirmed in writing before work begins.
Start with the customer action
A review should begin with the action the business actually needs: a call, an enquiry, a booking, a visit or a qualified request. Without that, it is easy to identify cosmetic differences while missing the moment where a customer cannot understand the service or take the next step.
For each agreed page, capture the evidence first: the page URL, device context, visible copy, interaction or technical response. Then state why it matters and what a realistic change would be. This keeps the final list useful to an owner, a developer or a future provider.
Five review lenses
1. Mobile enquiry journey
Check the first screen, service route, main call to action, contact method and form path on a phone-sized view. The question is not whether the site merely fits the screen; it is whether a new visitor can work out what to do next.
2. Service information and wording
Check whether the service, audience, location relationship, exclusions and next step are understandable without insider knowledge. Flag duplicate, vague or conflicting labels that make a real offer sound uncertain.
3. Accessibility and usable content
Look for clear headings, meaningful image descriptions where needed, readable contrast, visible focus and understandable controls. Accessibility is not an optional decoration: it also makes a service and its actions easier to interpret.
4. Trust and ownership signals
Check whether the site says who provides the service, how scope and payment are agreed, what the client receives and how issues are handled. Use truthful statements and authorised evidence only; do not fill a gap with invented testimonials.
5. Technical discoverability
Check public-page basics such as canonical URLs, titles, descriptions, internal links, sitemap and crawler access. For AI-search questions, distinguish technical access from a promise that any system will cite or recommend the business.
Turn observations into a decision document
Each finding should include four parts:
- Evidence: the page, screen, response or content element observed.
- Impact: how it may affect a visitor's clarity, confidence, access or next action.
- Recommendation: the smallest practical change worth considering.
- Verification: how the business can confirm the change after it is made.
Then group work into urgent, valuable and optional. An urgent item blocks a clear customer action or creates a material error; valuable work improves an important journey; optional work may be useful but does not need to delay the next release.
What a review does not do
A review is not a hidden promise to change a live website, provide ongoing monitoring, submit to directories, buy traffic or secure search rankings. Implementation needs a separate written scope. Any result that depends on a third-party platform, a search engine, an AI system or customer behaviour should be described as a risk or possibility, not a guarantee.
The outcome should be a concise action list that the client can keep, understand and use with Linshi Studio or another provider. That is a more durable result than an opaque score or a dashboard with no next step.
How Linshi Studio applies it
The £350 quarterly website and AI-search review uses this framework for the homepage and up to two agreed priority pages of a public website. The deliverable is a prioritised written action list. Live implementation, ongoing monitoring and any commercial outcome are outside that review unless separately agreed.