What to check before you believe the agent built it

The agent says it is done. That claim and the state of the site are two different facts, and the distance between them is where every bad launch comes from. What follows is not a general argument for being careful. It is the specific list of things we have been wrong about, each one found the expensive way, on sites that had already passed a review.

Measurement is not looking

We once passed a heading through every check we had. Its computed font size was right, its bounding box was right, its scroll width did not exceed its container, and it was visibly broken in a real browser. The tool doing the measuring was not compositing the page the way a browser does, so transforms, filters and stacking all reported values that were true in the object model and false on screen. The rule we work to now is that any visual claim needs a render from a real browser engine, and any numeric claim needs a measurement. Neither substitutes for the other.

The standard overflow check compares an element's scroll width to its client width. That finds content wider than its own box. It does not find content that fits its own box and is cut off by an ancestor with overflow: hidden, which is the far more common failure in a generated layout. The element reports healthy numbers while half of it is invisible. Checking for it means walking up the ancestor chain and intersecting the rectangles, not asking the element about itself.

The build is the artefact, not the source

Reading the source tells you what was written. It does not tell you what ships. A class that two rules define at the same specificity resolves to whichever comes last in the stylesheet, so an edit to the first one is dead code that looks correct in the file. A design token composed at runtime from a variable name never makes it into the compiled stylesheet at all, and nothing warns you. Every verification we trust now runs against the built output.

Text an agent cannot find with grep

Searching the source for a string is how an agent checks whether copy changed, and in a component framework it fails routinely. A sentence split across two JSX expressions, a label built from a template literal, or a string in a translation file keyed by something unrelated all return no match while the text is plainly on the page. An agent that greps, finds nothing and concludes the text is absent will then helpfully add a second copy of it.

Assets replaced in place

An image optimiser that caches by source path will keep serving the old file after you overwrite it, through a full rebuild and a server restart, because the path did not change. It fails partially: of six images replaced in one pass, some update and some do not, which presents as a layout bug rather than a cache one. Either clear the optimiser cache or change the filename, and verify by reading the rendered image's natural dimensions rather than the attributes, because the attributes come from your data and will look right either way.

Right to left is a layout, not a translation

If the site has an Arabic or Hebrew locale, mirroring it exposes decisions nobody made: icon direction, number formatting, where a visually hidden element scrolls the page to, and type scales that were tuned for Latin and are too small for Arabic at the same nominal size. A translated page that renders without errors has not been checked. The specifics are in what RTL testing tools miss and the build-level version in building an Arabic site that is not a mirrored English one.

What a usable verification loop looks like

• Verify against the built output, never the source. The source is a statement of intent.
• Render in a real browser engine for anything visual, and look at the image rather than describing it.
• Prefer a check that fails the build over a check somebody runs. The difference between teams that ship these bugs and teams that do not is never diligence.
• When a result surprises you, suspect the instrument before the site. Half of our worst reports were broken checks, not broken pages.

Packaging this as something you run rather than something you remember is what skills are for, and the search-specific half of the list is in the SEO checklist for a site an agent built.

Animation that is paused, not broken

Scroll-triggered animation is the most common false alarm we see. A headless browser with a frozen frame loop never advances the timeline, so every animated element reports its start state and the page looks like the animation is dead. It is not dead, it is paused, and the check that distinguishes them is to drive the timeline directly rather than scroll and hope. The same applies to anything gated on an intersection observer, which does not fire in a viewport that never moved.

Read the response, not the status code

A page returning 200 proves the route resolved. It does not prove the page has content, that the content is the right content, or that the framework did not quietly render an error boundary with a 200. Checking a deploy by walking a URL list and counting 200s is the check that feels thorough and catches almost nothing. Assert on something only the correct page would contain, which costs one extra line and is the difference between a smoke test and a comforting ritual.

Accessibility is a verification problem too

Generated markup is confidently structured and frequently wrong in the same few ways: a clickable div where a button belongs, an input with a visual label that is not associated with it, a heading level skipped because the size looked right. None of these are visible and all of them are detectable. The WAI-ARIA Authoring Practices describe what the correct pattern is for each component, which matters because an agent will often produce a plausible imitation of a widget rather than the widget.

An automated pass catches the mechanical half of this. It does not catch a focus order that makes no sense or a modal that does not trap focus, which need a keyboard and two minutes. Related reading on why the shortcut does not work is in why an accessibility overlay is not a fix.

Let the tool state its own limits

Every check should say what it did not check. A render at one viewport width is not a responsive check. A link crawl that followed only internal links says nothing about external ones. A build that passed proves the types compile. We write the limitation into the output of each check, because the failure mode is not a check that returns the wrong answer, it is a check that returns a narrow true answer which somebody reads as a broad one.

Where to get the authoritative answer

Every check above is only as good as the definition behind it, and for the measurable ones the definition is published. Page speed is the clearest case: the thresholds for Core Web Vitals are fixed and assessed on real visits, Lighthouse states plainly that it is a lab tool, and PageSpeed Insights shows field and lab side by side so you can watch them disagree. For anything you want to assert about rendered output rather than source, a real browser driver such as Playwright gives you a check you can commit, which is the difference between a verification and an impression.

The two companion pieces take this further in opposite directions. The hooks that gate a website repository turns these checks into something that runs without being remembered, and Core Web Vitals on an agent-built site covers the one class of defect that none of the checks on this page can see, because it is invisible once the page has finished settling.