1. What is evaluated
An audit covers thirty-two checks grouped into six categories: technical and crawlability (7 checks), performance (6), SEO and content (7), UX and accessibility (6), conversion and analytics (2), and security (4). The individual checks are listed on the comprehensive website audit page and each category has its own detail page.
The crawl covers the homepage plus every page linked directly from it — one level deep, up to 9 pages in total for very link-heavy homepages. Most checks are evaluated from the fetched HTML, headers and response status of each page. Three checks — keyboard operability, screen-reader signal and live analytics event firing — are additionally validated with real browser automation, since they depend on how the page behaves when it is interacted with rather than on what sits in the markup. Wider or deeper crawls are available as a scoped add-on.
2. How findings are identified
Every check is evaluated automatically — most from the fetched HTML and headers, and three (keyboard operability, screen-reader signal and analytics event firing) from real browser automation that interacts with the live page. Every finding, from either evaluator, is reviewed by the auditor before it enters the report: automated checks produce candidates, and the auditor decides what is a finding, what is a false positive, and what is technically true but not worth your time. That review — and walking you through it live — is what a W3Audit engagement adds on top of the automated pass.
Anything discarded during review is discarded silently rather than listed as a passed check. The report is a list of things worth acting on; padding it with dismissed candidates would make the priority order harder to read, not easier.
3. How findings are categorised
Each finding belongs to exactly one category — the one where the fix lives. An image with no alt text is an accessibility finding, not an SEO finding, even though it affects both; the report cross-references the second effect rather than counting it twice. Findings that share a single root cause are merged into one entry with the affected URLs listed underneath, and component-level problems are reported at the component with the pages that render it.
4. How severity is determined
Severity is assigned from three inputs: blocking (does the issue prevent access, indexing or task completion outright), reach (what share of pages and of traffic is affected), and consequence (what it costs when it happens).
- Critical — Blocks access, indexing or a revenue-critical task, or exposes traffic. A single instance is enough — one unlabelled checkout field, or any page served over plain HTTP, is critical regardless of scale.
- High — No hard block, but a measurable loss across a meaningful share of the site: failing Core Web Vitals on major templates, duplicate metadata across a section, missing structured data on commercial pages.
- Medium — A real defect with limited reach or indirect cost: a redirect chain, shallow content on a secondary page, inconsistent heading levels.
- Low — Correctness and hygiene items worth fixing when the file is open anyway. Reported for completeness and excluded from the top-priority list.
Each finding also carries an independent effort estimate — small, medium or large — based on whether the fix is a content edit, a template change or structural work. Severity sets the order, effort breaks ties, which is why a critical twenty-minute fix appears above a critical two-week one.
5. How scores are calculated
Each category scores from 0 to 100. A category starts at 100 and loses points per finding, weighted by severity and by the proportion of audited pages affected:
category score = 100 − Σ ( severity weight × share of pages affected )
severity weights critical 40 · high 20 · medium 8 · low 2
share of pages affected pages ÷ audited pages, floored at 0.25
for any critical or blocking finding
score floor 0
The floor on share matters: a critical finding on two pages out of two hundred still costs at least a quarter of its full weight, because blocking issues are not proportional to their page count. The overall health score is the mean of the six category scores, rounded to the nearest whole number. Categories are not weighted against each other, so a site cannot buy back an accessibility failure with a strong security posture.
6. What counts as passing
Scores are read in bands, and the same bands apply to category and overall scores:
- 85–100 · Healthy — No critical findings and no significant reach on high findings. Maintenance, not remediation.
- 70–84 · Solid, with gaps — No blocking issues, but enough accumulated loss to be worth a planned piece of work.
- 50–69 · Needs work — Either a critical finding or broad high-severity loss. This is where most sites arrive before their first audit.
- Below 50 · At risk — Multiple critical findings, or one critical finding affecting the whole site. Treat as urgent.
A check passes when it produces no finding at or above medium severity. There is no partial credit at check level — the granularity lives in the score, not in the pass mark.
7. How to read your results
Read the report in this order. Start with the critical list and ignore the scores entirely: those items are the reason you commissioned the audit. Then look at category scores to see where systemic weakness sits — a category in the 40s usually means a template or design-system problem rather than a set of page-level mistakes. Only then read the high and medium findings, which is where the effort estimates earn their place.
Two cautions. Scores are comparable to your own future scores, not to another site’s: they depend on crawl scope, so a hundred-page site and a ten-thousand-page site are not measured on the same denominator. And a perfect score is not the goal — the goal is no critical findings and a clear reason for every remaining one.
8. Re-audit
One re-audit is included once your fixes ship. It repeats the same crawl scope and the same checks so the scores are directly comparable, and reports three things: findings resolved, findings still open, and anything new that appeared since. Regressions are common after a release, which is the reason the re-audit exists.
Next: the website audit checklist covers the same ground in a form you can run yourself, and each audit category page explains its own checks in more detail.