An SEO content brief records the decisions for one page before writing starts: who it helps, what it must answer, which existing page owns neighboring questions, what evidence it needs and how the draft will be reviewed.
A keyword and a word count leave most of that undecided. Use the template below to give a writer a clear assignment, with enough room for useful judgment and a clear instruction to flag missing facts.
A brief contains more than an outline
An outline lists the sections. A brief explains why those sections belong, what they need to establish and where their evidence comes from. It also assigns responsibility for questions that an outline cannot settle.
For example, a heading called “Which option should you choose?” is not enough for a comparison. The brief should identify the reader's constraints, the criteria for judging each option and the sources needed before making a recommendation.
Use a brief for a new page or an update. When an existing URL already serves the reader's task, make that URL the assignment. The content audit handles the wider inventory decision; the brief turns one approved decision into instructions for a draft.
Copyable SEO content brief template
Copy this into your working document. Replace the bracketed instructions with actual decisions. Use “not applicable” where a field is unnecessary and “pending” where work is still required. Those mean different things.
PAGE ASSIGNMENT
Owner and reviewer: [Actual responsible people or team]
Action: [Update existing / new page / hold for evidence]
Canonical URL: [Existing URL or proposed path, clearly labeled]
Reader: [Audience, situation and relevant constraints]
Main task: [What the reader can understand, do or decide afterward]
Business purpose: [Why serving this task matters to the organization]
INTENT AND OWNERSHIP
Primary query family: [Hypothesis or measured source with checked date]
Reader questions: [Questions this page should answer]
Closest existing page: [URL, actual coverage and review date]
Unique contribution: [Useful evidence, example, template or explanation]
Out of scope: [Neighboring task and its existing owner]
Search observations: [Query, date, locale/device and observed formats]
Unverified assumptions: [What has not been researched or demonstrated]
CONTENT AND EVIDENCE
Outline: [Heading, reader question and purpose for each section]
Concepts/entities: [What must be explained for the answer to make sense]
Claims register: [Claim, source, checked date, limitation and status]
Original input: [Actual expert input, permitted data or demonstration]
Examples/assets: [What is available and what is still required]
Do not invent: [Results, quotations, product features or other restrictions]
LINKS AND PRESENTATION
Internal links: [Actual URL, suggested anchor and reader reason]
External references: [Primary documents supporting specific claims]
Title tag / H1 / description: [Accurate, distinct promises]
CTA: [Relevant next step and any verified offer terms]
Structured data: [Candidate type, eligibility and visible-content check]
Format/accessibility: [Tables, instructions, image text or other needs]
REVIEW AND RELEASE
Open evidence: [Missing fact, responsible person and next action]
Draft acceptance: [Specific checks the reviewer will apply]
Scope changes: [Who decides if the assignment must change]
Release status: [Draft / editorial review / hold / approved for build]
This is an editorial template, not a Blogoose interface, product export or guarantee that a draft will satisfy every requirement automatically.
Fill the brief in five passes
1. Decide the reader and page owner
Describe the reader's situation rather than naming a broad audience alone. “A small team comparing two working methods while handling frequent urgent requests” gives the writer more direction than “businesses.”
Read the closest existing pages before approving a new URL. If a current page already answers the task, refresh that page. If the proposed answer differs, explain the difference in the brief. Two pages receiving impressions for a shared query do not, by themselves, establish that one must be merged.
Use the topic-cluster guide when deciding how this page relates to a broader overview and supporting resources. The brief should inherit that ownership decision, not rebuild the entire cluster.
2. Separate observations from assumptions
When reviewing search results, record the query, date, location or language and the formats you actually saw. Results can vary. Describe what you observed without turning it into a universal rule or copying the leading pages' structure.
An unanswered reader need may come from an interview, support question or your own expertise. Record that origin too. If you have not checked whether competing pages address it, call it a proposed angle rather than a verified gap.
Model-generated suggestions and estimated search summaries belong in the assumptions column until checked. They do not supply measured search volume, difficulty, current rankings or citable sources.
3. Give each section a question and a purpose
Write the question a section must answer beside its heading. Add the evidence, example or explanation needed to answer it. That gives the writer a basis for changing the wording without losing the job.
List concepts because a reader needs them, not because a term tool includes them. Explain technical words at the point where they matter. Avoid requiring a fixed number of entities or mentions.
An estimated length can help schedule work, but it should not become a completion test. Google's helpful-content guidance says it has no preferred word count. Judge the draft by whether it answers the assignment without padding or missing necessary detail.
4. Attach evidence to consequential claims
Use a small register for claims that could mislead someone if wrong:
| Claim | Evidence to attach | Status before writing |
|---|---|---|
| A product supports a feature | Current documentation or a permitted demonstration, including plan/version limits | Verified or pending |
| A method produced a result | Actual measurement, scope, dates and limitations | Verified, illustrative or omit |
| A person said something | Recorded source and permission where needed | Approved or omit |
| A search platform applies a rule | The platform's current primary documentation | Verified with checked date |
Do not authorize a statement merely because a source URL is on the list. Check that the document supports the precise claim. Use source citation guidance to keep attribution clear.
When proof is missing, assign the next action. The writer can draft the supported sections and flag the gap. The page must remain on hold if the gap is material to its promise.
5. Set links, metadata and the next step
For each internal link, name the actual destination and why a reader would need it. Keep planned destinations in a pending task list until they are published. Google's link guidance supports descriptive anchors and usable links rather than a mechanical link quota.
Write a title and H1 that describe the same page promise. Write the description as a useful preview. Google selects title links and snippets automatically, so your submitted text may not appear verbatim. Use the title-tag guide for the detailed presentation decisions.
Treat structured data as an implementation candidate, checked against the visible page and current eligibility. The Article schema guide covers that handoff. A brief should not promise rich results or AI citations because markup is planned.
Filled example: a comparison for a small product team
This example is an illustrative assignment within a product-team-rituals cluster. It is not a completed comparison, observed search study or customer case. No Scrum or Kanban recommendation is asserted here.
| Brief field | Example decision |
|---|---|
| Reader | A six-person product team choosing how to organize delivery |
| Main task | Compare Scrum and Kanban against the team's actual work constraints |
| Query family | “Scrum vs Kanban for a small team,” an unverified query hypothesis |
| Page action | Hold new-page approval until the current inventory and evidence are reviewed |
| Closest owner | Pending inventory review; do not write “none” before checking |
| Proposed contribution | Apply explicit criteria such as incoming work, role capacity and planning needs |
| Out of scope | Detailed standup instructions and a full retrospective template |
| Outline | Define the decision; explain each method from primary references; compare criteria; discuss limits; propose a review process |
| Evidence required | Current primary method references and relevant practitioner review before making claims |
| Search observations | Not collected for this example; no claim about dominant results or a market gap |
| Internal links | Add the actual ritual overview and related resources only after confirming they exist |
| Draft acceptance | Each comparison claim supported; criteria explicit; no invented preference percentages or guaranteed team outcomes |
| Release gate | Evidence, ownership and reviewer approval still required |
The assignment makes the uncertainty visible. A writer may prepare the questions and research plan without presenting the unresolved comparison as ready to publish. The same approach applies to a product tutorial that needs a demonstration or a factual update that needs owner confirmation.
Instructions for an AI-assisted draft
Give the model the brief and the supporting materials it is allowed to use. Specify how it should behave when information is missing:
Write for the reader and task in this brief. Preserve its scope and use only
confirmed internal URLs. Ground consequential factual claims in the supplied
sources, checking whether the passage supports the claim.
Do not invent measurements, sources, quotations, customer stories, product
features or offer terms. Label illustrative examples. Flag missing evidence
with a clear editorial marker instead of filling the gap with a plausible fact.
If a section needs evidence outside the brief, list the missing input and
continue with supported work. Do not claim the page has been tested, approved
or published. Return unresolved questions with the draft for reviewer decision.
These instructions guide the draft; they do not replace review. Check sources, links and unsupported inferences even when the output follows the requested structure. Add voice examples and terminology where they improve consistency, while keeping factual constraints separate from style preferences.
Review the draft against the assignment
Before release, the reviewer should be able to answer:
- Does the opening promise match the reader's main task?
- Does each section answer its assigned question without absorbing a neighboring page?
- Are consequential claims supported by the actual cited material?
- Are assumptions, examples and missing assets labeled honestly?
- Do links resolve and help the reader continue?
- Do the title, description, author, dates and structured-data handoff match the page?
- Are the CTA and any product/offer claims current and appropriate?
If research changes the scope, revise the brief and have the responsible editor decide whether the existing URL remains the right owner. Do not quietly expand the assignment into a second page's job.
For the continuing review and delivery process, see the automated content workflow.
Put the review into your production process
Keep the worksheet and supporting evidence beside your draft. Verify the claims and intended destination before release. For the wider process, see the content workflow guide. If you are evaluating Blogoose, review current plans and publishing access.
Questions before the handoff
How long should the brief be?
Long enough that the writer can act without guessing at material decisions. A straightforward update may need a short assignment; a comparison involving changing product facts may need a detailed source register. Remove repetitive instructions, not necessary evidence.
Can writing start while a fact is pending?
Yes, if the writer can work on supported sections and clearly flag the missing input. Keep publication on hold when the unresolved fact affects the page's promise, recommendation or product terms.
Can the writer change the outline?
Yes, when the change makes the answer clearer and preserves the agreed reader task. A change to scope, evidence requirements or page ownership needs an editor's decision and an updated brief.