SEO Content Brief: A Markdown Template for Founders and AI Agents

You ask an AI agent to write a blog post. The draft is readable, but it explains the wrong problem, repeats your existing articles, and introduces a product feature you do not offer. Editing the sentences will not fix the missing decisions.

An SEO content brief makes those decisions before drafting starts. It gives a writer or agent a reader, a question to answer, a useful angle, evidence, and a clear definition of finished.

Below is a copyable Markdown template, the completed brief behind this article, and a handoff prompt you can use with an AI agent. You can keep the brief beside your code or notes, review it in a diff, and reuse the structure for your next article.

TL;DR

• An SEO content brief connects one search intent to a reader outcome and a relevant business goal.
• Include the angle, outline, verified sources, internal links, product facts, and acceptance criteria before asking for a draft.
• Use keywords to understand the question; choose length according to what the answer needs.
• Give an AI agent explicit boundaries for unsupported claims, missing evidence, and publishing permissions.
• Keep the research brief separate from the article, then review both before saving a draft.

Copy this SEO content brief template

Save this as a separate Markdown file and replace the bracketed instructions. Delete any field that does not improve the handoff.

# Content brief: [working article title]

## 1. Reader and purpose
- Audience: [role, situation, existing knowledge]
- Reader problem: [one concrete question]
- Reader outcome: [what they can do after reading]
- Business connection: [why this belongs on our site]
- Useful next step: [an appropriate CTA]

## 2. Search context
- Primary keyword: [one main query]
- Supporting queries: [closely related questions]
- Market and language: [country, language]
- Research date: [date]
- Volume and difficulty: [source, value, date; or unavailable]
- Observed intent: [what the reader is trying to accomplish]
- Expected format: [guide, template, comparison, reference]
- SERP observations: [relevant results and what they provide]

## 3. Editorial direction
- Proposed title: [clear promise]
- Angle: [specific scope and perspective]
- Original contribution: [example, template, analysis, walkthrough]
- In scope: [questions this page must answer]
- Out of scope: [adjacent topics covered elsewhere]
- Voice: [practical instructions and examples]
- Length: [a flexible target justified by scope]

## 4. Evidence and product facts
- Claim: [specific factual statement]
  - Source: [verified destination]
  - Support: [relevant passage or section]
  - Checked: [date]
  - Limitations: [scope, version, uncertainty]
- Approved product facts: [verified capabilities]
- Unsupported or prohibited claims: [what must not be asserted]
- Missing evidence: [what needs research or an owner's answer]

## 5. Outline
- Introduction: [reader's problem and promised outcome]
- TL;DR: [three to five useful takeaways]
- H2: [question or task]
  - Purpose: [what this section resolves]
  - Example or evidence: [what it needs]
- H2: [next question or task]
  - Purpose: [what this section resolves]
- Conclusion: [actionable next step]

## 6. Links and visuals
- Internal destination: [verified published page]
  - Anchor idea: [descriptive wording]
  - Placement: [section and reader benefit]
- External source: [verified page and supported claim]
- Cover: [topic, visual idea, brand direction]
- Inline visual: [section, explanatory job, alt-text idea]
- Avoid: [fake screenshots, invented chart data, decoration]

## 7. Metadata and handoff
- Proposed slug: [unique lowercase kebab-case]
- Meta description: [accurate concise summary]
- Draft destination: [CMS project or local folder]
- Content owner: [reviewer]
- Publishing permission: [explicit permitted action]

## 8. Acceptance criteria
- [ ] Answers the primary question early
- [ ] Includes the promised example or template
- [ ] Has a useful TL;DR
- [ ] Uses verified product facts and source-backed claims
- [ ] Adds relevant internal links to published pages
- [ ] Labels hypothetical examples
- [ ] Contains no invented results or personal experience
- [ ] Matches the intended scope and voice
- [ ] Has accurate metadata and descriptive image alt text
- [ ] Remains a draft until an authorized publishing decision

Keep the brief outside the folder your publishing pipeline automatically ingests, or otherwise exclude it from that pipeline. A research note and an article can both be Markdown files, but they have different destinations.

If you want structured metadata in the eventual article file, our YAML frontmatter guide explains the syntax and how fields vary by tool.

What is an SEO content brief?

An SEO content brief is a writing specification for a page that should answer a searcher's question and serve a defined audience. It records what the article needs to accomplish, why it belongs on your site, and what evidence the writer can use.

It is more detailed than a topic suggestion and more focused than an entire content strategy.

The useful test is whether another person could make the important editorial decisions from the brief. If they still need to guess the audience, invent the examples, or decide what your product does, the brief is unfinished.

What should an SEO content brief include?

Start with the fields that prevent expensive revisions. You can add workflow details later.

A reader and a concrete outcome

“Founders” is an audience category. “A solo founder who needs to send a clear weekly project update without maintaining another reporting system” gives the writer a situation.

Then state what the reader should be able to do after reading. Prefer an observable action: choose an approach, complete a task, diagnose a problem, or adapt a template.

Keep the article outcome separate from the business outcome. The reader wants a usable status report; your business may want a relevant trial signup. The article needs to earn that next step by helping with the first one.

Search intent and the page format

Record the primary query, the country and language, and what the current results suggest readers expect.

Look at the pages themselves. Are they tutorials, comparisons, templates, product pages, or reference documentation? A template query needs something readers can copy. A troubleshooting query needs a diagnosis path. An article that ignores that expectation may feel incomplete even when its prose is polished.

Write your interpretation in plain language. A provider's “informational” label is useful context, but it does not tell a writer which practical question to answer first.

An angle and a contribution

Explain what this page will add. Examples include a filled template, a reproducible walkthrough, a decision table, or a carefully bounded comparison.

Google's people-first content guidance asks creators to consider originality, usefulness, and the reader's ability to achieve their goal. Use those questions when choosing the article's contribution.

Evidence and product boundaries

List the sources that support important factual claims. For each, note the claim it supports, the relevant section, and the date checked. A collection of links without that mapping leaves the writer to guess.

Give product facts their own space. Include the features you verified, known limitations, and claims requiring a human check. Avoid mixing a planned feature with an available one.

For example, “users can export a Markdown file” and “automatic export is planned” must remain separate statements. If the second statement is irrelevant to the reader's task, leave it out entirely.

Structure, links, and acceptance criteria

The outline should answer the question in a sensible order. Under each heading, explain its purpose or the example it must contain.

Identify useful internal pages before writing. Record a destination, a natural anchor, and the section where the link will help. Google's link best practices recommend descriptive, relevant anchor text; a forced exact-match phrase adds little value.

Finally, define what makes the draft acceptable. “High quality” is hard to review. “The reader can copy the template, understand the example, and identify the next step” is something an editor can check.

How to fill the brief before you draft

1. Check whether the article should exist

Search your existing posts, drafts, and relevant product pages for the same question. Compare the intended reader outcome, not just the keyword.

A broad article on developer blogging and a focused guide to creating a content brief can coexist because they do different jobs. Two guides promising the same template to the same reader need a stronger distinction.

When the existing page already answers the question, improving it may be more useful than creating another URL. Record that decision before paying for drafting or artwork.

2. Inspect the results and write an intent statement

Review several relevant ranking pages. Note their format, audience, strengths, and missing explanations. Use this research to understand expectations, then make your own editorial decisions.

An intent statement might read: “The reader needs a copyable brief they can hand to a writer or agent, with enough explanation to customize it.”

That sentence helps you reject unnecessary sections. A long history of content marketing does not help that reader complete the task.

Also note disagreements between the query and the results. If a phrase returns mostly creative campaign briefs, a narrowly focused SEO guide should explain its scope immediately.

3. Set the contribution before the outline

Choose the artifact or insight that makes the article worth opening.

Do not build an outline by copying the headings of the first three results. That creates a familiar structure without deciding what you will contribute.

4. Build a small evidence map

Read each source before marking it verified. Check whether it supports the exact claim, applies to the right product version, and contains limitations the article needs.

A useful evidence row can be simple:

5. Choose a flexible length and useful metadata

Estimate length from the sections, examples, and reader decisions. A narrow tutorial may need fewer words than a comparison with several meaningful trade-offs.

Google explicitly states that it has no preferred word count in its helpful-content guidance. A target range is an editing tool. It should not become a reason to repeat the answer.

Draft a title that accurately promises the outcome. Google's title-link guidance recommends descriptive, concise titles and warns against keyword stuffing. Google may generate a different search title, so do not promise that your chosen wording will always appear.

Write the meta description after the scope is stable. It should describe what the reader will find, including a template or worked example when that is the main value.

Filled example: the brief behind this article

Here is a completed brief for the article you are reading. It uses Blogizi's verified publishing workflow and this campaign's keyword research, so you can see actual decisions instead of instructions to fill in later.

Reader, search context, and direction

Product facts and evidence map

The product statement this article needs is narrow: Blogizi's draft tool saves an article as a draft, with publishing handled separately. It does not need claims about time saved, customer outcomes, or guaranteed traffic.

Sources checked October 26, 2026. No unverified product capability is required for this angle. Omit quantitative performance promises; they have no supporting measurement in this brief.

Filled outline and link placement

1. Introduction and TL;DR: identify the handoff problem and explain what the reader can copy.
2. Copyable template: deliver the main resource early, with fields for evidence and review.
3. Definition and field explanations: distinguish a brief from a strategy or outline, then explain the decisions each field captures.
4. Preparation workflow: check existing coverage, inspect search intent, choose the contribution, and map claims to evidence.
5. Completed example: show this article's audience, keyword evidence, product facts, outline, and metadata.
6. Agent handoff: provide the reusable prompt and connect it to the existing repo-to-draft workflow guide.
7. Editorial review: demonstrate how to turn a vague instruction into an actionable revision.
8. Conclusion: ask the reader to create one brief and save the resulting article as a draft for review.

Use the published YAML guide in the metadata discussion, the agent-publishing guide in the handoff section, and the technical-writing guide during draft review. Those destinations already exist and support different reader tasks; no new supporting post is required.

Metadata, visuals, and acceptance criteria

• Title: SEO Content Brief: A Markdown Template for Founders and AI Agents
• Slug: seo-content-brief-template
• Description: Build an SEO content brief with a copyable Markdown template, a filled SaaS example, and an AI-agent handoff prompt. Includes sources and review steps.
• Draft destination: Blogizi Blog; project slug blogizi-blog.
• Reviewer: the Blogizi campaign owner.
• Next step: save the article as a draft for review. No publishing date is assigned.
• Visuals: a branded cover plus illustrations of brief structure, organizing source material, and editorial review. They explain concepts rather than presenting product screenshots or measured results.
• Acceptance: the reader can copy the template without reconstructing it; the example resolves each editorial decision; the handoff prompt is reusable; product claims and links are checked; the draft remains unpublished and unscheduled.

This brief is ready to hand off because it identifies what to write, what supports it, and what the reviewer will check. If new evidence changes the angle, update the relevant decision before rewriting the article.

How to hand the brief to an AI agent

An agent needs the same editorial direction as a human writer, plus clear handling instructions for missing information and external actions.

Keep the approved brief, evidence notes, and product documentation together. Ask the agent to identify unresolved assumptions before it drafts. For the broader workflow, see our guide to turning repo context into SEO drafts.

A reusable handoff prompt can be short:

Read the approved content brief, evidence notes, and product facts.

First:
1. Summarize the reader's question and the article's contribution.
2. Flag missing evidence, conflicting facts, or overlap with existing posts.
3. Propose an outline that answers the question in a useful order.

Then draft the article:
- Follow the approved scope and voice.
- Include a concise TL;DR near the beginning.
- Use only verified sources and relevant published internal links.
- Label hypothetical examples.
- Do not invent features, statistics, quotes, experience, or results.
- Remove nonessential unsupported claims.
- Flag essential claims that need a human answer.
- Produce metadata and describe any useful visuals.

Save the result as a draft for review.
Do not schedule, publish, or edit other published articles.

Treat the prompt as editorial instruction. If an agent has access to publishing tools, confirm the tool permissions and destination as part of the actual workflow.

Google's guidance on generative AI content emphasizes accuracy, quality, relevance, and review of generated content. A fluent draft still needs its claims, links, and metadata checked.

Review the draft against the brief

Review in two passes: decisions first, then sentences.

In the first pass, check whether the draft performs the promised job. Can a reader use the template? Does the example explain a decision? Are important claims supported? Does the product appear where it is relevant?

If those answers are weak, revise the scope or structure before polishing the introduction. Our guide to writing technical posts people can follow offers a useful next step for improving the explanation itself.

In the second pass, check repetition, headings, terminology, metadata, links, and image alt text. Compare each acceptance criterion with the actual article. Do not approve a checklist item simply because the brief requested it.

For a Blogizi workflow, save the reviewed article as a draft in the intended project. Blogizi's draft tool documentation describes draft creation separately from publishing. Leave scheduling unset when the next action is human review.

Example: turn vague feedback into an actionable revision

Suppose a brief says: “Write a comprehensive guide to content briefs. Include SEO tips, examples, and a CTA.” A writer can follow that instruction and still miss the job: helping a founder prepare a usable handoff.

An editor can replace it with three specific decisions:

Now review the draft against those instructions. A table containing “find sources later” does not satisfy the first decision. A lengthy keyword-research detour does not satisfy the second. A generic signup pitch does not satisfy the third.

Send the writer this revision request: “Replace the partial example with a completed brief and evidence map. Move the copyable template ahead of the longer explanation. End with the draft-review action.” The feedback names the change and its purpose, so the next revision can be evaluated directly.

Start with one brief you can reuse

Choose one question your intended customer needs answered. Check your existing content, inspect the search results, and write the reader outcome before drafting the outline.

Copy the template, fill the evidence and product facts, and ask your writer or agent to flag the remaining gaps. Review the first article against the acceptance criteria, then adjust the brief based on the decisions that actually helped.

Use the brief to prepare your next article, then save it as a Blogizi draft for review. Check the article against the brief before choosing a publication date.