Free Website Audit Checklist: 24 Checks You Can Run

Start with your homepage, a key landing page, and the page where someone buys, books, or signs up. A homepage can look polished while the form that brings in customers is broken.

This free website audit checklist covers 24 checks across copy, UX, SEO, accessibility, speed, and conversion. Most need only a browser. A few use free diagnostics because you cannot confirm indexing or real-world performance by looking at a page.

How do you run this audit without paid software?

Open each page in a private window so your existing login and cookies do not hide first-visit problems. Test on a phone as well as a desktop. Browser device emulation helps, but it does not reproduce every mobile keyboard, browser, or performance issue.

Choose one intended action per page: request a quote, start a trial, buy a product, or read a related guide. Judge the page against that action rather than a generic idea of what a website should look like.

Record the URL, check result, evidence, and proposed fix. Use pass, fail, or needs verification. An unfamiliar technical setting is not automatically a failure.

For a starting list of likely issues, run a free website audit. SiteScoper returns a scored report with ranked fixes in about 60 seconds, with no account required for the first audit. Still test interactive flows yourself; an automated report cannot replace completing your own form.

Does the first screen explain why someone should stay?

1. State the offer in plain language

Read the first heading and sentence without looking at the rest of the page. Can you identify what the business sells and who it serves?

“Unlock your potential” could describe anything. “Appointment scheduling for independent tutors” identifies a product and an audience. Add a specific benefit or differentiator only if you can support it.

2. Make the primary action obvious

Choose one dominant next step. “Start free trial” and “Book a demo” can coexist, but they should not compete equally unless the page clearly explains which visitor should choose each.

Check that the button label predicts the destination. A button saying “See pricing” should not open a sales-contact form.

3. Match the visitor’s reason for arriving

Compare the page with the ad, search query, email, or referring link that brings visitors there. If the promise is invoice templates, show templates—not a general accounting-software pitch with the promised download buried below.

For pages serving several audiences, make the routes to their needs explicit.

4. Show relevant proof near the claim

Put evidence where a skeptical reader needs it. A product screenshot can demonstrate a feature; a permissioned customer quote can support a service claim.

Check that testimonials are authentic, logos are authorized, and performance claims have evidence. Remove vague badges or unsupported promises rather than decorating the page with more of them.

Can visitors navigate and use the page on mobile?

5. Complete the mobile journey

On your phone, open the menu, visit a detail page, and reach the intended action. Look for horizontal scrolling, clipped pricing tables, overlapping text, and sticky banners that cover controls.

Repeat with the on-screen keyboard open. A form can look fine until the keyboard hides its submit button or error message.

6. Make navigation labels predictable

Use labels visitors recognize, such as Pricing, Services, and Contact. A label like “Explore the ecosystem” forces people to guess.

Check the logo link, back navigation, dropdowns, and footer. Visitors arriving on an inner page should be able to understand where they are and find related content without returning to the homepage.

7. Test keyboard access and focus

Use Tab and Shift+Tab to move through links, buttons, menus, and fields. Make sure the focused element is visible, the order is sensible, and dialogs do not trap you without a way out.

Activate controls with the appropriate keyboard keys. A clickable element that works only with a mouse needs fixing, even if it looks like a button.

8. Check labels, contrast, and zoom

Zoom in and confirm that text remains readable and controls remain usable. Use a free contrast checker when text is difficult to distinguish from its background.

Every form field needs an accessible label; placeholder text alone disappears as someone types. Errors should explain the problem in words, not rely only on a red outline. These checks catch obvious issues but are not a full accessibility audit.

Do search results and page content describe the same thing?

9. Give each important page a distinct title

Inspect the browser tab or page source for the title element. Describe the page’s specific topic rather than repeating the same business name everywhere.

There is no universal character limit that guarantees a complete search title. Google Search Central explains that title links are truncated to fit available device width and may be generated from other page content. Put the useful distinction early.

10. Write a useful meta description

Summarize what the visitor will find and why that page fits their need. Avoid descriptions that could apply to every page on the site.

Google may choose page text instead, and snippets vary by query and device. Treat a description as a relevant summary, not a guaranteed display. The free meta tag checker can help inspect titles, descriptions, and social-sharing metadata.

11. Use headings to organize the content

Aim for a clear main heading and descriptive subheadings. A practical default is one H1 for the page topic, with H2s and H3s showing the hierarchy.

Multiple H1s are not automatically an SEO penalty. The important checks are whether the structure makes sense and whether headings describe sections rather than simply making text larger.

12. Answer the questions needed to act

Read the page as someone unfamiliar with your business. Does it explain pricing or how quotes work, relevant limitations, delivery, compatibility, or what happens after signup?

Remove outdated claims and generic paragraphs. Do not expand a page just to reach a word count: a focused product page and an instructional guide need different amounts of detail.

Can search engines reach and understand the right pages?

13. Check crawl rules and indexing directives separately

Inspect the robots.txt file at your domain’s root for rules blocking important public content. A missing file does not itself prevent crawling.

Then check important pages for unintended noindex directives in their HTML or response headers. Robots.txt controls crawling; it is not a reliable way to keep a URL out of search. A crawler generally needs access to a page to see its noindex directive. Protect private content with authentication instead.

14. Review the sitemap’s contents

Find the sitemap through robots.txt, your CMS, or Search Console. It does not have to live at the conventional sitemap.xml location.

It should list canonical, indexable URLs you want discovered—not every public route. Exclude redirects, error pages, internal search results, and deliberately excluded pages. A sitemap helps discovery but does not guarantee indexing.

15. Verify preferred URLs and redirects

Check whether HTTP redirects to HTTPS and whether alternate hostname versions resolve consistently. Inspect canonical tags on important pages to ensure they point to the intended preferred URL.

Tracking parameters may reasonably canonicalize to a clean URL. Distinct product pages generally should not all canonicalize to a category page. Treat canonical tags as signals, not guaranteed instructions to Google.

16. Follow important links and check errors

Click navigation links, primary buttons, downloads, and links inside high-value content. Replace broken destinations and update links that unnecessarily pass through redirects.

Visit a made-up URL too. The site should show a useful error page and return an actual 404 status, rather than display an error with a successful 200 response. Your browser’s Network panel can show response codes.

17. Validate structured data where it applies

Use Google’s free Rich Results Test for markup associated with supported search features. Use Schema.org’s validator for broader vocabulary checks.

Choose types that match the page, such as Product or Article where appropriate, and ensure the data agrees with visible content. JSON-LD is a supported implementation format, not a requirement on every page. Valid markup does not guarantee a rich result.

Is the page fast, stable, and usable while loading?

18. Test performance instead of guessing

Run key URLs through Google PageSpeed Insights. Separate its lab test from field data, which reflects real-user experience when enough eligible data exists.

Google’s published good Core Web Vitals thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile of visits. These measure loading, responsiveness, and visual stability—not one generic “load time.” See the plain-English Core Web Vitals guide for interpretation.

19. Inspect image weight and loading behavior

Look for oversized hero images, large animated files, and desktop-sized images served to phones. Use appropriately sized, compressed files and responsive image delivery where supported.

Lazy-load suitable below-the-fold images, but avoid delaying the main image visitors need immediately. Also check alternatives: meaningful images need useful alt text; purely decorative images should normally have empty alt text, not keyword-filled descriptions.

20. Watch for shifting layouts

Reload the page and watch what moves as images, fonts, embeds, and banners arrive. A button moving just as someone taps it is both a stability and usability problem.

Reserve space for images and embedded content. Test consent banners and promotional strips in their first-visit state, not only after you have dismissed them.

21. Check responsiveness during real interactions

Open menus, select filters, change product options, and type into forms while the page is loading. Note delays, frozen controls, and clicks that appear to do nothing.

Review third-party chat widgets, video embeds, and marketing scripts before removing essential application code. Test changes on a staging copy where possible; a faster page with broken checkout is not an improvement.

Can someone complete the action without surprises?

22. Submit the form and verify delivery

Submit a realistic test enquiry using a recognizable test address. Confirm validation, the success message, notification delivery, and any CRM entry or confirmation email.

A success screen does not prove the lead reached your team. Test both valid input and recoverable mistakes, and make sure errors do not erase everything the visitor entered.

23. Reveal costs and commitments before submission

Check whether visitors can find the total price, recurring billing terms, shipping charges, cancellation conditions, or quotation process before committing.

For lead forms, explain what follows: an email, a phone call, or a booking screen. Ask only for information needed at that stage, and explain sensitive or unexpected requests.

24. Verify the completed journey and its measurement

Complete checkout using an approved test mode, or finish the relevant booking or signup flow. Confirm that the customer receives the promised access, receipt, or instructions.

If you use analytics, check that the success event fires at the actual completion point—not merely when someone clicks the button. Check for duplicates on refresh and respect consent settings. Avoid sending personal form data into analytics.

Which audit findings should you fix first?

Rank issues by their consequences, reach, and confidence—not by how easy they are to describe.

Assign each fix an owner and a clear acceptance test. “Improve the form” is vague. “A mobile visitor can submit an enquiry, see confirmation, and trigger the sales notification” is testable.

After deployment, repeat the failed check and nearby interactions. Record the change date before comparing performance or conversions; traffic mix and campaign changes can affect results too. Keep unresolved findings in the same log so the next audit starts with evidence, not memory.