A website UX audit — also called a usability audit — is a systematic, data- and test-driven evaluation of the user experience, aimed at identifying the changes with the biggest impact on conversion. The client receives two things: an analytical view showing where users abandon the path, and a backlog of recommendations with priorities and implementation cost estimates. It is not a designer's wish list; it is a diagnosis backed by evidence.
What to do in the first 48 hours after deciding to audit:
- Check the measurement setup in GA4: verify that key events (add to cart, sign-up, purchase) are recorded correctly and without duplicates.
- Pick one path to optimise — the checkout funnel or the sign-up form — and establish its current completion rate as the baseline.
- Define the audit's KPIs: conversion rate, drop-off rate at a specific step, time to purchase.
- Collect known problems and hypotheses from sales and customer support — the questions you get most often are the purest signal of what the site fails to say.
Scope and timing come later, at the brief stage: a quick heuristic review takes 2–5 days, a full audit one to four weeks — where you land in that range depends on the number of paths and on whether measurement needs repair before the work starts.
Key Takeaways
A website UX audit delivers measurable results only when it combines measurement verification, data analysis and user testing with a backlog of recommendations prioritised by conversion impact and implementation cost.
| Point | Details |
|---|---|
| Start with measurement | Verify GA4 events before diagnosing the interface — broken events lead to broken conclusions. UX metrics worth tracking: step completion, funnel drop-offs, time to purchase. |
| Combine methods | Data shows where the problem is, heuristics suggest why, user tests confirm the hypothesis. |
| Prioritise with ICE | Score every recommendation by impact, confidence and ease, so you start with the changes with the highest return. |
| Measure with a control group | Roll the change out to part of the pages or traffic, leave the rest unchanged, and compare the difference in trends for 4–6 weeks. |
| Session recordings need a legal basis | Whatever the tool, recording user behaviour in the EU requires consent and disclosure in the privacy policy. |
What should a full website UX audit include?
A complete usability review combines quantitative and qualitative work, and should end with an ordered backlog carrying priorities and implementation estimates. Below is the list of components a complete audit should cover.
Quantitative analysis
- Measurement verification: GA4 event correctness, no duplicates, correct device segmentation.
- Path and funnel analysis in GA4 Explorations: identifying the steps with the biggest drop-off.
- Session recordings and heatmaps (e.g. Microsoft Clarity or Hotjar): visual context for the numbers.
- Traffic segmentation: new vs returning, mobile vs desktop, traffic sources. Define the segments before the funnel analysis, not after — customer profiles built in marketing tools help here, for example the customer profile in automation systems.
Qualitative analysis
- User testing: 3–8 tasks performed by participants matching the customer profile.
- Heuristic review: usability assessment against Jakob Nielsen's ten heuristics or your own checklist. Nielsen Norman Group recommends 3–5 people evaluating independently — a single auditor catches only part of the problems, and beyond five the gains are small.
- Stakeholder interviews: collecting business context and hypotheses from the team.
Technical inspection
- Loading speed: Lighthouse and PageSpeed Insights for diagnosis, the Core Web Vitals report in Search Console for assessment. The three metrics are LCP under 2.5 s, INP under 200 ms and CLS under 0.1 — INP replaced FID in March 2024. Assessment relies on field data from the Chrome UX Report, not on a Lighthouse score, which is a lab measurement for finding causes, not for reporting.
- JavaScript errors: DevTools, Sentry or similar error monitoring.
- Responsiveness: tests on real mobile devices, not just the emulator.
- Accessibility: basic checks against WCAG 2.2, the W3C recommendation in force since October 2023 (contrast, form labels, keyboard navigation, focus visibility).
What belongs in the final report
Every observation should include: evidence (a screenshot or recording excerpt), a description of the problem, a recommended change, an implementation cost estimate and a priority. A report without these five elements is a list of problems, not a tool for action.
Additional conversion components
- Form analysis: fields causing abandonment, error messages, inline validation.
- Checkout path: number of steps, CTA consistency, payment error handling.
- Trust analysis: visibility of reviews, security certificates, return policy.
- Value proposition tests: does the homepage or landing page heading answer "why here, why now".
How does a UX audit run, step by step?
UX research on a site follows a proven order: data first, then heuristics, and user tests last to resolve ambiguity. Data shows where the problem is; heuristics suggest why; user tests confirm or refute the hypothesis.
Process stages
- Goal and KPI definition — establishing what the audit should measure and which metrics count as success.
- Measurement verification — checking GA4 events, tags and recording-tool configuration before any diagnosis. If events still need to be configured or repaired, the order of steps is covered in the guide to configuring GA4 events in Google Tag Manager.
- Quantitative analysis — path explorations, segmentation, identifying the steps with the biggest drop-off.
- Heuristic review — expert assessment of the interface against agreed criteria.
- User testing — observing real behaviour on key tasks.
- Organising observations — grouping problems, attaching evidence and priorities.
- Report and backlog — delivering a document ready to hand to the implementation team.
Deliverables
- Executive summary (2–4 pages): the most important problems and estimated conversion impact.
- Detailed backlog with evidence: every item carries a description, screenshot/recording, recommendation and priority.
- Recordings and screenshots file: the evidence base for the team.
- Implementation schedule: task order, owners, success metrics for comparison tests.
Indicative timeline and prioritisation
| Audit type | Turnaround | Scope |
|---|---|---|
| Quick heuristic review | 2–5 days | One path or landing page |
| Full site/store audit | 1–4 weeks | Funnels, user tests, technical checks |
The quick review ends with a prioritised report and works on a small budget, or when you need one path diagnosed before deciding on a wider scope. The full audit delivers the complete set from the list above — choose it before a redesign, or when abandonment is high and nobody knows what causes it.
Whether a full audit closes in a week or takes a month is decided by three things, not by site size: the number of paths in scope, the state of measurement (reconfiguring GA4 events can absorb the first week) and whether user tests need external recruitment or participants from the client's own base will do. A store with one funnel and correctly configured analytics can be audited in a week; a site with five funnels, multiple language variants and measurement in need of repair takes the full four.
For prioritising recommendations, ICE works well: you score every backlog item on three dimensions — conversion impact, confidence in the effect, and ease of implementation. The result is the product of the three values on a 1–10 scale. A change scoring ICE = 8 × 7 × 9 goes to the top of the queue even if it is not visually spectacular. RICE works the same way with a reach estimate added, useful on large sites with many user segments.
Two practical notes on scoring. Lower the confidence when you rely on a single data source or on "best practices" without your own observations — a recommendation backed by a session recording and a user test deserves a higher score than one derived from heuristics alone. Ease accounts for developer dependency: a task requiring a sprint scores lower than a copy change the marketing team can ship itself.
The backlog handed to the implementation team should name an owner and a success metric for every task. A sample entry: "Inline validation in the sign-up form — owner: frontend team — metric: sign-up step completion rate, measured 4–6 weeks after rollout against a control group". Without an owner and a metric, a backlog item is an observation, not a task.
Which tools matter and how to use GA4 Explorations?
Website UX testing tools fall into three groups: quantitative analytics, recordings and heatmaps, and user testing. The list below is a starting point, not a requirement — any tool that exports user paths and lets you watch a session is fit for this work.
- GA4 Explorations (path exploration): visualising behaviour sequences, identifying abandonment points.
- Microsoft Clarity: free session recordings and heatmaps, with form-field masking in settings.
- Hotjar: session recordings, heatmaps, on-site surveys.
- Lighthouse / PageSpeed Insights: performance and Core Web Vitals audits.
- Axe DevTools / WAVE: basic WCAG accessibility checks.
- Remote testing tools: participant recruitment and session moderation without a lab.
Session recordings and GDPR. Whatever tool you choose, recording user behaviour is personal data processing and requires a legal basis. The built-in field masking in Clarity and Hotjar limits the risk of leaking sensitive data, but does not release you from obtaining consent, disclosing in the privacy policy and signing a data processing agreement with the vendor. Treat privacy configuration as the first step of tool rollout, not an option to enable later.
How to use GA4 Explorations without the usual traps?
Path exploration in GA4 visualises behaviour sequences, supports open and closed modes and limits the report to a maximum of 10 steps, which affects how users are counted. Users only count when they perform the steps in the defined order, so a skipped step is not treated as abandonment but as non-qualification for the path.
A practical shortcut to a checkout exploration:
- Go to GA4 → Explore → Path exploration.
- Choose the closed mode if you are analysing a specific funnel (e.g. cart → shipping details → payment → confirmation).
- Limit the path to a maximum of 10 steps; more are not supported.
- Before interpreting results, confirm in DebugView that events on every step are recorded correctly.
- Break the path down by device — in the right-hand panel choose the Breakdown dimension → Device category; payment-step drop-off is often noticeably higher on mobile than on desktop. Mind this dimension's limitation: a user is assigned to the device on which they entered the path and stays in that bucket on all subsequent steps. Someone who browsed on a phone and paid on a computer counts as mobile at purchase too — in stores with frequent device switching this inflates mobile conversion and deflates desktop.
The usual traps: double-counted events (e.g. a purchase event firing twice through a tag error), no device breakdown, ignoring how skipped steps are counted, and confusing user counts with purchase counts. If the same user completes the path several times in the selected date range, Analytics records only the first sequence — the report shows how many users completed the path, not how many transactions there were. In a store with a high share of returning customers those two numbers diverge significantly. One broken event can make a working path look broken.
Which UX problems do audits find most often?
The question of how to improve a site's UX usually comes down to the four problem categories below. Knowing them upfront speeds up hypothesis-building and shortens the analysis. Two things covered separately are not problem categories but return in nearly every audit: CTA labels, because they are the single most frequent swap landing in the backlog, and the team's own assessment bias.
Form problems are the most common cause of abandonment at sign-up and checkout. Bad field labels, no inline validation (the error appears only after clicking "Submit"), unreadable error messages and too many required fields are the classic blockers. A user who once sees a red message with no explanation of what to fix often simply closes the tab.
Unoptimised paths mean too many steps, distractions in the form of unnecessary links, and inconsistent CTAs. If the product-page button says "Add to cart" and the next screen offers "Continue shopping" instead of "Go to checkout", the user loses track of their progress.
Technical problems hit trust directly. Slow loading, JavaScript errors blocking interactions and broken mobile responsiveness translate into higher bounce and lower task completion. Core Web Vitals are a good starting point here, but they do not replace tests on real devices.
Missing trust signals hurt online stores most. An invisible returns policy, no security certificate in a visible place, hidden delivery costs revealed only at checkout. A user who does not know the delivery cost before clicking "Buy now" abandons the cart.
CTA labels: six swaps to test
Inconsistent CTAs are usually fixed by one heuristic: the label should name the result of the click, not the demand placed on the user. The swaps below appear in audits most often, but treat them as hypotheses to verify, not ready-made answers — which version wins is decided by your audience and page context, not by a list of best practices.
| Instead of | Better | Why |
|---|---|---|
| "Sign up" before purchase | "Continue without an account" | Names the result and removes the fear that an account is a purchase requirement |
| "Submit" on a contact form | "Send enquiry — we reply within [X] h" | Says what happens after the click. Use a real time: an unkept promise costs more than none |
| "Next" at the shipping step | "Go to payment" | Keeps funnel orientation; "Next" says nothing about how many steps remain |
| "Place order" before the summary | "Go to summary" | Avoids implying irreversibility where there is none — otherwise users stop out of caution |
| "Download" for an email-gated asset | "Download PDF — no account needed" | Reveals the cost of the action before the click, not after |
| "More" under a product description | "See full specification" | A specific destination instead of a label that says nothing about where it leads |
These swaps are cheap to ship, which is why they usually score high on ICE — high ease at moderate impact beats costly changes with uncertain effect. Keep the confidence low, though, until you have your own data: these are recommendations derived from heuristics, not from observing your users. Roll each one out like any other backlog item — with a control group and the measurement described in the ROI section. Sometimes the longer, more descriptive label loses, because it wraps to two lines on a phone or sounds too informal for the industry.
Confirmation bias on the team's side
A separate problem category is not the interface but the way it is judged. Specialists assessing their own site often unconsciously read the data in line with their expectations. Confirmation bias makes us look for evidence of what we already believe instead of testing hypotheses. That is why an audit run by an external specialist, or built on structured methods (user tests, checklist-driven heuristics), produces more reliable results than an internal team review.
How much does a UX audit cost and what drives the price?
The price of a UX review depends on four main factors: the number of paths analysed, the range of methods, the number of devices and language variants, and whether measurement needs repair before the analysis proper.
Main price drivers
- Method scope: a heuristic review alone is cheaper than an audit combining heuristics, user tests and funnel analysis.
- Number of paths: auditing one checkout path is a different scope than analysing five separate funnels.
- Measurement repair: if GA4 needs reconfiguration before the audit, that is extra time and cost.
- Participant recruitment: user tests require recruiting people who match the customer profile.
- Documentation: a detailed backlog with recordings and priorities takes more work than a short report.
Indicative ranges on the Polish market
The figures below apply to the Polish market in 2026 and are net amounts. Treat them as a conversation starter, not a price list — the real quote depends on the number of paths and the state of measurement:
| Scope | Indicative cost | What you actually get |
|---|---|---|
| Automated scan / mini-audit | PLN 0–800 | A tool-generated report: Core Web Vitals, WCAG basics, meta tags. Shows symptoms, not causes |
| Heuristic review of one path | approx. PLN 500–1,500 | Expert assessment with a problem list and priorities, no user tests |
| Funnel audit with data analysis | approx. PLN 2,000–4,000 | Heuristics, GA4 explorations, session recordings, evidence-backed backlog. The most commonly ordered scope — the market average sits around PLN 3,000 |
| Full audit with user testing | approx. PLN 5,000–15,000 | All of the above plus recruitment and session moderation, an executive report, an implementation schedule |
| Measurement repair before the audit | approx. PLN 1,000–3,000 | GA4 event reconfiguration, duplicate removal, DebugView testing |
The market spread is wide: some agencies sell an automated scanner report under the name "UX audit", others a research sprint lasting weeks. The ranges above compile public price lists and comparison services as of August 2026, described in the sources at the end. Before comparing offers, check how many items from the list above are actually in scope — that is what explains the difference between PLN 800 and PLN 15,000.
If the audit is meant as the start of an ongoing engagement rather than a one-off, compare these amounts with the SEO pricing — in a subscription model, UX analysis is often part of the scope, not a separate invoice.
Two costs tend to be missed in quotes: participant recruitment for tests (honoraria plus coordination time) and the client-side developer time to implement the recommendations. An audit without reserved developer hours ends as a backlog nobody executes.
How to calculate the return
Tie every recommendation to a KPI: if the audit indicates that simplifying the sign-up form could raise the completion rate, design the measurement that will verify that effect. The strongest evidence is a controlled test — you roll the change out to part of the traffic or a subset of comparable pages, leave the rest unchanged, and compare the difference in trends for 4–6 weeks. Traffic can be split manually or with a dedicated platform; the differences between them, including GDPR compliance, are covered in the VWO vs Optimizely comparison. Without that link to a KPI, the audit remains a cost, not an investment.
An example audit: from diagnosis to decision
The scenario below is assembled from the problems that recur most often in e-commerce audits. It is not a description of a specific engagement — it shows the order of decisions and the way one method complements another. Actual results of our projects, with numbers, are in the portfolio section on the homepage.
Starting point: an online store with high abandonment at the account sign-up step. GA4 path exploration shows which step loses the largest share of users. Session recordings add the context the numbers lack — repeated clicks on the same field, backtracking, closing the tab.
Actions:
- Event verification: in DebugView you confirm that
begin_checkoutandadd_payment_infofire correctly. The typical finding at this stage is a double-counted event artificially inflating drop-off at one step. - User tests: five moderated sessions are usually enough to explain the cause. A frequent result: the password-field error message is unreadable on mobile and does not state the length requirements.
- Form simplification: removing the "Confirm password" field in favour of a show-password toggle, adding inline validation with a readable message.
- CTA fix: changing the button label from "Sign up" to "Continue without an account", with a note that an account can be created after the order. The label should say what happens after the click, not what it demands of the user — the same principle behind the inconsistent-CTA problem described above.
Measurement: you roll the changes out to half the traffic, keep the other half on the previous form as a control group, and compare the difference in trends for four to six weeks. Both groups must run in parallel — comparing the change against the previous month alone would mix seasonality into the result.
What follows from this:
- Measurement repair must precede interface diagnosis. A double-counted event can flag a working step as the problem.
- User tests answer the "why" that GA4 data cannot — which is the justification for the method order described above.
- A parallel control group is more reliable than a before/after comparison. Use before/after only when traffic does not allow a split — and then treat the result as an indication, not proof.
- The audit's ROI is the implementation cost compared against revenue from additional conversions over a quarter.
How AI SEO COMPANY approaches UX audits
A UX audit only makes sense when its findings reach the implementation team in a form ready to act on — not as a slide deck of problems with no repair plan. That is the difference between diagnosis and treatment.
AI SEO COMPANY's approach combines analytics with design: every recommendation is tied to a specific KPI and an implementation cost estimate, and the backlog is prioritised with ICE or RICE so the team knows where to start. Deliverables include an executive report, a detailed evidence-backed backlog (screenshots, recording excerpts), an implementation schedule and success metrics for measuring the effect.
We do not sell UX audits as a standalone service — a deliberate decision, because a report alone does not move the metrics. UX analysis enters our work at two moments, in both cases as part of a package, not a separate invoice:
- When taking over an existing site — at the start of SEO work, together with the SEO audit, within the monthly subscription. Both analyses draw on the same Search Console and Analytics data, so run in parallel they do not duplicate work, and findings from one adjust priorities in the other.
- When building a new site — as part of the design and build process, in a package covering the site and its SEO. There we do not diagnose existing faults — we design the path so they do not appear, then verify the assumptions with data after launch.
In both cases UX analysis is part of the monthly scope, not a line item. Which package covers which scope is shown in the pricing — the main differences are whether conversion optimisation is included and whether a new site is part of the deal.
In simple cases — one conversion path, measurement that needs no repair, test participants from the client's own base — we close the full analysis in a week. Four weeks is the timeline for sites with multiple funnels, language variants or measurement needing reconfiguration, not the default.
The consequence of this model is simple: user experience optimisation does not end at the report, and recommendations do not stay in a PDF, because the same team that writes them is responsible for implementing them and for the result. If all you want is a report to execute in-house, this model will not be your cheapest option — the table above shows what that service costs on the market detached from implementation.
When choosing an audit provider, check three things: report samples from previous projects (do they carry evidence and priorities, or just a list of problems), references from a similar industry, and whether the agency can name the specific KPIs the audit is meant to improve. An agency that does not ask about your KPIs at the first meeting will probably deliver a report that does not change your results.
AI SEO COMPANY specialises in conversion-optimised website design and pairs UX audits with implementation, which shortens the distance between diagnosis and effect. Results depend on the site's starting condition, traffic volume and how much of the backlog gets implemented — no agency can guarantee a conversion lift.
How to commission a UX audit and what to include in the brief
A good brief shortens the quoting time and raises the odds of an audit matched to your goals. An agency that receives a brief with specific KPIs and GA4 access can start within days instead of a week.
UX audit brief template (6 fields):
- Audit goal: what do you want to improve? (e.g. "reduce cart abandonment at the payment step by 15%")
- Traffic: average monthly sessions, mobile/desktop split, main traffic sources.
- Key paths: which funnels or pages should the audit cover?
- Expected deliverables: executive report, prioritised backlog, recordings, implementation schedule.
- Indicative budget: a range that lets the agency propose the right method scope.
- Contact and timing: decision-maker, preferred start date and implementation window.
Attach GA4 access to the brief (the "Viewer" role is enough at the quoting stage) and a list of known problems or hypotheses. If you already run a session-recording tool, include access to it as well — it lets the audit skip the first days otherwise spent on setup and data collection.
Contact AI SEO COMPANY through the agency website to send a brief or request a free analysis of your site's SEO and brand potential. A full UX analysis with tests and a backlog is included in the package, per the model described above. We usually reply to enquiries in under two hours, prepare an initial proposal within a day, and a full audit quote with the method scope in 2–3 working days from receiving a complete brief. The difference comes from the fact that quoting an audit requires a look at the measurement setup and traffic volume, not just a project description.
Sources
References useful when planning or commissioning a UX audit:
- GA4 Path exploration
- Confirmation bias — Wikipedia
- Nielsen Norman Group — the ten usability heuristics and the five-user rule in testing
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2, recommendation since October 2023
- Google Search Central — Core Web Vitals; INP replaced FID as a Core Web Vital in March 2024
- Price ranges: a compilation of public price lists of Polish agencies and comparison services, as of August 2026 — from approx. PLN 400 for a diagnostic audit to PLN 15,000–25,000 for a full research sprint
Last reviewed: August 2026. Core Web Vitals thresholds and the WCAG version reflect documentation as of that date.
Author
Filip Śliwa
SEO specialist at AI SEO COMPANY. Works on technical optimisation and search visibility strategy for B2B companies.
Related Articles
Convert More Customers: 5 Brand Storytelling Patterns
Five brand storytelling patterns, a four-pillar framework, and the metrics to test whether the story works — built for B2B and smaller companies.
Technical SEO Audit Checklist for Digital Marketers
Run a technical SEO audit that ends in a prioritized fix list: crawl, indexability, Core Web Vitals thresholds, and schema that still earns a result.
Dominate your market
Want to outpace your competition in search results? Leave us a message below and we will prepare a dedicated SEO strategy.
Consult Your Project