A useful website audit does more than collect warnings. It checks whether important pages can be found, whether people can complete the intended task, and whether the business has reliable evidence that the task succeeded. Then it records each verified problem with an owner, a specific repair and a retest.
This guide is for a site owner or marketer who needs a repair plan across the site, not just a quick check before one campaign. Work from a representative page set, keep observations tied to exact URLs and devices, and do not label a recommendation as a defect until you can reproduce or verify it.
Start with scope and an accepted outcome
Write down the audit goal before opening a crawler or analytics report. Examples include checking whether a set of service pages can be indexed, testing whether a mobile enquiry journey creates a received lead, or finding why a key product template shifts while loading.
Choose representative page types, then add high-value exceptions. A practical sample might include the home page, one service or product page, one category page, one article, a form or checkout step, and one deliberately missing URL. If the site has multiple themes, languages, subdomains or logged-in journeys, record which are included and which are not.
Define the business outcome in operational terms. A button click is not the same event as an accepted enquiry. A checkout visit is not an order. If the audit needs to prove successful completion, identify the system of record, such as the CRM record or order status, and use an authorised test path. Never create a real purchase just to close an audit item.
1. Check crawl access, index signals and page responses
Open the exact public URL and verify the returned status, rendered page and primary content. Look for redirects to the intended canonical destination, accidental login walls, soft 404 pages, blocked resources and internal links that point to old URLs. Test a known missing route as a control so you can see whether it returns a real not-found response.
For pages intended to appear in search, inspect the page's robots instructions, canonical URL and visible initial HTML. Confirm the sitemap includes the canonical public URL and does not expose account, checkout or other private paths. A sitemap helps discovery; it does not prove that a page was indexed. Google explains crawling and robots controls in its crawling overview, robots documentation and sitemap guidance.
Compare pages that should be duplicates or near-duplicates. Check whether canonical tags point to the preferred URL, whether redirect chains end at that URL, and whether the page remains useful without relying on a crawler to perform an unavailable action. Google documents canonical consolidation in its guide to duplicate URLs and canonicalization.
Record: URL, response status, rendered content observed, canonical target, robots state, sitemap presence and the exact steps needed to reproduce any mismatch.
2. Review the key page templates
Do not attempt to read every URL with equal attention. First group pages by template, such as product detail, service detail, category, article, location page and form. Inspect one representative of each template, then sample important or unusual pages where prices, content, language or calls to action differ.
For each page, check that the title and main heading describe the page, the primary content is present, internal links lead to valid destinations, images have appropriate alternatives when they convey information, and metadata does not conflict with visible content. Review pagination and archive patterns when they create duplicate or thin paths. Check a rendered page, not just a crawler export, where client-side behavior could hide content or controls.
Keep shared-template defects separate from one-page content issues. A missing heading on one article needs a different owner and acceptance test from a theme template that omits the page title across an entire section.
3. Check that the offer and next step are clear
Read the page as a person arriving from the search result, email or campaign that links to it. Can they identify who the offer is for, what it includes, any important limits or price, and what happens after the main action? Compare the page with the promise made by the referring message. An attractive headline cannot compensate for a missing term or a broken handoff.
Verify facts against the current product and terms. Remove unsupported claims, obsolete prices and proof that cannot be substantiated. If two reviewers describe the offer differently after reading the same page, record the conflicting interpretations and the exact sentence or missing detail that caused them. That is useful qualitative evidence, not a controlled conversion result.
4. Test accessibility and mobile tasks
Complete the main task with a keyboard on desktop. Check that focus is visible, controls have understandable names, headings describe the section, errors are associated with the relevant field and dialogs can be reached and closed. Zoom the page and inspect text contrast. The W3C Easy Checks are useful for finding common issues, but they are not a complete accessibility evaluation or a compliance certification.
Repeat the task at a narrow viewport on a real phone or a trustworthy device emulator. Test the navigation, form fields with the software keyboard open, validation errors, back navigation and the success state. Check that chat, cookie notices or sticky controls do not cover the action. Note the viewport and browser so another person can repeat the same route.
5. Diagnose performance on affected pages
Measure the pages that showed a user-facing problem, not only the home page. Record the device, network and test method. Field data describes visits from real users across their varied devices and connections. Lab data is useful for reproducing and diagnosing a controlled load; it is not a substitute for field data.
Identify the element behind the symptom before changing code. A late hero image, a slow server response, expensive client script, unreserved media space and a font swap can produce different problems. Use a performance report and the browser's performance tools to connect the reported metric to a page element and loading step. The web.dev Core Web Vitals guide describes the user-experience measures and current assessment approach.
After a change, retest the same URL and conditions where practical. Check that scripts removed or delayed for speed did not break analytics, consent, navigation or the actual task. A better lab score alone does not establish a business outcome.
6. Verify accepted conversion records
Write down the accepted outcome for each form, checkout or signup flow. Check the visible validation state, success state and the record created by the receiving system. Confirm that a failed request does not show success, a repeated click does not create duplicate records, and a clearly labelled test is excluded from business reporting.
Use the analytics debugger to check that the intended event and parameters are emitted. Google's GA4 DebugView documentation explains how to inspect debug events. Then reconcile an authorised sample with the CRM, order system or other record of completion. DebugView verifies instrumentation for the test; it does not prove that every visitor is measured or that an event caused a sale.
Document limits such as consent choices, ad blockers, cross-domain handoffs or an unavailable payment sandbox. Do not bypass a visitor's privacy choice to make a report look complete. If you cannot safely reach the final step, mark it unverified and name the access or test environment needed.
Build an evidence log that someone can act on
Use one row per reproducible finding. Separate what you observed from what you suspect, and define acceptance before the repair starts.
| Finding | Evidence to record | Owner | Acceptance and retest |
|---|---|---|---|
| A page is not reachable | Exact URL, status, redirect destination and reproduction steps | Site or platform owner | Intended public URL loads with the expected response and content |
| A form does not complete | Device, field values used, visible error or success state, and system record | Form or operations owner | A labelled test creates one accepted record and shows a clear confirmation |
| A template causes layout shift | Affected template, element that moves, viewport and measurement source | Frontend owner | The same template no longer shows the reproduced movement under the test conditions |
| A page has conflicting search signals | Canonical, robots state, sitemap entry and rendered source | SEO or platform owner | Signals point to the intended public URL and are verified after deployment |
Set severity from the observed impact and reach. A broken accepted-action path on a high-priority template is more urgent than a minor wording issue. Record the number of affected URLs only when you have checked the template or sample that supports that estimate. Assign one responsible person and a retest date, not a vague group.
Illustrative priority example
Suppose a fictional service page has three observations: the offer is hard to distinguish from a general service list, an image delays the main content on a phone, and a test enquiry shows a success message but no test record reaches the CRM. This is an illustrative scenario, not a customer result.
The missing record is first because a visitor can complete the visible form while the business receives nothing. The form owner traces the handoff and defines acceptance as one labelled test record plus one clear confirmation. The content owner clarifies the offer next. The frontend owner investigates the measured image delay without removing scripts blindly. Each repair has separate evidence and a repeatable retest.
Diagnostic order and a reusable worksheet
Work in this order so that later measurements are not built on a broken journey:
- Confirm scope, representative URLs and the accepted outcome.
- Verify public access, response codes, canonical destinations and index controls.
- Reproduce the page or task problem on the stated device.
- Check the real completion record and measurement event.
- Investigate accessibility, mobile interaction and performance symptoms.
- Assign severity, one owner, an acceptance check and a retest date.
- Re-run the same check after the change and record unresolved limits.
Copy this worksheet into your issue tracker or audit notes:
| URL and template | Device or method | Observed evidence | Severity | Owner | Next fix | Acceptance test | Retest date |
|---|---|---|---|---|---|---|---|
Avoid closing a finding because a score changed, a plugin was installed or a warning disappeared. Close it when the original problem is no longer reproducible and the acceptance check passes. For a narrower review before paid traffic, use the pre-campaign website audit checklist. For loading and interaction symptoms, see how to diagnose Core Web Vitals.