What a Website Audit Report Should Actually Tell You

I’ve read a lot of website audit reports, and most of them share a defect so common it’s almost the genre’s defining feature: they’re written to be impressive rather than to be used. Forty pages, a wall of charts, a hundred and thirty issues sorted by some internal metric, and at the end the reader knows one thing for certain — that they will do nothing. The report succeeded as a performance and failed as a tool. Nobody reads page thirty-one.

This happens for an understandable reason. Audit reports have historically been sales documents. An agency runs a scan, and the scan’s job is to justify the engagement, so more findings means more evidence that you need help. Volume is the point. But if you’re the site owner, and especially if you’re the one who has to fix things, volume is the enemy. What you need is not a catalog of everything that could conceivably be improved. What you need is to know what to do next, and why, in words you can act on. Everything else in the report exists to earn your trust in that answer.

So let me describe what I think a report owes you, because these convictions are what I built GazeSite around, and they’re worth stating independently of any tool.

First, every finding should be specific to your page. “Improve your headlines” is not a finding; it’s a horoscope. It applies to every site on earth, which means it says nothing about yours. A real finding quotes the actual headline, says what a first-time visitor will and won’t understand from it, and proposes concrete replacement language. The test is simple: could this sentence have been written without looking at your site? If yes, delete it. Generic advice is padding wearing the costume of analysis.

Second, every problem should arrive with its remedy attached. This is the rule I feel most strongly about. A report that says “your images lack alt text” has told you a fact. A report that says which images, what the alt text should roughly say, and why it matters — screen readers have nothing to announce, and search engines one less signal about the page — has told you a task. The distance between a fact and a task is where most reports die. In GazeSite every finding is a four-part unit: a score, a one-line headline, the issue explained, and a prescribed remedy. The remedy isn’t a bonus. It’s the reason the finding is allowed to exist. If we can’t say what to do about something, we haven’t finished analyzing it.

Third, scores should be honest, which mostly means they should be capable of being bad. There’s a temptation, in any tool that grades its own customers, to cluster everything between eighty and ninety-five so everyone feels good and nobody churns. But a score you can’t fail is flattery with a number on it. The value of a score is that it directs attention — accessibility is fine, clarity is in trouble, start there — and it can only direct attention if the range is real. A report that grades six areas separately and shows you one of them well below the others has done something a single blended number never can: it has told you where to look.

Fourth, the report should tell you what evidence it looked at. A verdict is only as good as its inputs. Was this the desktop rendering or mobile? The screenshot or the HTML underneath? A finding that says “your call to action is below the fold on mobile” should come from an actual mobile screenshot, and you should be able to see it — see your own site the way the auditor saw it. Findings you can verify with your own eyes build the trust that findings you can’t verify spend.

Fifth, plain language, and this one is less obvious than it sounds. Audit reports are usually read by the person who owns the site, not the person who built it, and jargon converts a report from something the owner can act on into something they must forward. Every finding written as “insufficient contrast ratio per WCAG AA” instead of “this gray text is hard to read on the white background, and here are the colors that fix it” adds one more human to the chain between problem and fix. Chains like that are where fixes go to die.

And last: a report should be small enough to finish. Not small because problems were hidden, but small because findings were ranked, merged, and the trivia left out. Ten findings you read beat a hundred and thirty you don’t. The author of the report should have made the hard editorial choices, precisely so you don’t have to make them while less informed.

Here’s the compressed version, usable on any audit anyone hands you, mine included. For each finding, ask: is it about my site specifically, does it say what to do, can I see the evidence, do I understand it without a translator, and is the whole thing short enough that I’ll actually finish it? A report that passes is a tool. A report that fails is a performance — and you were the audience, not the beneficiary.