Website UX Audit: Find the Friction That Stops Visitors

To run a website UX audit, start by listing what your visitors are trying to do and where they come in. Pick a few key tasks, then check whether a visitor can finish each one. Along the way, look at first-screen clarity, navigation, forms, and mobile use, log the friction you actually saw with evidence, and fix by severity before frequency.

A good audit has less to do with opinions and more to do with watching what happens when someone tries to get something done on your site. This guide walks through how we'd do it, in an order that keeps the evidence honest.

What is a website UX audit, and what isn't it?

A visitor comes to your site to do one thing, like book a call, and leaves without doing it. A website UX audit is a structured check on why that happens: whether visitors can find what they need, finish what they came to do, and trust the page enough to act. Design plays a part, but the audit covers more than a visual critique. It's also different from an accessibility evaluation, an SEO audit, a performance test, an analytics review, or research with representative users, even though evidence from each of those can feed into it.

An expert inspection applies well-known principles and records what the interface actually does. Watching real participants records what they do and say when nobody coaches them, and our website usability testing guide has a script for those sessions. Those are different kinds of evidence, so keep them apart. Either way, the goal stays task-centered. Does the site help, or get in the way of, someone trying to find information, complete a form, or make a decision?

Where should a UX audit start?

Start with the visitor's main goals and the doors they're likely to walk in through, before you look at any single page. Someone arriving from search might land on a service page, while an existing customer might begin on support. Then write down a handful of important tasks, such as "find pricing and understand what's included," "book a consultation," or "find support contact information." Success means finishing the task with the right information. Nobody's handing out prizes for hitting a magic number of clicks.

Say a prospective buyer (made up) wants to know whether a product connects to their CRM. The integration details are split between a feature page and a help article that nothing links to. No single page is broken, and yet the visitor can't confidently finish the task. The finding should name that failed task and the path you watched, rather than announce a universal rule about navigation.

How do you review first-screen comprehension and information scent?

At each entry point, ask whether a visitor can tell what's being offered, who it's for, what to do next, and where the limits are. Navigation labels and links should carry what's called information scent (our website navigation best practices guide goes deeper on menus). That just means words that let someone predict what's on the other side before they click.

Try it on an unfamiliar person and see whether they can pick a sensible route without coaching. The advice I gave in Build the Damn Thing was to get feedback from "someone who didn't lovingly sit through your 4th grade clarinet recital." People who know you already know what you meant. A new visitor only has the page. As you watch, write down every backtrack, every pair of labels that contradict each other, and every dead end.

How do you test forms and recovery?

Decide what should happen before you submit anything, then submit controlled dummy data and see whether it did. For each form you're allowed to test, check for labels that stay put, fields that earn their place, specific error messages, a sensible keyboard order, a way to cancel, failed requests, retries, and the confirmation state. A friendly success banner doesn't prove the request was saved, so when you're authorized, look for the resulting reference or the controlled record itself. Please don't submit live payments, contact real people, or create production records without permission.

Take a made-up appointment booking. A visitor picks a service and a time, mistypes their email, fixes it, and submits. The page shows a confirmation, but after a refresh there's no appointment reference anywhere. What you observed is the missing reference after those recorded actions. A database failure is only a guess at the cause until someone with deeper access confirms it.

Why check mobile, keyboard, and zoom basics?

Because layout, overlays, navigation, and input all behave differently as space shrinks, whatever your traffic mix looks like. Test at phone widths, zoom the text, move through the page with the keyboard, look for visible focus, and make sure no control is hidden or covered. These checks are useful, and they're also limited. They don't establish accessibility compliance, and they don't replace evaluation with disabled users.

How do you separate observation from preference?

Stick to what you can point at. "The button color feels dated" is a preference. "The button says Download but opens a request form" is a mismatch anyone can see. For each finding, record the page, the action, what you expected, what happened, your evidence, the impact, a recommendation, and how you'll retest. A good recommendation fixes the consequence you saw and leaves unrelated behavior alone.

In what order should you weigh severity and frequency?

Severity comes first, then frequency. A privacy exposure, a wrong charge, lost work, or a blocked main task can outrank frequent minor friction, even if it only showed up once. After that, use how often a problem happens and how many people it reaches to order issues of similar weight. Analytics can show aggregate patterns, but it can't tell you why a visitor struggled. Watching one person shows one attempt, and on its own that can't tell you how common the problem is. You'll usually want a bit of both.

How do you keep performance evidence honest?

Say which kind of data you used, and never make up numbers. Lab tests give repeatable diagnostics under conditions you set up, while field data describes what real visits experienced. web.dev's Core Web Vitals overview explains the difference between the two. A slow dependency can cause visible waiting, so connect that diagnosis to what it did to the task, rather than treating a metric as if it were the visitor's experience.

How do you keep a reproducible friction log?

Keep one row per finding, with enough detail that someone else could repeat it. The two rows below are invented to show the format. Neither is an actual customer finding.

In a real log, attach only the evidence someone would need to reproduce the finding, and leave out personal information. After a change, repeat the same entry point, action, viewport, and expected result. Until that check is done, the status stays Not retested.

How do UX, SEO, and research audits differ?

Each one asks a different question. A UX audit asks whether visitors can complete tasks. An SEO audit asks whether search systems can find and make sense of your content. Analytics records the events you configured and the aggregate behavior around them. Usability research watches representative people and can turn up needs an expert inspection misses. They work well together, but none of them gets to borrow certainty from another one's evidence.

This work pairs naturally with a landing page audit when one conversion page is the worry, and with a Lovable app audit for a broader public web-app review.

How do you turn findings into a decision?

Group findings by task and rank them by what they cost the visitor. Fix privacy, payment, data-loss, and main-path problems before decorative consistency. Give each one an owner, the evidence it needs, and a retest status. If you never watched representative users, say so plainly. If there's no field performance data, say that too.

If you'd like the public-page part done for you, Is My App Slop gives you a scored audit with the fixes to tackle first.

A useful website UX audit doesn't promise compliance, and it doesn't speak for every visitor. It records what an expert or participant really saw, keeps that apart from preference and guesswork, and hands the owner one concrete thing to do, one that can be repeated after the fix.