Website UX audit checklist: find friction in your key journeys

Define the task and what success means

“Improve the website” is too broad for a useful first audit. Choose a task such as finding pricing, booking a demo, submitting a ticket, or finishing onboarding. Name the starting point and the successful outcome. Include the visitor’s likely constraints, such as using a phone or arriving without product knowledge.

Write down the current completion measure if you have one. If you do not, define how you will recognize a completed task before making changes. Keep a record of the version and device you reviewed so later comparisons have context.

The website UX audit checklist

Use these checks while completing the task. Mark each item as working, uncertain, or blocked, then attach evidence to any issue. This is a practical starting point, not a formal accessibility conformance assessment.

• Entry page: does the headline explain the offer and make the next step clear?
• Navigation: do labels match what a visitor would look for?
• Calls to action: is the main action visible and distinguishable from secondary links?
• Forms: are labels, required fields, instructions, and error messages understandable?
• Recovery: can someone correct a mistake without losing their work?
• Mobile: do controls remain reachable when banners, menus, and the keyboard are open?
• Keyboard use: can you reach and activate controls, see focus, and dismiss overlays?
• Loading and errors: does the page explain what is happening and what to do next?
• Trust: are important conditions and costs available before a commitment?
• Confirmation: does success tell the visitor what happens next?

Compare your walkthrough with real behavior

Your own walkthrough reveals problems you can reproduce, but familiarity with the site can hide confusing details. Review recordings of the same task and read related feedback. Look for repeated obstacles, and keep successful journeys in the review so you can compare what differed.

An illustrative finding: the audit reviewer can submit a form, but mobile recordings show people repeatedly returning to the same field. A support request mentions an unexpected date format. Together, those observations suggest testing clearer format instructions and an error next to the field. They do not establish the size of the issue by themselves.

Write findings so someone can fix them

Capture the expected outcome, observed behavior, evidence, and next action. Avoid labels such as “bad UX” that leave the team to rediscover the problem.

Prioritize blockers before polish

Start with failures that prevent the task, such as a broken control or inaccessible form. Then consider how often you observed a problem, which visitors it affects, and how confident you are in the explanation. A high-impact issue with uncertain evidence may need research before implementation.

Choose a small release with a named owner and a verification method for each change. A repaired button can be tested directly. A new navigation label needs observation or a usability task to establish whether people understand it.

Repeat the journey after release

Run the original checklist on the changed page and review new journeys for the same task. Compare completion measures over a suitable period, accounting for shifts in traffic sources or devices. A change in the overall rate alone does not prove your fix caused it.

Keep the issue log as a record of what you learned. Over time, this gives the team concrete evidence for decisions and a short list of remaining questions instead of a recurring redesign debate.