Fictional worked example. This illustrates a review format. It is not a client audit or a set of researched findings.
Illustrative example, not client findings
This is a fictional worked example for a UK B2B services website. The observations below are invented to demonstrate the format of a review; they are not findings about a real company, researched search volumes or evidence of client results. No rankings, enquiries or AI recommendations are promised.
Assume the business wants more suitable enquiries. It has several services described on one page, a contact form and no confirmed record of successful form submissions in its analytics. A review would verify those assumptions before making recommendations.
From observation to decision
| Illustrative finding | Recommended action | Validation |
|---|---|---|
| Different services share a vague page title and short descriptions. | Research whether the audiences need distinct pages. Write substantive pages only where intent and service scope differ. | Check useful content, crawlable links, canonical URLs and indexing eligibility. |
| A button click is recorded as a lead, whether the form succeeds or fails. | Measure a confirmed successful submission, with an agreed duplicate-handling rule. | Test success, validation failure and repeated submission separately. |
| The site provides conflicting business details. | Agree one accurate business record and update visible content and structured data. | Compare the same details across important pages and external profiles. |
| One AI test omits the company. | Repeat a defined set of relevant questions and inspect the cited sources before diagnosing a cause. | Record platform, date, wording, location context and result type. |
Agreeing priorities
I would normally resolve measurement and access problems before judging whether a content programme is working. The next priority depends on evidence: a genuinely missing service explanation may deserve attention before minor wording changes, but a new page cannot help if it is blocked from indexing or answers the wrong buyer question.
An implementation instruction should name the affected URLs or templates, explain the expected behaviour, identify dependencies and define acceptance criteria. A developer should be able to understand what completion means without interpreting a vague recommendation such as improve technical SEO.
What happens after implementation
Technical validation and business measurement are different checks. First confirm that the agreed change works. Then observe relevant impressions, visits, enquiries and AI-search appearances over an appropriate period, accounting for other changes. A passed schema check does not demonstrate commercial success, and a single AI response does not establish visibility across a platform.
The paid review is based on your actual website, access and agreed scope. This example shows the reasoning structure, not a pre-written diagnosis that will be applied to every business.
Common questions
Can the recommendations be implemented by my developer?
Yes. Developer-ready instructions and validation criteria are part of the intended handover. The implementation route depends on the platform and scope.
Is this the same as the £199 Website Action Plan?
No. The Website Action Plan is a focused starting point with prepared deliverables. The SEO & AI Visibility Review has its own broader stated scope and price.