Start with the decision the audit should support
A request to audit a website can mean diagnosing lost search traffic, reviewing a planned migration or identifying problems on a service-page template. Ask which decision the client needs to make and what prompted the request. A generic checklist may produce many findings without answering that decision.
Write a one-paragraph problem statement with the business context, affected markets and known constraints. List unanswered questions separately from confirmed facts. Do not describe a suspected indexing issue as an established cause before examining evidence, and do not price an unlimited investigation under the label of a quick audit.
Map the pages and systems in scope
Record the domains, subdirectories, languages and page types included. Note whether the site uses distinct templates, a separate shop, a blog or content rendered by JavaScript. Estimate the inventory from available evidence and identify any areas that cannot yet be counted reliably.
Define where the review is comprehensive and where it uses a sample. Select samples by meaningful variation, such as template and language, rather than only the most convenient URLs. Keep a list of excluded areas and explain what the audit will not establish about them. Page count alone does not describe investigation complexity.
Tie access and deliverables to the questions
Google’s guidance on hiring an SEO recommends examining what an audit involves and granting read access to Search Console at that stage. It also expects realistic estimates of potential improvement and the work involved, rather than a promise of first place. Use these principles to explain the evidence needed for your proposed investigation.
Specify the deliverable: a prioritized issue list with affected examples, reproducible evidence, implications, recommended actions and unresolved questions. State whether implementation, content rewriting, a review meeting or a later verification round is included. These are separate work items and should not be hidden inside an ambiguous report promise.
Illustrative scope for a bilingual services site
Imagine a fictional agency reviewing an Arabic and English services website before a redesign. The proposed audit covers the two public language sections, shared navigation and representative service templates. It excludes the private customer portal and paid campaign management. The quote names a review meeting and one clarification round as deliverables.
During discovery, the team finds an additional public product catalogue using a different platform. Instead of silently absorbing it or ignoring it, the agency records the new scope question and offers a separately defined extension. The example demonstrates boundary management, not a standard price or a claim about any real client.
Estimate effort with visible assumptions
Break the estimate into discovery, evidence collection, analysis, reporting and discussion. Identify dependencies such as receiving read access or confirming the URL inventory. Give uncertain items an explicit assumption and explain what finding would require revisiting it. A fixed price can still have a clearly bounded scope.
Before sending the proposal, check that each promised conclusion has a plausible evidence source and that each deliverable answers the original decision. Use an initial SEO review to refine the scope, then obtain agreement on the defined work. The audit should leave the client with justified priorities, not a guaranteed ranking or an unexplained tool score.