Skip to main content

​
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:

​
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:
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: 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.