An SEO content brief is the page decided in advance. It says who the page is for, which query it answers, which query it must leave alone, what the headings have to explain, which sources may be cited, and which of your own URLs it should link. A content brief template is that list, filled in once per URL. It is not a spreadsheet of phrases with a target count beside each one.
Write one brief per page. Name the job of the page, the primary query and one close variant, the search intent, what is out of scope, the questions each heading must answer, the entities to explain, the sources you may cite, the internal links, and the title, slug, and schema. Keep word count as a range. Do not set a keyword density.
What is an SEO content brief?
Writers miss when the assignment is “write 1,800 words on scrum versus kanban.” That sentence does not say for whom, which situation, what the page must not repeat, or which of your articles already covers standups. The draft then borrows the shape of whatever ranks today, adds a few synonyms, and links to whatever URLs the writer remembers. The page can look finished and still be the wrong page.
Surfer, Clearscope, and Frase all sell a faster version of the same starting point: look at the current results, extract headings and related terms, and hand the writer a score. Those tools are useful for seeing the field. They are a weak brief if the score becomes the assignment. Clearscope-style term lists push coverage of concepts. Surfer-style editors also push structure: length, heading count, and term frequency. If you merge those into one number, people chase the number. The concepts get mentioned. The page does not get decided.
A brief is the decision. The tools can inform it. They should not replace the fields below. Google’s helpful-content guidance asks whether the page is made for a person who will read it. A density target does not answer that. A sentence about the reader does.
How a content brief differs from an outline
An outline is the order of sections. A content outline for SEO still matters, because a reader and a retrieval system both use headings to find the part they need. The outline is one field of the brief. The brief also locks the edges: the query this URL will not chase, the page you already have that is closest, the facts that are allowed, and the links that are real.
Teams that only share an outline get drafts that are structurally fine and factually loose. Teams that only share a keyword list get drafts that repeat the keyword and never choose a point of view. The editorial brief is the document that holds both the structure and the constraints. Call it an editorial brief, a content requirements note, or an SEO content brief. The name is less important than filling the fields before anyone writes the first paragraph.
What to include in the template
Use the same fields every time so a second person, or a model, can follow them without a meeting. Leave a field blank only when you have decided it does not apply, and write “none” so the blank is a choice.
| Field | What you write | What goes wrong without it |
|---|---|---|
| Job of the page | One sentence: who reads it, and what they can do afterward | The draft tries to rank and to convert and to define, and does none of them |
| Primary query and one variant | The query you want this URL to be known for, plus the close phrasing people also use | The title, the H1, and the slug drift apart |
| Search intent and SERP format | Learn, do, compare, or buy, and what the current results look like | You write an essay where the results are templates, or a list where the results explain |
| Out of scope | The neighboring topic, and the URL that owns it | The draft swallows the next article and both pages compete |
| Outline | Headings in order, each with the question that section answers | Headings become labels, and the answer is buried |
| Entities | The concepts, products, and standards the page must explain in plain language | The page hits a length target and still skips the thing the query assumes |
| Sources and banned claims | URLs you may cite, and the kinds of numbers you must not invent | The draft fabricates a percentage or cites a blog that contradicts you |
| Internal links | URL, suggested anchor, and why a reader would click | Links are added at the end, or they point at pages that do not exist |
| Title, description, slug, schema | The title link, the snippet hint, the path, and only schema you will show on the page | The HTML promises a how-to or an FAQ the article does not contain |
| Closest existing URL | The page you already have, and how this one differs | You publish a second URL for a query you already answer |
A word-count range can sit underneath the table as a guardrail, taken from the depth of the results, not from a superstition. “1,600 to 2,200 words” means the subject needs room. It does not mean a 2,199-word page is unfinished and a 2,201-word page is optimized. Title links and snippets are written for people. Google may rewrite either one. Write them clearly anyway, because they are also what a person sees when the rewrite does not happen.
A content brief example
This is a brief for one cluster page, not for a whole site. The subject is the topic cluster example from the companion guide: a product-team rituals pillar, and a comparison page underneath it.
Job of the page. Help a six-person product team decide whether to run Scrum or Kanban for the next quarter, and leave with one recommendation they can try on Monday.
Primary query. scrum vs kanban for a small team. Variant. scrum or kanban for six people.
Intent and format. Comparison. Current results are articles with a table, a “choose this if” section, and little about team size. The gap is the six-person constraint.
Out of scope. How to run the standup. That is a separate how-to. Do not paste a standup script here.
Outline. What each practice asks of a six-person team. A table on roles, cadence, and work-in-progress. Who should pick Scrum. Who should pick Kanban. What to review after four weeks.
Entities. Scrum, Kanban, sprint, work in progress, standup, retro. Explain each once, in a sentence, without a textbook detour.
Sources. The team’s own last retro notes if they are publishing a case. No industry survey unless you can name it and link it. Do not invent a percentage who “prefer Kanban.”
Internal links. Pillar page, anchor “product team rituals,” because the reader may want the map. Retro questions, anchor “sprint retro questions,” because the four-week review needs them. Do not link the standup procedure except in one clause that points away.
Title. Scrum vs Kanban for a Six-Person Team. Slug. scrum-vs-kanban-six-person-team. Schema. Article plus FAQ, and only if the FAQ is visible.
Closest URL. None yet. If “agile for small teams” already exists and ranks for this query, update that page instead.
A writer can execute that without asking what the page is for. A model can execute it too, which is the next section. Notice the brief never says “use the primary keyword four times.” The query appears in the title and the slug because that is where a person looks to confirm they are in the right place. The body uses “Scrum” and “Kanban” because those are the things being compared.
Search intent, people also ask, and the results in front of you
Search intent is not a label you pick from a dropdown and then ignore. Open the query in a private window and write down three things: the dominant format, the questions in the “people also ask” box, and the subtopics every serious result shares. The format is the assignment. The questions are candidates for headings or for the FAQ, but only if this page is the right place to answer them. A question that belongs to another cluster page goes in “out of scope,” with a link, not into this outline.
People also ask is a source of real wording. It is not a quota. If you answer eight adjacent questions on one URL, you have rebuilt the pillar on the cluster page. Pick the questions that a person with this intent still has after the introduction. Point the others at the URL that owns them.
Write one line on what the top results fail to do. In the example, they compare the frameworks and skip the team size. That line is the information gain. It is the reason your page exists beside theirs. If you cannot name a gap, you may be about to paraphrase the results. Stop and either find a situation you know firsthand or choose a different query.
Entity coverage is not a word count
An entity here is a thing the page must be able to explain: a method, a role, a standard, a product, a constraint. For the example, “work in progress” is an entity. A reader comparing Scrum and Kanban will misunderstand the recommendation if the page never says what limiting work in progress means for six people.
List those entities in the brief as words you will teach, not as a density column. Teaching means a sentence that defines the thing and a sentence that applies it. Mentioning the thing in a comma-separated list is not coverage. This is the split the better 2026 brief guides insist on, and it is the split most scoring tools blur. Keep the list short enough that every item can be taught. Twenty entities on a single cluster page usually means the page is secretly a pillar.
Length still has a use. A comparison that teaches six entities, includes a table, and walks through a four-week trial will not fit in 400 words. Put a range in the brief so nobody pads to a superstition or stops before the recommendation. Review the draft against the entity list and the job sentence, not against the midpoint of the range.
Sources you may cite, and claims you must not invent
Every factual claim in the brief should have a home: a primary document, your own product behavior, or a measurement you ran. Link the primary document when you state its rule. The page on citing sources is how that sentence should read. For search, that is usually Google’s own documentation, not a recap of it. The helpful-content page, the page on crawlable links, and the page on title links are enough for most editorial rules. You do not need a chain of blogs citing each other.
Write a do-not-invent list in the brief, especially if a model will draft:
- No percentages, rankings, or “studies show” without a URL and a date.
- No quotes from a person you did not interview.
- No claim that a method “guarantees” rankings, traffic, or citations.
- No competitor weakness you cannot demonstrate from their public page.
- No customer story that is not yours.
This list is what keeps a fast draft from becoming a page you have to apologize for. Answer engines repeat precise claims. A made-up statistic is not a shortcut to being quoted. It is a quote you cannot defend.
Internal links, with anchors
The brief should name each internal link before the draft exists. Three columns are enough: the URL, the anchor you would accept, and the reason a reader on this page would want it. If you cannot write the reason, cut the link. Footer links and “related posts” blocks do not count as this field. They are site chrome. The links that teach are the ones inside the explanation.
Anchors should describe the destination in the sentence you already needed. “See our guide to topic clusters and pillar pages” is a real reason if the paragraph is about where this URL sits in the cluster. “Click here for SEO” is not. Match the anchor to the page, then vary it across the site. You do not need every article to use one frozen phrase.
Only list URLs that return a page today. A brief that assigns links to next month’s drafts will ship broken anchors if the calendar slips. When the other page is published, add the link in an update. That is also how a pillar page should grow: links appear when the cluster page is real.
Title, meta description, slug, and schema
Write the title as the promise of the page, with the primary query in natural language. Google does not publish a character limit for the title element or the meta description. The result is cut to fit the device, which is why a short promise is easier to read than a keyword list. The title tag page is that choice. The meta description is a one or two sentence summary you hope a person reads before they click. Google may ignore it and use a passage from the page instead, so the opening has to be able to stand as the snippet.
The slug should be short, lowercase, and made of words from the promise. scrum-vs-kanban-six-person-team is a slug. blog-post-17-final-v3 is a file name. Do not stuff the variant, the pillar query, and five modifiers into the path.
Schema is a description of what is visible. If the page has a real question-and-answer block, FAQ schema can mirror those questions and answers word for word. If it does not, do not add FAQ schema. The same rule covers how-to steps and reviews. Mismatched structured data is a trust problem, not an enhancement. FAQ rich results stopped appearing in Google Search on 7 May 2026, so the markup does not produce an accordion. The article schema guide is which fields to repeat, and which types not to add.
The cannibalization check
Cannibalization is two of your URLs competing for the same query because you did not decide which one owns it. The check is a field, not a feeling. Search the primary query on your site. Look at Search Console and see which URL already receives impressions for it. Read that page. If it answers the job in your brief, update it. If it answers a neighboring job, say so in “out of scope” and link to it. Only then is a new URL justified. Doing that review for the whole site, not only the draft in front of you, is an SEO content audit.
This is also how a cluster stays intact. The pillar owns the broad query. The comparison owns the choice. The template owns the copy-and-paste job. The brief for each one names the other two as out of scope. Without that, the next draft “helpfully” includes a little of all three, and you are back to overlapping pages. The pipeline guide describes the same guardrail as a system: group queries so articles do not chase one keyword twice.
What to add when a model writes the first draft
A person can infer tone from the last three articles. A model will not, unless you say so. When the writer is a model, add five constraints to the same template:
- Voice. Sentence length, whether you use “you,” and the words you do not use.
- FAQ wording. The questions, written as you want them asked, so the visible FAQ and the schema cannot drift.
- Allowed URLs. Internal links may only use this list. No guessed paths.
- Dated facts. If a fact can go stale, include the date you checked the source.
- The do-not-invent list from above, pasted in full, not summarized as “be accurate.”
Google’s position on automation is not a ban on generated text. Scaled pages that exist to catch queries, without helping anyone, fall under spam policies. A brief is one of the practical differences between those pages and a page someone is accountable for. The model can draft. A person, or the organization, still has to be able to stand behind the sources, the scope, and the links. That is also why BloGoose drafts from your site’s context and your real sitemap instead of from a keyword alone. The API docs cover connecting the site. The brief is the editorial half of the same idea.
After the draft, review it against the brief, not against a vague sense of quality. Did it stay inside scope? Did every entity get a real explanation? Are the links on the allowed list? Do the title, the H1, and the first answer say the same thing? If a section only exists to raise the word count, cut it. Then publish, and send the URL for indexing when you are ready. The indexing setup is the step after a page that deserves to be fetched, not a substitute for the brief.
How this shows up in BloGoose
BloGoose does not ask you to paste this template into a blank form for every article. It builds the same decisions from the site: the pillar, the intent, the outline, the internal URLs that exist, and a draft that can be reviewed before it goes live. If you want to see the fields on one page before you trust a calendar of them, fill this template once by hand for a single cluster page. You will notice immediately which of your current posts were written from a keyword and which were written from a job.
Turn the brief into a draft you can edit
Connect a site, confirm the pillars, and review the article before it publishes. The links come from your sitemap, not from a guessed URL.
Start the 1-day trialQuestions about SEO content briefs
What is an SEO content brief?
An SEO content brief is the set of decisions for one page, written down before the draft. It names the query, the search intent, who the page is for, what it will not cover, the outline, the sources, the internal links, and the title, slug, and schema. It is not a keyword list.
What should an SEO content brief include?
Include the job of the page, the primary query and one close variant, the search intent and the format of current results, an out-of-scope note, an outline of questions the headings must answer, the entities the page must explain, sources you may cite, internal links with anchors, the title, meta description, and slug, the schema that matches visible content, and the closest URL you already have.
How is a content brief different from an outline?
An outline is the heading order. A content brief also decides intent, scope, sources, links, and what must not be invented. An outline without those decisions still lets the draft wander into a neighboring topic or cite a claim nobody checked.
Should a content brief set a keyword density?
No. Repeating a phrase a set number of times is not a ranking method, and it makes the page worse to read. Name the primary query, a close variant, and the entities the page must explain. Use them where they belong in the title, headings, and sentences.
How do you stop a brief from causing cannibalization?
Write down the closest URL you already have and the query it serves. If the new page would answer that same query, do not create it. Update the existing URL, or narrow the new page until the two jobs are different.
Can an AI writer follow a content brief?
Yes, if the brief is specific. Add a list of claims that must not be invented, the exact questions the FAQ should answer, and the internal URLs that are allowed. A model given only a keyword will invent structure, sources, and links.