Auditing a Site You Built vs. One You Inherited
The site you built and the site you inherited fail your audit in opposite ways: one hides problems behind your pride, the other behind your ignorance.
There are two situations in which you sit down to seriously evaluate a website. Either you built it, or you inherited it — a new job, an acquisition, a client engagement, a predecessor who left. These feel like the same task. They are opposite tasks, and I’ve come to think most audit advice fails because it doesn’t say which situation it’s for.
When you audit a site you built, your problem is that you know too much. Every questionable decision on the page has a justification stored in your head, and your memory helpfully supplies it before your judgment can object. The confusing headline was A/B tested once, in 2024. The strange page structure exists because of a constraint that may or may not still hold. The audit degenerates into a tour of your own reasoning, and your reasoning approves of itself. Worse, you don’t distribute attention evenly. You linger on the parts you’re proud of and skim the parts you’re bored by, and the parts you’re bored by are usually the neglected ones — precisely where problems live. Auditing your own site is like proofreading your own writing: you read what you meant, not what’s there.
When you audit a site you inherited, your problem inverts: you know too little. You have fresh eyes — genuinely, the thing every creator wishes for — but no map. You can see that a page is strange but not whether the strangeness is load-bearing. Is that odd redirect chain a mistake, or does something depend on it? Are those three near-identical landing pages sloppy duplication, or a deliberate experiment someone forgot to end? The inherited site is full of what programmers call Chesterton’s fences: things you shouldn’t remove until you know why they were put up. And the person who knows why is gone, or was never asked to write it down. Your fresh eyes generate findings at a tremendous rate, and you can’t tell the real ones from the ones that would break something.
Notice the symmetry. The creator has context and no perception. The inheritor has perception and no context. A useful audit needs both, so each situation demands that you manufacture the half you’re missing — and the manufacturing techniques are completely different.
If you built the site, your job is to simulate ignorance, and you can’t do it by trying harder; knowledge doesn’t switch off. You need an external instrument that never had the knowledge. Show the site to someone new. Or point a tool at it that takes nothing on faith. This is the case GazeSite was originally built for — my own sites, my own blindness. It fetches the URL cold, renders it on desktop and mobile, and six focus-area reviewers grade what’s actually there, with no access to my justifications. The findings that sting most are the ones where I catch myself composing the rebuttal — “well, that’s because” — since a visitor never hears the because. For the creator, the discipline is to treat every explanation you’re tempted to give as evidence for the finding, not against it. If the page needs you standing next to it, the page is broken.
If you inherited the site, your job is the reverse: manufacture context before you act on your perceptions. The temptation is to start fixing immediately, because everything looks fixable and you’d like to make a mark. Resist it, briefly. First, write down your naive observations — all of them, fast, before familiarity sets in, because your fresh eyes are a wasting asset. Within weeks you will be a local too, unable to see what you can see today. An audit report generated on day one, whether by you with a notebook or by a tool with six reviewers, is a snapshot of a perspective you are about to permanently lose. Capture it. Then, separately, dig for context: old tickets, analytics history, whoever’s been around longest. Only where a naive observation survives contact with context does it graduate into a change you make. The inheritor’s discipline is the two-list system: what looks wrong, and what you’ve confirmed is wrong. Move items from the first list to the second deliberately, never assume they start there.
There’s one more difference, and it’s emotional rather than epistemic. Findings about a site you built feel like criticism of you, so the risk is defensiveness — explaining findings away. Findings about a site you inherited feel like criticism of your predecessor, so the risk is the opposite: accepting them too eagerly, because every flaw flatters you by comparison. Both distortions corrupt the audit, in opposite directions. The creator under-counts problems; the inheritor over-counts them, then burns trust fixing “problems” that were decisions.
The common cure is the same one for both: separate the observing from the judging. Let the observation be made by something without a stake — a stranger, a checklist, an automated reviewer that reports a score, an issue, and a suggested remedy without knowing whose ego is attached. Then do the judging yourself, with all your context, or all your freshness, whichever you happen to own. You’ll never have both. But if you know which one you’re missing, you know exactly what to go borrow.
More articles
The person least qualified to judge whether a tagline is clear is the person who wrote it.
Read →Design pages for the skimmer first and the reader second, because every reader starts as a skimmer.
Read →The least accessible parts of most sites are the custom widgets that replaced perfectly good native controls.
Read →