On this page
An SEO content brief is the shared plan for a page: who it helps, what question it answers, what evidence it needs and how the finished work will be approved. It should let a writer or AI-assisted workflow begin without inventing the product facts or guessing the reader’s task.
Copy the fields below into your project document. These are free inline templates, followed by completed fictional examples. A brief supports editorial decisions; it cannot guarantee rankings or remove the need for subject review.
What belongs in an SEO content brief?
| Field | Decision it records |
|---|---|
| Reader and task | Who needs the page, what they already know and what they need to do. |
| Search intent and page type | Why this should be a guide, comparison, category or product page. |
| Existing coverage | Whether to create, improve or merge, with the relevant URLs. |
| Evidence and original value | Sources, product facts, examples and first-hand material. |
| Structure and next step | The answers, assets and action that belong on the page. |
| Owner and acceptance | Who checks claims, approves the draft and publishes it. |
Swipe the table to see all columns.
A copyable content brief template
1. Project and audience
- Working title: [Specific question or useful outcome.]
- Reader: [Role, situation and relevant prior knowledge.]
- Task: [What the reader should be able to decide or do.]
- Business purpose: [Why this page belongs on this site.]
- Scope exclusions: [Questions this page will not attempt to answer.]
2. Search and existing coverage
- Main query: [Phrase and intended meaning.]
- Supporting questions: [Relevant questions, without a repetition quota.]
- Research record: [Tool, market, date and limitations.]
- Existing URLs: [Pages or drafts that already cover the task.]
- Decision: [Create, improve or merge, and why.]
3. Evidence and product boundaries
- Approved sources: [Direct primary links, dates and the claims they support.]
- Original material: [Interview, worked example, screenshot or measured result.]
- Product facts: [Current features, availability and responsible owner.]
- Unknowns: [Items that need verification before publication.]
- Claims to avoid: [Unsupported guarantees, invented statistics or retired features.]
4. Outline and assets
- Direct answer: [The concise opening answer.]
- Main sections: [Questions in a useful reading order.]
- Example: [Inputs, steps, result and limitations.]
- Images: [Purpose, rights, alt text and caption.]
- Internal links: [Useful next pages and descriptive labels.]
- Call to action: [A relevant next step with no invented offer.]
5. Delivery and review
- Voice: [Specific style guidance and an approved example.]
- Length budget: [Space needed for the task, not a ranking target.]
- Owners: [Writer, factual reviewer, editor and publisher.]
- Dates: [Draft, review, release and next evidence check.]
- Acceptance: [Facts verified, sources linked, examples labeled, mobile checked and next step working.]
- Measurement: [Page-level baseline and meaningful reader outcome.]
Three completed examples
Service business: payroll handover checklist
Reader and task: An operations manager switching payroll providers needs to identify the information and approvals required before the first run. The page should help them prepare a handover, not supply jurisdiction-specific tax advice.
Evidence: An approved provider checklist, actual service boundaries and a reviewed sample handover record. An expert must approve any deadline or regulatory statement.
Outline: Establish the cutover date; confirm data owners; reconcile required records; test the handover; approve the first run. Include an original sample record with owner, due date, status and unresolved issue.
CTA and acceptance: Request a handover consultation. Remove any promise of error-free payroll. Confirm that the service page explains what is included.
SaaS: choosing a support ticket workflow
Reader and task: A support manager needs to evaluate assignment, escalation and reporting. Compare workflow requirements rather than declaring one product universally best.
Evidence: Verified configuration screenshots, documented plan availability and a test ticket moving between two owners. Label a demonstration as a demonstration.
Outline: Define the incoming channels; assign an owner; set escalation rules; inspect the handoff history; review unresolved tickets. Distinguish a configured integration from a native feature.
CTA and acceptance: Request a workflow demonstration. A product owner checks every feature and the editor confirms that the example contains no customer data.
Ecommerce: choosing a commuter bottle
Reader and task: A commuter compares capacity, dimensions, closure and cleaning. Link to a suitable collection and individual products.
Evidence: Supplier specifications, original photographs and approved care information. Any insulation or leak-resistance claim must have supporting evidence for that model.
Outline: Measure the intended fit; compare capacity; inspect closures; check cleaning; compare suitable models. Use a small comparison table of verified attributes.
CTA and acceptance: View the matching collection. Check current availability, prices and the actual mobile product journey before release.
Use the brief in the current BrandWell workflow
- Review existing coverage in RankWell. Decide whether to create a page, improve one or combine overlapping coverage.
- Bring relevant research from Visibility. Keep estimates separate from your own observed results.
- Supply the approved brief, sources, product facts and voice. Ask AIMEE to flag missing evidence rather than invent it.
- Review the outline and draft, inspect sources and media, and use the search preview to check how the page is described.
- Get factual and editorial approval, then publish through your configured destination.
Review structure before publishing
W3C’s heading guidance recommends a logical hierarchy that communicates page organization. Give each section a descriptive heading and nest subsections consistently. Do not select heading levels simply to make text larger.
Make the opening answer self-contained, then support it with clear definitions, evidence and an original example. This helps readers evaluate the page and makes its meaning easier to extract. It does not guarantee an AI Overview citation.
Common questions
How long should a brief be?
Use enough detail to resolve important decisions. A narrow update may need a short record; a technical guide needs more evidence and review instructions. Repeated generic instructions do not make a brief more useful.
Can AI create the brief?
It can prepare an outline from approved inputs. A person still needs to confirm the audience, evidence, product availability and missing questions.
How do you know the brief helped?
Record revision time, factual issues found and acceptance outcomes. After release, compare page-level search and conversion results over comparable periods. Publishing a brief is not itself an outcome.
Reviewed and updated October 7, 2026.
Written by
Julia McCoy has contributed articles to BrandWell on content marketing, writing, and search engine optimization. This archive retains her original bylines; individual articles may be updated by the BrandWell editorial team.
