Website UX audit: how to run one

A website UX audit is a structured review of how well a live site lets people do what they came to do, and where it gets in their way.

To audit a large site without testing every page, audit its page templates and its key journeys. Check usability, accessibility and performance in the same pass, keep what a tool can measure apart from what needs a person’s judgment, rank what you find, and close a finding only when a re-check no longer finds it.

Our UX audit checklist has the checks for each template, with how to run them.

What a UX audit is, and what it is not

A UX audit is an expert review: someone who knows usability and accessibility works through the site against its goals and against established principles, and writes down what fails, where, and how badly. It looks at the site as it is today, in a real browser, at the screen sizes people use.

It is not three other things it is often confused with:

• Usability testing. Watching real users try real tasks shows problems an expert does not predict, and it tells you why people struggle. An audit needs no recruiting, and it finds many problems before you put anyone in front of the site, but it does not replace testing. See heuristic evaluation, the expert method an audit builds on.
• An accessibility audit. A UX audit includes accessibility, because a barrier for a disabled visitor is a usability problem, but a formal accessibility audit against WCAG has its own method and its own report. See how a website accessibility audit works.
• A redesign. An audit says what is wrong and how to fix it, and leaves the fixes to you. Many of them are small changes to a template or a component.

The six steps

Step 1: set the goals and the key journeys

Start with what the site is for. A shop wants people to find a product and buy it; a council wants residents to find a service and apply; a software company wants visitors to understand the product and sign up. Write down two to five goals like these, in the visitor’s words: “find opening times”, “compare two plans”, “pay an invoice”.

Each goal is a journey through the site: the pages someone passes on the way and the decisions they make on each. List the steps of each key journey, so that the audit follows them end to end instead of stopping at the first page.

Analytics help here, but only as pointers. They show where people leave a journey, which pages they land on and which searches return nothing. They do not show why. A page with a high exit rate is a place to look, not a finding.

Step 2: scope by template, not by page

A large site can have thousands of URLs but only a few dozen templates: the home page, a category page, a product or article page, search results, a form, an account page. Every product page shares the product template’s layout, navigation and components, so a defect in the template is a defect on every product page.

So scope the audit by template:

1. Inventory the pages. Read the sitemaps and crawl the public links, and compare the two lists.
2. Group them into templates, by URL pattern and by page structure.
3. Choose a representative page of each template: the one most likely to break, such as the most complete instance or the one with the longest content.
4. Add the states a template can be in: empty search results, a form with errors, a signed-in page, a sold-out product.
5. Add the journeys from Step 1 as complete processes, every page from start to finish.

Our post on template-based UX auditing works through each of these, with a worked example. WCAG-EM, the accessibility evaluation methodology from the W3C’s Accessibility Guidelines Working Group, samples the same way: a structured sample of the common views, functionality and types of page, plus a random sample of 10 percent of that number, which should show nothing the structured sample missed. WCAG-EM 2, published on 23 July 2026, keeps that rule and extends the method from websites to apps and other digital products.

Step 3: check each template three ways

Some problems a tool can measure in the browser, some need an expert’s judgment, and some only show up when real people use the site. Plan for all three, and know which is which.

With a tool. An automated check in a real browser renders each page at several screen sizes, checks focus behaviour, and measures what can be measured: contrast, names and roles, layout, touch targets, broken links, performance. It is repeatable and it scales across templates. It cannot tell whether a label makes sense. We go through what automated UX testing can and cannot find, defect by defect.

By an expert. An expert reviews each template against usability principles. The best known are Jakob Nielsen’s ten heuristics, “broad rules of thumb and not specific usability guidelines”, from visibility of system status to help and documentation. Our UX audit checklist turns them into checks for each template. Review visual consistency in the same pass: whether the same component looks and behaves the same across templates. See UI audits of components and visual consistency.

Accessibility in the same pass. Check the WCAG 2.2 Level A and AA criteria on the same templates, with the same tool and the same reviewer, instead of in a separate project. Many accessibility failures are usability failures for everyone: a form error that does not say which field is wrong, or how to fix it, confuses every visitor, not only screen-reader users.

Performance. Core Web Vitals are Google’s measures of loading, responsiveness and visual stability. A page meets them when Largest Contentful Paint is within 2.5 seconds, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less, at the 75th percentile of real page loads, measured separately on mobile and desktop. A lab run in an audit approximates these, and shows Interaction to Next Paint only if it interacts with the page; only field data from real visitors shows the full picture.

With real users. For the key journeys, a small usability test, a handful of people trying the tasks from Step 1, shows which of the expert’s findings matter most and finds problems nobody predicted.

Step 4: rank by severity, then by reach

Rank by severity first. Severity is how badly a problem blocks someone who meets it. Jakob Nielsen’s scale runs from 0 to 4:

Nielsen’s rating combines frequency, impact and persistence. Here, rate severity on impact (how hard the problem is to get past) and persistence (whether it keeps bothering people once they know about it) only, and treat frequency separately, as reach. Reach is the second sort: among findings of equal severity, the one on the template with the most pages, or the most traffic, goes first. Have several people rate independently and take the mean: in Nielsen’s experience one evaluator’s ratings are too unreliable to trust, and the mean of three is “satisfactory for many practical purposes”.

An illustrative example, for a shop with four findings (the findings and page counts are invented):

The checkout trap comes first although it is on one page: nobody who meets it can finish. The product and category findings have the same severity, so the template with more pages goes first. The cosmetic finding on every page still comes last.

Step 5: write findings someone can act on

A finding is useful when the person who has to fix it can find it, fix it and check the fix without asking you. Write each one with:

• Where: the template, an example URL, the screen size, and the element.
• What happens: what the visitor tries to do and what stops them.
• Who it affects: everyone, phone users, keyboard users, screen-reader users.
• Evidence: a screenshot, the selector, a measurement, or the WCAG criterion it fails.
• Severity, and the template’s reach.
• The fix, in terms of the template or component, not the one page.
• How to check it is fixed: the measurement or the test that should now pass.

Group findings by template, so a team fixes each template once. Then say what you did not test: the templates outside the sample, the journeys you did not walk, the states you could not reach, such as signed-in pages without a test account. A report that hides its gaps reads as a clean bill of health it has not earned.

Step 6: fix at the template, then re-check

Fix a template-level defect in the template or the component, never on one page. Then re-check two pages: the representative page and one you did not test before. If the problem is gone from both, the fix most likely reached the whole template.

Close a finding only when a re-check no longer finds it, not when someone says it is fixed. Re-check measured findings with the same tool and the same settings, and judged findings with the same reviewer or the same task. Audit the key templates again after each significant release, because a new component or a content change can bring a closed finding back.

If you audit a single landing page rather than a site, the steps shrink but do not disappear. Our guide to auditing a landing page covers them.