How to Write an SEO Content Brief With AI
The writer delivered 1,800 clean, well-argued words about the wrong thing — because nobody told them who was searching, what question the page had to answer, or which claims needed a source. Every decision you leave out, the writer makes at 4pm, alone.
Build a Content Brief Assistant1,800 clean words about the wrong thing
The draft comes back and it's good. The sentences work, the structure holds, the writer clearly cared. It is also aimed at the wrong reader, answers a question nobody typed, opens with four hundred words defining a term the audience uses daily, and asserts a number with no source under it. Nothing here is a writing failure. The writer received a topic and a word count and, being competent, filled the gap between those two things with their own judgment — because judgment is what you use when nobody has told you who's searching, what they're trying to get done, what the page must answer, or which claims need evidence. Those decisions got made. They just got made at 4pm by someone with less context than you, and now you're rewriting a good article.
A brief is where those decisions get made on purpose, before anyone writes a sentence. Not headings — the artifact that tells a writer *why this page exists*, who it's for, what query it's aimed at, what the reader is trying to accomplish, which questions it has to answer, what's deliberately out of scope, which claims need a source, and what a draft has to satisfy before you'd publish it. AI is genuinely good at turning your scattered notes into that document and at pushing on the parts you left vague. What it cannot do is know any of it. NewPrompt builds a prompt in your browser and that's the whole of its involvement: it doesn't search the web, doesn't read Google's results or scrape a SERP, doesn't connect to Search Console or any analytics account, doesn't measure search volume or keyword difficulty, doesn't look at a competitor's page, doesn't track a ranking, and doesn't write the article or publish anything to a CMS. Every fact in the brief is one you supplied. A brief is a set of instructions, not a forecast — it can't promise a position, traffic, or that anyone will read the page. You bring the query and the research; the SEO owner or content strategist confirms the target, the angle and the evidence; the writer researches and drafts against it; and whoever publishes owns the accuracy, the originality and the legal and brand review of what goes out.
Every question you leave open, the writer closes
That's the mechanism worth internalising, because it explains why briefs fail in the specific ways they do. A writer cannot start without an audience, an angle, a scope and a bar for done. If the brief supplies them, they're your decisions. If it doesn't, they're still made — silently, by someone optimising for a finished draft rather than for the query — and you find out in review, when the disagreement is about eighteen hundred words instead of one line.
So the useful test for anything you're about to leave out of a brief is: *what will the writer assume instead?* Leave out the reader's expertise and they'll pitch at a beginner, because that's the safe default and it's why so much content opens by defining its own title. Leave out scope and they'll go broad, because breadth feels like value. Leave out the evidence rule and they'll write "studies show" — not dishonestly, but because it's the register of the genre. Leave out what done means and they'll optimise for finished. None of those are the writer being careless; each is a rational guess in the absence of an instruction.
Which also draws the line at the far end. A brief stops at the point where the writing starts. It fixes what the piece is for and what it has to satisfy; it doesn't produce sentences, and an outline — headings and order — is one field inside it rather than the thing itself. If your brief contains prose you'd publish, it stopped being a brief and became a bad first draft.
Step 1: Fix the query, the reader, and why you're publishing at all
Three things, and they're separate. The target query is the phrase someone types — you bring it, from whatever research you already did, because nothing here discovers it. The reader is who's typing it, described by what they already know and what situation they're in, not by a persona name: "an office manager at a 40-person company who has just been told to standardise laptop spend and has never done it before" produces a different article than "SMB decision-makers." And the business goal is why the page is worth writing, which is not the same thing as the search intent and must never be allowed to replace it.
That last distinction is the one that quietly wrecks pages. Search intent is what the reader wants; the business goal is what you want. A page that answers the query earns the right to make an offer at the end. A page that leads with the offer because that was the goal answers nothing, and no amount of keyword placement rescues it. Write both down, keep them in separate fields, and let the brief carry the tension honestly rather than resolving it in the writer's head.
Then the reader's task state, which is the field most briefs skip and the one that does the most work: what are they trying to *do*, and what happens right after they read? Someone building an equipment checklist for the first time needs a defensible starting list and permission to not overthink it. Someone rebuilding one after an audit needs the edge cases. Same query, two different pages, and the difference doesn't show up anywhere except here.
Step 2: Turn your notes into observations that carry a date
Whatever you learned by actually looking at the results — the titles that came back, what the top pages seem to be doing, the format the results share, what the People Also Ask box surfaced — goes into the brief as an *observation*, attributed and dated. "Checked 12 June: the first page is eight listicles and one vendor product page; six of the eight open with a definition; none of them mentions the tax treatment" is evidence a writer can use. "Competitors don't cover tax" is a claim, and it's the kind that turns out to be wrong in a way that makes your differentiation section a lie.
The date matters more than it looks. Results move, and a brief that sits for three weeks before anyone writes against it will otherwise present a stale snapshot as current fact. Stamping the observation keeps the writer's trust calibrated — they can see how fresh the ground is and re-check if it's gone cold. Both of the brief resources here are explicit that nothing pulls live SERP data or confirms a ranking — the model reasons only over the titles and notes you paste in. They split on intent, and the split is worth knowing: the template takes your classification as an input you supply, while the assistant proposes one as its first section and tells you to verify the label before trusting anything below it, because the angle and the whole structure hang off it. Either way the call lands with you. That's not a caveat to bury. It's the reason the observations need provenance.
So keep four things in different buckets and make the model keep them there: a fact you supplied about your product, an observation you made about the results, something the writer needs to go and find out, and an idea nobody has evidence for. A model handed all four in one paragraph will smooth them into equally confident prose, and the statistic with no source will read exactly like the one from your own dashboard. Ask for them labelled, and treat any number that appears without a label as invented until proven otherwise — because it usually is.
Step 3: Name the questions the page has to answer
From the reader and the intent, derive the actual questions — the ones this specific person needs settled before they can do the thing they came to do. Not topics. Questions, phrased the way the reader would ask them: *what actually goes on the list?* *who pays if someone breaks it?* *what do I do when they leave?* A topic list produces sections; a question list produces answers, and it's the difference between a page that covers a subject and a page that finishes a reader's job.
This is also the field that makes the brief checkable later. "Covers equipment policy" can't be verified; "answers what happens to the laptop when someone resigns" either happened or it didn't, and you can point at the paragraph. When a draft comes back and something feels thin, the must-answer list is what turns your unease into a specific note.
The model is useful here in a way that isn't obvious: ask it to generate the questions a reader in that situation would have, then cut hard. It'll produce fifteen. Four are what your reader actually needs, six belong to a different reader entirely, and five are the ones every generic article already answers badly. Keeping all fifteen is how a brief becomes an outline for a 4,000-word page nobody finishes — the cutting is yours, and it's the part that decides whether the page is any good.
Step 4: Commit to one angle, and say what's out of scope
The angle is a decision that arrives at the brief already made — the brief records it and hands it over; it isn't the place to explore options. One line on what this page is doing that the results you looked at aren't, grounded in your observation rather than in a claim about competitors you haven't read. "The results are all generic lists; ours is organised by the moments equipment changes hands — onboarding, role change, offboarding — because that's when things actually go missing" is an angle a writer can execute against. "More comprehensive" is not an angle; it's a word count.
Then scope, and specifically the out-of-scope line — one line long, and the one people leave out. A writer given no boundary will expand, because covering more feels like doing more. Naming what the page deliberately doesn't do — "no procurement negotiation, no device-management software comparison, no tax advice" — costs you one line and saves a whole rewrite. It also protects the reader: a page that stays inside its scope finishes their job faster than one that keeps almost finishing several.
The SEO Content Brief Assistant is a system prompt for this shape — it produces search intent, a recommended angle, the audience, a suggested H1, an H2 structure mapped to the reader's questions, and must-cover and avoid lists. The System Prompt Generator is the tool that builds it, and it's worth knowing what loads with it: the assistant's rules arrive already set, including the one that matters most here — do not draft the article content, produce the brief only, and no generic headings like Introduction or Conclusion. It emits a prompt you run in your own AI tool. For a per-piece version, the SEO Brief Template is a fill-in template with the fields as variables — keyword, intent, audience, goal, competitor notes, required sections, internal links — built with the Prompt Template Builder, which is the right shape when you're briefing the same way repeatedly and only the target changes.
Step 5: Set the evidence rules before anyone needs them
Three lists, and they're cheap to write and expensive to omit. What the writer can state as fact because you're supplying it — your product's real behaviour, your pricing, the thing your support team actually sees. What needs a citation, named specifically: any statistic, any legal or tax claim, any assertion about what a competitor does. And what is not to be written at all — the unsupported claims that show up in this genre by default, the comparative superlatives, the invented percentage that makes a paragraph feel authoritative.
That third list is the one that earns its place, because the failure it prevents is invisible in review. Nobody reads a draft and thinks "where did 73% come from?" — it reads like research. It gets published, and it's wrong, and it's wrong under your name. Writing "no statistic without a linked primary source; if you can't find one, say the pattern qualitatively or cut it" gives the writer permission to not have a number, which is the actual problem: the number exists because the sentence felt weak without one.
Add the constraints that live elsewhere by pointing at them rather than restating them. Voice and tone rules belong to whatever governs your voice; legal review belongs to legal. The brief's job is to name that they apply and where they live, in a line each. A brief that reproduces the style guide has grown into a document nobody reads to the end, and the fields that would have saved the draft are on page three.
Step 6: Say what done looks like, then hand it over
Close with the things that make the brief usable by someone who isn't you. A suggested structure — headings with a line each on what that section is *for*, since a heading without its intent gets filled with whatever fits. The internal links you want and why they belong. The one action a reader should be able to take at the end, matched to their intent rather than to your funnel: someone mid-task wants the template, not a demo booking. The format and length you expect, with the length framed as a consequence of the questions rather than a target to hit.
Then the criteria a draft has to satisfy, written so they can be checked rather than felt. "Answers all four must-answer questions" is checkable. "Every statistic carries a linked source" is checkable. "Doesn't define the term in the first section" is checkable. "Reads well" can't be met or missed, so it constrains nothing — the writer reads it and still doesn't know when to stop. This is the field that converts a review from an argument about taste into a list, and it's why the brief is worth more to the writer than to you — it's the first time they've been able to know whether they're finished.
Finally, separate what you know from what's open. Anything you couldn't settle goes in an open-questions list with a name attached, not smoothed into a confident instruction. If you're unsure whether the page should cover the international case, say so and say who decides — because a brief that quietly asserts a decision nobody made is worse than one that admits the gap. Then hand it over, and understand what you've handed over: a document that tells a writer what to research and produce. The research is theirs, the draft is theirs, and the version that gets published is reviewed by people, for accuracy and for law, before it's anyone's opinion about search.
Common mistakes
Most bad briefs aren't wrong. They're silent in the places that decide the article:
- A topic where the query should be. "Write about equipment checklists" leaves the writer to guess what someone typed, so they aim at the topic's centre — and nobody searches for a topic's centre.
- Business goal wearing the search intent's clothes. If the brief's reason to exist is the offer, the page answers nothing and the offer has nothing to sit on. Two fields, kept apart.
- Letting the model supply the numbers. It has no access to volume, difficulty, rankings or anyone's traffic — a figure it produces is a plausible shape, not data. If you didn't paste it, it isn't evidence.
- SERP notes without a date. Results move. An undated observation presented to a writer three weeks later is a stale snapshot with the authority of a fact.
- Keeping all fifteen questions the model offered. Every one looks reasonable, which is the problem — a brief with fifteen must-answers is a brief for a page nobody finishes, and the cutting is the judgment nobody can do for you.
- No out-of-scope line. Absent a boundary, breadth feels like quality, and the page ends up almost finishing four jobs instead of finishing one.
- Smoothing an open question into a confident instruction. A brief that quietly asserts a decision nobody made is worse than one that admits the gap — the writer executes it, and nobody ever revisits it.
- Briefing all the way into prose. Once you're writing the sentences you'd publish, you're drafting badly and slowly. The brief stops where the writing starts — and NewPrompt doesn't write the article or publish it either.
Briefing a page on employee equipment checklists
A thin request, and the brief that would have prevented the rewrite. Every input below is a fictional sample — the SERP notes are made up for the example, not real or current data.
A thin request turned into a brief: the reader's task state, dated sample observations kept separate from claims, four must-answer questions cut from fifteen, an angle grounded in what was actually read, evidence rules that permit the writer to have no number, and criteria a draft can be checked againstTHE ASK THAT PRODUCES A REWRITE
"write a blog post about employee equipment checklists, ~1500 words"
FIXED FIRST (you supply all of this -- nothing here discovers it)
target query "employee equipment checklist"
reader an office manager at a ~40-person company, told last
week to standardise laptop spend. has never built one.
not an IT specialist.
task state needs a defensible starting list today, and permission
not to overthink it. next step: send it to a manager.
business goal we sell asset-tracking software. the page earns the
right to mention it at the end. it is NOT the reason
the page exists.
SERP OBSERVATIONS (SAMPLE DATA -- fictional, for this example.
a real brief would carry your own notes + date.)
"checked 12 June, page one"
- 8 of 10 results are listicles; 1 vendor product page; 1 forum thread
- 6 of the 8 open by defining "equipment checklist"
- none of the ones I read organise by WHEN equipment changes hands
- People Also Ask surfaced: "who pays if an employee breaks a laptop"
^ these are observations, not claims. I read the titles and four of
the pages. I have not read the other four.
SEARCH INTENT
informational, task-shaped: they want a list they can use today, not
an explanation of what a checklist is.
(note: this is what the READER wants. the asset-tracking pitch is
what WE want. they are not the same field and the page loses if the
second one leads.)
MUST ANSWER (cut from 15 the model produced, down to 4)
1. what actually goes on the list, for a company this size?
2. who pays if something is broken or lost?
3. what happens to the equipment when someone leaves?
4. how do I keep it current without it becoming a job?
^ the eleven cut: too advanced, wrong reader, or already answered
badly by everyone on page one.
ANGLE (already decided. recorded here, not explored here.)
organise the checklist by the moments equipment changes hands --
onboarding, role change, offboarding -- because that is when things
actually go missing.
grounded in: observation above (none of the four I read do this).
NOT "more comprehensive."
OUT OF SCOPE (say it, or the writer expands)
- procurement negotiation and vendor pricing
- device-management software comparison
- tax treatment of equipment <- see open question
- anything for companies over ~200 people
EVIDENCE RULES
facts we supply our support team's three most common tickets;
our pricing; what our product actually does
needs a source any statistic; anything about liability or tax;
any claim about what a named competitor does
do not write invented percentages. "studies show." "most
companies." superlatives about our product.
if a number can't be sourced, describe the
pattern qualitatively or cut the sentence.
STRUCTURE (headings + what each is FOR -- not prose)
H1 intent-matched, contains the query, promises the list
H2 the checklist itself, by handover moment -> answers Q1
covers onboarding AND role change. the payload, so it goes
FIRST -- and it does not open by defining the term, because
6 of 8 results already do and our reader knows what one is.
H2 who pays when something breaks -> Q2
H2 offboarding: the moment it actually goes missing -> Q3
(the third handover moment earns its own section rather than a
row: recovery is where the reader is about to fail)
H2 keeping it current without it becoming a job -> Q4
H2 a short honest note on when a spreadsheet stops being enough
-> where the product belongs, at the end, having earned it
INTERNAL LINKS (fictional site paths, for this example)
/blog/onboarding-checklist from the checklist H2 (onboarding rows)
/blog/offboarding-process from the offboarding H2
CTA
download the checklist as a template. NOT "book a demo" -- they are
mid-task and they came for a list.
ACCEPTANCE CRITERIA (checkable, not felt)
[ ] all four must-answer questions are answered explicitly
[ ] the checklist appears before any definition of the term
[ ] every statistic has a linked primary source, or is cut
[ ] nothing from the out-of-scope list appears
[ ] the product is mentioned once, in the final section
WRITER RESEARCH
- find a primary source on employer liability for damaged equipment,
or write the section without a number
- confirm our three most common support tickets with support
OPEN QUESTION -- not the writer's to settle
should the page cover the international case (equipment shipped to
remote hires abroad)? it is a real reader question and a different
article's worth of tax and customs. currently out of scope.
decides: whoever owns the content plan. before the writer starts.
WHAT THIS IS NOT
there is not a single publishable sentence above. that is the point.
the brief says what the page must be; the writer researches and
writes it; a person reviews what gets published.Where this fits in NewPrompt
A brief is one step of a bigger editorial motion, and the AI Content Strategy Workflow is that motion: set the goals and audience, map audience needs to topics, brief the priority pieces, then turn it into a content plan. This guide is the brief slice — the third step, for when the topic is already chosen and what's missing is the direction. In the workflow's own words, briefs are how a strategy survives contact with production. It supplies the prompts, links and order; you run them. Everything on either side of that step — deciding which topics are worth it, building the calendar — is strategy, and it isn't this.
The two pieces here do the same job at different cadences. The SEO Content Brief Assistant is a system prompt — a standing assistant you keep — built with the System Prompt Generator, which loads its rules along with it, including the one that keeps this artifact honest: produce the brief, not the draft. The SEO Brief Template is the per-piece version — a fill-in template with the fields as variables — built with the Prompt Template Builder. Reach for the first when you brief often and want the reasoning to be consistent; reach for the second when the shape is settled and only the target changes. Both are honest in their own copy that neither pulls live SERP data nor confirms a ranking. Where they differ is intent: the template asks you to classify it before you fill anything in; the assistant proposes a label and tells you to check it first. That input-versus-output split is the real reason to reach for one over the other.
Downstream, the boundary is a real one and it's worth respecting in both directions. An outline is headings and order, and expanding one into prose is its own craft with its own failure modes. A brief is what sits above the outline: it decides what the piece is for, and the outline is one field inside it. If you find yourself writing the transitions, you've walked past the handoff — the writer's job started and you're doing it worse, because you're not the one who's going to be judged on the sentences.
The reason to write the brief is that it's the only document in the process that can still be cheap. A wrong angle costs a line to change here and a rewrite to change after the draft exists; a missing evidence rule costs one sentence now and a correction notice later. But the part worth being clear-eyed about is what the model contributed: it shaped your notes, it pushed the vague fields, it generated fifteen questions so you could find the four. It did not know your reader, it did not look at the results, and it could not have told you that the office manager needs permission to not overthink this. That sentence is why the page works, and it came from you.