An SEO brief should make it possible to recommend work the business can actually use. I would start with what you sell, whom you want to sell it to and what stands in the way. A list of keywords can follow. It cannot supply those answers on its own.

Consider a hypothetical software business asking for more organic traffic. Its public website promotes several products, but its sales team only has capacity to support one of them properly. An SEO consultant reviewing the website alone might see opportunities across the entire range. The brief needs to reveal the difference between an available product and a commercial priority.

That distinction changes which opportunities deserve attention. It also prevents a technically sensible recommendation from becoming work the business never wanted.

Describe the customer you would welcome

I would replace a broad audience label such as “business owners” with a description of the buyer's situation. Explain the problem that brings them to you, the conditions that make your service suitable and the reasons a seemingly relevant enquiry might be wrong for the business.

A company selling complex implementation work might want organisations with an internal project owner. A business offering standardised packages might prefer customers who can choose without extensive consultation. Both could use similar language on their websites while needing quite different search journeys.

Include the questions prospects ask before committing. If price depends on scope, explain what changes the scope. If buyers confuse your service with a cheaper alternative, describe the difference without dismissing the alternative. This gives the consultant something more useful than instructions to find “high-intent keywords”.

You do not need to solve the research yourself. You need to make the commercial reality available for investigation.

Put the inconvenient constraints in writing

A good brief should contain information you might hesitate to put in a sales presentation. The product team cannot change a certain feature. The developer is shared with another department. A service description needs approval from a subject specialist. The company does not want to promote an offering that is being withdrawn.

These are planning inputs, not admissions of failure.

Imagine a hypothetical distributor whose stock availability varies. A recommendation to build detailed product pages could be sensible, but the implementation will depend on how those pages handle products that cannot be supplied. A consultant who knows the constraint can investigate it. A consultant who does not know may mistake a business decision for a content omission.

I would also describe any commitments already made. A redesign, supplier change or new content system can affect the sequence of SEO work even when it is not part of the SEO assignment. The brief should expose those dependencies before anyone promises delivery.

Separate what you know from what you suspect

“Our competitors are winning because they publish more” is a hypothesis. “Our sales team keeps answering the same delivery question” is an observation. Both deserve space in a brief, but they should not arrive with the same status.

I suggest using plain labels: known issue, suspected cause and question to investigate. Add the supporting material where it exists. That could be an example page, a relevant report or an anonymised description of a customer conversation.

This avoids turning the brief into a request to confirm a preferred explanation. If management has already decided that links are the problem, the consultant should still be allowed to discover something else. Otherwise the investigation begins with a conclusion it is expected to defend.

The same applies to goals. Wanting more suitable enquiries is a legitimate objective. Expecting a particular ranking because another company has it is an assumption about the route to that objective.

Explain who can make a recommendation happen

I want a brief to make responsibility visible. Who can approve a change to a service page? Who can publish it? Who resolves a disagreement between brand language and product accuracy? Who decides whether a technical task enters the development queue?

One person may fill several roles. That is fine. What matters is that the roles have owners.

A marketing manager can be responsible for SEO without having permission to change the website. If that is the arrangement, the plan must account for it. Describing the manager as the “main contact” does not tell a consultant how work gets approved.

Include what the business can contribute: product explanations, editorial review, development time or customer-service input. Avoid describing capacity simply as “available when needed”. A realistic explanation of the team's limits is more useful than an optimistic commitment nobody has checked.

Offer evidence without opening every door

The brief should list which information exists and who can provide it. Search performance data, website analytics and examples of qualified enquiries answer different questions. A consultant should explain which material is needed for the proposed investigation and why.

Google's guidance on hiring an SEO recommends discussing the business and its customers, and granting read access to Search Console for an initial audit rather than write access. I agree with keeping investigation and implementation permissions distinct.

There is no need to paste passwords into a document or circulate raw customer records. Anonymised examples may be enough to explain a sales problem. Access can be granted through the appropriate account permissions when its purpose is clear.

Missing information should remain visible. If you cannot connect enquiries with their source, say so. A plan built around that limitation is more credible than a forecast that silently assumes perfect measurement.

Finish with the decision you need to make

The brief should end by explaining what the consultant's response must help you decide. Perhaps you need to prioritise development work, define a content assignment or understand what evidence is missing before allocating a budget.

I would ask for recommendations with reasons, dependencies and clear boundaries. I would also ask the consultant to identify assumptions that could change the recommendation. That gives you a way to challenge the plan constructively, rather than comparing proposals by their length or quantity of promised tasks.

A useful brief leaves room for discovery while making the business legible. You are not hiring someone to repeat your preferred answer in more technical language. You are giving them enough context to recommend a course of action you can judge, approve and carry through.