You receive a proposal that promises a “complete SEO audit.” It lists technical SEO, content, links, and a final report.
It sounds useful. But what will you actually get?
Will someone check your main service pages by hand? Will they test your contact form? Does the price include fixing problems, or just finding them?
These details should be clear before you agree to the work.
An SEO audit proposal is a document that explains what an SEO review will cover, how the work will be done, what the client will receive, and what it will cost. It should also define access, timing, exclusions, and the next steps after delivery.
A useful proposal gives both sides the same picture of the job. Here is how to write one, review one, and spot missing details.
What should an SEO audit proposal include?
Use this table as a first check.
| Proposal section | What it should explain | A useful question to ask |
|---|---|---|
| Business goal | The problem the review will investigate | Which business decision will this audit help us make? |
| Website scope | Domains, sections, languages, and page limits | Is our blog or separate shop included? |
| Review method | Tools, data, and manual checks | Which pages will a person review? |
| Deliverables | Files, findings, and the action plan | Can our developer use the report? |
| Access | Accounts and permission levels needed | Why is each permission required? |
| Timeline | Start conditions, milestones, and delivery | When does the delivery clock start? |
| Fees | Included work, payment stages, and extra costs | What could increase the quoted fee? |
| Exclusions | Work outside the agreed scope | Are implementation and follow-up checks included? |
| Completion rules | How both sides will check delivery | What makes the audit complete? |
“Full audit” is too broad to answer these questions on its own. Ask for named tasks and clear limits.
1. Start with the business problem
The goal should explain why the audit is needed.
“Improve SEO” gives the reviewer very little direction. A more useful brief might say:
We want to understand why our main service pages get search impressions but few relevant visits, and whether visitors can easily request a quote.
That brief creates three areas to investigate: search visibility, the match between searches and pages, and the path to an enquiry.
It does not assume that changing a title will solve everything.
Ask the client to name their main services, target locations, best customers, and preferred enquiries. Also ask about recent site changes and known tracking problems.
A report about blog traffic may be accurate but still miss the point if the business needs more enquiries for one service.
Keep the proposal honest about outcomes. Google’s advice on hiring an SEO recommends realistic estimates of improvement and the work involved. It also warns against guaranteed first-place rankings.
Promise a clear investigation and useful evidence. Do not promise a search position that you cannot control.
2. Define which parts of the website are included
The SEO audit scope should name the website areas covered by the fee.
A company may have a main website, a shop on another subdomain, a help centre, and several language versions. One website address in a proposal may hide a much larger job.
Write down:
- The main domain and any included subdomains.
- The sections and languages to review.
- The crawl limit and how extra URLs will be handled.
- The pages selected for detailed manual checks.
- The search markets and devices being considered.
- Any access or data limits that may affect the findings.
Separate crawl coverage from manual review
A crawl collects information from pages. A manual review involves a person checking meaning, context, and user experience.
Those are different kinds of work.
For example, a proposal could include a crawl of up to 500 in-scope URLs and a detailed review of 12 named pages. Those numbers are sample scope choices, not industry standards.
The important part is naming the 12 pages and explaining why they matter. They might include the homepage, the main services, a contact page, and examples of common page layouts.
Also explain what happens if the crawl finds more URLs than expected. Does the reviewer pause, agree a new limit, or sample the extra pages? A silent cutoff can leave the client believing that every page was checked.
3. Describe Each Check and Its Limits.
A list of tools is not a review method. Explain what the tools and the reviewer will investigate.
| Area | Example checks | Boundary to make clear |
|---|---|---|
| Technical SEO | Broken links, redirects, crawl access, and indexing signals | Whether the review covers all sections or a sample |
| Search performance | Queries, pages, countries, and device trends | Data range and any missing account access |
| Page content | Whether key pages answer the right questions and explain the service | Named pages; whether writing is included |
| Internal links | Whether people and crawlers can reach important pages | Sitewide crawl versus selected user journeys |
| Page experience | Loading, response, layout movement, and mobile use | Tested pages and available real-user data |
| Structured data | Whether existing markup fits the visible page content | Review only versus new implementation |
| Enquiry path | Calls to action, forms, and confirmation messages | Whether test submissions and tracking checks are included |
Use a technical SEO checklist to help choose relevant checks. The final scope should fit the website, rather than include every possible test.
Make performance checks measurable
If a proposal includes Core Web Vitals, name the measures being reviewed.
Google’s Web Vitals guidance gives these “good” thresholds:
| Measure | What it describes | Good threshold |
|---|---|---|
| Largest Contentful Paint, or LCP | How quickly the main content appears | 2.5 seconds or less |
| Interaction to Next Paint, or INP | How quickly the page responds to an interaction | 200 milliseconds or less |
| Cumulative Layout Shift, or CLS | How much the layout moves unexpectedly | 0.1 or less |
These thresholds are assessed at the 75th percentile, with mobile and desktop considered separately. They are performance benchmarks, not promised traffic gains.
The proposal should say whether the review uses real-user data, controlled tests, or both. If real-user data is unavailable, the report should say so. One test of the homepage does not describe every visitor’s experience across the whole site.
4. Name the SEO audit deliverables
“You will receive a report” leaves too much open.
Ask for the format and purpose of each item. A practical package might include a short summary, a findings spreadsheet, supporting evidence, and a handover call.
Each confirmed issue should answer five questions:
- What is happening?
- Which pages or journeys are affected?
- Why does it matter?
- What should happen next?
- How will someone check the result?
Compare these two findings:
Vague: “Improve internal linking.”
Useful: “The main service page links to an old quote URL that returns an error. Replace the link with the current quote page. Then open the link on mobile and confirm the form loads.”
The second finding gives a developer or site owner a clear task.
Ask the reviewer to separate confirmed problems from ideas that need more evidence. A suspected cause of low traffic should not be presented as a proven cause.
Our SEO audit report guide explains how to turn findings into a useful action plan.
Include a priority method
An audit should help the client choose what to do first.
Ask for priorities based on business impact, confidence in the finding, effort, and dependencies. A broken enquiry path may deserve attention before a minor warning on an old page.
A high tool score is not a substitute for a working website and useful pages.
5. Agree account access before the start date
The reviewer should explain which data is needed and why.
For an audit, start with the least access that supports the agreed checks. Do not share your main account password.
Google’s Search Console permissions guide distinguishes between owners, full users, and restricted users. Full users can take some actions; restricted users have basic viewing rights for most data. These roles are not interchangeable.
If a planned check needs access beyond the agreed viewing permission, the reviewer should explain that need. The client can then decide whether to provide an export, perform the check themselves, or approve a specific change in access.
The proposal should also identify who grants access, when it is needed, and when it will be removed.
For contact-form testing, agree on a clearly labelled test enquiry. Tell the person receiving enquiries so it is not mistaken for a real lead. Avoid requesting customer messages when a summary or test record will answer the audit question.
6. Separate the audit from implementation
Finding a problem and fixing it are separate jobs.
A proposal should state whether the fee covers:
- Diagnosis and recommendations.
- Written instructions for a developer.
- Changes to the live website.
- Testing after changes are made.
- Ongoing monitoring.
For an audit-only project, a clear sentence might be:
This fee covers investigation, reporting, and handover. Changes to the live website require a separate agreed scope.
If implementation is included, name the changes or define an agreed allowance. “All fixes included” can become unclear when the review finds a problem that needs a redesign or outside developer.
Also record any restrictions. For example, a business may want to keep existing articles unchanged. The proposal can still include research and recommendations while making clear that no existing content will be edited, merged, or removed under that scope.
7. Set a timeline with clear start conditions
“Delivered in ten days” raises a question: ten days from when?
Define whether the timeline starts after approval, payment, access, or a kickoff meeting. Also distinguish business days from calendar days.
Here is an illustrative schedule for a small, agreed project:
| Stage | Example timing | What must be ready |
|---|---|---|
| Confirm scope and access | Before Day 1 | Named pages, business goals, and working access |
| Gather data and crawl | Days 1–2 | Site available and crawl limits agreed |
| Review pages and findings | Days 3–6 | Required data and client answers |
| Prepare report and action list | Days 7–8 | Important findings verified |
| Handover and questions | Days 9–10 | Client and reviewer available |
This is an example, not a standard delivery promise. A large shop, a multilingual site, or a difficult technical problem may need a different schedule.
Explain how missing access or major site changes affect delivery. If a redesign goes live halfway through the audit, both sides need to agree which version is being reviewed.
8. Make the fee easy to compare
Two proposals can use the same title but cover very different work.
One may include a crawl export. Another may include manual checks, business context, evidence, and a developer handover.
Compare what is included before comparing the price.
The fee section should state the currency, payment stages, included tools or costs, and what requires a new quote. It should also name any included review call or follow-up check.
Avoid treating a large page count as proof of value. A focused review of important pages can answer a business question that a much larger export does not address.
Ask this question before agreeing:
If the scope grows, who approves the extra work and when will we know the extra cost?
A written change process helps both sides avoid surprise work and surprise bills.
9. Define AI, AEO, and GEO work clearly
Some proposals now include AI visibility, answer engine optimization (AEO), or generative engine optimization (GEO).
Ask what those labels mean in the actual work.
For example, does the reviewer check whether important facts are clear, whether service details are consistent, and whether claims have useful evidence? Are they reviewing Google Search, another AI service, or both?
Google’s guide to generative AI search explains that established SEO practices remain relevant to its AI search features. Useful content and a clear technical structure remain part of the work.
A proposal should name the platform and method being assessed. Advice about Google’s systems should not be presented as a rule for every large language model, or LLM.
If the deliverable includes testing AI answers, record the prompts, platform, date, and observed answers. Treat the results as a limited snapshot. A single mention does not prove lasting visibility, and an audit cannot guarantee that an AI system will cite a business.
If AI tools help produce the audit itself, ask who checks their recommendations. Our AI SEO audit guide shows how to verify advice before acting on it.
A worked example: turn a vague proposal into a clear one
Imagine a fictional cleaning company with 80 public pages. It wants more enquiries for office cleaning.
The first proposal says:
Full SEO audit, competitor review, and recommendations.
That leaves the key questions unanswered.
A clearer scope could say:
Review the main English-language website, including a crawl of up to 100 in-scope URLs and manual checks of eight agreed pages. Review available search and enquiry data for the agreed period. Test the mobile route from the office-cleaning page to the quote form. Compare three named competitors’ relevant service pages. Deliver a findings sheet, a priority action list, and one handover call. Implementation is excluded.
The numbers are illustrative. They show how a proposal can become specific.
Now suppose the crawl also discovers a separate help centre with 400 URLs. The reviewer records it as outside the current scope and asks whether a separate review is needed. They do not quietly skip it or add an unexpected charge.
The client can also judge completion. They can confirm that the eight pages were reviewed, the enquiry path was tested, and the agreed files were delivered.
Copyable SEO audit proposal template
Use this as a scope worksheet. Fill in the brackets and remove anything that does not apply. It is not a complete legal contract.
Project: SEO audit for [business and website].
Business question: We will investigate [specific problem] to help the client decide [next business action].
Included website areas: [Domains, subdomains, sections, languages, and target markets].
Coverage: Crawl up to [number] in-scope URLs. Manually review [number and named pages]. Handle extra URLs by [agreed process].
Data and dates: Use [accounts, exports, and tools] covering [date range]. Record missing data and its effect on the review.
Checks: Review [named technical, content, performance, structured-data, and enquiry checks].
Deliverables: Provide [report format], [findings sheet], [priority action list], and [handover arrangement]. Each confirmed issue will include evidence, affected pages, a proposed next step, and a way to check completion.
Access: Request [specific permissions] from [responsible person]. Remove access at [agreed point].
Exclusions: This scope does not include [implementation, writing, other websites, ongoing monitoring, or other excluded tasks].
Timeline: Start after [conditions]. Deliver by [date or agreed duration], subject to [named dependencies].
Fee: [Amount and currency], with [payment stages and treatment of additional costs]. Extra work requires [approval process].
Completion: Confirm delivery against [agreed list]. Raise questions or missing items through [process and review period].
Next steps: After handover, [person or team] will decide which recommendations to approve and who will implement them.
Questions to ask before approving the proposal
Ask the provider to walk through one sample finding. It can come from an anonymized report or a clearly labelled demonstration.
Look for evidence, clear reasoning, and an action someone can carry out. Then ask:
- Which important pages will you check by hand?
- What will you do if the data is incomplete?
- How will you choose the first recommended fixes?
- Who will answer our developer’s questions?
- What is outside the fee?
- How will we know the agreed work is complete?
These questions reveal more than the number of checks printed on a sales page.
Frequently asked questions
What is the difference between an SEO audit proposal and an SEO audit report?
A proposal defines the work before it starts. A report presents the evidence, findings, and recommended actions after the review. The proposal should describe what the report will contain.
Does an SEO audit include fixing the website?
Only if implementation is included in the agreed scope. Check whether the fee covers recommendations, actual changes, and testing after those changes. Each should be stated clearly.
How much should an SEO audit cost?
There is no single price that fits every website. Compare the areas covered, manual review, data analysis, deliverables, and support. Ask for a clear quote based on your site and business question.
Should an SEO auditor need administrator access?
Do not assume administrator access is needed. Ask which specific check requires each permission. Many review tasks can begin with public pages, viewing access, or client-provided exports.
Can an SEO audit guarantee more clicks?
No. It can identify problems and useful opportunities, but clicks depend on factors beyond the audit itself. Judge audit delivery by its evidence and usefulness, then measure the results of approved changes separately.
Get a clear scope for your SEO review
Before paying for an audit, make sure you understand what will be checked, what you will receive, and who will handle the next steps.
If you want help defining that work, explore Worsoo’s SEO services. Share your website, main services, target locations, and the search or enquiry problem you want to understand. That gives the discussion a clear starting point.