What is a website audit?

An audit is defined by its check list, not by its tooling. The categories below are the ones that recur across published guidance, and each corresponds to a class of defect a visitor or a search engine can observe from outside the server.

Availability and status: which URLs answer, which return a 4xx or 5xx, which redirect, and how long the redirect chains are. A page that answers 404 from an internal link is a defect regardless of what it would have contained.

Technical SEO: the presence and uniqueness of titles and meta descriptions, canonical tags, heading structure, robots directives, the sitemap, and whether the robots.txt allows the pages you want indexed.

Performance: how long a page takes to become usable, and which resources dominate that time. Google publishes the Core Web Vitals thresholds that define 'good' here.

Accessibility: the machine-checkable subset of WCAG — image alternatives, form labels, contrast, document language, heading order. Machine checks cover a minority of the success criteria; the rest need a person.

Security and transport: whether HTTPS is enforced, which security headers are present, and what the TLS configuration allows. This is configuration review, not intrusion testing.

Content and markup: duplicate titles, thin or empty pages, broken images, missing alternative text, and structured data that does not match the page it describes.

Most free testers take one URL and report on it. That answers a narrower question than the one most people have: a site's home page is usually its best page, because it gets the most attention. Problems concentrate in the pages nobody looks at — old posts, filtered category listings, pages generated from a template that was changed once.

The difference matters for prioritisation. A missing meta description on one page is a small task; the same defect on four hundred pages is a template bug. Only a crawl of the whole site distinguishes the two, and the distinction is what turns a list of findings into a plan.

1. Fix the boundary first. Decide which host, which subdomains, and whether parameters and filters count as separate pages. An audit with an undefined boundary produces a page count nobody can reproduce.

2. Discover the URLs. Start from the home page and follow internal links, then reconcile with the XML sitemap. The gap between the two is itself a finding: pages in the sitemap that no link reaches, and pages reachable by link that the sitemap omits.

3. Check what robots.txt permits before concluding anything about coverage. A section absent from an audit because it was disallowed is a very different fact from a section that does not exist.

4. Apply the checks uniformly, and record the evidence — the URL, the status code, the header, the element. A finding without its evidence cannot be verified, and will be argued about instead of fixed.

5. Group by cause, not by page. Four hundred instances of one template defect is one task.

6. Re-run after the fixes. An audit whose findings are never re-measured is a document, not a process.

Most reports rank findings by severity, which is a property of the defect. Priority is a property of your situation, and the two diverge often enough that taking the ranking at face value wastes the first week of work.

Three questions turn one into the other. How many pages does it affect — one, or a template applied to a thousand? Who meets it — a visitor on the checkout path, or a crawler on a page nobody links to? What does fixing it cost — a configuration line, or a rebuild?

A 'critical' finding on a single orphaned page usually loses to a 'moderate' one on every product page. The report cannot know that, because it cannot know which pages earn you anything. That judgement stays with you, and it is the reason an audit is an input to a decision rather than the decision itself.

One caveat worth holding on to: an absence of findings in a category is not a clean bill of health in that category. It means the checks that ran found nothing. What was not checked, and what could not be reached, matters as much as what failed — which is why a report that hides its coverage is hard to act on.

Every step above can be done by hand, and for a ten-page site that is a reasonable afternoon. What does not scale is step 4 on a site of any size: applying the same several hundred checks to every page, and keeping the evidence for each result.

VeriFixScan crawls the site, applies its check catalogue to the pages it reaches, and attaches the observed evidence to each finding. It also reports what it could not reach and why, because coverage you cannot see is coverage you cannot trust.