Author
A Google SEO consultant is best defined by the stage of work they take on, not by a job title. Four stages cover almost every engagement: diagnosis, strategy, implementation, and ongoing operations.
Diagnosis establishes what is actually happening in search and on the site. Strategy converts those findings into a sequenced plan with owners. Implementation executes the changes. Operations keeps measurement, iteration, and reporting running.
The same person can work across stages, but the buying decision changes at each one. A consultant may advise while your team executes, or execute directly.
That distinction — advisory versus done-for-you — determines price, access, and risk far more than seniority claims do.
Before comparing anyone, write one sentence naming your stage. "We do not know why organic traffic declined" is diagnosis. "We know the problems and need a plan" is strategy. "We have a plan and no capacity" is implementation.
"We need someone to keep this running" is operations. Scope boundaries should be stated up front by the consultant; if they are not, you will be negotiating them later under pressure.
Separate your problem into three types. A knowledge gap means nobody internally knows what to do. A capacity gap means someone knows but has no time. An execution gap means the plan exists but the work stalls.
A consultant fits a knowledge gap and often a strategy gap. A freelancer or agency usually fits capacity and execution. If the problem is purely internal prioritization, no external hire fixes it — an audit alone may be enough to restart internal work.
Ongoing operations require a retained owner, whether internal or external, because search work does not complete in a single project.
The cost of choosing the wrong model is not just fees. Hiring an implementer for a diagnosis problem produces activity without direction. Hiring a strategist for a capacity problem produces documents nobody executes.
Match the model to the gap before you shortlist.
A diagnostic audit should show its inputs before it shows conclusions. Expect crawl and index findings, query and demand evidence, content and intent gaps, and a conversion and measurement review.
Each finding should carry a stated assumption where the data is incomplete.
Read the audit for method, not volume. A credible diagnostic tells you which tools and data sources produced each finding, what was checked, and what was out of scope.
If the document jumps from a problem list straight to recommended tactics, you are reading a strategy pitch wearing an audit’s clothes.
Ask for the raw inputs alongside the summary: exported query data, crawl output, and the measurement definitions used. You are not testing whether the consultant is impressive.
You are testing whether their findings can be re-derived by someone else — including your next hire.
A strategy is not a longer recommendation list. It maps each finding to an action, sequences those actions by dependency and effort, and names an owner per action. Success criteria should be defined before work starts, not after results arrive.
Sequencing matters because search work has dependencies. Technical fixes that block indexing usually precede content expansion. Measurement setup precedes any claim about improvement.
A plan that lists twenty parallel priorities has not made a decision; it has deferred one to you.
Good strategies also list assumptions and unknowns explicitly. If a plan assumes your developers have capacity in a given month, that assumption should be visible so you can confirm or reject it.
When you review a strategy, ask one question per action: who does this, and what tells us it worked?
Implementation is where access and change control become the real risk. Name the implementer for each workstream — consultant, your developer, your content team, or a mix.
Access should follow least privilege: the minimum level needed for the specific task, granted for a defined period.
Require a change log and a rollback path. Every deployed change should be recorded with what changed, when, by whom, and how to reverse it.
QA should run before and after deployment, with a defined check that the change did what it was supposed to do and did not break something adjacent.
Handoffs between developers and content teams are the most common failure point. If a technical fix requires a content update, or a content change requires a template edit, that dependency should be written down with a named owner on each side.
Verbal handoffs disappear when people change roles.
Recurring reporting should tie metrics to business outcomes, not to position charts alone. Record a baseline before changes begin, so later movement can be compared against something real.
Define decision triggers in advance: what result would cause you to stop, continue, or scale the work.
Set the reporting cadence and audience explicitly. A weekly operational note and a monthly decision summary serve different readers. Keep observation and attribution separate — a metric moving after a change is an observation, not proof the change caused it.
Google’s guidance on helpful content emphasizes original information, clear sourcing, and content that helps the intended audience complete its task, which is a useful standard for judging whether reporting explains anything or merely displays numbers ([Creating helpful, reliable, people-first content](https://developers.
google. com/search/docs/fundamentals/creating-helpful-content)).
If a report cannot tell you what decision it supports, it is not reporting. It is reassurance.
Ask for proof you can examine rather than proof you can admire. Sample audits with the method shown, change logs, access history, measurement definitions and data sources, and references tied to comparable scope are all inspectable.
Claims that cannot be verified — private client results, unnamed case studies, screenshots without context — should be treated as marketing, not evidence.
Google states that standard SEO foundations apply to AI features and that eligibility does not guarantee appearance ([AI features and your website](https://developers. google. com/search/docs/appearance/ai-features)).
That is a useful boundary for evaluating any consultant who promises visibility in AI-generated results: foundations can be worked on, appearance cannot be guaranteed.
Use the embedded scorecard below during the first conversation. Fill it per candidate so answers are comparable rather than memorable.
| Scorecard field | What to record |
|---|---|
| Problem stage | Diagnosis, strategy, implementation, or operations, in your own words |
| Evidence reviewed | Which sample audits, change logs, or measurement definitions you actually inspected |
| Deliverables listed | Named outputs, not activity descriptions |
| Owner per workstream | Who executes each item: consultant, your team, or shared |
| Access and ownership terms | Access levels requested, account and property ownership |
| Reporting metrics | Metrics, baseline, cadence, and decision triggers |
| Red flags found | Guarantees, undisclosed tactics, vague scope, lock-in language |
| Exit and handover terms | Notice period, documentation transfer, access revocation, transition support |
Working fit is a delivery variable, not a personality question. Establish a single point of contact on each side, response and escalation terms, and who approves content and technical changes.
Meetings should have a stated purpose tied to a decision; recurring calls without decisions drain budget.
Decision rights are the part buyers most often leave implicit. If the consultant can publish content without approval, say so. If they cannot touch templates, say that too.
Ambiguity here produces either blocked work or unwanted changes, and both are expensive.
Agree who owns documentation. If the consultant maintains the change log and measurement definitions, those artifacts must transfer to you at exit. Documentation ownership is a handover term disguised as a housekeeping detail.
Ranking and revenue guarantees should end the conversation. No consultant controls search algorithms or competitor behavior, so a guarantee is either a misunderstanding or a sales device.
Undisclosed link or content schemes carry the same problem: if the tactic cannot be described in the contract, you cannot evaluate its risk.
Vague deliverables and open scope let a provider bill for activity without producing outputs. Data and account ownership ambiguity creates lock-in — if the consultant owns the properties or the analytics, your leverage disappears at renewal.
Exit, notice, and handover terms should be written before you need them.
Screen these against the actual contract language, not the sales conversation. A provider who resists putting ownership and exit terms in writing has told you something important.
Pricing structure should follow the deliverable. Fixed-scope models suit diagnosis and strategy, where the output is a defined document. Retainers suit operations, where the work is continuous.
Implementation can be either, depending on whether the work is a defined project or an ongoing queue.
Build the proposal comparison on the deliverable list, not the hourly rate. Note how change requests are handled, what is included versus excluded, and whether payment ties to milestones or periods.
Two proposals at the same price can differ enormously in what they actually produce.
This guide deliberately avoids quoting figures. Consulting prices vary by market, scope, and seniority, and any number stated without a basis would mislead you.
Compare proposals against each other and against the deliverable list you wrote in the diagnosis stage.
Define what transfers if the engagement ends. Account and property ownership should sit with you from day one. Documentation and assets — audits, change logs, measurement definitions, content briefs — should transfer in a usable format, not as a summary.
Specify the access revocation process and a transition support period. A short overlap where the outgoing consultant answers questions is cheaper than reconstructing context later.
Post-exit data retention terms should also be stated, so you know what happens to your data after the relationship closes.
A clean handover is a test of the whole engagement. If the work was documented as it happened, exit is administrative. If it was not, exit reveals how much of the engagement lived only in one person’s head.
Use the first call to confirm comparable facts across candidates.
Restate your problem and stage, ask which evidence they will provide and review it, confirm deliverables and the owner per workstream, agree decision rights and cadence, and end with a next step and a written scope.
A shortlist of two or three candidates is enough if you ask the same questions in the same order. The goal is not to find the most confident answer but the most checkable one.
Candidates who welcome the scorecard and the written scope are showing you how they will work after signing.
Before any commitment, request a written scope that names the stage, deliverables, owner, evidence, and exit terms.
If a provider cannot produce that document, the engagement’s boundaries will be defined later by whoever has more leverage — and that will not be you.
Sources cited:
No comments yet. Be the first!