A findings list nobody finishes is a report.
The fix queue is a worklist, not a report: findings are prioritised, tied to a page, and close only when an automated re-check confirms the fix landed.
The fix queue is a worklist, not a report: findings are prioritised, tied to a page, and close only when an automated re-check confirms the fix landed.
The fix queue is the part of Praised that turns findings into finished work: a crawl-wide audit and per-crawler access checks feed a prioritised list of specific changes, and each item closes only when an automated re-check confirms the page actually changed. It exists because the failure mode of every visibility tool is the same — a long list of issues, a busy team, and no way to tell six weeks later which ones were really fixed. Work arrives from what the site looks like to a machine, and from what the engines are actually saying. Both land in the same list, ranked together.
A crawl of your site, each page scored 0–100 against a fixed rubric: structured data, answer-first structure, entity grounding, metadata and crawlability. Site-level issues are reported separately from page-level ones, because "no Organization schema anywhere" is one fix, not four hundred.
Client-rendered pages are flagged rather than scored near-zero — if the content only exists after JavaScript runs, that is the finding.
Per-crawler verdicts for the agents that matter — GPTBot, ClaudeBot, PerplexityBot, Google-Extended and the rest. robots.txt is parsed per user-agent, then live requests are sent with those agents to catch the blocks robots.txt cannot see.
A CDN rule that quietly 403s one crawler is invisible from the inside and fatal to grounded answers. This is how you find it.
Every finding becomes an item with a state. There are only four, and the last one is not reached by a human clicking "done".
If the re-check fails, the item reopens with what was found instead. That single rule is what keeps the queue honest as it ages.
A fix pack bundles related items — every page missing the same schema type, say — so a repeated change is one piece of work rather than forty.
The queue is ordered by severity and by reach: a critical finding on a page that several lost prompts depend on outranks a minor finding on a page nothing points at. The reasoning is shown, and you can override it.
Alongside the ordering sits a projected score — what the audit total becomes if the top items ship. It is an estimate of the audit score, clearly labelled as one, and never an estimate of your visibility. Whether visibility moved is a question only a re-measurement can answer.
The same rubric we publish and hold our own site to. Every check names the failing element and the change that clears it.
| Category | Examples | Why an engine cares |
|---|---|---|
| Structured data | JSON-LD present and valid, a primary entity type, FAQ markup, dateModified | It is how a machine works out what kind of thing the page is about |
| Answer-first | One H1, a definition-led opening, scannable lists and tables, enough server-rendered text | Models quote openings; an unliftable page is not quoted |
| Entity grounding | Organization sameAs links, alias lines, claims without unverifiable superlatives | Disambiguation — engines discount what they cannot pin to an entity |
| Metadata | Title, description length, canonical, link-preview tags, image alt text | The cheap signals every retrieval layer still reads first |
| Crawlability | Indexable, reachable, robots allows the AI agents, llms.txt present | None of the above matters if the fetch never succeeds |
We run this gate against praised.co on every change, and a new page that scores below 85 does not ship. It would be a strange thing to sell otherwise.
The crawler access check is free and needs no account. The full site audit and the queue come with the app.