Compare SEO Audit Proposals Before You Hire

Two proposals can both call themselves an SEO audit and still describe very different work. One may deliver an export of warnings; another may explain what the warnings mean, which pages they affect, who should act and what to do next. A long report is not proof of a thorough audit. You should be able to see what will be checked, how the auditor will support each conclusion and what your team can decide afterward.

Google’s hiring guidance suggests interviewing potential SEOs, asking for examples, discussing how success will be measured and asking what changes they would make. It also says an auditor should explain the reasoning behind recommendations and that site owners should review the work carefully (Google’s guide to hiring an SEO). This article applies those ideas to one specific purchase: comparing audit proposals before you sign. It does not revisit fee ranges. For the work an audit can cover, see our technical SEO audit guide; for price factors and ranges, use the technical SEO audit pricing guide.

Start with the decision you need the audit to support

Before you request proposals, write down in one sentence what decision the audit should help you make. Perhaps you are deciding whether to migrate platforms, trying to understand why a section of the site is not appearing in Search, preparing a redesign, reviewing a large online store or choosing what to fix next quarter. “We want better SEO” does not define an assignment. It does not say what is at stake or how you will know whether the analysis helped.

A clear brief stops each provider from solving a different problem. If one proposal covers a migration and another offers a general review of every template, their fees may not be comparable because they answer different questions. State the objective, the markets and languages the site serves, the type of site, the areas that concern you and who will need to act on the findings. You do not have to diagnose the cause in advance. Describe what you have observed and why you want it investigated.

Add context where you have it: the CMS, unusual technology, an approximate page or product count, recent changes, teams that will need to take part and the analytics systems available. Separate an observation from a theory. “Since the migration, we have seen fewer indexed pages in this directory” is something the provider can investigate. “Google has penalised us” is a hypothesis; the provider should explain what evidence would be needed before accepting it.

Set boundaries, too. Say whether you want diagnosis alone or implementation as well; whether certain directories, countries or page types are outside the assignment; who can approve changes; and whether the report is for developers, marketing or leadership. A narrow review can be more useful than an exhaustive one when there is a precise question to answer. The important part is to put exclusions in writing so they do not appear as a surprise at handover.

Turn the scope into a fair comparison

Ask every provider to answer the same questions. Their methods do not have to be identical, but you need to know what each one will examine and what will remain outside the work. This table can help you compare proposals:

Do not turn the table into a final score. A 4.2 out of 5 does not measure audit quality. Use it to find gaps. When two proposals differ sharply, ask what would change in the sample, tests or recommendations if you chose the narrower scope. The answer often tells you more than a promise of a “complete analysis”.

Ask for an anonymised example of a finished finding, not only a software screenshot or the cover of a report. It should explain the issue in plain language, show an affected URL or pattern, provide evidence, describe a possible consequence and propose an action. If the provider cannot share client material, they can prepare a generic illustrative example and label it as fictional. You are trying to see the level of detail, not pass off a demonstration as a real result.

Ask what “full audit” means in practice

“Full audit” has no single, agreed scope. Reviewing every URL may be practical for a small site with a few templates. An online shop with filters, pagination, product variants, several markets and thousands of products usually calls for automated checks combined with a considered sample of pages and patterns. A large crawl count may look impressive, but it does not tell you what the results mean or what was left unchecked.

Ask for a coverage map that names the areas in scope. A technical review might cover crawling and indexation (including robots.txt, noindex directives and XML sitemaps), canonical tags, structured data, Core Web Vitals such as LCP, internationalisation through hreflang, and analytics. These are examples, not a mandatory checklist. Depending on the question, the work may also need to examine content, information architecture, a migration or spam risks. No proposal needs to include every topic. If an area does not relate to your objective, you may not need to pay for it now. If it matters to the assignment, ask how it will be analysed and what evidence you will receive.

The sampling method matters. Will the provider select URLs from every template, or only pages with the most traffic? Will they check pages that convert, pages that lost visibility and newer pages? Will they examine examples in each language? Does the site need JavaScript rendering for a crawl? What data will be used to confirm that the sample is representative? A useful answer gives rules you can review, not just a list of tools.

Google describes Search as an automated process in which crawlers discover pages and add them to its index. A technical audit can investigate obstacles that stop Google from finding, crawling or understanding content, but an audit cannot decide by itself which pages Google will show. Google explains this process in its SEO Starter Guide. That is why crawl volume should not stand in for analysis. Look for a connection between a technical signal and a decision: change a rule, validate a template, protect a migration or accept that another factor needs investigation.

Ask for the limits of the work as well. Tool constraints, an incomplete sample, unavailable data, CMS restrictions and changes that require a developer may affect what the auditor can conclude. Listing these limits is useful: it shows which conclusions are supported and which would need another test. Be cautious of a report that labels every automated warning a “site problem” without checking whether it affects relevant pages.

Judge the findings, not the PDF length

A recommendation becomes actionable when the report says what the auditor observed and how they know. Ask whether significant findings will include the following:

1. Observation: what was found and on which URL, template or segment.
2. Evidence: a capture, response, data point, example or test you can verify.
3. Interpretation: why it could matter to crawling, indexation, understanding or the user experience.
4. Extent: how many pages or patterns appear affected, and what has not been checked.
5. Proposed action: a change described precisely enough for someone to assess it.
6. Reasoned priority: likely impact, confidence, effort, urgency and dependencies.
7. Validation: how to confirm that the fix was applied and what signal to watch afterward.

Not every finding needs seven long sections. A localised issue may take a few paragraphs; a change affecting thousands of URLs needs more context. In either case, someone who did not take part in the audit should be able to follow the reasoning without guessing what the author meant.

Keep priority separate from severity. A technically striking issue may affect few pages; a less dramatic issue may repeat across a template used by many important pages. Ask the provider to explain how they connect an issue to pages and business objectives. “Critical” is not evidence. The auditor should be able to show what makes a task urgent and say what new information would change that assessment.

Look for alternatives. There may be more than one sensible fix: revise a template, limit a filter combination, consolidate pages, improve internal links or leave the current state alone. A good recommendation explains its main cost or dependency, along with the situations where it would not apply. If a recommendation involves removing content, changing URLs or altering indexation rules, the plan should state who will assess the impact and how the change will be checked before and after.

The priority list might be a shared spreadsheet, a backlog or part of the report. The format matters less than the information it carries: the action, evidence, affected pages, suggested owner, urgency, dependency, estimated effort and completion test. Any impact estimate should be a hypothesis, not guaranteed revenue. The point is to help your team choose a next task, not dress an intuition in a precise-looking percentage.

Find out who will do the work

Ask who leads the audit, who performs the analysis, whether any work is subcontracted and who will answer your questions. If you speak to one person during the sales process but someone else will produce the report, ask to meet the people doing the work and understand their availability. You do not need an organisation chart. You do need to know who makes decisions, what experience is relevant to your platform and whom to contact if two findings conflict.

Google recommends interviewing prospective SEOs, asking for examples and references, discussing relevant industry and geographic experience, and clarifying communication and the reasoning behind proposed changes (Google’s hiring guidance). Adapt those questions to the audit team: which parts will they perform directly? How will they document recommendations? How will they distinguish Google’s published guidance from their own interpretation? What will they need from your team to finish the analysis?

Agree on checkpoints before the work starts. A short kickoff can confirm the objective and access. For a broad assignment, an interim review of early findings may help if the audit uncovers an issue that needs prompt attention. The handover should leave time to explain the report and clear up misunderstandings. Put these moments in the proposal; do not assume “delivery” includes more than a link to a PDF.

List follow-up separately. Record how many question sessions are included, for how long, whether the provider will review implementations and where that review ends. An audit and implementation are different jobs, even when they are sold together. If the same provider offers both, ask how diagnosis will stay separate from the sale of fixes and who will approve each change. One team may reduce handovers, but you should still be able to see which observations support additional work.

Give access carefully and keep control

Before approving permissions, ask which system the auditor needs, for what task and for how long. An audit may use Search Console, analytics, a crawler, a CMS, server data or third-party tools. A project rarely needs every source. Start with the data required to answer the question, and agree how sensitive information will be shared.

For an SEO audit at this stage, Google recommends granting read access to Search Console and not write access. Google makes this recommendation in its guide to hiring an SEO. Search Console distinguishes owners, full users and restricted users. Owners have full control; full users can see all data and take some actions; restricted users have read access to most data. The role differences are set out in Google’s Search Console permissions documentation. Choose the permission level that fits the work and check the exact capabilities attached to the property.

An auditor who is analysing data does not need to change the site settings. If a later phase calls for publishing a fix, separate that work from the diagnosis: agree on the change, who is responsible and how to reverse it. Do not share personal passwords to solve an access problem. Use the account and permission controls provided by each platform, then remove access when the work is done. The proposal can state when access ends and how data copies will be handled.

Make an access list before the start date. For each item, record the tool, permission, person who grants it, purpose and removal date. If a provider asks for owner permissions, FTP, CMS administration or production access, ask why that level is essential to an audit and whether a narrower alternative would work. Without a clear reason, pause that request and keep the review read-only.

Agree on what the data and promises mean

A proposal may promise to “improve rankings”, “recover traffic” or “fix indexation”. Ask what observable measure each phrase refers to and what hypothesis can be tested. A confirmed crawl directive issue, a decline in clicks across a page group and a recommendation with an uncertain impact are different kinds of statements.

Search Console defines clicks, impressions, click-through rate and average position separately. Average position uses the topmost result for a property or page in each impression and averages those values. The definitions are set out in Google’s documentation on clicks, impressions and position. Ask which dimension the audit will use, which dates it will compare, how it will segment pages and queries, and what the metric cannot tell you. A site-wide average position does not describe the experience of every person searching for a particular URL.

For an audit, immediate success may mean that your team receives a verifiable diagnosis and a task list it can understand. The effect of fixes in Search can be assessed later, and it may depend on other factors. Google says some changes can take effect within days, while it can take several months for its systems to assess site-wide improvements; it also says changes may have no noticeable effect and that rankings are not fixed. See Google’s guidance on core updates and timing. A specific ranking promise or guaranteed date is not a measurement plan.

Question any forecast. If a proposal estimates growth, ask which data supports it, what assumptions it makes and how uncertain the estimate is. Keep work metrics, such as confirmed issues and validated fixes, separate from business outcomes such as sales or enquiries. A provider can discuss targets. A future correlation should not be presented as a guaranteed result.

Google says third-party SEO tools do not have access to its internal ranking data, and using a service or tool does not guarantee better rankings. These limits are in Google’s guidance on third-party SEO tools and advice. A tool can help find patterns. What matters is what the specialist checks and how they interpret the result for your site, not the number of software logos in a proposal.

Warning signs that deserve a pause

One awkward phrase does not prove bad practice. Ask for an explanation and assess the answer. These claims or requests deserve a pause until you understand them:

• A guarantee of first place, a precise amount of traffic or recovery by a fixed date.
• A claim of a special relationship with Google or privileged access to its internal data.
• No named person responsible for the work, or an unwillingness to explain proposed changes.
• A generic audit sent without questions about your site, objectives or market.
• A request for write or administrator access before the provider has explained why it is needed.
• Tool alerts presented as confirmed errors without verifiable examples.
• Large changes to URLs, content or indexation proposed without a validation plan.
• Pressure to buy implementation work before the diagnosis has been explained.

Google says no one can guarantee a number-one ranking and advises caution when an SEO promises rankings, claims a special relationship or is secretive about their methods. That warning appears in Google’s advice on hiring an SEO. Google also says the site owner remains responsible for the actions of companies they hire. Ask the provider to explain any step you do not understand before you grant permissions or approve a change.

Make the decision on one page

After the interviews, summarise each proposal on a single page. Note the problem it will address, what it will review, how it will select its sample, what evidence you will receive, the exclusions, the person responsible and the support available afterward. Add the permissions requested and the questions still open. If you cannot explain to a colleague why one proposal fits, you do not have enough information to decide yet.

Do not choose by page count, number of tools, adjectives or promises. Choose the proposal that best connects your objective with a reproducible analysis and a plan your team can take on. A small company may need a bounded diagnosis and a useful conversation. A site with several platforms, markets and teams may need a formal sample, technical coordination and follow-up. Let the complexity you described set the size of the assignment, rather than a sales template.

Before signing, document the scope, deliverables, milestones, fee and payment terms, exclusions, data handling, permissions, ownership of the documents and the process for ending or extending the work. This is a practical checklist, not legal advice or a substitute for reviewing a contract. If a term changes your rights or responsibilities, ask a qualified professional in your jurisdiction.

Prepare a one-page brief and send the same version to two or three providers. Use the same comparison table in each conversation. Methods may differ, but every provider should explain their choices, the limits of the analysis and how a finding becomes a task someone can verify.

Frequently asked questions

What should an SEO audit proposal include?

It should state the objective, areas to be reviewed, site size or sample, required data and access, deliverables, exclusions, who will do the work, the schedule and any follow-up support. It should also explain how findings will be documented and how recommendations will be prioritised.

Do I need to give an SEO auditor administrator access to Search Console?

Not for an initial audit. Google recommends granting read access to Search Console at this stage. Ask which properties and data the provider needs; write or owner permissions need a separate, explicit reason.

Does an SEO audit include implementing the fixes?

Not necessarily. Some proposals cover diagnosis and recommendations only; others add specifications, handover meetings or implementation. Check what is included, who owns each task and how out-of-scope changes will be priced.

Should I choose the cheapest or the most detailed SEO audit proposal?

Neither label should decide for you. Compare proposals against the same brief and consider how much risk and work each deliverable removes. A long checklist is of little use if it does not identify affected pages, evidence and a next step; a narrower scope may be enough when it answers a specific question.

Can an SEO agency guarantee that my site will rank first?

No. Google says no one can guarantee a number-one position in its results. A serious proposal can set out hypotheses and explain how the work will be measured, but it must acknowledge that rankings change and improvements do not guarantee a visible impact.