How to Make Claude Check Its Own Work on a Website

The short version

The open-ended version fails for a reason, and it is not laziness on the model's part. Two papers are worth knowing about here. Jie Huang and co-authors tested models asked to correct their own reasoning with no outside signal and found the corrected answers were frequently worse than the originals (Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024). Gladys Tyen and co-authors then pinned down where the failure sits: models repair a mistake competently once told where it is, and are bad at finding it unaided (LLMs cannot find reasoning errors, but can correct them given the error location).

That result transfers to a website build almost directly. A model that just wrote four hundred lines of HTML is the worst available judge of whether those four hundred lines contain a duplicate id, because nothing in the request told it to go looking. Supply the looking. The checklist is how you do that, and the screenshot is how you do it for anything visual.

Why "how does this look?" returns nothing

A question with no possible wrong answer produces description, not review. Ask how the hero section looks and you get a summary of the hero section, phrased approvingly, usually restating the intent the model inferred from your earlier messages. Nothing in that exchange could have come back negative, which is the tell.

A real check is falsifiable. It names a condition that is either met or not met, and the answer can be no. Compare the two shapes:

Produces prose: "Does the hero look good on mobile?" Produces a finding: "At 390 pixels wide, does any element extend past the right edge of the viewport? If yes, name the element and the selector."

Second rule for the same turn: no edits. If the model is allowed to fix things while it grades, it stops grading after the first fix and starts narrating a rewrite. Say it explicitly, in the review message, every time. The shape of the request matters as much here as it does when you are asking for the page in the first place.

Sort the checks into three piles

Which pile a check belongs to decides what you have to hand over with it. Getting this wrong is why review sessions go in circles: people paste a screenshot to ask about something that lives in the markup, or ask about spacing while the model is looking at nothing but code.

Pile one, checks the file answers. Internal links pointing at a path that does not exist. A missing, duplicated or over-long meta description. Two elements with the same id. Heading order jumping from h1 to h3. Images with no alt text. A form with no action attribute. Placeholder copy that survived into the final draft, the Lorem paragraph, the 555 phone number, Your Company Name. A canonical tag still pointing at the example domain. These are the cheapest findings on the list and the ones humans miss most reliably.

Pile two, checks that need a picture. Horizontal overflow at phone width. A button smaller than a thumb. Body text too light against white. One card in a row taller than its neighbours. Lines of text running past about seventy-five characters. What sits above the fold before anyone scrolls. None of this is reliably derivable from CSS, so a screenshot is not optional.

Pile three, checks it cannot make. Whether the offer is worth buying. Whether the price is right. Whether the copy sounds like a person, which is a separate problem with its own fixes. Whether the contact form delivers mail. A model given a static image cannot submit a form, and a model given your pricing cannot tell you the number is too low.

Write the checklist once and keep it

Improvised review questions drift. You ask about contrast on Monday and spacing on Tuesday, and three rounds later you have no idea whether the page got better or the questions got easier. Write the list down once as a file, then paste the same list every round.

Each line should state a pass condition, not a topic. Contrast is a topic. "Body text is 16 pixels or larger and no lighter than #595959 on a white background" is a pass condition. The difference is whether the model has something to test against or merely something to talk about.

A workable starter list for a one-page site runs about ten items: no horizontal scroll at 390 pixels, every internal link resolves, one h1 only, meta description present and under 155 characters, every image has alt text, the primary button is at least 44 pixels tall, no placeholder text anywhere, body copy at 16 pixels minimum, the form has an action and named fields, and the page title differs from the h1. Add your own as you find them. Every bug you ship once becomes a line on the list.

Then tell it what to return. "One line per check: the number, PASS or FAIL, and for every FAIL the element and the reason in under fifteen words. No fixes, no summary, no preamble." Rigid output is what makes two runs comparable. Keep the file in project knowledge so it is present without being pasted, alongside whatever design rules you already hand it.

Screenshots it can actually use

Claude reads images you put in the chat, and that is the whole of its access to your rendered page. It did not open the browser, it does not know the viewport width, it cannot scroll, and it sees nothing outside the frame you captured. Four habits follow from that.

State the width in pixels. An image of a narrow page could be a phone, a resized window, or a tablet in portrait, and the judgment differs for each. Capture the full page rather than the part you suspect, because a crop invites a verdict on a fragment. Send one screenshot per message; two in the same turn produces a comparison instead of two reviews. And describe what the element is supposed to do rather than what you think is wrong with it, or you will get your own hypothesis back with supporting detail.

Some things no screenshot shows. Hover and focus states. Scroll behaviour. A web font that silently fell back on a visitor's machine. A video that failed to load on a slow connection. An image that is sharp on your display and soft on a retina phone. One image is one moment in one browser on one machine, and the review is only ever as wide as that.

Grade, then fix, then grade again

Keep the two activities in separate messages. A model that has just edited a file is reviewing its own decision from thirty seconds ago, and it grades that decision kindly. Ask for the verdict first, read it yourself, decide which failures matter, and only then ask for the repair.

One fix per turn. A message listing six fixes comes back as a rewritten page, and a rewritten page needs the full review again from zero. Narrow repairs stay auditable: you can look at the diff and see what moved.

After each fix, take a fresh screenshot and re-run the entire list, not the item that failed. Fixes break neighbours. Widening a button to clear the tap-target check is exactly the kind of change that pushes a row into horizontal overflow, and the only way that shows up is running check one again. Models that hold a long file well make this cheaper, which is part of why the tool choice matters for anything past a single screen.

Where the loop ends

Stop on two consecutive clean passes, or when the remaining failures are judgment calls you have looked at and disagree with. Three or four rounds of this on a normal page is typical. If round five is still turning up new structural problems, the file has probably grown past what the model holds reliably in one piece and wants splitting rather than more review.

What the loop never catches is worth being honest about. It will not tell you the page is boring. It will not flag a price that is wrong for your market, or a headline that describes a product nobody asked for. It will not notice that your name is misspelled the same way in every instance. It cannot confirm the form delivered mail, because nothing it has access to can press submit. Those remain yours, and the cheapest version of that work is opening the live URL on your own phone and trying to do the thing a visitor would do. If you want the mechanical half of it as a standing procedure, the scored self-audit covers an existing site the same way.

The useful reframing is small. Self-review is not the model forming an opinion about its work, it is the model executing a test you wrote. Supply the test and the thing to test against, forbid repairs in the grading turn, and the output stops being reassurance and starts being a list of defects with locations attached. That is the part worth having, and it is the part that gets skipped.

Build the checklist on your first page and it serves every page after. Mine started at four items and got long the way all such lists do, one shipped bug at a time. The build itself is a short job by comparison.

Related: What to Do When Claude's Code Doesn't Work

Common questions

Can Claude see a screenshot of my website?

Yes. Paste or upload the image into the chat and it reads it like any other input. What it cannot do in a normal chat window is take the screenshot itself, scroll the page, or see anything outside the frame you captured, so grab the full page rather than a crop and say in the message how wide the viewport was in pixels.

Why does Claude say my page looks good when it clearly does not?

Because the question had no wrong answer available. With no stated pass condition to test, the model describes what it sees and aligns with the intent it picked up from your earlier messages. Replace the open question with a written check that names a measurable condition, and a FAIL becomes a possible response.

Can Claude test whether my contact form actually works?

Not end to end. It can read the markup and tell you if the action attribute, method or field names are missing or wrong, which catches a fair share of broken forms before they go live. Submitting the form is beyond it, so the only real test is filling it in yourself on the live URL and confirming the message arrives.

How many review rounds should a page take?

Three or four is normal for a single page. The first pass clears mechanical defects, the second catches what the first repair broke, and by the third the remaining failures are usually taste rather than bugs. New structural problems still appearing in round five is a sign the file should be split into smaller pieces.