UX Audit Checklist: 25 Things to Check Before Launching a Website

A website can look finished and still feel difficult to use.

This happens often during the final stage of a project. The homepage looks polished, the client has approved the design, the development team has fixed the obvious bugs, and everyone is ready to launch. Then someone tries the site on a phone, submits a form, uses the navigation with one hand, or searches for a basic piece of information and finds problems that were invisible in the design review.

A pre-launch UX audit catches those problems before real users do.

After working across website design, UI systems, responsive layouts, forms, content structure, and development handoffs, I have found that the final UX issues are rarely dramatic. They are usually small points of friction repeated across several screens. This checklist covers 25 things worth checking before launch, with a focus on practical decisions rather than another generic usability scorecard.

Check whether the website has a clear purpose

The first part of a UX audit is not visual. It is about understanding what the website is supposed to accomplish.

A visitor should not need to study the interface to figure out what the business does, who it serves, or what they can do next.

1. Can a first-time visitor understand the website quickly?

Open the homepage without explaining the project to yourself.

Ask:

• What does this company or product offer?
• Who is it for?
• What problem does it solve?
• What should I do next?

A strong homepage usually answers those questions through the headline, supporting copy, navigation, imagery, and primary call to action.

One useful test is the five-second test. Show the page to someone who has not worked on the project for five seconds, then hide it and ask what they remember.

You are not testing whether they liked the design. You are testing whether the page communicated its purpose.

If internal project language appears on the website but ordinary customers would not use those terms, rewrite it.

2. Is there one obvious primary action?

Many websites have too many competing calls to action.

A service company might display:

• Get Started
• Book a Call
• View Services
• Download Brochure
• Contact Us
• Request a Quote

None of these is necessarily wrong. The problem appears when they all receive the same visual emphasis.

A visitor should be able to identify the most important next step.

This does not mean every page needs one button. It means the hierarchy should reflect the user’s likely task.

For example, a service landing page may make “Request a Quote” the primary action while keeping “View Services” as a secondary route.

The UX audit question is simple:

If I had to choose one action for this page, which one would it be?

If the answer changes depending on who is reviewing the page, the hierarchy probably needs work.

3. Does every major page have a clear job?

A website often accumulates pages because someone asks for them during the project.

That can produce pages such as:

• About
• Company
• Our Story
• Why Us
• Who We Are

which may all contain similar information.

Review every important page and write its purpose in one sentence.

For example:

“This page helps potential customers understand our industrial products and request a quotation.”

If you cannot describe the purpose clearly, the page may need to be merged, rewritten, or removed.

A smaller website with clear page roles is usually easier to use than a larger website filled with overlapping content.

Audit navigation, information architecture and page flow

Navigation is where a polished interface can quickly become frustrating.

Users do not arrive with your sitemap in their heads. They arrive with a goal.

4. Can users find the important pages without guessing?

Review the primary navigation.

Check:

• Are the labels familiar?
• Are important pages easy to reach?
• Are similar items grouped logically?
• Are dropdowns actually necessary?
• Does the navigation work on mobile?
• Can users tell where they are?

Use labels that describe the destination.

“Solutions” may sound polished, but “Services” might be clearer if the page contains services.

Likewise, “Resources” can mean almost anything. If it contains case studies and guides, the structure should make that clear.

The navigation should reflect how users think about the content, not how the company is organized internally.

5. Can users tell where they are?

A user who lands directly on a service page from Google should not have to work out where that page sits within the website.

Useful orientation signals include:

• Clear page headings
• Active navigation states
• Breadcrumbs where appropriate
• Descriptive URLs
• Consistent page layouts

Breadcrumbs are especially useful for websites with deeper information architecture, such as ecommerce stores, documentation sites, directories, and large service websites.

They are not mandatory for every small website.

The question is whether the site’s structure remains understandable when someone enters from somewhere other than the homepage.

6. Test common journeys from beginning to end

Do not audit pages only as isolated screens.

Test complete journeys.

For a service website:

Homepage → Service → Case Study → Contact → Form → Confirmation

For ecommerce:

Homepage → Category → Product → Cart → Checkout → Confirmation

For a school website:

Homepage → Admissions → Course Information → Enquiry → Form → Confirmation

Watch for points where the user has to stop and think.

A common UX mistake is fixing each page individually while ignoring the transition between pages. A button may look correct on one screen but send users somewhere unexpected.

Quick journey test

Choose three important tasks and perform each without using internal knowledge.

Record:

• Where you start
• What you expect to happen
• What actually happens
• Where you hesitate
• Whether the next step is obvious

Those hesitation points are often more valuable than another round of visual polishing.

Review content, hierarchy and calls to action

UX is not just interaction design. Words, headings, labels, and content order directly affect how people use an interface.

7. Can users scan the page instead of reading every word?

Most visitors do not read a website from top to bottom on the first visit.

They scan.

That means your content hierarchy needs to work visually.

Look for:

• Clear H1
• Descriptive H2 headings
• Short paragraphs
• Useful bullet lists
• Strong information hierarchy
• Visible key facts
• Adequate spacing between sections

A page can contain excellent copy and still have poor UX if everything appears as one large block of text.

For long service or product pages, use headings that communicate information rather than decorative phrases.

“Built for Better Performance” sounds attractive but tells the user little.

“Industrial Water Pumps for High-Pressure Applications” provides more context.

8. Are calls to action specific?

Generic buttons are one of the easiest things to improve during a UX audit.

Compare “Learn More” with “View Pricing” or “See Our Web Design Services”.

The more specific label reduces uncertainty.

This becomes particularly important when several buttons appear on the same page.

A user should be able to predict what happens after clicking.

If a button says “Submit,” consider whether something more specific such as “Send Enquiry” or “Request a Quote” better describes the action.

9. Does the content answer the user’s practical questions?

Before launch, read important pages as if you were a prospective customer.

For a service:

• What exactly do they provide?
• Who is it for?
• How does the process work?
• What does it cost, if appropriate?
• How long does it take?
• What happens next?
• Why should I trust this company?

For a product:

• What is it?
• Who uses it?
• What does it do?
• What are the specifications?
• How do I buy it?
• What support is available?

A visually impressive page that leaves basic questions unanswered is still a UX problem.

Test forms, feedback and error handling

Forms deserve their own audit because they are where many business websites lose conversions.

A form that looks perfect in Figma can behave badly in the browser.

10. Are form fields actually necessary?

Every additional field creates another decision or typing task.

Ask why each field exists.

If the sales team only needs:

• Name
• Email
• Phone
• Requirement

then adding company size, job title, city, budget, preferred date, industry, and ten other fields may reduce completion without providing enough value in return.

There are cases where detailed qualification is necessary. The point is to make every field earn its place.

11. Do labels remain visible?

Placeholder text should not have to carry the entire meaning of a form field.

For example, “Enter your email” is useful as an example, but a persistent label such as “Email address” makes the form easier to understand after the field is populated.

This is especially important for longer forms and users who rely on assistive technologies.

12. Are validation messages useful?

A message such as “Invalid input” does not help much.

A better message explains the problem and what to do next:

Enter a valid email address, such as name@example.com.

Good validation should also appear close to the relevant field.

Do not make users scroll to the top of a long form to discover that one field is wrong.

13. What happens after submission?

Submit the form yourself.

Do not stop when the button changes.

Check:

• Is there a success message?
• Is it obvious that the submission worked?
• Does the user know what happens next?
• Is an email confirmation sent when appropriate?
• Can the user continue browsing?
• Does the page prevent duplicate submissions?

A vague success message creates uncertainty.

A useful confirmation might explain that the enquiry was received and provide an expected response time if the business has a real service-level expectation.

Test responsive design, accessibility and real devices

A website that works on a designer’s desktop monitor is not finished.

Responsive UX needs to be tested at actual sizes and with real interaction.

14. Check mobile navigation with one hand

Open the site on a phone.

Try common tasks without zooming:

• Open navigation
• Find a service
• Tap a CTA
• Open an accordion
• Submit a form
• Close a popup
• Return to the previous page

Watch for tiny controls, awkward overlays, menus that cover content, and buttons that sit too close together.

A mobile layout should not feel like a desktop design squeezed into a narrow screen.

Sometimes the best mobile solution is a different interaction pattern rather than simply reducing the desktop layout.

15. Check text size, contrast and focus states

Accessibility is part of UX quality, not a separate decoration added at the end.

Check:

• Text is readable
• Important text has sufficient contrast
• Links are distinguishable
• Keyboard focus is visible
• Buttons have clear states
• Form controls have labels
• Images with meaningful information have useful alternative text

The Web Content Accessibility Guidelines provide testable criteria for areas such as contrast, keyboard accessibility, focus, labels, and text alternatives. WCAG 2.2 is the current W3C Recommendation.

You do not need to turn every website audit into a full accessibility certification. But basic accessibility checks should happen before launch.

16. Test keyboard navigation

Put the mouse aside.

Use:

• Tab
• Shift + Tab
• Enter
• Space
• Arrow keys where appropriate
• Escape for dismissible overlays

Can you reach the main navigation?

Can you open and close menus?

Can you submit a form?

Can you see where focus is?

If the interface becomes confusing without a mouse, that is a real usability issue.

Keyboard testing is also valuable because it exposes interaction problems that visual inspection often misses.

17. Test zoom and text expansion

Increase browser zoom.

Try 125%, 150%, and 200%.

Look for:

• Text overlapping images
• Navigation breaking
• Buttons disappearing
• Horizontal scrolling
• Fixed elements covering content
• Cards becoming unreadable

Responsive layouts should be tested beyond the designer’s preferred viewport.

Audit performance, visual stability and launch details

The final category covers the technical details users experience directly.

18. Check Core Web Vitals

Google’s Core Web Vitals currently focus on:

Metric	Measures	Good threshold
LCP	Loading performance	2.5 seconds or less
INP	Interaction responsiveness	200 ms or less
CLS	Visual stability	0.1 or less

These are assessed using real-user data at the 75th percentile when field data is available.

Do not treat these numbers as the entire definition of UX.

A page can pass Core Web Vitals and still have confusing navigation. A page can also have a temporary performance issue while delivering an otherwise excellent experience.

Use the metrics to identify performance problems, then investigate the actual causes.

19. Check image sizes and loading behaviour

Open the browser’s network tools or use a performance testing tool.

Look for unnecessarily large:

• Hero images
• Background images
• Product images
• Logos
• Decorative graphics

Check whether below-the-fold images are being loaded unnecessarily early.

Also check whether the main visual content appears quickly enough.

In design reviews, I often see images exported at huge dimensions because “we can optimize them later.” That later step frequently gets forgotten.

Image optimization is much easier when it becomes part of the publishing workflow rather than a cleanup project after launch.

20. Check layout shifts

Load important pages on a slower connection.

Watch for content moving while the page loads.

Common causes include:

• Images without reserved dimensions
• Ads
• Web fonts
• Embedded videos
• Dynamic banners
• Late-loading content

A user trying to tap a button that suddenly moves is experiencing a genuine interaction problem.

This is why visual stability matters. Performance is not only about making the page appear quickly. It is also about making it behave predictably.

21. Check links, redirects and 404 pages

Click the important links manually.

Then check them systematically.

Look for:

• Broken internal links
• Incorrect URLs
• Old page links
• Wrong redirects
• External links that no longer work
• Buttons pointing to the wrong page

Also open a deliberately invalid URL.

Does the 404 page help the user recover?

A useful 404 page should offer routes back into the site, such as the homepage, search, or important sections.

22. Check browser and device compatibility

Test the website in the browsers your audience actually uses.

At minimum, check current versions of:

• Chrome
• Safari
• Edge
• Firefox

Also test common mobile environments.

You are not looking for pixel-perfect equality across every browser. You are checking whether the core experience works.

Pay particular attention to:

• Navigation
• Forms
• Sticky elements
• Animations
• Video
• Font rendering
• Modals
• Dropdowns

23. Check metadata and social sharing

Before launch, verify:

• Page title
• Meta description
• Canonical URL
• Open Graph image
• Social title
• Social description
• Favicon
• Correct author information where applicable

Then paste the page URL into the platforms where the business plans to share content.

Check whether the preview shows the correct image and description.

This is a small task, but broken social previews make a finished website look unfinished.

24. Check analytics and conversion tracking

A website launch without measurement is difficult to improve.

Verify that analytics is actually receiving data.

Then test important events such as:

• Form submissions
• Phone clicks
• Email clicks
• WhatsApp clicks
• Downloads
• Important CTA clicks
• Purchases where applicable

Do not track every click just because the analytics platform allows it.

Track actions connected to actual business or user goals.

A useful event should help answer a question.

For example, “How many visitors who viewed the services page requested a quotation?” is more useful than “How many times did someone click this decorative icon?”

25. Do a final fresh-eyes audit

This is the final test I recommend before launch.

Give the website to someone who was not involved in designing or developing it.

Do not explain the navigation.

Give them three tasks.

For example:

1. Find a specific service.
2. Find out how to contact the company.
3. Submit an enquiry.

Watch silently.

Do not correct them when they hesitate.

If they ask, “Where should I click?” that is useful evidence.

If several people make the same mistake, the problem is probably in the interface rather than the users.

The 15-minute final launch pass

Before pressing the launch button, check:

• Content: Is everything accurate and current?
• Navigation: Can users find important pages?
• Mobile: Can common tasks be completed comfortably?
• Forms: Can users submit them and understand errors?
• Accessibility: Can the site be used with keyboard navigation?
• Performance: Are major pages loading and responding well?
• Links: Do important links and redirects work?
• SEO: Are titles, URLs, canonicals, indexing settings, and metadata correct?
• Tracking: Are important conversions being recorded?
• Trust: Are contact details, company information, privacy information, and other relevant trust signals present?

FAQs

What is a UX audit before launching a website?

A pre-launch UX audit is a structured review of how easily people can understand, navigate, interact with, and complete important tasks on a website before it goes live.

It typically covers navigation, content hierarchy, forms, responsive behaviour, accessibility, performance, errors, and key user journeys.

When should a UX audit be done?

The most useful time is after the main development work is complete but before launch.

For larger projects, do smaller UX reviews throughout development rather than waiting for one final audit. This reduces the cost of fixing structural problems late in the project.

A final audit should still happen on the near-production version of the website.

Is a UX audit the same as a UI design review?

No.

A UI review focuses heavily on visual details such as typography, colour, spacing, components, consistency, and visual hierarchy.

A UX audit looks more broadly at whether people can understand the site and complete their goals.

There is overlap, but a beautiful interface can still have poor UX if the navigation, content structure, forms, or interaction model create unnecessary friction.

How long does a website UX audit take?

It depends on the size and complexity of the website.

A small five-page company website might receive a useful first-pass audit in a few hours. A large ecommerce website, SaaS product, or content-heavy platform can require substantially more time and testing.

The number of pages is only one factor. User journeys, forms, integrations, account areas, and responsive states add complexity.

What should I fix first after a UX audit?

Fix problems that prevent users from completing important tasks first.

A practical priority order is:

1. Broken functionality
2. Navigation and information architecture problems
3. Form and conversion problems
4. Mobile usability issues
5. Accessibility barriers
6. Performance problems
7. Content clarity
8. Visual polish

There is little value in adjusting a button’s border radius while users cannot find the enquiry form.

Conclusion

A pre-launch UX audit is less about finding 25 things wrong with a website and more about removing the friction that users should never have to experience.

Start with the basics: purpose, navigation, content hierarchy, forms, responsive behaviour, accessibility, performance, links, tracking, and real user journeys. Then test the website as someone who has never seen the project before.

This approach works particularly well for company websites, service websites, portfolios, ecommerce sites, and content-driven websites where the main user journeys can be clearly defined. It becomes less sufficient for complex products where deeper usability research, moderated testing, analytics analysis, and accessibility evaluation are needed.

The strongest pre-launch audit is not the one with the longest list. It is the one that catches the problems most likely to stop real users from accomplishing what they came to do.