Website Audit Checklist: A Practical Evidence-Based Review

Website audit checklist: define the scope and evidence

A website audit checklist is useful when it produces evidence that someone owns. Define whether the review covers the whole domain, one subfolder, or a template family. Require each finding to include the affected URL or system, the observation, the method and date, an owner, and a next action. The checklist is an operating aid, not a certification, compliance statement, security assessment, or accessibility-conformance claim.

Set a finishable review window and name the business outcomes that matter. A small brochure site and a large store require different samples, but both need a consistent evidence standard. Save screenshots or exports for visual and measured findings, record the conditions of each test, and rank consequences instead of copying a tool's score.

• Scope, business goal, and evidence date
• Exact URL, template, or account affected
• Observable finding and repeatable test method
• Named owner, consequence, next action, and retest date

Inventory URLs, templates, owners, and critical journeys

Reconcile the URLs available from the CMS, XML sitemap, analytics, and a crawl. Differences can reveal orphaned landing pages, retired campaigns, unexpected parameter URLs, or pages that the current publishing system no longer manages. Group the result by template so a defect in every article or service page is treated as one system problem rather than hundreds of unrelated tickets.

Name the journeys that create a lead, booking, application, or sale and test them by hand. Record who owns the domain, DNS, hosting, CMS, forms, analytics, email delivery, and other services behind those journeys. A page-level finding is difficult to resolve when the controlling account and decision owner are unknown.

Check search signals and internal discovery

Request representative URLs and review response codes, error pages, redirect chains, and destinations. Confirm the intended hostname and HTTPS version. For pages meant to appear in search, inspect titles, crawlable links, robots directives, canonical URLs, and whether the page is included in an XML sitemap. Google recommends listing the canonical URLs that you want shown in search rather than treating a sitemap as an inventory of every URL the server can return.

Inspect internal links as a visitor would. Important pages should have a logical route from navigation or related content, descriptive link text, and no dependence on an internal search box. Review broken links and pages that receive no internal links, then decide whether each should be connected, redirected, consolidated, or removed.

Review content accuracy, intent, duplication, and staleness

Verify claims that affect a decision: prices, service areas, hours, staff, contact details, policies, product capabilities, and guarantees. Record the source of truth and the person who can approve a correction. Then compare the title and opening answer with the question the page promises to resolve. A technically sound page is still weak when it does not satisfy its stated purpose.

Look for several pages targeting the same decision, repeated location pages with little distinct value, outdated products, and links to retired resources. Choose a primary destination before merging anything. Preserve material that remains useful, redirect an old URL only to a relevant replacement, and keep a record of the content decision.

Evaluate accessibility with automation and human checks

Run automated checks across representative templates, then use them as leads for human review. W3C's Easy Checks cover page titles, image alternatives, headings, contrast, text resizing, keyboard access, forms, labels, and moving content. Automation cannot decide whether an alternative description conveys the image's purpose or whether instructions and error messages make sense in context.

Use the keyboard to move through navigation, dialogs, forms, and the main conversion journey. Confirm that focus is visible, the order is understandable, controls have useful names, and the task can be completed without a pointer. Record barriers and affected templates. A formal conformance evaluation is separate specialist work; this review does not certify conformance.

Measure representative performance journeys

Measure the homepage, a common content or service template, the primary conversion path, and an unusually heavy or interactive page. web.dev identifies Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift as the current Core Web Vitals. Keep mobile and desktop evidence separate and save the test conditions so a later measurement is comparable.

Where sufficient real-user data is available, use it to choose priorities and use controlled lab tests to diagnose them. Record the largest visible content, blocking work, oversized media, layout movement, and third-party scripts with no clear owner. The audit should state what was observed and who will investigate rather than presenting a synthetic score as a complete description of user experience.

Test forms, bookings, payments, notifications, and analytics

Complete each critical transaction from the public page through its destination. For a form, verify validation, confirmation, email or CRM delivery, autoresponders, reply-to behavior, and an understandable failure state. Use a provider's documented test mode for payments when available, and do not create a real charge merely to finish an audit.

Check measurement during the same journey. Confirm the intended event occurs once at the correct step and that the documented consent behavior is working. Retain the test record, destination record, and analytics evidence together so a future reviewer can distinguish a working front end from a working end-to-end system.

• Primary contact or lead form
• Booking, application, or checkout path
• Transactional notification and reply path
• Conversion event and documented consent behavior

Review data, access, software, backups, and incidents

Inventory the personal information each form and integration collects, why it is needed, where it goes, who can access it, and how long it is retained. The FTC's business guidance organizes this work around taking stock, scaling down, locking information, disposing of it safely, and planning ahead. Escalate legal and privacy requirements to qualified counsel rather than turning this checklist into legal advice.

Review the accounts controlling the registrar, DNS, hosting, CMS, email, analytics, payments, and key vendors. Remove stale access, prefer named accounts, and use multi-factor authentication where available. Record supported software versions, backup contents and locations, the latest restore evidence, incident contacts, and any unresolved exception.

Turn findings into an owned, prioritized audit report

Deduplicate findings that share a root cause and rank them by user impact, business consequence, likelihood, dependency, and effort. Separate immediate containment from durable correction. Each accepted item needs an owner, due date, expected evidence, and retest method; each deferred item needs a reason and review date.

Keep a short executive summary above the detailed evidence: what was reviewed, what was not reviewed, the highest-consequence findings, and the next three actions. After fixes ship, repeat the original observation under comparable conditions and close the item only when the evidence changes. Your next action is to choose the critical journeys and create the URL-and-owner inventory that the rest of the audit will use.