Most website audits start from a list. Check the page speed. Check the alt text. Check that the checkout loads. The list is the same for a bakery, a law firm and a software company, which is exactly the problem.
The issues that cost a business customers are rarely on a generic list. They are things like a returns policy that search cannot find, or a price that changes between the product page and the basket. You only find those by using the site the way a real customer would.
Product Reviewer is built to do that. Here is how an investigation works.
Step one: work out what the business is
Before it tests anything, Product Reviewer reads the site to understand it. It looks at the homepage, navigation, product and pricing pages, policies, forms and footer, then builds a model of the business: what it sells, how it makes money, who it sells to, where, and what it most wants a visitor to do.
That model is not fixed. If the investigation later discovers something new, like a subscription option or a store locator, the model is updated and the plan changes with it. You can also read the model, correct it or add context.
Step two: work out who the site is for
From that understanding it infers the people the site actually serves. Take a hypothetical online shop selling linen clothing. Its visitors might include a first-time buyer unsure about sizing, a returning customer reordering a favourite, and someone hunting for the returns policy before they commit.
Each persona carries a context, a motivation, concerns, the evidence that suggested it, and a confidence level. Some will be high confidence. Some are marked speculative. Nobody has to write them by hand, though you can add, edit, merge or remove them.
Each persona then gets goals worth attempting: compare two products, check delivery costs, find the size guide, get in touch. Persona and goal together become a journey.
Step three: walk the journeys in a real browser
Product Reviewer drives a real browser along each journey, step by step, the way that persona would. It records what it sees at every step, so the investigation can be followed while it happens and explained afterwards.
Journeys can end in more than two ways. A journey might succeed, partly succeed, get blocked, hit a website error, or stop because it needs your authorisation. Each outcome is recorded as what it is.
A gate you can read
A real browser on a live site can do real damage. It could place an order, send a support request, or change someone's account. So before any action that changes state, Product Reviewer stops and classifies it: is it a submit, a purchase, a delete, an outside message?
What happens next is decided by an explicit rules engine, not by a model's judgement in the moment. The engine can allow the action, deny it, simulate it, stop just before it, or hand the decision to you. A model saying "this is safe" is not permission. That is the only version of this we think is safe to point at a live site.
And it is only for sites you are entitled to test: your own, or one you have written permission to investigate.
Step four: findings with the evidence attached
Findings are drawn from what the browser actually captured, not from a model's impression of a page. Every finding is stored with the screenshot and page capture it came from. Click it and you see exactly what the reviewer saw, at the step where it saw it.
A finding traces a straight line from the person to the problem:
- Persona
- Goal
- Journey
- Step
- Evidence
- Problem
- Impact
- Recommendation
Where the evidence is not strong enough to call something a fact, the finding is marked as an inference. We would rather tell you we are not sure than present a guess as a finding.
Step five: check the fix
A report that ends at "here is what is wrong" leaves the hard part to you. So Product Reviewer is designed to verify fixes too. When you mark a finding as ready, it re-runs the relevant journey against the criteria the original finding set, and reports one of several results: fixed, partly fixed, not fixed, regressed, or unable to verify, with fresh evidence either way. Monitoring is designed to keep watching so a fixed problem does not quietly return.
Honest about coverage
No investigation sees everything. An investigation stops when it reaches your budget, scope, depth or time limit, or when it runs out of useful branches to explore. It does not stop because it finished a checklist, and it does not pretend it covered what it did not.
So the investigation shows its coverage: which personas, goals and journeys were planned, which were completed, and which were blocked or need your input. "We checked the parts we could reach, and here is what we could not" is a more useful answer than a single score out of a hundred.
Where it is today
The investigation runtime is implemented end to end. One pipeline crawls a site, models who it serves, drives journeys in a real browser, evaluates what it captured, and stores evidence-backed findings with clickable screenshots. Product Reviewer is still in development, and we are opening it through early access.
