How to brief a white-label SEO partner (with a template)

A good white-label SEO partner brief gives enough context to make the next decision without burying the assignment in account history. It names the question, site, market, audience, pages, constraints, access, deliverable and owner. It also states what evidence should support the work and how the agency will review it.

The brief protects both sides. Your agency avoids paying for research aimed at the wrong question. The partner avoids guessing about scope, audience or approval. Use the template below for a one-off assignment, then keep a short change log for recurring work.

Prepare the brief with the account owner

Separate confirmed facts from hypotheses. List the site, market, audience, pages, templates, stakeholders and known changes. For multilingual work, name the reviewer and note whether markets differ. State the evidence available, the least access needed, the constraints, the format, the client-facing brand, deadline, definition of done, exclusions and approval owner. A partner should return questions before deep research when essential context is missing.

Set review and verification points

For larger work, schedule a direction check before the final deliverable. Review the interpreted question, early evidence, likely structure and blockers. At final review, compare output with the original definition of done. Every major action needs an owner, dependency and check. For technical work inspect the live state; for content check the intended page and audience question; for search outcomes define baseline, window and limitations.

Maintain recurring briefs

Keep stable context in a core account brief and changing priorities in a dated cycle note. Record releases, redirects, tracking changes, approvals and rejected recommendations only when relevant to the current question. Close each cycle with delivered, approved, implemented and verified statuses. Move unresolved questions into the next scope or close them deliberately. This keeps the brief a delivery control rather than a forgotten form.

Briefing questions before research

Ask whether the client objective is stated in one sentence, whether pages and markets are named, whether the deliverable supports a decision, and whether exclusions are clear. Check that evidence is dated and access has an owner. Confirm language, brand and client-contact rules. Ask the partner to restate the question, scope, assumptions, risks and first review point before research. Keep approved changes in the stored brief, not only in chat. Review evidence, completeness, ownership, brand, links, confidentiality and limitations before client delivery. Include the final brief, source material, unresolved questions, implementation notes and verification plan in the handoff. Close the output when complete; keep later outcomes open until they can reasonably be observed.

Write the brief as a decision record

State the client or internal decision, why it matters now and when the agency needs a usable answer. Name the site, templates, markets, languages and page groups rather than saying “the website”. Identify the audience and the person who can approve scope. If the question is exploratory, say what a useful discovery would change. If operational, define the state that counts as complete. This prevents a broad research document when the agency needs implementation-ready actions.

Separate facts, assumptions and requests. Label a migration date, a shared-template assumption and a traffic investigation differently so the partner knows what can be challenged. Include source and date for important facts. Do not paste passwords or private tokens into the brief; record where approved access is managed and who can grant or remove it.

Define the output and its review path

Describe format, length, naming convention, brand treatment and delivery location. List required fields for findings: affected URL, evidence, priority, rationale, owner, dependency and verification method. State whether the partner prepares client-ready copy, internal notes, implementation tickets or only analysis. Name the reviewer and stages. A direction check confirms interpretation; a final check confirms completeness against the definition of done.

Agree how uncertainty is returned. Ask the partner to flag blocked access, conflicting evidence, scope risk and questions needing an account decision. Set an escalation route rather than discovering urgent matters in a final file. Record client changes before requesting more work. Record adjacent discoveries as follow-up options instead of silently adding them to the promise.

Make recurring briefs easier to reuse

Keep durable context in one controlled account record: business objective, audiences, market rules, contacts, brand requirements, access boundaries and platform constraints. Add a dated cycle note for priorities, releases, incidents, approvals and open questions. At cycle end, mark work delivered, approved, implemented and verified separately. Carry forward only unresolved items with an owner and next check.

Use a complete brief template

A reusable template can begin with assignment name, client decision, business context, audience, site, markets, languages, relevant pages and recent changes. Follow with the question, confirmed facts, working assumptions, evidence available and evidence missing. Add access owner, confidentiality boundary and client-contact rule. Define deliverables, format, brand treatment, exclusions, deadline, review points, approval owner, implementation responsibility and verification method. End with dependencies, risks, open questions and the route for approving change. For final acceptance, compare delivered work with the brief: check page groups, markets, limitations, assignable recommendations and reasoning. Record corrections separately from new requests.

Add acceptance and communication rules

Confirm that the output answers the stated question, names affected pages or systems, links observations to evidence, separates recommendations from completed work, records assumptions and identifies a verification step. State whether the partner may contact the client, attend meetings, edit shared documents or communicate only through an account lead. Name the route for urgent blockers. When a release changes the page set, access is withdrawn or the client changes the decision, update the dated cycle note and explain the impact on scope.

Review the white-label SEO brief before sending it

Ask an account owner who did not draft the brief to read it once. They should be able to identify the decision, scope, audience, evidence, constraints, deliverables, deadline and approval route without relying on chat history. Remove background that does not change the assignment, but retain facts that affect interpretation. Check every linked source for access and date. Confirm that page groups, markets and languages use precise names. Resolve contradictory deadlines or owners before the partner begins. Where information remains unavailable, label the gap and state whether the partner should proceed, pause or propose a discovery step. This short review is cheaper than correcting research built on an unstated assumption.