The public website audit checklist
A useful audit starts with the same surface a search engine, AI crawler or ordinary visitor can reach — no login, no private credentials. That constraint keeps the evidence reproducible: anyone can re-run the same checks and compare findings before and after a fix.
Signal coverage across audit categories
Most sites have uneven coverage across audit categories. SEO on-page signals tend to be present because they are well-understood; privacy and accessibility signals lag. The chart below shows typical public signal coverage for an average site.
1. Confirm the origin and crawl boundary
Start with the canonical HTTPS origin. Verify the redirect chain from HTTP to HTTPS resolves cleanly (≤ 2 hops). Fetch robots.txt and check it is readable, then confirm the sitemap is declared there and returns 200. Record the final URL and response status for every observation.
2. Check whether each page explains itself
- One unique, meaningful
<title>element (30–60 characters) - A
meta descriptionthat matches the page content - One
<h1>aligned with the declared page purpose - A
rel=canonicalURL when multiple paths can represent the same content - Important content available in the initial HTML — not only after JavaScript executes
- Open Graph title, description and image for predictable social preview
3. Validate structured data and social previews
Structured data should describe the visible page rather than inventing claims. For each Schema.org block, confirm the @type matches the page purpose and that required fields — such as headline, datePublished and author on an Article — match what a reader can see.
Open Graph and Twitter metadata should have a stable title, description and image. A shared URL with a broken preview creates friction in distribution, which matters even if it is not a ranking factor directly.
4. Keep findings actionable
A good finding names four things: the rule or signal checked, the target URL, the evidence (the observed value or its absence), and a practical next action. Separate an unavailable external signal from a failed check; otherwise a missing integration looks identical to a false negative and cannot be prioritised correctly.
5. Re-run after fixes
Compare normalised URLs and stable finding fingerprints across runs. A finding that disappears should be marked resolved with a timestamp. A materially changed target — for example a URL that now redirects — should be treated as a new observation, not a continuation of the old one.
FluxRadar applies this public-only approach across SEO, AI discoverability, security headers, accessibility, reliability and privacy signals. Run a public website check →