What Belongs in a Content Brief, and What Doesn't

Most content briefs are keyword lists wearing a suit. Primary keyword, five secondary keywords, a word count copied from an average of the top ten, and a note that says "match search intent." A writer receiving that document has to redo the research themselves, which means the brief added a meeting and subtracted nothing.

A brief is a specification. Its job is to eliminate guessing about anything that can be determined from evidence, so the writer spends their effort on the part that can't be: explanation, examples, judgment, and prose. Everything below is about where that evidence comes from and how to write it down in a form someone can act on.

Why does the SERP beat the keyword tool as a starting point?

A keyword tool tells you what people typed. The SERP tells you what the ranking system currently believes satisfies that typing. Those are different objects, and only one of them is feedback.

When you open the results for a target query, you're looking at a set of pages that have already survived selection. The commonality among them — page type, depth, whether they're commercial or editorial, whether the answer arrives in the first screen — is the closest thing you get to a public statement about what the query rewards. Google has documented that it tries to match results to intent, and the SERP is the observable output of that attempt.

So the first section of a brief is not a keyword. It's a one-sentence claim about what the page must be, defended by the SERP: "Eight of the ten results are step-by-step tutorials with screenshots; two are tool landing pages that rank for the brand modifier. This page is a tutorial." That single sentence prevents the most expensive failure mode, which is a well-written page of the wrong type.

Which questions does the page actually have to answer?

This is the highest-leverage part of a brief and the part most often skipped. You are trying to enumerate the sub-questions a reader carries into the query, and there are four cheap sources:

• People Also Ask panels, expanded a couple of levels deep. These are query reformulations Google associates with the topic. Not all are worth answering, but they show the shape of the follow-up.
• Subheadings from ranking pages, scraped and deduplicated. If seven of ten top results have an H2 about pricing, pricing is table stakes, not a differentiator.
• Autocomplete and "related searches" for the head term plus common modifiers (vs, without, cost, for).
• Forum and community threads — Reddit, Stack Overflow, trade forums — where the actual phrasing of confusion lives. This is where you find the questions nobody in the top ten answers.

Write them as questions, ordered, with a note on which ones the competition handles badly. That last column is where the brief stops being a summary of the SERP and starts being a plan to beat it.

Why name specific entities instead of listing secondary keywords?

Secondary keyword lists encourage insertion. Entity lists encourage coverage. The difference matters because of how retrieval systems appear to work.

Google has documented that it maintains a Knowledge Graph of entities and relationships, and that it uses passage-level analysis to surface specific parts of a page. The reasonable inference — not documented mechanism, but consistent with how embedding-based retrieval behaves — is that a page which names the specific tools, standards, people, formats, and organizations in a topic is easier to place confidently in that topic than a page that gestures at it with generic phrasing. Naming Core Web Vitals, INP, and the CrUX dataset disambiguates in a way that "site speed metrics" does not.

Practically, the entity section of a brief lists nouns a subject-matter expert would inevitably mention: named specifications, competitor products, governing bodies, file formats, version numbers, statute names. If your writer can produce the draft without mentioning any of them, the draft is probably generic. This is not a keyword density instruction, and you should say so in the brief, because writers have been trained by bad briefs to sprinkle.

What does "match the format" mean concretely?

Format matching is about the physical layout of the answer, and it's specific enough to specify:

• Answer position. If the SERP shows a featured snippet, the winning pattern is usually a direct answer within the first hundred words or so, in the format the snippet uses (paragraph, list, or table). Specify which.
• Table vs. prose. If comparison tables appear in most ranking pages, the brief should contain the table's column headers, not a suggestion to "consider a table."
• Media. Screenshots, original diagrams, code blocks, embedded calculators. Note what the top results include and what they conspicuously lack.
• Schema. If the ranking set is dominated by pages with FAQPage, HowTo, or Product markup rendering visible SERP features, the brief should name the type and the required properties.

Then decide, explicitly, where you're breaking format. Copying the SERP produces a tenth identical page. The useful pattern is: match the structural expectations, differ on substance — an original dataset, a working example, a decision framework nobody else provides.

Isn't word count the one number the brief needs?

No. Google's John Mueller has said repeatedly that word count is not a ranking factor, and the observable correlation between length and ranking in the top results is better explained by topic coverage than by volume. A brief that specifies 2,400 words gets you 2,400 words.

Use length as a sanity range, expressed as a consequence: "Answering these eleven questions properly will land around 1,800–2,400 words. If it comes in at 900, something is unanswered. If it comes in at 4,000, cut the background." That gives the writer a diagnostic instead of a quota.

What fields should the brief actually contain?

The last two rows do more work than they look like they do. "Claims needing sources" is what stops a writer from inventing a statistic to fill a paragraph. "Out of scope" is what stops two of your pages from competing for the same query six months later.

A machine-readable version travels better than a doc:

slug: /guides/incremental-static-regeneration-seo
page_type: tutorial
thesis: ISR can serve stale HTML to crawlers; here is how to detect and bound it.
questions:
  - What does ISR actually serve to a first-time crawler?
  - How do you tell a stale response from a fresh one in logs?
  - Which revalidate values are safe for which page types?
entities: [Next.js, revalidate, stale-while-revalidate, Vercel, x-nextjs-cache]
format:
  answer_position: first_120_words
  code_blocks: required
  table: [page_type, revalidate, risk]
out_of_scope: [app-router-vs-pages-router, general CDN caching]

What to do with this

1. Take your current brief template and delete every field a writer can't act on. Keyword density targets, "LSI keywords," and readability score thresholds go first.
2. Add the questions list and make it the longest section. Build it from expanded PAA plus scraped competitor subheadings, and mark the two or three the top results answer badly.
3. Replace secondary keywords with an entity list, and add a line stating that these are things to cover, not strings to insert.
4. Specify format as layout, not as advice — column headers, answer position, schema type and properties.
5. Name the differentiator before the writer starts. If you can't name one, the brief isn't finished, and the page probably shouldn't be written yet.
6. Ship internal link targets as URLs. Anchor text suggestions are optional; the URL list is not, because nobody retrofits internal links later.

The test of a brief is whether two competent writers given the same one would produce pages that compete similarly on the SERP, differing in voice rather than in substance. If the outputs diverge structurally, the brief left decisions on the table that you should have made from the evidence.