How to build a content brief that can pass review
Turn a verified user need into a distinct page contract, source packet, claim-and-proof outline, acceptance tests, owner and review plan.
A useful content brief is a testable page contract. Start with an observed user, task and decision; check whether an existing URL should be updated instead; define the new page's unique promise and scope; attach the sources, first-hand evidence and open questions; then outline each section as a claim, its proof and the action it enables. Finish with named ownership, factual and accessibility acceptance checks, a real destination for every call to action and a review plan. Keywords may clarify vocabulary, but search volume and a target word count cannot substitute for user need or evidence.
Write the user need before choosing the format
Record who is trying to do what, the situation that triggers the need, the decision or outcome they need and the evidence that the need exists. Use interviews, support themes, site searches, product events or performance data with a stated collection period. Treat stakeholder requests and keyword lists as assumptions until user or product evidence supports them, and include people whose access needs or circumstances differ from the assumed default.
- Name the audience and triggering situation.
- Describe the task in the user's terms.
- State the decision or outcome the page must enable.
- Link the research or behavior evidence and its date.
Decide whether a new canonical page is necessary
Audit the existing inventory before assigning a URL. Compare the proposed promise with current pages, merged query groups, internal links and the wider user journey. Update or expand an authoritative page when the same audience would receive the same answer; create a separate page only when the task, decision, scope or evidence is materially distinct. Record the canonical destination and which near-duplicate proposals were merged or rejected.
Build an evidence packet with visible gaps
Attach the current primary references, product contract, tested fixture, original analysis, approved policy and subject-matter owner needed to support the page. For each planned claim, name its source, applicable date, jurisdiction, version and important limit. Mark unanswered questions and assign them rather than letting a writer fill them with plausible language. Remove private or licensed source material that cannot be safely published or paraphrased.
Outline claim, proof and reader action
Give the opening a direct answer bounded by the available evidence. For every section, state the question it resolves, the claim or instruction it can support, the proof or worked example it will show and what the reader can do next. Use descriptive headings and the shortest structure that completes the task. A prescribed word count, competitor heading list or pile of related phrases is not an outline and can encourage repetition instead of useful coverage.
Make acceptance and maintenance part of the assignment
Define what must be true before indexation: distinct intent, supported facts, original wording, one clear H1, accurate title and description, correct canonical and schema, meaningful links, accessible structure, loaded original media, a live CTA, and desktop/mobile review. Name the writer, expert reviewer and publisher, set a review date, and identify the behavior or feedback that would trigger revision. Search performance can expose mismatched queries or low engagement; it does not by itself prove why a page succeeded or failed.
Check the primary references
Check the source against the result
Brief for /guides/how-to-write-meta-descriptions-at-scale: SEO, content and engineering teams need to decide how to create many accurate descriptions without producing duplicates or display promises. Existing related pages cover titles, duplicate intent and scaled-content abuse. Evidence packet: current Google snippet, starter, spam and Search Console guidance plus the exact live JSON Formatter and Flowchart Generator descriptions.
Page contract: explain verified page records, family-specific templates, missing/duplicate/unsupported-output gates, rendered-head inspection, snippet uncertainty and page/query measurement. Acceptance: five distinct sections, four official references, both exact live descriptions, one H1, Article and Breadcrumb schemas, original text-free artwork, a live JSON Formatter CTA, no unsupported fixed-length rule, and no promise of snippet display, ranking or CTR improvement.
The brief names a user decision, differentiates the route, connects every major section to evidence and makes review observable. It does not prove the need is frequent, the sources have been interpreted correctly or the finished page will help every reader; research, subject-matter review, browser QA and post-publication feedback remain required.
Inspect the completed page behind the worked brief
The meta-description guide turns the brief's user decision, two exact product records, four primary references and explicit non-guarantees into a reviewable article.
Open the completed guide