An AI model can turn a keyword into a usable SEO content brief and outline, but only if you split the job into steps and feed it data it cannot see on its own: the current search results, competitor headings and real reader questions. The prompts that work ask for search intent first, then a gap analysis of what ranks, then the outline, and finally a check that the brief says something the top results do not. A single “write me a brief for keyword X” prompt produces a generic outline that restates the keyword in every heading.
This guide gives you a five-prompt chain you can copy, explains why each part of each prompt is there, and runs it on an illustrative keyword so you can see what good output looks like and where the model usually goes wrong.
What a content brief is and what it must contain
A content brief is the one-page instruction set a writer (human or AI) works from: who the article is for, what question it answers, how it is structured and what makes it different from what already ranks. An outline is only one part of it. A brief that is just a list of H2s leaves the writer guessing about the most important decisions.
A useful brief contains these fields:
- Primary keyword and close variants, taken from your keyword tool or Search Console, not invented by the model.
- Search intent: what the searcher wants to do or know, and which content format satisfies it (tutorial, comparison, definition, tool page).
- Target reader: their role, what they already know and what they will do after reading.
- Angle: one sentence on what this piece offers that the current top results do not.
- Working title and H2/H3 outline, with a note under each heading saying what that section must accomplish.
- Questions to answer, sourced from real queries: People Also Ask boxes, support tickets, sales calls, forum threads.
- Evidence requirements: which claims need a source, where first-hand experience or an expert reviewer is needed, and what original element (example, table, template) the piece will include.
- Internal links to and from existing pages on your site.
Notice what is missing: a target word count. Google’s guidance on creating helpful, reliable content lists writing to a word count you believe Google prefers as a warning sign, and states plainly that it has no preferred length. Competitor length can tell you how much ground the topic needs to cover, but the brief should define scope by the questions answered, not by a number.
Why a single prompt produces a weak brief
A one-shot brief prompt fails because the model has to guess at three things it cannot know: what currently ranks, what readers actually ask, and what your site already covers. Without that information it falls back on the most statistically common outline for the phrase, which is roughly the outline every other AI-assisted page already has.
The typical symptoms are easy to spot:
- Every H2 contains the keyword (“What is X”, “Benefits of X”, “How to use X”, “X best practices”).
- The intent is assumed rather than checked, so a commercial query gets a definition article.
- FAQ questions are invented and overlap with the body.
- There is no stated angle, so nothing stops the writer from producing a summary of the top three results.
Splitting the work into a chain fixes this. Each step has a narrow job, you can check its output before moving on, and you inject real data exactly where the model would otherwise invent it. If your AI tool can browse, you can let it fetch the search results, but still review what it pulled: browsing tools sometimes return localized, cached or partial results.
The five-prompt chain
The chain below works in any chat model (Claude, ChatGPT, Gemini) and is designed to be run in one conversation so later steps can see earlier outputs. Replace everything in square brackets.
Prompt 1: Classify search intent before anything else
Intent comes first because every later decision depends on it: format, depth, title and whether you should write this page at all. If you need a refresher on the intent categories, see our explainer on semantic SEO and search intent.
You are helping me plan one article for my site [SITE NAME], which
covers [SITE TOPIC] for [AUDIENCE].
Keyword: [KEYWORD]
Below are the titles and URLs of the current top 10 organic results,
copied from a search I ran today in [COUNTRY/LANGUAGE]:
[PASTE TITLES + URLS]
Tasks:
1. Classify the dominant intent: informational, commercial
investigation, transactional or navigational. If results are mixed,
say so and give the split.
2. Name the content format that dominates (tutorial, listicle,
comparison, definition, tool, product page, video).
3. Describe the most likely searcher in two sentences: role, what they
already know, what they want to do next.
4. Tell me if a [FORMAT I CAN PRODUCE, e.g. blog article] is a poor fit
for this keyword, and why.
Base every answer on the pasted results. Do not write an outline yet.Why each part exists: the site context stops the model from picking an audience that does not match yours; the pasted results ground the classification in what Google is actually showing; “if results are mixed, say so” prevents a confident single label on a split SERP (search engine results page); and task 4 gives the model permission to tell you not to write the piece, which a brief prompt almost never does. “Do not write an outline yet” keeps the model from jumping ahead and anchoring on its own first draft.
Prompt 2: Map what the competitors cover
Competitor mapping turns “write something better” into a concrete list of what is table stakes and what is missing. Paste the H2 and H3 headings from the three to five most relevant results; most browsers’ reader view or a heading-outline extension makes this a one-minute task.
Here are the headings from the top [N] results for [KEYWORD].
Each block starts with the URL.
[URL 1]
[HEADINGS]
[URL 2]
[HEADINGS]
...
Build a table with three groups:
- Covered by all or nearly all pages (table stakes)
- Covered by some pages (optional, decide case by case)
- Not covered by any page but likely needed by the searcher you
described earlier (gaps)
For every gap, explain in one sentence why the searcher would need it.
Mark any gap you are unsure about as "unverified". Do not invent
headings that are not in the pasted text when filling the first
two groups.The three-group structure is the important part. Table-stakes topics must appear in your outline or the page will feel incomplete. Gaps are where your angle usually comes from. The instruction not to invent headings in the first two groups matters because models tend to “round out” a competitor’s outline with sections it does not have, which corrupts the comparison. For a deeper version of this step across a whole site rather than a single keyword, see our prompts for content gap analysis.
Prompt 3: Collect real reader questions
Real questions are the best raw material for H3s and for deciding scope. Collect them from People Also Ask, related searches, Search Console queries for nearby pages, support tickets, Reddit or Stack Exchange threads and your own inbox.
Here are questions real people have asked about this topic, with
where each came from:
[PASTE QUESTIONS + SOURCE]
1. Remove duplicates and merge questions that ask the same thing.
2. Group them by the stage of the task they belong to
(before / during / after, or beginner / experienced).
3. Mark which questions are already answered by the table-stakes
topics and which belong to the gaps.
4. List any question that would need first-hand experience, a
qualified expert or a cited source to answer responsibly.
Do not add questions that are not in my list.Point 4 is where E-E-A-T planning starts. E-E-A-T (experience, expertise, authoritativeness and trustworthiness) is the framework Google’s quality raters use, and the brief is the cheapest place to decide who must review a claim. Our guide to E-E-A-T in AI-assisted content covers what that looks like in practice. For health, finance, legal or safety topics, any question flagged here should be answered by, or checked by, someone qualified.
Prompt 4: Write the brief
Only now does the model write the brief, and it has everything it needs in the conversation: intent, competitor map and real questions. The prompt asks for a fixed set of fields so briefs are consistent across writers and easy to review.
Using the intent analysis, the competitor table and the question list
above, write a content brief with exactly these fields:
ANGLE: one sentence on what this article offers that the current top
results do not. It must reference a specific gap from the table.
READER: one sentence.
WORKING TITLE: descriptive, no hype words, no year unless the content
is genuinely time-bound.
OUTLINE: H2s and H3s. Under each heading, one line saying what that
section must accomplish for the reader. Headings must describe the
content, not repeat the keyword.
ORIGINAL ELEMENT: the example, table, template, calculation or
walkthrough that a reader cannot get elsewhere.
EVIDENCE: claims that need a primary source, and which sections need
first-hand experience or expert review.
FAQ: only questions from my list that the outline does not already
answer. Zero is an acceptable number.
INTERNAL LINKS: suggest where these existing pages fit:
[PASTE TITLES + URLS OF YOUR RELATED PAGES]
OUT OF SCOPE: topics to leave out and why.
Keep the brief under 500 words.Two fields do most of the work. “Out of scope” prevents the writer from padding the article with every loosely related subtopic. “FAQ: zero is an acceptable number” removes the pressure to invent questions, which is how most AI briefs end up with an FAQ that repeats the body. The length cap keeps the brief a brief; a 2,000-word brief is a first draft in disguise.
Prompt 5: Critique the brief against the competition
The final step asks the model to argue against its own work. A separate critique prompt finds problems the generating prompt does not, because the model is now evaluating a fixed document instead of producing one.
Act as a skeptical SEO editor reviewing the brief above.
1. If a reader had already read the top 3 results, what would they
learn from this article that is new? If the answer is "not much",
say so directly.
2. Which headings could be swapped into a competitor's article
without anyone noticing? Rewrite them to be specific.
3. Which outline sections do not serve the reader you described?
4. Is the working title accurate to the outline, or does it promise
more than the article delivers?
Return a revised brief only if changes are needed, and list what you
changed.Question 2 is the most useful single check in the chain. Generic headings are the clearest sign of a generic article, and asking whether a heading could be moved to another site without anyone noticing is a quick test for it. Question 4 lines up with Google’s title link guidance, which lists inaccurate titles among the reasons Google rewrites them in results.
Worked example: running the chain on one keyword
The example below is illustrative: the keyword is real, but the competitor observations are a plausible scenario written to show how the chain behaves, not a snapshot of a live results page. The site is a small blog for cloud engineers, and the keyword is “rotate aws access keys”.
Step 1 output (summarized). The intent is informational with a strong task component: the searcher needs to do something now. The dominant format is a step-by-step tutorial, mixed with official documentation pages. The likely reader is an engineer or admin who has been told to rotate keys (by an audit, a security alert or a leaked credential) and wants to do it without breaking a running application. A blog tutorial fits, as long as it does not try to replace the official docs.
Step 2 output (summarized). In this scenario, table stakes are creating a second key, updating the application, deactivating the old key and deleting it. Some pages cover the CLI commands; some cover the console. The gaps the model identifies: how to find every place the old key is used before deactivating it, what to do when the rotation is triggered by a leak rather than a schedule, and whether long-lived access keys should exist at all versus short-term credentials.
Step 4 output (excerpt).
ANGLE: Most guides show the four rotation steps; this one shows how to
find every consumer of the old key first, so deactivation does not
cause an outage, and how the steps change when the key has leaked.
READER: An engineer asked to rotate an IAM user's access key on a
system they did not build.
WORKING TITLE: How to Rotate AWS Access Keys Without Breaking
Running Workloads
OUTLINE:
H2 Before you rotate: find where the key is used
-> reader leaves with a list of every consumer of the key
H2 Scheduled rotation, step by step
H3 Create the second key
H3 Update each consumer and verify it uses the new key
H3 Deactivate, wait, then delete
H2 If the key leaked: what changes
-> order of operations differs; containment first
H2 Should this key exist at all?
-> when to replace it with short-term credentials
ORIGINAL ELEMENT: a checklist table of consumer types (CI pipelines,
local profiles, app config, third-party tools) with where each stores
the key.
EVIDENCE: all CLI commands and limits checked against current AWS IAM
documentation; the leak section reviewed by someone with incident
response experience.
FAQ: none - every collected question is answered in the outline.
OUT OF SCOPE: IAM policy design; root account keys (separate article).Compare that with what a one-shot prompt typically returns for the same keyword: “What are AWS access keys”, “Why rotate access keys”, “How to rotate AWS access keys”, “Best practices”, “Conclusion”. Every heading contains the keyword, none says what the reader will leave with, and nothing in it is specific to a reader with a production system to protect.
Step 5 output (summarized). The critique flags “Deactivate, wait, then delete” as underspecified (wait how long, and watching what?) and suggests the section explain what signal confirms the old key is no longer used. That one change moves the article from generic to useful, and it is exactly the kind of detail a writer with real operating experience should fill in.
Common mistakes and how to fix them
| Mistake | What it causes | Fix |
|---|---|---|
| Letting the model guess what ranks | Outline based on stale or imagined results | Paste titles and headings from a search you ran today, or review what a browsing tool fetched |
| Asking for intent and outline in one prompt | Intent is rationalized to fit the outline | Run intent as its own step and confirm it before continuing |
| Setting a word count target | Padding, repeated points | Define scope with questions answered and an out-of-scope list |
| Model-invented FAQs | Questions nobody asks, overlap with the body | Supply real questions; allow zero FAQs |
| No stated angle | A summary of the top results | Require the angle to reference a specific gap |
| Trusting model facts in the brief | Errors carried into the article | Mark claims that need a primary source in the EVIDENCE field |
| Treating the brief as finished | Generic headings survive | Run the critique prompt and the “could this heading go on another site” test |
The fact-checking row deserves emphasis. Google’s page on using generative AI content notes that models can produce inaccurate output and that AI-assisted content, including titles and meta descriptions, should be reviewed before publishing. A brief is upstream of all of that, so a wrong assumption in the brief spreads into every section.
Turning the chain into a reusable template
Once you have run the chain a few times, the fixed parts can live in a saved instruction so you only paste the variable data. In Claude Projects, ChatGPT custom GPTs or Gemini Gems, put the site context, the brief field list and the rules (no keyword in every heading, FAQ can be empty, flag unverified claims) in the standing instructions. Each new brief then needs only the keyword, the pasted results, the competitor headings and the question list.
Keep a few things manual on purpose:
- Choosing the keyword. Whether a topic belongs on your site is a strategy decision. Our post on topical authority and content clusters covers how to decide which pages a site should have.
- Approving the angle. The model can suggest gaps; only you know which ones you can fill with real experience.
- Reviewing the out-of-scope list. It often reveals the next article in the cluster.
The same chain works for existing pages. Replace step 1’s “which format fits” with “what does the current page miss compared with these results”, paste your current headings next to the competitors’ in step 2, and the output becomes a refresh brief. Our prompts for refreshing old blog posts go further down that path.
A quick checklist before you hand the brief to a writer
- The intent was classified from real results, and the format matches it.
- The angle names a specific gap, not “more comprehensive”.
- No more than one or two headings contain the exact keyword.
- Every section has a one-line purpose.
- There is one original element the writer must produce.
- Claims that need sources and sections that need experience are flagged.
- The FAQ, if any, uses only real questions not answered elsewhere.
- The title is accurate to the outline and has no hype words.
- Internal links point to genuinely related pages.
- The out-of-scope list is explicit.
If a brief passes these ten checks, the writer, human or model, has what they need to produce something more useful than the pages already ranking. If it fails on the angle, no amount of polish later will fix it.
