An SEO Content Brief Template With Evidence and Clear Scope
Create an SEO content brief that defines the reader, evidence, outline, scope and review steps before writing, with a reusable field-by-field template.
TL;DR
- An SEO content brief should define the reader's problem, the intended answer and the evidence needed to support it.
- Include the primary topic, scope boundaries, useful sources, an outline and the next step the reader can take.
- Review existing pages before commissioning a new one so the brief does not create avoidable duplication.
- Treat word count as a planning estimate, and approve the brief based on completeness and usefulness rather than a fixed length.
Make the brief a set of decisions
A useful brief reduces ambiguity before writing begins. It tells the writer who the page is for, what the reader should understand afterward and which claims need checking. A list of keywords and competitor headings leaves most of those decisions unresolved.
Begin with a plain-language sentence: “This page helps a small SaaS team diagnose why its sending domain is not verifying.” That statement is more useful than “write an SEO article about email.” It gives the writer a problem, an audience and a boundary.
The following template is an editorial framework. Adapt it to the article instead of requiring every field to have the same depth for every topic.
Record the audience and the job to be done
Write down the reader's starting situation, likely knowledge and immediate question. Identify what they need to decide or do. This helps distinguish an introductory explanation from a troubleshooting guide or product comparison.
For example, a developer fixing a rejected API request needs different details from a founder choosing an email provider. Both might search for related terms, but the most useful page structure is not necessarily the same.
Add a success statement: “The reader can identify the failing verification record and knows which value to check next.” Keep that outcome realistic and within the article's scope.
Use this compact brief template
| Field | What to write |
|---|---|
| Working title | A specific promise the article can fulfill |
| Primary topic | The main question or query |
| Audience | The reader's role, context and starting knowledge |
| Reader outcome | What the reader can understand or do afterward |
| Included scope | The questions the page must answer |
| Excluded scope | Related questions handled elsewhere |
| Evidence | Primary sources, product checks, examples or original data |
| Outline | Sections in the order the reader needs them |
| Internal links | Existing pages that supply context or the next step |
| Product connection | A relevant, accurate reason to mention the product |
| Review owner | The person responsible for factual or technical approval |
| Publication checks | Image, metadata, links, preview and live-page verification |
Keep the full brief in a document and link it from the content calendar. The calendar tracks progress; the brief explains the work.
Check the existing library first
Search your own site for pages that already cover the topic. Read the most relevant ones, including older articles whose titles may not match the new query exactly. Decide whether to update a page, create a supporting article or merge the proposed work into an existing brief.
If two pages would promise the same answer to the same reader, define a meaningful difference before commissioning both. The keyword overlap guide provides a way to investigate that decision without assuming every shared query is a problem.
Record the chosen relationship in the brief. “This article explains verification errors; the existing setup guide covers the first-time process” is a useful boundary.
Specify evidence instead of copying competitors
Competitor pages can reveal questions readers encounter, but their claims still need verification. Prefer original product documentation, standards, direct product checks and clearly labeled examples when those sources fit the topic.
Google's people-first content guidance emphasizes useful, reliable content and original value. For a brief, that means identifying what your page contributes rather than reproducing another site's structure with different wording.
Mark facts that require current verification, such as limits, pricing or interface steps. Give the reviewer a source and retrieval date where the information is likely to change.
Outline the answer in the reader's order
Put the immediate answer near the beginning, then explain the reasoning, steps, examples and exceptions. A troubleshooting article may start with a diagnostic checklist; a comparison may begin with the criteria that determine the choice.
Include a short TL;DR that summarizes the actual article. Do not use it to promise outcomes the body cannot support. Add tables or examples when they clarify a decision, not merely to make the page look more substantial.
Avoid prescribing an arbitrary number of headings or repeatedly inserting the primary keyword. The outline should reflect the problem's structure.
Approve the brief before expanding the draft
Ask whether the proposed evidence can support the title, whether the scope is manageable and whether the product connection is relevant. If a critical fact is unavailable, change the promise or leave the claim out.
Set a reasonable length estimate for planning, then let the answer determine the final length. A page should be as detailed as its task requires without adding repetitive sections to meet a quota.
Use RankWin to organize the keyword, article and publishing work, and retain a clear review step. A good brief gives the writer enough direction to produce something useful while leaving room for better findings during research.
