Site Audit Checklist: 84 Checks Across 7 Areas, With Severity and Effort for Each

A site audit and an SEO audit are not the same job, and conflating them is why most audit deliverables are half a document.

An SEO audit asks whether a page can rank. A site audit asks whether the site works: whether it loads, whether a screen reader can use it, whether it leaks data, whether the analytics you are making decisions from are recording anything real. Those questions have separate answers and separate fixes, and a client who paid for a site audit and received a keyword report has a legitimate complaint.

This page is the whole-site half. We keep the ranking half in a separate SEO audit checklist of 42 checks, and the two are designed not to overlap. Where a check belongs in the other document, this page says so and moves on.

What this checklist covers, and what it deliberately does not

Seven areas, 84 checks:

1. Crawl and inventory, 12 checks. What pages exist and which are broken. 2. Performance, 12 checks. Load speed and Core Web Vitals. 3. Accessibility, 13 checks. Whether people using assistive technology can use the site. 4. Security, 12 checks. Transport, headers, dependencies, exposure. 5. Privacy and consent, 11 checks. What data leaves, with whose permission. 6. Analytics and tracking, 12 checks. Whether your measurement is trustworthy. 7. Navigation, forms and conversion mechanics, 12 checks. Whether the site does its job.

Not covered here, because they live in the SEO audit: keyword targeting, content quality and cannibalisation, title and meta optimisation, internal link architecture for ranking purposes, backlink profile, and search visibility measurement.

One area sits in both and is worth naming: page speed. It is a ranking input and a usability problem, and the checks are the same either way. It is in this document because the fixes are engineering work, not content work.

Privacy and consent is the area most audit checklists skip entirely. We checked the pages currently ranking for this query and the strongest of them, a 4,800 word checklist with roughly 80 items, covers accessibility, security and analytics but does not address privacy or consent at all. It is also the area with the clearest legal exposure, which is an odd combination.

The tools, all free

You can complete every check below without paying for anything.

• Google PageSpeed Insights for Core Web Vitals and performance diagnostics. Use the field data section, not the lab score, when it is available.
• WAVE for accessibility. It catches a meaningful share of WCAG failures in one pass and explains each one.
• Your browser's developer tools for security headers, console errors, and every network request the page makes. This is the single most useful tool on the list and it is already installed.
• Screaming Frog's free tier for crawling up to 500 URLs, which covers most small and mid-sized sites.
• Google Search Console for coverage, indexing and mobile usability, and to cross-check what Google actually sees.

Two notes on tools before you start. Automated accessibility testing catches perhaps a third of real WCAG issues, so the manual checks in that section are not optional padding. And any crawler will report hundreds of items on a site of any age, so the severity ratings below exist to stop you working through them in the order the tool listed them.

Part 1. Crawl and inventory, 12 checks

Start here, because you cannot audit pages you do not know about. Budget an hour.

• Crawl the full site and export the URL list. Count the pages. If the number surprises you, that gap is your first finding.
• Compare the crawl against your sitemap. Pages in one and not the other are both problems, in opposite directions.
• Find every internal link returning 404. Fix the link, not just the page.
• Find every internal link returning a 301 or 302. Internal links should point at the final URL.
• Check for redirect chains of two or more hops, and flatten them.
• Check for redirect loops. Rare, fatal, easy to miss.
• Confirm one canonical hostname. The www and non-www versions, and http and https, should all resolve to a single address.
• Check for orphan pages: URLs in the sitemap with no internal links pointing at them.
• Check that pagination and faceted URLs are not generating near-infinite crawl paths.
• Verify robots.txt does not block anything you need crawled, and does block staging and admin paths.
• Check for staging or development URLs that are publicly reachable and indexed.
• Confirm a custom 404 page exists, returns a genuine 404 status, and offers navigation rather than a dead end.

That last one has a trap. A "not found" page that returns HTTP 200 is a soft 404, and it will accumulate indexed junk quietly.

Part 2. Performance, 12 checks

Measure on mobile, on a throttled connection, and on the templates that matter rather than only the homepage. The homepage is usually the fastest page on the site and the least representative.

• Largest Contentful Paint under 2.5 seconds on mobile field data.
• Interaction to Next Paint under 200 milliseconds.
• Cumulative Layout Shift under 0.1.
• Check Time to First Byte. Above roughly 800 milliseconds points at hosting or backend rather than at the front end.
• Identify the largest image on each key template and check it is sized for its container.
• Confirm images use a modern format and are compressed. This is the most common single cause of a slow page.
• Confirm images below the fold are lazy loaded, and images above it are not.
• Check for render-blocking scripts and stylesheets in the head.
• Count third party scripts and total the bytes they add. Tag managers hide a lot here.
• Check that fonts are subset, preloaded and have a fallback so text renders during load.
• Verify caching headers on static assets, and that a CDN serves them if you have one.
• Test the site on a real mid-range phone. Numbers and lived experience diverge more than you expect.

The one check people skip is the third party audit. Sites regularly ship a megabyte of tag manager payload that nobody in the building can account for, and it is usually the cheapest large win available.

Part 3. Accessibility, 13 checks

This is the area where automated tools are least sufficient and the legal and ethical stakes are highest. Run WAVE first, then do the manual checks, which are the ones that matter.

• Run WAVE or an equivalent on your main templates and resolve every error it reports.
• Check colour contrast on body text, buttons, links and placeholder text against WCAG AA ratios.
• Confirm every meaningful image has alt text that describes its function, and decorative images have empty alt attributes.
• Check heading structure is a real hierarchy: one h1, no skipped levels, headings used for structure rather than for size.
• Navigate the entire site with the keyboard only. Every interactive element must be reachable and operable.
• Confirm the focus indicator is always visible. Removing focus outlines for aesthetics is the single most common accessibility regression.
• Check focus order follows visual order, especially in modals and dropdowns.
• Confirm modals trap focus while open and return it on close.
• Check every form input has a programmatically associated label, not just placeholder text.
• Confirm form errors are announced to assistive technology and identify the specific field.
• Check video has captions and audio has a transcript.
• Confirm nothing conveys meaning by colour alone, including form validation and chart legends.
• Test one full task, such as a purchase or a contact form, with a screen reader. Tools cannot tell you a flow is confusing.

The W3C WCAG quick reference is the authority when you need to settle whether something passes.

Part 4. Security, 12 checks

You are not doing a penetration test. You are checking that the obvious controls are in place, which is what a site audit is scoped to.

• HTTPS on every page, with no mixed content warnings.
• Certificate valid, not near expiry, and covering every hostname in use.
• HTTP requests redirect to HTTPS with a 301.
• HSTS header present.
• Content Security Policy present, and not so permissive that it does nothing.
• X-Content-Type-Options, Referrer-Policy and X-Frame-Options or a frame-ancestors directive set.
• Server, CMS and framework versions not disclosed in headers or in page source.
• CMS, plugins, themes and dependencies patched. List anything unmaintained.
• Admin login not on a predictable path, with rate limiting and two factor authentication enabled.
• No credentials, API keys or tokens in client-side source. Search the bundle rather than assuming.
• Directory listing disabled, and no backups, database dumps or archive files reachable by URL.
• File uploads, if any, validated by type and size and served from a path that cannot execute code.

Header checks take about ten minutes in developer tools and turn up findings on most sites. The dependency check is the one that produces genuinely serious findings, and it is tedious enough that people skip it.

Part 5. Privacy and consent, 11 checks

Missing from every ranking checklist we reviewed, and the area where a finding is most likely to matter commercially.

• Inventory every third party request the site makes, on each key template. Developer tools, network tab, filter by domain.
• For each one, identify what data it receives and whether you have a lawful basis for sending it.
• Confirm no tracking, analytics or advertising script fires before consent is given, where consent is required.
• Check that rejecting consent actually stops the requests. Banners that set a cookie and load everything anyway are common.
• Confirm the consent choice persists and can be changed later from a visible control.
• Check the cookie banner offers a genuine reject option with equal prominence, not only "accept" and "manage".
• Verify your cookie policy lists the cookies actually set, including third party ones.
• Confirm the privacy policy is current, reachable from every page, and names the processors you use.
• Check forms collect only what you need, and state what happens to it.
• Confirm no personal data appears in URLs, query strings or referrer headers, since those propagate to third parties.
• Check whether any page that handles sensitive information loads a marketing pixel. This is the highest-risk pattern in this section.

That last check deserves its own line in your report. A tracking pixel on a page where a user enters health, financial or otherwise sensitive information transmits that context to a third party, and it is the pattern regulators have been most active on.

Part 6. Analytics and tracking, 12 checks

The purpose of this section is to establish whether your numbers can be trusted. Audits that skip it end up recommending decisions based on broken measurement.

• Confirm the analytics tag fires exactly once per page. Duplicate tags silently halve your bounce rate and inflate sessions.
• Verify the tag is present on every template, including checkout, thank-you and error pages.
• Check internal traffic and known bot traffic are filtered.
• Confirm your own staging and preview environments are not reporting into the production property.
• Verify goals and conversions fire on the real completion event, not on a button click that may not have succeeded.
• Test each conversion end to end and confirm it appears in the report.
• Check ecommerce or lead values are passed and are in one currency.
• Confirm cross-domain tracking is configured if the journey spans domains, including a payment provider.
• Check UTM conventions are consistent. Case differences alone will fragment your channel reports.
• Verify Search Console is connected, verified on the correct property type, and that the sitemap is submitted.
• Cross-check analytics sessions against server logs or another source for one period. Large unexplained gaps mean a measurement problem.
• Confirm data retention settings match what your reporting actually needs.

The duplicate tag check is worth doing first. It is common, it invalidates every engagement metric on the site, and it takes one minute.

Part 7. Navigation, forms and conversion mechanics, 12 checks

Whether the site does the job it exists to do.

• Confirm the primary navigation reaches every important section within two clicks.
• Check the navigation works on mobile, including nested items, and can be closed.
• Confirm site search returns useful results for common terms, if you have site search.
• Check every form submits successfully, and that you receive the submission.
• Confirm the success state is unambiguous. Forms that clear silently are read as failures.
• Check validation messages are specific and appear next to the field.
• Confirm long forms retain entered data on a validation error.
• Check the phone number is a tel link and the address is tappable to maps on mobile.
• Confirm the primary call to action is visible without scrolling on mobile on key templates.
• Check for layout breakage at common widths, including 320 pixels and around 768.
• Confirm the site is usable with images blocked and with JavaScript degraded, at least for core content.
• Check outbound links, especially to partners and resources. Link rot on older pages is near universal.

Severity and effort, so you fix things in the right order

A crawler will hand you 400 items. This is how to sequence them. None of the ranking checklists we reviewed rate their items, which is why they read as inventories rather than plans.

The pattern worth internalising is the top-left quadrant: critical severity, low effort. A pixel on a sensitive page, an exposed API key, a duplicate tag, a removed focus outline. Each takes minutes and each is a real finding. Work through those before you touch anything requiring a sprint.

If you only have two hours

• Developer tools, network tab, on your three most important templates. Note every third party request and whether it fires before consent. (30 min)
• PageSpeed Insights on those same three templates, mobile, field data. Note LCP and CLS. (15 min)
• Tab through one full conversion flow with the keyboard. Note anything unreachable or any lost focus indicator. (20 min)
• Check security headers and CMS version on one page. (10 min)
• Confirm the analytics tag fires once and your main conversion registers. (20 min)
• Crawl with the free Screaming Frog tier and export 404s and redirect chains. (25 min)

That produces a short report with real findings, and it is a defensible deliverable on its own.

Turning this into a client deliverable

The GSC data for this page shows people searching "site audit deliverables" and a cluster of white-label audit queries, so a note for agencies specifically.

A checklist is not a deliverable. What a client can act on has four parts: the finding, the evidence, the severity and effort rating, and the named owner. Evidence means a screenshot or a copied header, not a description. Severity and effort mean the client can decide what to fund. An owner means the item can actually move, and "developer" is not an owner.

Structure the document by severity rather than by the seven areas above. The areas are how you conduct the audit; severity is how the client reads it. Lead with critical and low-effort items so the first thing they see is something they can fix this week, then group the rest.

Two practical points. Re-audit dates matter more than the audit: put a review date on every item and a re-audit date on the document, or the report becomes shelf furniture. And state your scope explicitly, including what you did not check, because an audit that stays silent on privacy will be read as having cleared it.

If you run audits for clients under your own brand, our white-label SEO platform covers the reporting side, and our website audit tool survey compares what the automated options actually detect. Do read the limitation in the next section before you rely on any of them.

Where automated tools stop

Every tool in this document, ours included, detects a subset of what is on this list. Broadly, automated crawling and performance measurement is reliable, accessibility scanning catches roughly a third of real issues, security scanning covers headers and versions but not logic, and privacy compliance is barely automatable at all because it depends on your lawful basis rather than on what the code does.

That is the honest boundary for our own product too. Distribb is an AI SEO platform, so it covers the search visibility side of a site audit: crawl and indexation issues, on-page problems, content and cannibalisation, internal linking. It does not test accessibility, it does not check security headers or dependency versions, and it does not assess consent compliance. For those three areas you need the free tools listed at the top of this page plus manual work, and on accessibility and privacy you may need a specialist. What that looks like in practice is walked through in our guide to running an AI SEO audit.

Anyone selling a single tool that audits all seven areas above is overstating what the software does. Use tooling for inventory and measurement, and reserve your own time for the judgement calls, which are most of the findings that matter.

Where the SEO half lives

To keep the boundary explicit, since these two documents are deliberately split:

• Ranking, keywords, content quality, cannibalisation, titles and metadata, backlinks, search visibility: our SEO audit checklist, 42 checks in six parts.
• Authority and link profile measurement: domain authority checker.
• Search Console property setup, which trips people up before an audit even starts: what URL prefix means.

Run this document for site health, that one for search performance. Together they are the audit. Either one alone is half of it, which is the state most audit deliverables ship in.

How this checklist was built

The 84 checks come from running audits on our own properties and from the areas where we have found real defects rather than from a generic best-practice list. Several checks exist because we failed them: soft 404s returning HTTP 200, internal links whose anchor text named one page while the href pointed at another, and orphaned pages created by publishing into a CMS without touching anything else.

For the competitive scope we read the pages currently ranking for this query and recorded their structure. The strongest is a roughly 4,800 word checklist with six phases and around 80 items, covering accessibility, security and analytics, with a linked spreadsheet template. Another runs about 3,300 words across nine steps with a downloadable PDF. Neither covers privacy and consent, and none of them rate their items by severity or effort, which is why this version adds both.

Two limits. This is a checklist for small to mid-sized sites: an enterprise audit adds log file analysis, crawl budget management and internationalisation work that is out of scope here. And nothing on this page is legal advice, particularly the privacy section, where the correct answer depends on your jurisdiction and your lawful basis for processing.

Frequently asked questions

What is the difference between a site audit and an SEO audit? A site audit asks whether the site works: performance, accessibility, security, privacy, analytics accuracy and usability. An SEO audit asks whether pages can rank. They share only page speed. The search half of that distinction has its own walkthrough in our guide to how to do an SEO audit.

How long does a site audit take? A focused pass on a small site is two hours and produces real findings. A thorough audit across all seven areas above is one to three days, most of it in accessibility and privacy, which are the manual sections.

How often should I run one? Quarterly for the fast-changing areas, which are performance, analytics accuracy and third party scripts. Annually for the full document, plus after any redesign, replatform or major dependency upgrade.

What are the crucial elements of a site audit checklist? In order of what actually turns up serious findings: third party requests and consent, dependency patch state, keyboard accessibility, analytics correctness, and Core Web Vitals on mobile. Crawl errors are the most numerous and usually the least consequential.

Can I automate a site audit? Partly. Crawling and performance measurement automate well, accessibility scanning catches around a third of issues, and privacy compliance barely automates at all. Treat tool output as an inventory rather than as an audit.

Do I need paid tools? No. Every check on this page can be completed with PageSpeed Insights, WAVE, Search Console, the free Screaming Frog tier and your browser's developer tools. Paid crawlers save time on large sites and find nothing categorically new.

What should I fix first? Anything critical with low effort: a marketing pixel on a sensitive page, an exposed key, a duplicate analytics tag, a removed focus indicator. Those four take under an hour combined and are genuine findings.

Why is privacy on a site audit checklist? Because it is where the clearest legal exposure sits and because no other checklist covers it. Every third party script on your site is a data transfer, and an audit that does not inventory them has not looked at the highest-risk part of the page.