How to Brief a Search Consultant

The brief is the part you control

Buyers spend a great deal of energy evaluating providers and almost none on the document they send them. That is backwards. The brief determines what you get back. A vague brief gets a template proposal, because a template is the only rational response to an unclear problem — and then you compare three templates and choose on price or on how much you liked the call.

A specific brief does something different. It forces every respondent to engage with your actual situation, which makes their answers comparable, exposes who has read the data and who has not, and lets a competent person scope the work rather than pad it against uncertainty. It also does something for you: writing it usually reveals that what you thought you were buying is not what you need.

What follows is what goes in it. It is two to four pages, not a procurement document, and you can write it in an afternoon.

State the problem as a symptom with evidence, not as a solution

Most briefs open with a purchase decision already made: SEO is needed, or more content, or link building. That instruction removes the most valuable thing an outside specialist offers, which is an independent read on which part of the chain is broken.

Write the symptom instead, with dates and numbers attached. Compare these two openings:

The site needs better SEO and higher rankings for its main keywords.
Organic clicks fell roughly a third between February and May, concentrated on product pages while category pages held. Non-brand impressions fell in the same window. The site migrated platform in January. Revenue from organic landing pages is down proportionally.

The second version can be priced. It can also be challenged, which is the point: a good respondent will tell you that the migration and the drop may not be related, and will say what evidence would settle it. The first version can only be answered with a package.

If you genuinely do not know the symptom, say that, and buy a diagnostic first. Stating that nobody internally knows whether the problem is technical, competitive or commercial, and that establishing it is the job, makes a completely legitimate brief, and a much better one than a guess dressed as a requirement.

The five things that make a brief priceable

These are the variables that actually determine scope. Omit them and every quote you receive will be padded to cover the worst case.

Site size and shape. Roughly how many URLs, how many distinct templates, how many languages or country versions. The difference between 400 URLs and 400,000 is not a difference of degree.
Platform. Name it, including the version and any headless or custom front end. Platform sets hard ceilings on what is possible: on some hosted platforms server logs and custom crawl directives are simply unavailable, and the correct recommendation becomes "this cannot be fixed here," which is a governance conversation rather than an SEO one.
Who implements. This is the single largest scope variable. Does your team ship the changes, does the consultant work in the CMS, or is there an external development agency with its own queue and commercial terms? Diagnosis and execution are different purchases and should be priced separately.
What has already been done. Previous audits, previous providers, any disavow file that exists, any manual action history, any migration in the last two years. Withholding a previous audit to test whether the new person finds the same things wastes the budget you are protecting.
The commercial shape. Whether this is a one-off diagnostic, a fixed-scope project with an end date, or ongoing counsel — and roughly what the internal appetite is. You do not have to publish a number, but a respondent who knows whether you are scoping weeks or quarters can propose something real instead of guessing.

The access pack, and why to assemble it before kickoff

Access delays cost more engagement time than any other administrative issue. Sort these before day one and the first week produces findings instead of emails.

Search Console, verified as a domain property so subdomains and both protocol variants are included, with the right permission level to read every report rather than a filtered view.
Analytics, with the definitions of your conversion events written down. Which event counts as a lead, what deduplication exists, what is excluded. This is the document nobody has and everybody assumes.
Sixteen months of Search Console performance data, exported. Retention is sixteen months and the interface and its spreadsheet export cap at 1,000 rows, so historical comparisons that are not exported now are permanently unavailable in the shape you will want them. Export queries, pages, countries and devices.
Server logs, or a clear statement that they cannot be obtained on your platform. Either answer is useful; discovering it in week three is not.
CMS access, staging environment access, and knowledge of the release cycle — how often you ship, what the approval path is, and who can push a robots.txt change.
Ads accounts if paid is in scope, at a permission level that allows reading the search terms report and conversion settings.

Constraints are worth more than wishes

Briefs describe ambitions in detail and constraints not at all, and constraints are what shape a workable plan. State them plainly, including the embarrassing ones.

Development capacity is the constraint that matters most. A recommendation queue that would take four engineer-weeks is worthless to a team with one developer, half of whose time belongs to someone else. Say how much implementation capacity actually exists and how it is prioritized, and you will get advice arranged around it rather than a document that never gets built.

Then the others: legal or brand review on published copy and how long it takes; regulated language you cannot use; a platform migration already scheduled that will invalidate half the work if it is not accounted for; a parent company that controls the domain; a freeze period around your peak trading season. Every one of these changes sequencing, and sequencing is where most of the value in a plan sits.

Add the things that are off the table. If you will not buy links, will not publish AI-generated content at scale, or will not change the URL structure this year, say so. The best use of a brief is to eliminate the proposals that were never going to survive your organization.

Decision rights, and who is actually in the room

Name the people. Who approves the work, who approves spend, who can prioritize a development ticket, who owns the content, and who has the authority to say no to a recommendation on brand grounds. If the answer to several of those is the same person and that person is not in the kickoff, the engagement will run at the speed of their calendar.

State the reporting cadence you want and to whom. There is a real difference between a monthly written update to one marketing manager and a quarterly presentation to a board that will ask about attribution, and the second costs meaningfully more time. Deciding this up front prevents the slow accumulation of reporting obligations that quietly consumes the hours you were paying for the actual work.

Finally, define what the engagement produces, in artifacts. Not "improve rankings" — a prioritized findings document, implementation specifications a developer can build from, a URL mapping, a monthly written analysis. Outcomes cannot be committed to; artifacts can. A brief that asks for artifacts gets proposals that promise artifacts, and those are the proposals you can actually hold someone to.

Running the process, and reading what comes back

Send the identical brief to everyone you are considering, at the same time, with the same deadline and the same question set. Variations in what you sent make the responses incomparable, and comparability is the only real advantage a written process gives you over a series of nice conversations.

Then read the replies for three things.

Did they engage with your evidence? A response that references the specific dates, templates or platform constraints in your brief was written for you. One that arrives within an hour, describes a methodology, and contains no fact about your site is a template, whatever its quality.

Did anyone tell you something you did not want to hear? The most valuable response is often the one that says the work you asked for is not the work you need, or that a smaller diagnostic should come first. Google's own hiring guidance warns about providers who are secretive about what they intend to do; the inverse signal is a respondent who explains their reasoning well enough that you could disagree with it.

Are the deliverables and the exit both concrete? You want the artifact list, the assumptions the scope depends on, what happens if those assumptions are wrong, and what you keep if the engagement ends early. Documents, access, files and specifications should be yours regardless. If that is not stated, ask, and put the answer in writing before you sign.

One more thing, easily forgotten: reply to the people you did not choose, and tell them why. The search consulting market is small, you may need one of them in eighteen months, and a reputation for running a clean process gets you better responses next time.

Frequently Asked Questions

How long should a search consulting brief be?

Two to four pages is plenty. The value is in specificity, not length. It needs the symptom stated with dates and numbers, site size and platform, who implements changes, what has already been tried, the constraints that shape sequencing, who makes decisions, and what artifacts you expect. A procurement document three times that length usually contains less usable information, because it substitutes process language for facts about your site. If you cannot fill in the symptom section, that is itself the finding, and the right first purchase is a diagnostic.

Should I say what my budget is when briefing a consultant?

Give the shape even if you withhold a number. There is a real difference between scoping a two-week diagnostic and an ongoing engagement across quarters, and a respondent who knows which one you mean can propose something real rather than hedging against uncertainty. Withholding everything tends to produce either padded quotes or proposals that get withdrawn once reality lands. The compromise that works is stating the engagement model you want and the timeframe, then letting the scope conversation set the rest of it.

What access does a search consultant actually need?

Search Console verified as a domain property with full report access, analytics with your conversion definitions documented, CMS and staging access, knowledge of your release cycle, and server logs where the platform allows them. Ads accounts at a level that permits reading the search terms report if paid is in scope. Assemble these before kickoff rather than during it. Access delays consume more engagement time than any other administrative issue, and on a fixed-scope project that time comes out of the work you are paying for.

Should I share a previous audit with a new consultant?

Yes. The instinct to withhold it as a test is understandable and expensive. You end up paying a second time for the same diagnostic work, and you lose the more useful conversation, which is why the previous findings were not implemented and whether they were right. Share the audit, the disavow file if one exists, any manual action history, and the record of previous migrations. If you want an independent read on a specific conclusion, ask for that explicitly as a scoped question rather than by concealing the context.

How do I compare proposals that are structured completely differently?

Send an identical brief with the same questions and deadline, which is what makes comparison possible in the first place. Then compare on three axes rather than on price: the artifacts each one commits to producing, the assumptions the scope rests on and what happens if those are wrong, and how much of the response is specific to your evidence rather than to their methodology. A proposal promising outcomes and a proposal promising documents are not two versions of the same thing, and outcomes are the ones nobody can be held to.

What should a brief ask for that most buyers forget?

Three things. Who personally does the work, since the people who present are often not the people who deliver. What you retain if the engagement ends early — documents, specifications, access, raw files should be yours regardless. And what the provider expects from you, in hours and decisions, because the most common cause of a stalled engagement is not the provider's capacity but an implementation queue nobody scoped. Asking for these before signing converts a series of assumptions into terms you can point at later.

Published 2026-08-11