How do you do a website audit?

What a website audit is

A website audit is a structured review of a site against a set of standards, ending in a list of problems ranked by how much they matter. A useful audit is evidence-based: every finding points at a specific page, response or element someone can check. A score on its own is not an audit.

For the full list of what to check, see the website audit checklist. This page is about how to run the audit.

Step 1: decide the scope

• What the site is for: selling, booking, signing up, informing. That decides which journeys matter most.
• Which hosts and sections are included: the marketing site, the blog, the app, subdomains.
• What you can access: only the public site, or also Search Console, analytics, hosting logs and the code.

Step 2: crawl the site

Collect every reachable URL with its status code, title, canonical, robots rules and response time. A crawl turns a vague site into a list you can sort. Compare it with the sitemap: pages in one list and not the other are often the first findings.

Step 3: review each area

• Technical: status codes, redirects, broken links, errors in the console, failed resources.
• Security: HTTPS everywhere, a valid certificate, security headers, cookie flags, nothing sensitive exposed.
• Speed: Core Web Vitals in lab and field data, server response time, page weight, images.
• Search: titles, descriptions, headings, canonicals, sitemap, robots, structured data, indexing status in Search Console.
• Accessibility: automated checks for missing alt text, labels, contrast and language, then keyboard and zoom testing by hand.
• Mobile: viewport, layout at narrow widths, tap targets.
• Legal and trust: privacy policy, cookie consent behavior, contact details, terms.
• Journeys: sign-up, checkout, contact and search, tested by hand from start to finish.

Step 4: write findings that can be acted on

Each finding needs four things: what is wrong, where (the exact URLs), the evidence (a status code, header, screenshot or measurement) and the severity. Group findings that share one root cause, such as a template, so the fix list does not repeat the same problem a hundred times.

Separate what was measured from what was judged. An automated check proves a missing attribute. Only a person can judge whether alt text is good.

Step 5: prioritize and fix

Fix in this order: anything that blocks visitors or crawlers, then security exposures, then broken journeys, then speed and search, then the long tail. After fixing, rescan the same scope and compare. A fix that is not verified is a guess.

Step 6: record the limits

Every audit has blind spots: pages behind a login, behavior under load, server internals, legal judgment. List them in the report. Unchecked areas written down are a to-do list. Unchecked areas left out become false confidence.

What a scan can and cannot tell you

WebAuditOS automates the crawl and the measurable parts of steps 2 to 4: technical health, security headers and TLS, speed, search basics, automated accessibility checks, mobile layout and legal links, each with evidence and a severity, and rescans to confirm fixes.

It cannot test journeys behind a login, judge content quality, review your code or give legal advice. Those parts of an audit stay with a person.

Use the scan for coverage and consistency, then spend human time where judgment is needed.

Short answers

How long does a website audit take? An automated pass takes minutes. A full audit with manual testing takes days for a large site.

What tools do I need? A crawler or scanner, Google Search Console, PageSpeed Insights and a browser with developer tools.

How often should I audit? Fully a few times a year, and with automated checks after every significant release.

What should an audit report include? Findings with URLs, evidence, severity, recommended fixes and a list of what was not checked.