QUICK ANSWER
What should a website audit template include?
Include scope, URL or flow, audit area, check, method, evidence link, observed result, severity, decision owner, fix owner, accepted action, status, due date, retest date, retest evidence, and notes. Sample representative pages and critical journeys, separate automated signals from manual review, and close findings only when the original acceptance check passes again.
A website audit should produce more than a scanner score or a presentation of screenshots. A useful audit records the scope, page or journey, check, method, evidence, observed result, severity, decision owner, fix owner, accepted action, due date, status, and the evidence required to close the finding.
This template gives those fields one shared ledger. It can hold content, accessibility, functionality, search, performance, privacy and security, responsive behavior, analytics, ownership, resilience, and maintenance findings without pretending that one tool or reviewer can certify every discipline.
Use the ledger as an evidence and decision system
Run the audit in four passes. Keep the scope and method stable enough that another reviewer can reproduce the finding and the fix owner can repeat the acceptance check.
Define scope, objectives, roles, and representative samples
List the public pages, private flows, repeated templates, important user journeys, environments, devices, accounts, languages, providers, and data boundaries in scope. Name the decision owner and discipline reviewers. When every URL cannot be reviewed manually, select representative and critical samples deliberately and record the sampling rule.
Sources: [w3c-wcag-em], [google-search-essentials], [owasp-wstg]
Capture a reproducible observation, not only a score
For each check, record the exact URL or flow, date, environment, browser or device, account role, tool and version, input, expected behavior, observed result, screenshot, trace, response, report, or source link. Label lab measurements, field measurements, automated signals, manual review, and user evidence separately.
Sources: [w3c-evaluation-tools], [w3c-easy-checks], [web-vitals]
Triage severity and accept an owned action
Describe impact and reach before assigning severity. Separate immediate harm, release blockers, degraded journeys, evidence gaps, maintainability, and informational observations. Give one person authority to accept, defer, reject, or escalate the action and another owner to implement it when appropriate.
Sources: [owasp-wstg], [w3c-wcag-em], [google-search-essentials]
Retest the original boundary and preserve the evidence
A code or content change moves a finding to ready for retest, not closed. Repeat the original method and acceptance condition, inspect affected neighboring states, record the release and new evidence, and close only after the observable result passes. Reopen when the fix changes scope, creates a regression, or lacks production proof.
Sources: [w3c-wcag-em], [owasp-wstg], [web-vitals]
What this worksheet is designed to hold
Use one ledger for coordination, then attach discipline-specific evidence and escalate beyond the team when the question needs qualified expertise.
Included
- Content accuracy, proof, ownership, rights, review dates, page purpose, and visitor-task findings
- Accessibility observations from automated checks, keyboard and zoom review, assistive-technology review, and representative task testing
- Critical journey behavior, validation, durable results, retries, duplicate handling, provider handoffs, and cleanup
- Rendered search controls, status, crawlability, titles, H1s, canonicals, internal links, sitemaps, and structured-data evidence
- Performance lab and field evidence with environment, device, page, date, metric, and diagnostic context
- Privacy, security, responsive layout, analytics, consent, account ownership, resilience, recovery, and maintenance observations
Not included
- A universal score that ranks unlike accessibility, security, content, performance, search, legal, and business risks on one numeric scale
- A claim that automated tools prove accessibility conformance, security, privacy compliance, legal compliance, or production readiness
- Guaranteed rankings, traffic, conversion, uptime, revenue, accessibility, security, or regulatory outcomes
- Legal, compliance, penetration-testing, threat-modeling, licensed-professional, or user-research conclusions beyond the evidence and reviewer scope
- A replacement for the distinct website launch, migration, recurring maintenance, or symptom-led Google visibility workflows
DOWNLOADABLE RESOURCE
Download the Website Audit Worksheet
The CSV opens in spreadsheet tools and preserves one row per finding. The included rows are fictional reserved-domain examples that demonstrate how evidence, ownership, action, and retest fields relate. Replace them with your reviewed scope; do not present starter observations as facts about a real site.
Website audit worksheet
A 17-column audit ledger with 12 fictional starter findings across ownership, content, accessibility, functionality, search, performance, privacy and security, resilience, responsive behavior, measurement, maintenance, and retest state.
Format: CSV
Locally reproduced August 1, 2026. SHA-256: 679e96dee47cbae99893ce982ef6200b66edc8cd6d15ac0b6f6e8ee5a9890bf5
Included
- Scope, URL or flow, area, check, method, evidence, and observed-result fields
- Severity, decision owner, fix owner, accepted action, status, and due-date fields
- Retest date, retest evidence, notes, and a stable audit ID for every row
- Fictional example.test starter rows that demonstrate evidence boundaries without making real-site claims
Verification boundary
Parsed locally on 2026-08-01 as UTF-8 CSV: one 17-field header, 12 unique audit IDs, 12 equal-width data rows, reserved example.test URLs only, allowed status and severity values, and no spreadsheet-formula prefixes. Public HTTP and content-type verification remain pending deployment.
Three ways to configure the same audit ledger
These are scoped worksheet patterns, not completed audits or claims about real organizations. Each pattern changes the sample and evidence plan while keeping the same finding, owner, action, and retest fields.
Service website lead-journey audit
Use when: The primary website job is helping a visitor understand a service and submit a request that an operator can receive and follow up.
Sample the homepage, one page from each service template, proof and policy pages, the contact journey, confirmation, destination, failure state, and mobile layout. Trace a labeled test submission from input through durable storage or provider delivery and cleanup.
Structure
- Content and proof: audience question, service fact, evidence, rights, owner, review date, and primary action
- Journey: entry, labels, validation, consent, accepted record, duplicate or retry behavior, delivery, confirmation, and operator lookup
- Public page: status, title, H1, canonical, crawlability, internal links, responsive behavior, performance evidence, and analytics boundary
Watch for: A successful browser confirmation does not prove durable storage, provider delivery, qualified leads, bookings, sales, or revenue. Verify each boundary separately.
Sources: [google-search-essentials], [w3c-easy-checks], [web-vitals]
Signed-in workflow audit
Use when: The site includes accounts, roles, private records, state transitions, files, external actions, or operator review.
Sample each role and state, then test authorized and denied paths, direct URLs, invalid input, stale writes, retries, duplicates, provider failure, audit history, export, deletion, monitoring, backup, restore, and the public-to-private handoff.
Structure
- Access: identity source, tenant or record scope, role, action, server authorization, session behavior, and denied result
- State: record version, permitted transition, duplicate or retry key, provider attempt, reconciliation, audit event, and operator recovery
- Data: collection, minimization, retention, export, deletion, backup, restore, secret boundary, and incident escalation
Watch for: A generic checklist is not a penetration test, threat model, privacy review, or compliance opinion. Escalate material risks to qualified security, privacy, legal, or regulatory reviewers.
Sources: [owasp-wstg], [w3c-wcag-em]
Content and search library audit
Use when: The site publishes many articles, products, services, locations, resources, profiles, or other repeated page types.
Inventory page types and lifecycle states, select structured and random samples, and test source ownership, review dates, rights, duplicate jobs, templates, navigation, search, pagination, canonical ownership, links, archives, redirects, sitemaps, and representative accessibility and performance states.
Structure
- Record model: stable ID, fields, source, owner, rights, review date, status, URL, canonical, archive, redirect, and deletion rule
- Template sample: complete item, incomplete item, long content, missing media, narrow screen, keyboard path, indexability, and structured data
- Discovery: hub path, contextual link, site search, pagination, filter URL policy, sitemap owner, crawl result, and stale or duplicate handling
Watch for: Sitemap presence, an automated scan, or one sampled template does not prove every URL is useful, accessible, current, indexable, or assigned to the intended search owner.
Sources: [w3c-wcag-em], [google-search-essentials], [web-vitals]
Triage findings by impact and proof
Severity is a decision about impact, reach, exploitability or harm, and business context. Do not derive it from the audit category or tool color alone.
The finding exposes private data, permits unauthorized action, misleads a user about a consequential outcome, or creates immediate material harm.
Choose: Treat it as critical, contain the exposure or action, preserve evidence, involve the accountable security, privacy, legal, compliance, or operational owner, and define the safe recovery gate before resuming.
Tradeoff: Containment can interrupt service or launch work, but leaving material harm open is not a normal backlog decision.
A primary journey fails, blocks a user group, loses data, creates duplicate side effects, sends work to the wrong destination, or publishes a materially false claim.
Choose: Treat it as high severity, assign an owner and acceptance check, and block the affected release or journey until the production boundary can be verified.
Tradeoff: The release may narrow or wait, but a polished interface cannot compensate for a broken or misleading outcome.
The issue degrades understanding, performance, accessibility, search discovery, maintenance, or measurement without currently blocking the primary task.
Choose: Use medium severity with evidence of affected pages or users, a named fix owner, due date, and retest plan. Escalate if broader sampling shows greater reach.
Tradeoff: Scheduled work preserves focus, but an evidence gap must not be silently converted into low impact.
The observation is cosmetic, low-reach, or an improvement idea with no demonstrated task, access, safety, data, search, or operational impact.
Choose: Use low or informational status, record why, and avoid displacing higher-impact work. Revisit when user evidence or broader recurrence appears.
Tradeoff: Some polish waits, but the backlog remains explainable and does not pretend that every audit note is a release blocker.
A tool reports an issue that the reviewer cannot reproduce or interpret within the current expertise and scope.
Choose: Record it as an unverified observation, capture the tool, version, URL, environment, rule, and evidence, then route it to the correct discipline rather than assigning false certainty.
Tradeoff: The row remains open longer, but it avoids false fixes, false passes, and unsupported compliance or security claims.
Move from evidence to scope
Turn accepted findings into a bounded improvement brief
Bring the open rows, evidence links, owner decisions, acceptance checks, current content, and provider boundaries into a Playcode project. Keep deferred and unresolved findings visible rather than asking a builder to infer them.
Start BuildingA generated change still requires qualified review, representative tests, production verification, monitoring, and recovery evidence for the affected scope.
Use Playcode AI SEO tools to research queries, competitors, and live SERPs while improving an owned page.Research and diagnostics can help prioritize work; they do not guarantee rankings or replace the worksheet evidence boundary.
What this template cannot prove
The worksheet makes evidence and accountability visible. The quality of the audit still depends on scope, expertise, representative sampling, methods, environments, user involvement, and production verification.
- Automated accessibility checks find only some barriers and can produce inaccurate results; manual and user-centered evaluation remain necessary.
- A general website audit is not a penetration test, threat model, code audit, legal review, privacy impact assessment, or compliance certification.
- A lab performance run is diagnostic evidence for that setup. Field data, page mix, device class, network, geography, cache state, and time can change the result.
- Search controls help crawlers interpret and discover content but do not guarantee indexing, canonical selection, visibility, rankings, traffic, or clicks.
- Representative samples reduce work but can miss rare templates, account states, locales, provider failures, content extremes, and low-volume journeys.
- Closing a row requires retest evidence from the relevant release and environment; a code diff, ticket status, or verbal confirmation is not enough.
Current audit-method references
The references below support specific parts of the worksheet method. They do not merge their scopes or authorize one reviewer to claim expertise in every discipline.
[w3c-wcag-em] W3C Web Accessibility Initiative:WCAG-EM Overview
Checked August 1, 2026. Supports: Accessibility evaluation scope, website exploration, representative sampling, sample evaluation, reporting, and required expertise boundaries.
[w3c-evaluation-tools] W3C Web Accessibility Initiative:Evaluation Tools Overview
Checked August 1, 2026. Supports: Automated tools as useful but incomplete and potentially inaccurate inputs that must not replace manual evaluation.
[w3c-easy-checks] W3C Web Accessibility Initiative:Easy Checks - A First Review of Web Accessibility
Checked August 1, 2026. Supports: Preliminary manual review examples for page title, images, headings, contrast, zoom, keyboard access, focus, forms, errors, and media, plus the non-comprehensive boundary.
[google-search-essentials] Google Search Central:Google Search Essentials
Checked August 1, 2026. Supports: Current technical, spam, and key-practice boundaries for Google Search eligibility and crawlable, useful public content.
[web-vitals] web.dev:Web Vitals
Checked August 1, 2026. Supports: Current Core Web Vitals metric set, field-measurement framing, percentile and device segmentation, thresholds, and evolving metric lifecycle.
[owasp-wstg] OWASP Foundation:Web Security Testing Guide
Checked August 1, 2026. Supports: Structured web-application security-testing categories and the boundary between general observations and qualified security testing.
Website audit template questions
How often should I audit a website?
Use event-based reviews for launches, migrations, provider changes, major templates, new regulated data, incidents, or primary-journey changes. Schedule recurring content, access, domain, certificate, provider, dependency, analytics, backup, restore, and representative page checks according to risk and change frequency.
Should I audit every page?
Inventory every known page and state, then decide which checks can be exhaustive and which need structured and random samples. Always include critical journeys, unique templates, high-value entry pages, private states, error states, extremes, and pages with known risk. Record the sampling boundary.
Can Lighthouse or another scanner complete the audit?
No. Automated tools can identify useful signals, but they do not understand every user task, content claim, permission, provider outcome, screen-reader experience, recovery path, security threat, or business rule. Record the exact tool result and combine it with qualified manual review.
What is the difference between an audit finding and a fix?
A finding records reproducible evidence that observed behavior differs from an expected condition. A fix is an accepted change intended to address it. The row remains ready for retest until the original acceptance check passes on the relevant release and environment without a material regression.
How should audit severity be assigned?
Assess user harm, blocked tasks, data or access exposure, reach, exploitability, misleading outcomes, operational loss, evidence quality, and release context. Do not convert a tool color or category directly into severity. Name the decision owner and record why the chosen level fits.
Does a website audit improve Google rankings?
An audit can identify crawl, canonical, content, link, rendering, performance, or policy issues worth fixing, but it cannot guarantee indexation, ranking, traffic, clicks, leads, or revenue. Track the intended owner and actual outcomes after verified changes instead of promising a result.
Is this a security or accessibility certification?
No. The template can hold observations and evidence from qualified reviews, but the file itself is not a penetration test, threat model, accessibility conformance evaluation, privacy assessment, legal opinion, or certification. Use reviewers and methods appropriate to the claim you need to make.
Keep the audit reproducible
Build, retest, and close one observable result at a time
Use Playcode to update the site or workflow from an approved brief, then repeat the original audit method on the actual release. Record evidence for the fix, neighboring states, monitoring, and recovery before closing the row.
Start BuildingPlaycode does not certify accessibility, security, legal compliance, rankings, conversion, or business outcomes.