Website Audit Template: Sections, Thresholds, Fill-In Guide

By Lazar Milicevic · Published November 1, 2026 · 12 min read

You've been told to "audit the site" and you're staring at a blank doc, a Lighthouse tab, and three browser extensions that each disagree with the others. A template doesn't make the audit smarter, but it makes it repeatable: same sections, same thresholds, same evidence format every time you run it. This post gives you the structure to copy into Word or Google Docs, the pass/fail thresholds that are current as of 2026, and the traps that make most downloadable audit templates quietly wrong.

One note up front: I'm not attaching a file here. Everything below is written so you can paste it into a blank Word or Google Docs document in about ten minutes and own it. That also means no stale download sitting on a landing page.

What a website audit template needs to do (and what most get wrong)

A useful audit template forces three things: a fixed set of sections, a threshold for each check so "good" isn't a feeling, and an evidence column so someone else can verify your finding. If a template has checkboxes but no thresholds and no evidence field, it produces opinions, not audits.

Here's the skeleton I'd use. Six sections, each with the same four columns:

The six sections:

1. Scope and baseline: what you audited and when
2. Performance: Core Web Vitals plus lab data
3. SEO fundamentals: crawlability, metadata, content basics
4. UX and accessibility: usability checks plus WCAG
5. Security: headers, HTTPS, exposure
6. Findings and action plan: the part people actually use

The most common failure in downloadable templates is outdated metrics. If your template still lists First Input Delay (FID), it's out of date: INP replaced FID as a stable Core Web Vital in 2024. Check any template you download for that one line before you trust the rest.

Section 1: Scope and baseline

Start every audit with a short header block, because an audit without a date and scope is useless in six months. Record the target URL(s), the date and time, the tools and versions used, the device profile (mobile or desktop), and who ran it. This takes two minutes and saves hours when someone asks "did this regress or was it always like this?"

Copy this block into the top of your document:

audit:
  site: example.com
  date: 2026-11-01
  auditor: your name
  pages_sampled:
    - /            # homepage
    - /pricing     # money page
    - /blog/top-post
    - /contact     # conversion page
  tools:
    - Lighthouse (note version)
    - PageSpeed Insights / CrUX field data
    - Browser dev tools
  device_profiles: [mobile, desktop]
  goal: "pre-launch check | quarterly review | pitch audit"

Sample at least one page per template type, not just the homepage. A site's homepage is usually the most-optimized page; the product page or the blog post template is where the problems live. For a small business site, 4–8 pages covers the distinct templates.

Section 2: Performance (record lab and field data separately)

Your performance table needs two sets of rows because Lighthouse and Core Web Vitals measure different things. The Lighthouse Performance score is lab-only, a simulated load, not measured from real users. The Core Web Vitals assessment is based on real user data. An audit template should record both, and never let one stand in for the other.

Core Web Vitals thresholds (from web.dev):

The "needs improvement" and "poor" bands are summarized in this 2026 guide. One rule people miss: a page passes only if it meets the targets at the 75th percentile for all three metrics, and that percentile should be measured across mobile and desktop. Two out of three isn't a pass.

Lighthouse score bands, per Chrome for Developers: 0–49 poor, 50–89 needs improvement, 90–100 good. Google notes a perfect 100 isn't expected, so don't write "must be 100" in your template.

If you want to know why a Lighthouse score moved, the Lighthouse 10+ weighting is: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10%, Speed Index 10% (as reported by secondary sources citing Lighthouse's source). Practical takeaway: TBT and LCP together are over half the score, so JavaScript main-thread work and your hero element are where to look first.

Another detail that trips people up: Lighthouse uses different scoring thresholds for mobile and desktop. An LCP subscore of 90 needs 2.5 s or less on mobile but 1.2 s or less on desktop (DebugBear). So always label which profile a score came from.

Here's the performance block for your template:

performance:
  field_data:           # real users (CrUX via PageSpeed Insights)
    lcp_p75_ms: ""
    inp_p75_ms: ""
    cls_p75: ""
    passes_cwv: ""      # yes / no / insufficient data
  lab_data:             # Lighthouse, state version + profile
    profile: mobile
    performance_score: ""
    tbt_ms: ""
    lcp_ms: ""
    cls: ""
  notes: "Biggest contributor to LCP; third-party scripts; image weight"

"Insufficient data" is a legitimate result. Low-traffic sites often don't have enough real-user data for a field assessment, which is exactly when you lean on lab data and say so explicitly.

On performance budgets (JS size caps, page-weight ceilings, third-party script counts): you'll see specific numbers circulated, but they come from agency blogs rather than Google. Set your own budget based on your current baseline and your audience's devices, and treat any number you copy as one person's opinion.

Section 3: SEO fundamentals

For a small-business site, the SEO section should be a short list of things that are binary and verifiable, not a 200-point checklist. Google's own SEO Starter Guide is aimed at newer site owners, and its 2024 refresh added sections on duplicate content, videos, and how long SEO takes to show impact. That last one matters for your template: add a line reminding the reader that fixes take time to show up, so they don't re-audit in a week and panic.

Checks I include, each with a clear pass condition:

You can run the indexability and duplicate-variant checks from a terminal in under a minute:

# Status and redirect chain for each URL variant
for u in example.com example.com example.com example.com; do
  echo "== $u"
  curl -sIL -o /dev/null -w "final: %{url_effective}  status: %{http_code}  redirects: %{num_redirects}\n" "$u"
done

# Is anything telling crawlers to stay out?
curl -s example.com
curl -sI example.com | grep -i x-robots-tag

All four variants should land on one final URL with a 200. If two of them return 200 independently, that's a duplicate-content finding.

I deliberately left "target keyword density" and "word count minimum" out. They create busywork and don't map to anything Google documents as a requirement.

Section 4: UX and accessibility

Split this section into a usability pass you do by hand and an accessibility pass anchored to WCAG, because they need different evidence. The usability pass is about whether a first-time visitor can do the one thing the site exists for. The accessibility pass is about whether everyone can.

Usability pass (manual, 20 minutes):

• Open the site on a real phone, not just a resized desktop window.
• Pick the primary goal (book a call, buy, request a quote) and time how many taps and screens it takes.
• Check that the primary call to action is visible without scrolling on mobile.
• Submit your own contact form and confirm you get the confirmation and the notification email arrives.
• Look for broken links, dead buttons, and forms that fail silently.
• Check for layout shift while loading (this ties back to CLS).

That form-submission test is the one that finds real money problems. I've seen sites where the form looked fine and posted to nowhere.

Accessibility pass, current standard: WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the current W3C version is dated 12 December 2024 and incorporates errata. W3C advises using 2.2, but WCAG 2.0 and 2.1 remain valid Recommendations and are not deprecated. WCAG 2.2 also became the international standard ISO/IEC 40500:2025 on 21 October 2025, according to Sitebrunch.

Your template should name the target level (most teams target AA) and the version, so "accessible" has a definition. Quick checks that catch a lot:

Automated tools catch only a portion of accessibility issues, so record in the template which checks were automated and which were manual. Don't claim "WCAG compliant" from a green automated scan.

If you sell to EU consumers, add a legal-context row. The European Accessibility Act (Directive (EU) 2019/882) applies to e-commerce services offered to consumers in the EU, with an exemption for microenterprises providing services. Exact thresholds, transitional rules, the technical standard used to demonstrate conformity, and penalties are set by the directive and by each member state's national law. I read about these points in secondary sources, not the directive text itself, so check the official EUR-Lex text or your member state's national law before relying on any detail, and talk to a lawyer if this applies to you. This isn't legal advice.

Section 5: Security

A website audit for a small business doesn't need a penetration test, but it should check the free, high-signal basics: HTTPS everywhere, response headers, and what the site exposes publicly. The OWASP Secure Headers Project is the reference I point people to.

Headers worth recording:

On Referrer-Policy, different OWASP resources suggest different values, so in your template make it a "present and deliberately chosen" check rather than hard-coding one value as the answer. For HSTS, use the OWASP value above or write "at least one year" if you want a looser floor.

Pull the headers yourself:

curl -sI example.com | grep -iE \
  "strict-transport-security|x-content-type-options|content-security-policy|referrer-policy|x-frame-options"

Additional security rows for the template:

• Valid TLS certificate; all HTTP requests redirect to HTTPS
• No mixed content (HTTP assets on HTTPS pages)
• CMS, plugins, and themes on supported versions
• Admin and login pages not publicly guessable without protection (MFA on admin accounts)
• No exposed .git, backup files, or .env at the web root
• Third-party scripts inventoried: who loads what, and why

That last one is underrated. Every third-party script is both a performance cost and a security dependency, so one inventory serves two sections of the audit.

Section 6: How to fill it out without lying to yourself

The findings section is where audits succeed or die. Three rules keep it honest:

1. One finding, one row, one piece of evidence. "Site is slow" is not a finding. "Mobile field LCP at p75 is 3.4 s on /pricing; hero image is 1.8 MB, served uncompressed" is. If you can't attach evidence, downgrade it to a note.

2. Prioritize by impact on the site's job, not by tool color. A red Lighthouse audit on a blog archive page matters less than a contact form that silently fails. Use three buckets: fix now (breaks revenue, access, or security), fix soon (measurable drag), note only.

3. Cap the action plan. Ten findings with an owner and a date beats sixty findings in a PDF nobody opens. Here's the findings format:

{
  "id": "PERF-03",
  "section": "performance",
  "finding": "Mobile LCP p75 over threshold on /pricing",
  "evidence": "PageSpeed Insights field data, 2026-11-01, screenshot ref #4",
  "threshold": "LCP <= 2.5 s (web.dev)",
  "priority": "fix now",
  "owner": "",
  "due": "",
  "status": "open"
}

Also record what you did not check. A "Not covered" line (e.g., "checkout flow, logged-in areas, international variants") tells the reader what the audit does not vouch for, which protects both of you.

When you're done, re-run the same audit after fixes using the same pages, tools, and profiles from Section 1. That's the entire point of a template: the second run is comparable to the first.

Where automation fits

A static template is the right starting point, but it has a ceiling: someone has to run Lighthouse, copy numbers into cells, curl the headers, and do it again next quarter. That repetitive evidence-gathering is the part that gets skipped. I'm a senior engineer who builds AI automations for solopreneurs and small teams, so this is the kind of thing I might build as a custom project: a scheduled script that runs the mechanical checks, writes results into the same structured fields you see in the YAML and JSON above, and compares them against the previous run. That's an example of what a project like this could look like, not a ready-made product. The judgment calls, like priority, trade-offs, and what the business actually needs, stay with a human.

If you outgrow the doc, the upgrade path is the same sections and thresholds, with the measurement step running on a schedule. Start with the template either way; it's the spec for whatever you automate later.

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.

Request 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.