> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Page reviews — the critic on any URL > Review any landing page URL with Erdo's real conversion critic: typed defects with severity, the principle each one violates, the evidence in the captures, and the fix — plus what the page does well. # Page reviews — the critic on any URL Erdo builds landing pages against a body of conversion-rate knowledge, and grades its own builds with a dedicated critic — a fresh-context discriminator that reads the *rendered* page and reports the concrete ways it loses visitors. A page review points that same critic at any public URL. You hand it one or more landing pages — your own, a competitor's, an agency client's — and it returns typed findings: what each page does well, and where it leaks conversions, with the reasoning and the pixel evidence behind every claim. This is the same critic that grades Erdo's own pages, not a separate prompt that happens to look similar. It is grounded in the one shared conversion-rate corpus the page *builder* also builds against, so when that knowledge improves, the reviews improve with it — there is no second critic to keep in sync. ## What you get back A review returns one entry per URL, and each entry is structured, not prose: * **Context** — the critic's committed one-sentence reading of what the page is selling, to whom, and at what stage, inferred from the captures alone. Every finding is judged relative to this reading, because the right *form* of each principle is category-relative: a pre-construction residence cannot have resident reviews, and its third-party proof is a named developer track record, an independent certification mark, or press — not star ratings. Surfacing the reading lets you challenge the premise, not just the findings. * **Strengths** — what the page genuinely does well against the conversion principles (a clear outcome-headline, proof above the fold in the strongest form the category can truthfully possess, one strong repeated call-to-action). * **Defects** — each a claim you could defend to a skeptical client: * **issue** — what is wrong, naming the specific element. * **basis** — how strongly the violated principle is known, as a typed field: `measured_prior`, `replicated_finding`, or `craft_prior`. A *measured prior* cites a real experiment corpus with a number (headline priors are mined from 29,423 statistically confident pairwise outcomes across 11,915 real Upworthy A/B tests), a *replicated finding* has been observed repeatedly across published CRO practice, and a *craft prior* is stated as exactly that. The critic never invents a study or statistic: a justification is only ever as strong as it truthfully is. * **because** — the reasoning: the specific conversion principle the element violates and why it costs *this* page conversions, carrying the measured prior's number when there is one. * **evidence** — the one observation the claim hinges on: the element or quoted copy and **which viewport** it was seen at. Deliberately minimal — the captures accompany the report, so evidence exists to let you locate and falsify the observation, not to narrate the page. * **fix** — the minimal change the evidence entails, left empty when the evidence dictates no obvious one (the critic is a discriminator, not a designer). * **viewports** — the capture labels (`desktop-fold`, `desktop-full`, `mobile-fold`, `mobile-full`) where the defect is observable, declared by the critic. A UI uses them to place each finding next to the exact capture it cites, instead of guessing from the evidence text. * Each defect carries a **severity** — `high` (broken or the conversion path materially damaged), `medium` (noticeably weakens conversion), or `low` (minor polish). * **Captures** — the screenshots the critic actually judged the page from, one per viewport (`desktop-fold`, `desktop-full`, `mobile-fold`, `mobile-full`). Each carries a stable `bucket_key` and a signed `url` you can render directly. The signed URLs **expire after about an hour** and are minted fresh on every read, so treat them as short-lived — re-`GET` the review for new ones rather than storing them. The captures let a report reader see what the critic saw, and, paired with each defect's `viewports`, anchor the finding to the frame it came from. Because the findings are typed, you can render them, sort by severity, or feed them into your own scoring — you are not parsing a paragraph hoping the shape holds. ## The scores Every reviewed page carries a **conversion score** (0–100) with a four-way breakdown, and — when available — its real **Lighthouse** scores. The scores are arithmetic, not opinion. Each of the four principle families — **Clarity**, **Credibility**, **Action**, and **Friction** — starts at 100 and subtracts a fixed cost for each of its findings: 18 for a `high`, 8 for a `medium`, 3 for a `low`, floored at 5 (each defect names its family, and a family with no findings stays at 100). The page's headline score is the **mean of those four family scores** — the breakdown you see genuinely composes the number above it. That makes every score exactly explainable ("Credibility is 82 because of one high finding"), stable (identical findings always produce identical scores), and honest about movement: nothing changes unless the findings change. The review as a whole carries the rounded mean across its pages. The **`lighthouse`** block is the genuine article: Google Lighthouse category scores (`performance`, `accessibility`, `best_practices`, `seo`, each 0–100) measured through PageSpeed Insights on the mobile strategy. It appears when the measurement succeeds and is simply absent when it doesn't — a review never fabricates a Lighthouse number. ## Tracking a page over time `GET /v1/page-reviews` lists past reviews, newest first, as lean summaries — id, status, the reviewed URLs, and the scores, without the findings (those stay on the single-review read). Pass `url` to see every review that included one exact page, which is how you watch a page's score move as it changes: ```bash theme={null} # Every review that included this page, newest first curl "https://api.erdo.ai/v1/page-reviews?url=https://acme.com/landing&limit=50" \ -H "Authorization: Bearer $ERDO_TOKEN" ``` ```bash theme={null} # The same from the CLI erdo pages reviews --url https://acme.com/landing ``` ## How it sees the page The critic never guesses from source; it judges what a visitor actually sees. Each URL is captured at **four frames**: the fold and the full page, on desktop (1280×800) and on a phone (390×844). The **fold** shots — exactly what shows before scrolling — are where the most damaging, most-missed defects live: a headline clipped on mobile, a call-to-action pushed below the fold. The **full-page** shots walk the entire scroll height, so "there's nothing below the hero" is a finding grounded in the whole page, never an artifact of a capture that couldn't scroll. A defect that only appears at one width cites the viewport it was seen at, so you know whether it hits desktop, mobile, or both. Only public `http(s)` URLs are reviewed. A private address or a signed-in Erdo workspace URL is refused — the renderer is anonymous and would only capture a login screen; publish the page and pass its public URL instead. ## Declaring the goal and the audience The pixels tell the critic what the page *is*; they can't tell it what the campaign is *for* or *who* it is aimed at. So a review takes two optional declarations, each up to 500 characters: * **`goal`** — what the page is trying to achieve ("book qualified demos", "build launch awareness"). A page built for brand awareness and one built to book demos can look almost identical, yet the right findings differ — the awareness page is not defective for lacking a hard-conversion call-to-action, while the demo page lives or dies on form friction and CTA clarity. * **`audience`** — who the page targets, your ICP ("out-of-state condo investors buying pre-construction", "ops leads at 50–500-person logistics firms"). The critic then judges clarity, proof, and tone through *that* reader's eyes: what they must grasp in five seconds, which proof forms they weigh, what tone earns their trust. Without it the critic infers the audience from the page — and hedges when the page itself is ambiguous about who it's for. Declarations steer *how* the page is judged — never the evidence bar — and the critic still infers its own reading from the captures rather than taking your word for it. The most useful consequence: when the page's evident form **contradicts** a declaration — built as a hard funnel against an awareness goal, or speaking to a different reader than the audience you named — the critic reports that mismatch as a defect in its own right, at the severity it costs. Both declarations are echoed back on the review so a reader can see the frame the findings were judged against. ## Running a review A review is asynchronous: you submit URLs and get a **review id** back immediately, then read the findings once they land. A single unreachable URL never sinks the review — it reports its own reason while the other pages still return findings. Ask an agent in a thread: > "Review these three landing pages and tell me which one is weakest and why." Or run it directly: ```bash theme={null} # CLI — submit URLs and wait for the findings erdo pages review https://acme.com/lp-a https://acme.com/lp-b --wait # Submit and poll later by id erdo pages review https://acme.com/lp-a erdo pages review-result ``` ```bash theme={null} # REST — start a review (goal is optional) curl -X POST https://api.erdo.ai/v1/page-reviews \ -H "Authorization: Bearer $ERDO_TOKEN" \ -d '{"urls": ["https://acme.com/lp-a", "https://acme.com/lp-b"], "goal": "book qualified demos"}' # Read it back (status → ready, then the typed findings) curl https://api.erdo.ai/v1/page-reviews/ \ -H "Authorization: Bearer $ERDO_TOKEN" ``` The MCP tools are `erdo_review_pages` (start) and `erdo_get_page_review` (read). All three surfaces return the review id immediately; the status moves `pending → capturing → reviewing → ready` (or `failed` if not one page could be captured). ## Where it fits A page review judges *one page at a time* — its strengths and defects in isolation. When you want to know which of several variants is likely to *win*, run the [persona panel](/persona-panel): it ranks a field of variants by predicted conversion. The two compose naturally — the critic tells you what to fix on each page, the panel tells you which page to bet on — and both read the page the same way, from rendered captures rather than source.