Screenshot + HTML: Why We Audit Both, Not Just One

A web page is two documents pretending to be one. There’s the picture — what a browser paints on the screen — and there’s the HTML underneath it. Most people assume these are the same thing in different formats, the way a PDF and its printout are the same. They aren’t. They diverge constantly, and the divergence is where a surprising number of a site’s real problems live.

When I built GazeSite, the earliest design decision was that every audit would capture both: a screenshot of the rendered page, on desktop and on mobile, and the HTML the browser actually ended up with. Not because two artifacts are better than one in some vague thoroughness sense, but because each one can lie in ways only the other can catch.

Start with what the screenshot knows that the HTML doesn’t. HTML tells you a heading exists; it doesn’t tell you the heading renders in pale gray on white at a size nobody over forty can read. It doesn’t tell you that two elements overlap at phone width, or that the cookie banner covers the signup button, or that the hero image failed to load and left a gray void where your value proposition was supposed to be. Layout, contrast, visual hierarchy, what’s above the fold — these are properties of the painted result, not the source. You can write a program that parses markup all day and never learn that the page, as experienced, is a mess. Contrast is the cleanest example: the accessibility guidelines set minimum ratios between text and its background, and whether you meet them depends on the final computed colors after every stylesheet has had its say. The markup alone is silent on the matter.

Now the other direction: what the HTML knows that the screenshot doesn’t. A screenshot can look perfect while the page beneath it is hostile to everyone who doesn’t browse with a mouse and good eyesight. Images without alt text look identical to images with it. A clickable div styled to look like a button is indistinguishable, in pixels, from a real button — but a real button can be focused with the keyboard and announced by a screen reader, and the div can’t, unless someone did extra work they almost never did. The title tag and meta description, which decide how the page appears in search results, are invisible in any screenshot. So is the heading outline that search engines and assistive technology use to understand the page’s structure. So is the sea of half-broken markup a visual check will never surface. A page’s looks and its bones are audited by different instruments.

The really interesting findings, though, come from neither document alone but from the gap between them. Text that exists in the HTML but is rendered invisible — sometimes leftover cruft, sometimes an old trick that search engines treat as deception. A heading that reads as the page’s main message in the markup but is visually buried below three decorative sections. A page whose HTML arrives nearly empty because everything is assembled by JavaScript afterward, which is precisely why we capture the HTML from a real browser after the page has settled, rather than fetching the raw source the way a naive crawler would. What the server sends and what the visitor sees can be almost unrelated, and you want to audit what’s real.

And then there’s the mobile capture, which is really a third witness. The same HTML produces a different picture at phone width, and the differences are rarely neutral. Modern search ranking looks at the mobile rendering first, and so do most of your actual visitors. A site that has only ever been reviewed on a designer’s monitor has, in a meaningful sense, never been reviewed.

There’s a general lesson here that took me a while to articulate. When you audit anything — a website, a codebase, a company — you should collect evidence from independent vantage points, because problems hide in exactly the places a single vantage point can’t see. Anyone who has debugged software knows the feeling: the logs say one thing, the behavior says another, and the bug lives in the contradiction. A screenshot-only review is a design critique. An HTML-only review is a lint pass. Both are useful and both are routinely done, which is why so many sites have passed both and are still quietly broken.

So each of GazeSite’s six reviewers gets the full bundle — both screenshots and the settled HTML — and writes findings against whichever evidence is relevant, each with a score, an issue, and a prescribed remedy. The clarity reviewer mostly reads the picture. The SEO and technical reviewers mostly read the markup. The accessibility reviewer needs both at once, because accessibility is exactly the discipline of making the picture and the bones tell the same story.

That’s the standard I’d suggest even if you never use my tool. Whatever process reviews your site, ask one question of it: does it look at the picture, the source, or both? If the answer is one or the other, you’re only ever seeing half the page.