What a UX Audit Actually Involves, Step by Step

"Audit" gets used loosely in web design — sometimes it means a genuine, structured review, and sometimes it means someone scrolled through your homepage once and gave you three opinions. I want to be specific about what an actual UX audit involves, because the difference between the two determines whether the redesign that follows fixes real problems or just rearranges the same ones.

I ran this exact process on my own site recently, so I'll walk through it using that as the example.

Step 1: Go page by page.

The audit doesn't start with an overall impression. It starts with a literal walk-through of every page a visitor could land on — homepage, about, services, blog, contact — checked individually. Overall impressions are useful at the end, as a summary.

At the start, they cause you to miss specific, fixable things because you're reacting to the whole rather than examining the parts.

For each page, I'm asking the same set of questions: what is a first-time visitor supposed to understand by the time they leave this page, and does the page actually deliver that. Not "does it look nice" — does it do its job.

Step 2: Check for broken and stale things first

Before evaluating anything subjective, I check for objectively broken things. Links that 404. Icons that don't render. Forms that don't submit. Images that don't load.

These are the easiest problems to find and the most damaging to leave, because a visitor doesn't distinguish between "this business has bad UX judgment" and "this business didn't notice their footer icon has been broken for months."

Both read as the same thing: nobody's paying attention.

On my own site, this step is where I found a broken newsletter icon in the footer. Small, in isolation. But multiplied by however many visitors scrolled to the footer looking for a way to subscribe and found a dead icon instead, it's a specific, countable cost — not a vague aesthetic quibble.

Stale content gets checked at the same stage: calls-to-action referencing an old offer, testimonials for a service you no longer provide, a "recent posts" section that hasn't updated in over a year. These aren't broken in a technical sense, but they're broken in a trust sense — they tell a visitor the site isn't actively maintained, which raises quiet doubts about whether the business behind it is either.

Step 3: Evaluate proof and trust signals specifically

Separately from the general walk-through, I do a dedicated pass just for trust signals: testimonials, case studies, credentials, specific results.

I check not just whether they exist, but whether they're actually functioning — are the photos rendering, is the attribution specific enough to be believable, is there enough of it to matter, or is it one vague quote sitting alone on an otherwise proof-free page.

My own audit turned up testimonial photos that weren't rendering correctly — present in the code, invisible on the page. That's worse than having no testimonials at all in one specific way: an empty gap where an image should be looks more broken than an absent section would have.

A missing feature reads as "not yet built."
A broken one reads as "not maintained."

Step 4: Evaluate the above-the-fold section on its own

Because above-the-fold carries so much weight — it's the only guaranteed real estate every visitor sees — it gets its own dedicated check, separate from the rest of the page.

Is the hero image or headline doing a specific job, or is it decorative. Would a stranger, seeing only this section and nothing else, understand roughly what the business does and who it's for.

My own hero image failed this test: generic enough that it could have belonged to any consultant in any industry, doing no actual work for the page.

Step 5: Check the blog for cadence, not just quality

A blog gets evaluated differently from the rest of the site, because its problems are often about frequency and recency rather than the quality of any individual post.

A thin blog — a handful of posts, no consistent schedule — signals inactivity even if every post that exists is well-written.

This step isn't asking "are these good posts," it's asking "does this look like an active, ongoing practice or a project that was abandoned after a strong start."

Step 6: Write everything down before proposing a single fix

This is the discipline that separates a real audit from an opinion session: every finding gets written down as a plain factual statement before any solution gets discussed.

"Footer newsletter icon doesn't render."
"Hero image is generic stock photography."
"Blog has published four times in eighteen months.
" Not "the footer needs work" — specific, checkable statements.

The reason this matters: the moment you start solving problem one, your attention shifts into fix-it mode, and fix-it mode makes you rush past problems two through five with a less careful eye.

A complete list, gathered first, means the redesign that follows addresses everything that's actually wrong — not just whatever was most obvious or most recently complained about.

How long this actually takes, and what it takes to do it

For a typical small business or personal-brand site — five to ten pages, one blog — a proper audit like this takes a few focused hours, not a few minutes and not a few weeks.

That's worth stating plainly, because the two failure modes on either side are both common.

Rushing it to under an hour means you're back to a vibe-based scroll-through wearing an audit's name.

Stretching it into a multi-week engagement usually means scope has crept in from "find the problems" into "start solving them mid-review," which defeats the purpose of gathering the full list first.

The tools involved are less important than the discipline. A link checker to catch broken URLs quickly rather than clicking every one by hand. Viewing the site on an actual phone, not just a resized browser window, because phone browsers and rendering engines behave differently in ways a desktop simulation misses.

And a simple running document — a plain list, not a formatted report — because formatting an audit nicely before it's finished tempts you to treat early findings as more final than they are.

A note on what an audit is not measuring

It's worth being clear about the boundary here too.

An audit like this isn't a technical performance review — it's not measuring server response times or checking for security vulnerabilities, though a broken site can have both those problems as well. It's specifically a UX and trust review: does this site, as a human visitor experiences it, communicate what it needs to and hold up under scrutiny.

If deeper technical issues turn up along the way, they get flagged, but they're not what this particular process is built to catch.

What comes out the other end

A finished audit isn't a redesign plan.

It's a factual inventory: what's broken, what's stale, what's structurally weak, what's missing proof, and where the blog stands on cadence.

That inventory becomes the brief for every decision that follows — which is exactly why it has to come first, and why it has to be thorough rather than quick.

If your last "redesign" started with someone's opinion about your colour palette rather than a walk-through like this one, there's a reasonable chance it fixed what was visible and missed what was actually costing you trust.