Scenario · Something looks broken
Something's wrong with this page
“This page isn't right.” No symptom named, or one too vague to act on.
"This page isn't right," with no further detail, is one of the most common tickets and the hardest to start on, because there's no symptom to reproduce yet. This runs the broad, cheap checks immediately rather than waiting on a reply — a full page audit, what the page is actually built on, its links and images, a scan for anything that shouldn't be there — which answers most of these tickets before the clarifying reply even arrives, and routes the rest straight to whichever specific procedure actually fits.
What to ask for
See it work
A real run of Page audit (all-in-one):
Page audit (all-in-one) · page-audit-all-in-one — https://toolkit-tests.pages.dev/suite/kitchen-sink.html
running accessibility-a11y · performance-core-web-vitals · screenshots across desktop,iphone-17 …
FAIL — https://toolkit-tests.pages.dev/suite/kitchen-sink.html
accessibility-a11y FAIL
performance-core-web-vitals FAIL
screenshots captured
report: ./out/page-audit-all-in-one-page-audit-all-in-one.html
text: ./out/page-audit-all-in-one-page-audit-all-in-one.txt
cost: ~<n> token(s) of raw tool output (<n>KB)The captured report, exactly as a run hands it to a client —open the full report ↗
The fourth-busiest kind of ticket, and the only one whose defining feature is that the symptom is missing. The instinct is to ask the client what they mean. Ask, but run the cheap checks while you wait — most of the time the answer is already visible.
- Ask what they saw, and where. Which browser, phone or desktop, and what they expected instead. Then continue without waiting: half these tickets are answered before the reply arrives.
- Run the all-in-one page audit. Accessibility, performance and a visual capture in one pass, with one verdict. This is the cheapest broad look at a single URL and it catches the common causes outright — a page that is slow, a layout that collapses, an element nobody can reach.
- Check what the page is running. The stack inspection tells you whether it is WordPress, which builder produced the page, and what caching sits in front of it. A “the page is wrong” report is often a cache serving a version the client already had changed.
- Check the links and images. Broken images are the single most common thing a client describes as “the page looks wrong”, because a missing image reads as a layout fault rather than a 404.
- Rule out the ugly one. If the complaint mentions text they do not recognise, run the injected-content scan before anything else — content that should not be there is a containment problem, not a page fault, and it has its own procedure.
- Route to the specific scenario and stop working this one. Layout collapse, a vanished embed, a gallery not showing, links going nowhere, a form not submitting, the site being down — each has its own procedure with its own verification. This scenario’s job is to find out which, not to fix it.
- If every check passes, say so with the reports attached and ask again. A clean audit is real information: it narrows the problem to something only a person who knows the content can see.
Why a triage scenario earns its place
Without one, a vague ticket gets whatever check the person picking it up happens to think of first, and the variance between two people handling the same ticket is enormous. The value here is not the checks — they all existed already — it is that the same four run every time, in the same order, before anyone starts guessing.
What this does not cover
What the client meant. This is a triage entry point: it runs the broad checks, reads what they return, and hands off to the specific procedure that matches. It cannot find a defect nobody can see from the outside — a wrong price, an out-of-date surgeon bio, a form that submits but sends to the wrong inbox all pass every check here and need a human who knows what the page should say.