The short answer
An SEO audit should explain what needs attention, show evidence and affected pages, connect findings to business priorities, and specify who should fix each issue and how the fix will be checked. Request explicit scope, exclusions, editable tasks, and implementation and retesting terms. A scanner export can support the audit, but it is not a substitute for a diagnosis.
The proposal promises hundreds of checks.
Check: Does it name the business questions, page types, and manual review method?
Next: Request a coverage plan rather than accepting the check count as evidence of depth.
Every finding is marked urgent.
Check: Are business exposure, confidence, effort, and dependencies explained?
Next: Ask for a short first batch of work with reasons for its order.
The sample report contains only charts and scores.
Check: Can a developer reproduce an issue from the evidence?
Next: Request an example task with affected pages and a testable completion condition.
The price includes an audit but says nothing about fixes.
Check: Are implementation, questions, and post-release checks included?
Next: Have each activity listed separately before approving the scope.
Define the decision the audit must support
Start with the question you need answered: why important service pages are missing from search, which problems should be addressed before expansion, or whether a redesign is ready to launch. These require different investigations. My recommendation is to buy a defined diagnosis, not a promise to inspect everything. A useful scope names the business goal, relevant markets, important page types, available data, and decisions the report should support.
A technical SEO review examines how search engines access, process, and interpret your pages. It does not automatically include a full content strategy, conversion study, or backlink investigation. For a broader engagement, the SEO support options should still be translated into named deliverables. If the concern is a redesign or domain change, use a dedicated website migration checklist; a general audit can miss the need to compare old and new page destinations.
Separate a scan from a manual diagnosis
A crawler is software that follows links and records page properties. It can identify repeated titles, broken destinations, or instructions that prevent indexing. It cannot independently decide whether an excluded page should appear in search or whether two similar pages serve different customers. Ask the auditor to distinguish observed conditions, suspected causes, and confirmed defects. A warning can be accurate without deserving a change.
Coverage also needs a denominator. Reviewing 20 pages means something different on a 25-page consultancy site and a large catalog. Request the number discovered, the number successfully checked, and the sampling method for manual review. Samples should cover important templates and meaningful exceptions, such as unavailable products or location pages. Record access restrictions, blocked requests, and missing analytics. Where evidence is unavailable, the conclusion should remain limited rather than being presented as a site-wide finding.
Require evidence that another person can inspect
Each significant finding should identify the affected pages, observation date, test method, expected behavior, observed behavior, and business relevance. Request a full affected-page list where available, not just three screenshots. Separate measured scope from estimated scope: finding a defect on four sampled pages does not prove that every page using that template has it. Evidence should also show enough context to reproduce the test.
A finding about lost inquiries needs more than a search visibility chart. Check whether form submissions are measured correctly and whether the comparison includes seasonal changes or releases. GA4 records attributable visits and measured events within its collection limits; it does not reveal every customer interaction. The report can identify a plausible contributor without claiming it caused a revenue change. A useful conclusion may be that more evidence is needed before changing the site.
- Confirmed defect: reproducible behavior conflicts with an agreed requirement.
- Investigation: a plausible explanation needs another test or missing access.
- Opportunity: a proposed improvement, not a broken feature.
Prioritize issues affecting important pages
I recommend ordering work by the importance of affected pages, breadth of exposure, confidence in the diagnosis, implementation effort, and risk of side effects. Keep those judgments visible instead of hiding them inside an unexplained score. One incorrect indexing instruction on a core service page can deserve attention before hundreds of cosmetic inconsistencies. Conversely, a large warning count on deliberately excluded pages may require no change.
The first batch should fit the capacity of the people implementing it. Name dependencies: changing a URL may require redirect rules, updated internal links, and editorial approval. If the business has no developer available, distinguish safe CMS edits from development work rather than quietly dropping the latter. For WordPress-specific implementation checks, the WordPress audit checklist complements the report; it answers how to inspect the platform, rather than what to buy.
Worked example: turn a finding into an assignable task
Illustrative example—not a client case: a hypothetical equipment supplier has 12 category pages pointing to its homepage through canonical tags. A canonical tag indicates the preferred version among duplicate or substantially similar pages. Google treats canonicalization signals as guidance and may select a different URL. The existence of a tag alone therefore does not establish which page Google has selected.
Assume manual review confirms that these categories contain distinct product selections and are intended to appear separately in search. The proposed task below follows the sequence I use in hands-on WordPress work: inspect evidence, define the change, and check the published result. It is a reusable example, not a claim about results. The critical distinction is between verifying the implementation and waiting to observe search behavior.
| Task field | Required detail | Owner | Acceptance evidence |
|---|---|---|---|
| Diagnosis | Attach all 12 affected pages and dated canonical output; confirm their distinct purpose. | SEO specialist + business owner | Page purpose approved; observed output reproducible. |
| Change | Correct the category-template rule so each approved page references itself. | Developer | Staging checks pass on the 12 pages; other templates retain intended behavior. |
| Release check | Check live output after cache clearing and repeat the affected-page crawl. | Developer + SEO specialist | All 12 return intended content and canonical output; no conflicting indexing instruction. |
| Search follow-up | Record available Search Console inspection evidence after recrawling. | SEO specialist | Google-selected canonical recorded where available; indexing or ranking is not a completion promise. |
Make implementation and retesting explicit
Analysis, implementation, and verification are different activities. A proposal should say whether it covers only recommendations, preparation of developer tasks, actual changes, or post-release checks. Request an editable task register alongside any presentation. Useful fields include status, owner, dependencies, supporting evidence, acceptance criteria, and the date of verification. Written answers to implementation questions also need an agreed place in the scope.
My hands-on implementation is mainly WordPress; specialist development is coordinated with the client’s developers. On Supplement Explained, my ongoing practices include research, content refreshes, contextual internal linking, and publication QA. For purchased work, agree who handles backups, staging approval, release decisions, and rollback if an edit causes problems. Retesting should check both the intended correction and likely side effects.
Compare proposals using the same deliverables
Google’s hiring guidance advises asking prospective SEOs to explain recommended changes and their reasoning. It also cautions against ranking guarantees. For your purchase decision, my recommendation is to compare proposals against the same scope, evidence standard, and implementation expectations. A lower quote may cover less work rather than reflect better value.
Ask each provider to specify data access, sample coverage, exclusions, delivery formats, clarification support, and retesting arrangements. Content rewriting, tracking repairs, link outreach, and development should not be silently assumed. Agree timing around access and dependencies rather than relying on a universal turnaround promise. The SEO consultant cost guide explains fee-model differences; here, the key is knowing what the fee buys and what would trigger additional work.
- Before approval: request an anonymized or explicitly illustrative task example.
- At handover: confirm the highest-priority findings have evidence, owners, and acceptance criteria.
- After release: record what passed, what remains unresolved, and what requires later observation.
Common questions
Is a free SEO analysis tool enough?
It can support an initial check or help reproduce a specific issue. It cannot replace business context, investigation of causes, or implementation planning. Pay for the reasoning and deliverables you need, not simply for access to a scanner.
Should every page receive a manual review?
Not necessarily. A small site may justify it; a large site often needs template-based sampling plus targeted exceptions. The report should explain its coverage and avoid extending sampled conclusions beyond the evidence.
How do I know whether the audit was successful?
First assess whether it answered the agreed questions and produced supported, usable tasks. Then verify implemented changes. Search and business outcomes require separate observation; a completed audit or correctly implemented fix does not guarantee growth.