What Does a Website Audit Include? Full 2026 Checklist

Developer reviewing website audit checklist and performance metrics on a laptop screen with code editor open

Your site loads fine on your laptop, ranks page 2 for your best keyword, and converts about half as well as it should. You know something is off, but "audit the site" is a fuzzy task that swallows a weekend and produces a 40-page PDF nobody acts on. This post fixes that: a concrete, engineer-grade checklist of what a real audit actually covers in 2026, what tools produce defensible numbers, and what to skip.

I run audits for solo founders and small ops teams. The pattern is always the same — five domains matter (SEO, performance, accessibility, security, UX), and inside each there are maybe 10 checks that move the needle. Everything else is noise a consultant added to justify their invoice.

The 5 domains a real audit covers

A website audit in 2026 covers five domains: technical SEO, Core Web Vitals performance, WCAG 2.2 accessibility, security posture (headers, TLS, dependencies), and UX/conversion friction. Anything sold as an "audit" that skips one of these is a partial audit — usually SEO-only, which is the cheapest to automate and the least useful in isolation.

Here is the matrix I use to scope work before quoting:

Domain Primary question Main tools Typical time (manual)
Technical SEO Can crawlers find, render, and understand every important page? Screaming Frog, Google Search Console, Ahrefs/Semrush 3–5 hours
Performance Do real users get LCP, INP, CLS in the "good" bucket? PageSpeed Insights, WebPageTest, CrUX 2–4 hours
Accessibility Can users on screen readers, keyboards, and reduced-motion actually use the site? axe DevTools, Lighthouse, manual keyboard pass 3–6 hours
Security Is the site hardened against the boring, common attacks? Mozilla Observatory, SSL Labs, npm audit 2–3 hours
UX / conversion Where do users abandon, and why? GA4, Microsoft Clarity, session replays 4–8 hours

That's roughly 14–26 hours of focused work for a mid-sized site (50–500 pages). Below is what each domain actually contains.

Technical SEO: crawl, render, index, rank

The lead question is: can Google crawl the page, render the JavaScript, index the result, and match it to the query you want? Fifteen years of SEO advice can be reduced to those four verbs. Anything the audit surfaces should map back to one of them.

The checks that consistently matter:

  • robots.txt and XML sitemap sanity. Sitemap referenced in robots.txt, only 200-status canonical URLs, submitted in Google Search Console, and last-mod dates that aren't lying.
  • Canonicals. Every page has a self-referential canonical unless it's intentionally consolidating. Paginated archives, UTM variants, and faceted URLs are the usual offenders.
  • Indexation vs. impressions. Pull GSC's Pages report. Any URL in "Discovered — currently not indexed" for more than 30 days is a signal, not noise. Usually it's thin content or a soft duplicate.
  • Rendered HTML matches source. SPAs still ship broken. Use the URL Inspection tool's "View crawled page" and diff it against your React/Vue output. If your h1 or main copy is missing, so is your ranking.
  • Structured data. Article, Product, FAQPage, BreadcrumbList where relevant. Validate with Google's Rich Results Test, not just Schema.org.
  • Internal linking depth. Screaming Frog will show crawl depth. Anything past depth 4 from the homepage rarely ranks. Fix by linking from high-authority indexed pages into the buried ones.
  • hreflang if you serve multiple locales — one wrong self-reference breaks the whole cluster.

A quick Screaming Frog config that catches 80% of issues:

crawl_config:
  respect_robots: true
  render: javascript
  user_agent: Googlebot Smartphone
  crawl_depth: unlimited
  extract:
    - canonical
    - meta_robots
    - h1
    - schema_org
  export:
    - internal_html_200
    - response_codes_client_error
    - response_codes_server_error
    - canonicalized
    - directives_noindex

Export those five reports, sort by priority (product/service pages first), and you have your technical SEO backlog.

Performance: Core Web Vitals from real users, not lab

Core Web Vitals in 2026 are LCP (Largest Contentful Paint), INP (Interaction to Next Paint, which replaced FID), and CLS (Cumulative Layout Shift). Google uses field data from the Chrome UX Report for ranking, not lab data from Lighthouse. Optimizing your Lighthouse score to 100 while real users still see LCP over 4 seconds is a common and expensive mistake.

The audit sequence I run:

  1. Pull the CrUX field data first. PageSpeed Insights shows both. If field data says "Failed Core Web Vitals" on mobile, that's your headline.
  2. Identify the LCP element per template. Usually a hero image, a large H1, or a video poster. Open DevTools → Performance → LCP marker. Ninety percent of LCP fixes are: preload the image, set fetchpriority="high", serve it in AVIF or WebP, and drop the render-blocking font above it.
  3. Trace INP under real load. INP catches the jank when a user actually clicks something. If a click handler kicks off a 400ms React re-render, INP tanks. Break long tasks with scheduler.postTask or defer non-critical work.
  4. CLS is almost always images without dimensions or late-injected ads/consent banners. Add explicit width/height, reserve space for embeds, and load the CMP script with proper containment.

A useful lab check via WebPageTest CLI:

webpagetest test https://yoursite.com/pricing \
  --location "Dulles:Chrome" \
  --connectivity 4G \
  --runs 3 \
  --video \
  --lighthouse

Run this on your top 5 templates (home, pricing, blog post, product, checkout). If the median LCP is over 2.5s on 4G, that's your first ticket.

One honest note: the "good" thresholds Google publishes get tightened periodically — check the web.dev Core Web Vitals page for the currently enforced numbers rather than trusting a blog post (including this one) that could go stale.

Accessibility: WCAG 2.2 AA is the floor

The lead question: can someone using only a keyboard, or only a screen reader, complete every important task on the site? WCAG 2.2 AA is the standard most audits target. In the US, ADA lawsuits over inaccessible sites are steady business for plaintiffs' firms — the DOJ published guidance in 2022 confirming ADA applies to web content, and it hasn't gotten looser.

The checklist that catches the real problems:

  • Automated pass with axe. axe DevTools finds roughly 30–50% of issues. Run it on every distinct template. Fix critical and serious issues first.
  • Keyboard-only pass. Tab through the whole page. Every interactive element must be reachable, have a visible focus ring, and respond to Enter/Space. Skip links present.
  • Screen reader spot check. VoiceOver on macOS or NVDA on Windows. Read the top of the page — does the H1 come through? Are form labels announced?
  • Color contrast. 4.5:1 for normal text, 3:1 for large text. WCAG 2.2 added a 3:1 minimum for focus indicators and non-text UI, which most sites still fail.
  • Motion and animation. Respect prefers-reduced-motion. Auto-playing hero videos are a real barrier for users with vestibular disorders.
  • Forms. Every input has a <label>, errors are announced via aria-live, and error messages don't rely only on red text.
  • Alt text audit. Not every image needs it — decorative images get alt="". Product and content images need descriptive alt.

A quick axe-core run in CI, so regressions don't ship:

{
  "scripts": {
    "a11y": "axe https://staging.yoursite.com --tags wcag2a,wcag2aa,wcag22aa --exit"
  }
}

Automated tools are a floor, not a ceiling. The W3C's WCAG-EM methodology is the reference for how a full evaluation is structured if you want the formal version.

Security: the boring hardening that stops the boring attacks

The lead question: if a script kiddie runs a scanner against your site tonight, what does it find? Most SMB sites get compromised through the same three vectors: outdated dependencies, missing security headers, and exposed admin surfaces. An audit closes those.

The checklist:

  • TLS configuration. Run SSL Labs — target grade A or A+. TLS 1.2 minimum, TLS 1.3 preferred, no legacy ciphers.
  • Security headers. Run Mozilla Observatory. The headers that actually matter: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy.
  • Dependency vulnerabilities. npm audit, pip-audit, or Dependabot/Renovate on the repo. Focus on high/critical in dependencies you actually import, not transitive noise.
  • Exposed admin surfaces. /wp-admin, /.git, /.env, staging subdomains without auth. A five-minute check with curl prevents six-month embarrassment.
  • Rate limiting on auth and forms. Contact forms and login endpoints without rate limits become spam relays and credential-stuffing targets.
  • Backups you've actually restored. A backup you've never tested is a rumor.

A minimum-viable CSP for a marketing site, as a starting point (not copy-paste-and-ship — you have to allow your actual analytics/CDN sources):

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' data:;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';

If you're on WordPress, add a WAF (Cloudflare's free tier is enough for most SMBs) and keep core + plugins on auto-update. That combination alone eliminates most incidents I see in the wild.

UX and conversion: where users actually leave

Every other domain is a means to this end. The lead question: where do users drop off, and can we tell whether it's a bug, a confusion, or a mismatch with intent? GA4 gives you the "where," session replays give you the "why."

The checks that produce action items:

  • Funnel step drop-off. In GA4, define your key funnel (landing → pricing → signup → activation). The step with the biggest drop is your first ticket. Not the biggest overall number — the biggest relative drop.
  • Session replays on drop-off pages. Microsoft Clarity is free, decent, and privacy-friendly. Watch 20 sessions on your worst-converting page. Patterns emerge fast: rage clicks on a non-clickable element, form fields that reject valid input, mobile CTAs below the fold.
  • Form analytics. Which field is abandoned? Usually phone number, company size, or a required field that shouldn't be.
  • Mobile parity. Fifty to seventy percent of traffic is mobile for most SMB sites. Redo the entire audit on a real phone, not just Chrome DevTools mobile emulation.
  • Search Console query alignment. Are the queries bringing traffic aligned with what the page actually offers? A mismatch is a title/meta rewrite, not a redesign.
  • Load-to-first-interaction time. If a user has to wait 3 seconds for the CTA to become clickable, they're gone. This overlaps with INP but is worth checking as its own UX metric.

The output of a UX audit isn't a score — it's a ranked list of specific screens with specific frictions and a proposed fix per screen.

The complete 2026 checklist

Copy this into a Notion page or a Google Sheet and work top to bottom:

[ ] robots.txt references sitemap
[ ] XML sitemap only lists indexable canonical URLs
[ ] Zero "Discovered — not indexed" pages older than 30 days
[ ] Self-referential canonicals present
[ ] Rendered HTML matches source (SPA check)
[ ] Structured data validates in Rich Results Test
[ ] No page deeper than click-depth 4
[ ] hreflang correct (if multilingual)

[ ] Field-data LCP < 2.5s mobile (top 5 templates)
[ ] Field-data INP in the "good" bucket
[ ] Field-data CLS < 0.1
[ ] LCP element preloaded, images in AVIF/WebP
[ ] All images have width/height
[ ] No render-blocking third-party scripts above the fold

[ ] axe DevTools: zero critical/serious issues
[ ] Full keyboard traversal works
[ ] Visible focus ring on every interactive element
[ ] 4.5:1 contrast on body text, 3:1 on UI
[ ] prefers-reduced-motion respected
[ ] All form inputs labeled, errors announced

[ ] SSL Labs grade A or A+
[ ] Mozilla Observatory: CSP, HSTS, X-Content-Type-Options set
[ ] Zero high/critical vulns in direct dependencies
[ ] No exposed .env, .git, or unauthenticated staging
[ ] Rate limits on auth + contact forms
[ ] Backups tested via restore in the last 90 days

[ ] GA4 funnel defined for primary conversion
[ ] 20+ session replays reviewed on top drop-off page
[ ] Form field abandonment identified
[ ] Mobile audit done on a real device
[ ] GSC queries align with landing page intent

If you can honestly tick every box, your site is in the top few percent for its category. Most sites I audit start at about 40% ticked.

How BizFlowAI approaches this

We built a free audit pipeline that runs about two-thirds of the checks above automatically. You paste a URL, and within a few minutes you get back a structured report: Lighthouse and field-data Core Web Vitals for the top templates, axe accessibility violations grouped by severity, security header and TLS grade, and a technical-SEO crawl summary with the top 10 issues ranked by traffic impact. The report is a markdown file plus a JSON payload, so it plugs into whatever ticketing system you already use.

What we intentionally don't automate: the UX/session-replay layer and the "does this content actually match the query" judgment call. Those still need a human watching real users. The point of the automation is to hand you a clean, prioritized backlog in ten minutes instead of a wasted weekend — so the human hours go to the parts that need taste, not the parts a script can handle. You can try it on the free audit generator and see the exact output before deciding whether to run it every sprint.


Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.

Frequently asked questions

What does a complete website audit include in 2026?

A complete website audit in 2026 covers five domains: technical SEO (crawl, render, index), performance measured by Core Web Vitals (LCP, INP, CLS), WCAG 2.2 AA accessibility, security posture (TLS, headers, dependencies), and UX/conversion friction. Audits that only cover SEO are considered partial. For a mid-sized site of 50–500 pages, a thorough manual audit takes roughly 14–26 hours of focused work.

What are the Core Web Vitals thresholds and how are they measured?

Core Web Vitals are LCP (Largest Contentful Paint), INP (Interaction to Next Paint, which replaced FID in 2024), and CLS (Cumulative Layout Shift). Google uses field data from the Chrome UX Report (CrUX) for ranking, not lab data from Lighthouse. Optimizing Lighthouse scores while real users still experience LCP over 2.5s on 4G is a common mistake. Always start an audit by pulling CrUX field data via PageSpeed Insights.

Which tools should I use for a website audit?

Use Screaming Frog, Google Search Console, and Ahrefs or Semrush for technical SEO; PageSpeed Insights and WebPageTest for performance; axe DevTools plus manual keyboard and screen reader testing for accessibility; Mozilla Observatory, SSL Labs, and npm audit for security; and GA4 with Microsoft Clarity for UX and conversion analysis. Automated tools catch roughly 30–50% of issues, so manual checks remain essential.

What accessibility checks are required for WCAG 2.2 AA compliance?

WCAG 2.2 AA requires 4.5:1 color contrast for normal text, 3:1 for large text, and a new 3:1 minimum for focus indicators and non-text UI. Every interactive element must be keyboard reachable with a visible focus ring, forms need proper labels and aria-live error announcements, and sites must respect prefers-reduced-motion. Automated tools like axe find only 30–50% of issues, so manual keyboard and screen reader passes are mandatory.

What are the most common security issues found in website audits?

Most small and mid-sized business sites are compromised through three vectors: outdated dependencies, missing security headers, and exposed admin surfaces like /wp-admin, /.git, or /.env files. An audit should verify TLS grade A or A+ via SSL Labs, confirm Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers are set, and run npm audit or Dependabot to catch high and critical dependency vulnerabilities.