Roast My Website: Turn a Landing Page Critique Into One Useful Change
An evidence-first way to use a website or landing page roast: verify the observation, locate the decision bottleneck and revise the real section instead of chasing a score.
A “roast my website” request is useful when it produces an inspectable critique and a specific hypothesis. It is not a usability study or a conversion experiment. The best next step is to verify the observation on the actual page, identify the affected visitor decision and make one accurate, focused revision.
If you want a landing page roast, begin with a public URL, the intended audience and the next step the page asks visitors to take. Without that context, an automated critic may reward a generic design pattern that does not fit your product.
Replace a score with a decision question
A low score for “clarity” is not enough to tell you what to change. Ask what the visitor cannot determine: the product category, intended user, output, setup requirements, price scope or meaning of the CTA. Those questions lead to different interventions.
Consider a hypothetical operations tool whose hero says “Unlock intelligent work.” A critic might recommend a dramatic redesign. The underlying problem may be simpler: the page never says it creates a reviewable weekly summary. A truthful clarification in the existing hero could address the uncertainty without replacing the layout.
Do not assume all long pages should be shortened or all subtle buttons made brighter. A B2B page may need substantial detail. The test is whether the relevant information supports the decision and can be found, not whether the page matches a critic's favorite template.
Verify every criticism against the page
A useful observation is inspectable: the CTA does not state whether it opens a sales call, or the mobile layout clips an input. A claim such as “users don't trust you” is an interpretation until supported by appropriate evidence.
Check whether the criticism applies to the actual viewport and current page. Do not redesign a section because an automated review saw a missing asset, stale content or an incomplete capture. Keep technical defects separate from messaging concerns.
Accessibility also needs more than a roast. W3C explains that evaluation draws on appropriate tools and expertise; no single automated result establishes full accessibility. Use a suitable accessibility evaluation process rather than a critic's visual judgment. 1
Turn the roast into an evidence-linked action
Hypothetical examples of different criticism types.
| Criticism | What to verify | Possible next action |
|---|---|---|
| The headline is vague | Can a reader name the product and output? | Clarify the existing hero |
| The CTA is confusing | What does clicking actually initiate? | Describe the real next step |
| The page feels slow | Which loading or interaction issue exists? | Investigate performance |
| There is not enough trust | Which concrete question remains unanswered? | Add verified information near the decision |
Choose one bottleneck rather than ten cosmetic fixes
Prioritize a problem that blocks an important next decision. A missing explanation of data access may matter more than decorative spacing. An incorrect product promise may matter more than visual polish. Do not equate the critic's confidence with the issue's impact.
Write the intervention in concrete terms: “clarify that the output is a draft reviewed by a manager in the current hero.” State the evidence, affected context and validation needed. Avoid “make the page modern” because it has no clear stopping point.
Add a section only when necessary information is genuinely missing. If you add one, match the current page's design and use verified facts. Never manufacture customer logos, endorsements, security certifications or performance claims to satisfy a trust critique.
Use Cairo as a critique-to-revision workspace
Cairo explores public pages with segmented synthetic visitors and presents simulated journeys. You can inspect a recommended change and apply it to a copy of the actual section, preserving the original. This makes the proposed intervention reviewable instead of leaving it as generic advice.
The revision is not a live deployment. Simulated feedback is not observed customer behavior, and a simulated comparison is not a guaranteed conversion result. Explore a public page in Cairo and keep the decision you want to investigate explicit.
For a simple messaging issue, use the claim-and-evidence matrix. For delivery problems, follow the landing-page diagnostic sequence before debating persuasion.
Validate the result without chasing a higher roast score
Check that the revision is accurate, that it appears in the right section and that it answers the question you identified. Then use human task research or appropriate live measurement for consequential claims. Improving an automated score is not itself evidence of improved customer outcomes.
Performance and usability remain distinct. Google's Core Web Vitals guidance addresses loading, interaction and stability, not whether the offer is persuasive. Keep that boundary when reporting a technical improvement. 2
Website roast questions
Can a landing page roast predict conversions?
Not by itself. It produces a critique or generated hypothesis, not a measurement of real visitor outcomes.
Should I implement every suggestion?
No. Verify the observation, assess relevance and prioritize one evidence-linked intervention. Discard advice that relies on missing facts or generic preferences.
What should I provide with the URL?
The intended audience, the next decision and any factual constraints on the product claim. Do not share private credentials or sensitive customer material for a public-page critique.