How to Do a Website Audit for a Client: A Practical Checklist and Process

A client audit succeeds or fails on one question: “Why should I trust this finding?” This guide walks through scoping, evidence collection, scoring, reporting, and pricing so every answer in your audit traces back to something the client can inspect.

Auditing your own site is forgiving. You know the history, you can re-check anything in seconds, and nobody asks you to defend a number. Auditing a client’s site is different. The client is paying for conclusions they cannot easily verify themselves, an implementer they hire later will challenge your findings, and a vague deliverable turns into an argument about scope. The process below is the one I use in my own evidence-led audit method, adapted for the specific pressures of client work: a written boundary, an evidence ledger, published scoring rules, a report written for two different readers, and a pricing structure that does not depend on promising outcomes you cannot control.

1. Scope the engagement in writing before you open a crawler

The most expensive audit mistakes happen before any data is collected. Agree these items in writing — an email the client confirms is enough:

• Canonical domain and allowed origins. Which hostname is the site of record, and which subdomains are in or out.
• Page sample. The full public site, or a bounded sample (for example, the pages in the sitemap on the observation date). Name the sample; do not leave it implied.
• Observation window. The dates your findings describe. A site is a moving target; your audit is a snapshot, and the report should say so.
• Exclusions. Staging environments, authenticated areas, third-party properties, paid-media accounts — anything the client might assume is included but is not.
• Deliverables. Exactly what the client receives: a report, a prioritized gap list, raw evidence, a walkthrough call, a re-run. Listing deliverables is also the foundation of your price.
• What the audit does not claim. State plainly that the audit documents observed conditions and does not predict rankings, traffic, or revenue. Clients respect this more than you might expect, and it protects both sides.

The scope document prevents the quiet failure where an audit starts with ten public pages, absorbs a help center and a staging URL mid-project, and then presents one percentage as if every page belonged to the same population.

2. Agree on the checklist and scoring rules up front

Send the client your checklist and scoring model before you start — not with the final report. Each check needs a name, a rule, and one of at least four states: observed pass, observed fail, not applicable (with a recorded reason), and unknown (evidence unavailable or outside scope). Unknown should earn zero credit rather than guessed credit. When the rules are agreed in advance, the final score is an application of a known procedure instead of a negotiation, and the conversation moves from “is this number fair?” to “what do we fix first?”

3. Collect evidence, not impressions

Every conclusion in the final report should trace to an observation the client can inspect. The practical tool for this is an evidence ledger: one record per observation, created as you work, each with a stable ID.

{
  "id": "sitemap-root",
  "source": "https://client-site.example/sitemap.xml",
  "observedAt": "2026-07-29T10:00:00Z",
  "observation": "Returned HTTP 200; 42 URLs listed",
  "confidence": "high"
}

Three habits make the ledger worth its overhead in client work:

• Record facts, not inferences. “Returned HTTP 200 during the review” is defensible. “Search engines can crawl the whole site” is a broader claim that one observation does not support.
• Timestamp everything. When the client’s developer says “that page has a title tag now,” you can answer “it did not on July 29 at 10:00 UTC” instead of arguing from memory.
• Keep raw material. Screenshots, response bodies, and the raw per-page rows behind any percentage. If your report says 70% of sampled pages have a meta description, another reviewer should be able to reproduce that figure from your rows.

When evidence is missing, resist the urge to fill the gap with judgment. Mark the check unknown and say why. A client audit with visible unknowns reads as more credible, not less, because it shows the boundary of what was actually verified.

4. Score with published rules — or skip the score

A score is optional. If you use one, publish the model first: which checks exist, how they are weighted, and the fact that the weighting is your operational model rather than an industry standard. A simple structure allocates fixed points to a handful of areas — for example discoverability, metadata coverage, content hygiene, and operational readiness — and awards credit only for observed passes.

The property that matters is traceability: total score → area → individual check → evidence IDs → original observation. If any link in that chain breaks, present the finding qualitatively instead of numerically. A precise-looking number with an untraceable origin is the fastest way to lose a technical client’s trust.

5. Write the report for two readers

Nearly every client report has two audiences with opposite needs, and most weak reports serve only one of them.

• The decision-maker needs one to two pages: what was reviewed, the top gaps in priority order, what each gap costs in effort to fix, and — explicitly — what was not verified. Lead with the boundary, not the score.
• The implementer needs the full detail: for each finding, the check name, its state, the evidence IDs behind it, why it matters operationally, a concrete suggested next step, and a rough effort size. An implementer who can jump from a finding to the exact observation that produced it will fix things instead of re-litigating them.

Two report rules keep you honest. First, priority order should reflect impact on the client’s stated goals and effort to fix — and you should say that this ranking is your professional judgment, not a computed certainty. Second, never let the recommendations section promise outcomes. “Adding meta descriptions to these 12 pages closes the largest coverage gap in this audit” is accurate. “This will increase your traffic” is a claim your evidence does not support.

6. Price the engagement on scope, not on promised outcomes

Because a well-scoped audit has a defined sample, defined checks, and defined deliverables, it prices naturally as a fixed fee. Estimate your hours across collection, scoring, report writing, and the walkthrough call, apply your rate, and quote one number tied to the written scope. Three structural choices are worth considering:

• Standalone diagnostic. The audit is the whole engagement. Cleanest to sell, and the report must stand alone without you attached to it.
• Audit credited toward implementation. Some or all of the audit fee is credited if the client hires you to fix what you found. This aligns incentives but disclose it in the report itself, since it means you benefit from finding work.
• Audit plus scheduled re-run. Sell the initial audit and a re-audit after an agreed implementation window as one package. The re-run is where the client sees progress, and it is much cheaper for you to produce because the scope and rules already exist.

Whatever the structure, two rules hold. Scope changes reprice: adding a subdomain or doubling the sample is a new quote, which is exactly why the boundary from step one is written down. And never price against outcomes you do not control — an audit fee contingent on ranking or traffic movement converts your honest snapshot into a sales document.

7. Re-run the same audit, and hand over the record

The re-audit is only meaningful if it is comparable: same scope, same page sample, same normalization rules, same scoring version. Save the before-and-after inputs, reports, and evidence ledgers with their observation dates. If anything changed — the sample, a rule, a weight — disclose it rather than presenting the two scores as a clean delta. A score can move because the site changed, because the evidence improved, or because the rules changed, and those are different events.

Finally, hand the client the full record: ledger, raw rows, and scoring definition, not just the PDF. It signals that the audit survives inspection, and it makes you the obvious choice for the next re-run, because you are the only party who can produce a comparable one.