What a website audit looks at, and what the report should tell you
The nine areas a proper website audit covers, what evidence each produces, and how to tell a useful report from a sales document.
The short answer
A website audit is a structured examination of a site and everything around it, producing findings with evidence and recommendations. A proper one covers nine areas: who owns the domain, hosting, code and accounts; the technical health of the site, its platform, dependencies and errors; speed as visitors experience it; accessibility against the standard; security posture; search visibility and what holds it back; content and structure against what the business needs the site to do; analytics and tracking, including what is measured and whether it is lawful; and the maintenance situation, meaning who does what, how often, and what would happen if they stopped. The report states each finding with evidence, a severity and a specific recommendation, separates what must be fixed from what could be improved, and is specific enough that a different partner could act on it. An audit whose only conclusion is that the site must be rebuilt, without that evidence, is a sales document. The most valuable findings are usually about ownership, security and maintenance rather than design.
The nine areas
| Area | What is examined | Typical findings |
|---|---|---|
| Ownership and accounts | Domain, registrar, DNS, hosting, repository, analytics, email, who holds what | Domain in a former agency’s name; no repository; shared logins |
| Technical health | Platform, versions, dependencies, errors, broken links, redirects | Outdated platform; failed updates; hundreds of not-found addresses |
| Speed | Real-user and lab measurements on key pages, mobile first | Heavy images; third-party scripts; render-blocking resources |
| Accessibility | Automated checks plus manual keyboard, screen reader and contrast tests | Missing labels; poor contrast; keyboard traps; no focus styles |
| Security | Headers, HTTPS, forms, secrets, dependencies, admin exposure, backups | Missing headers; keys in front-end code; no second factor; no tested backup |
| Search visibility | Indexing, structure, metadata, structured data, rankings, backlinks | Duplicate pages; missing metadata; thin content on key pages |
| Content and structure | Site map against offerings and audiences; clarity; calls to action; currency | Services not represented; outdated pages; no path to contact |
| Analytics and tracking | What is measured, whether it works, consent compliance, useful reports | Broken tracking; tracking before consent; no goals defined |
| Maintenance situation | Who updates, monitors, backs up, responds; documentation; what stops if they leave | Nobody; no monitoring; no documentation |
Reading the report
- Check the scope: which areas were examined and how, so you know what the report does not cover.
- Read the ownership and security findings first; they decide this week’s actions.
- Sort the rest by severity, then by how many visitors each affects.
- Look for evidence behind every major finding and ask for it where missing.
- Separate fix from improve: what is broken versus what could be better.
- Turn it into a plan with owners and dates, and revisit quarterly.
- Judge the recommendations by whether another partner could execute them from the report alone.
What we do with our own audits
One finding from auditing our own knowledge base is worth passing on. Of 242 external sources we checked in September 2026, 58, or 24 percent, could only be established in a rendering browser: 42 refused a plain request with a 403, seven failed to connect at all, and nine returned a page whose title existed only after scripts had run. A link checker that reads status codes would have called 49 of those dead and 9 of them fine, and it would have been wrong about all 58.
When we take over a site we audit it in all nine areas in the first weeks, write the findings with evidence, and put the ownership and security items first, because a site whose domain is in someone else’s name or whose keys are in its front-end code has a problem more urgent than any design. The report becomes the first quarter’s plan, and it is written so that if the client took it to someone else, that someone else could act on it.
What this means for you
A proper website audit covers ownership, technical health, speed, accessibility, security, search, content, analytics and maintenance, with evidence and specific recommendations, and it is useful regardless of who does the work next. Read the ownership and security findings first, turn the rest into a plan with dates, and treat any audit that ends only in a rebuild pitch without evidence as a sales document rather than an assessment.
Frequently asked questions
Is a free audit worth anything?
A free automated scan produces a score and a list of generic items, which is worth a glance. A real audit costs time because a person looks at the accounts, the code, the content, the analytics and the security posture, and writes findings with evidence. Free audits offered as a sales step tend to find that you need what the auditor sells. Judge any audit by whether its findings are specific enough that another partner could act on them.
What should we do with the report?
Sort by severity and by what it protects: ownership and security findings first, because losing the domain or being compromised are the worst outcomes; then speed and accessibility, which affect every visitor; then search, content and analytics, which compound over time. Give each finding an owner and a date, and revisit the list quarterly. The report is a work plan, not a verdict.
How often should a site be audited?
Fully when you take over a site, change partners or are considering a rebuild; lightly every year as part of maintenance, focusing on the areas that drift: accounts, security, speed, broken links, analytics. Sites under a monthly partnership are effectively audited continuously through monitoring and the monthly report.