Quick answer: Brief the decision the reader needs to make, the evidence the writer must gather and the useful action the article should enable. Keywords help describe demand; they do not replace the assignment. “Write 2,000 words about websites” is a length request wearing a strategy hat.
Jump to: Practical table · Checklist / record
For: owners commissioning articles from a writer, agency or AI-assisted process. This is a practical editorial template, not a ranking formula. The sample is hypothetical.
Check before moving on: If an existing page already serves the same intent, brief an update instead of a duplicate.
- Define one reader and one unresolved decision
- The brief’s essential fields
- Use research to define intent, not copy competitors
- Assign the question to a page before drafting
- Give claims an evidence contract
- A worked brief: should a service site use a CMS?
- Build an outline around decisions
- Review the draft with a practical acceptance test
- Close the brief with maintenance responsibility
- Useful detail: Give a writer a claim to verify, not a word-count target
- Source and review date
Define one reader and one unresolved decision
Replace “small businesses” with a specific situation. For example: “An owner of a five-person service company has a working website but cannot update staff profiles without contacting the developer.” The useful decision is whether to improve the editing process, add structured content or change platforms.
State what the reader already knows and what would change their choice. Do they need a definition, a comparison, an implementation checklist or a troubleshooting path? If you cannot state the useful outcome, stop before generating an outline.
Keep commercial intent honest. A tutorial should help complete a task even if the reader does not buy a product. A comparison should include cases where the cheaper or existing option is adequate. Trust is difficult to build when every road mysteriously ends at the same checkout.
The brief’s essential fields
On a small screen, swipe the table sideways to see all columns.
| Field | What the writer needs | Acceptance question |
|---|---|---|
| Reader situation | Business type, constraint and existing setup | Can the opening recognise a real situation? |
| Primary question | One decision or task | Does the article answer it directly? |
| Scope boundaries | What is included and deliberately excluded | Does it avoid competing with an existing page? |
| Evidence | Official sources, authorised observations and dated checks | Can material claims be traced? |
| Distinct value | Worked example, decision table, template or original test | What can the reader do after reading? |
| Outline | Sections ordered by the reader’s task | Does each section earn its place? |
| Next step | Relevant action and internal destination | Is the action useful without a purchase? |
| Review owner | Who checks facts and who maintains them | Can the article stay accurate? |
Use research to define intent, not copy competitors
Review the actual search results for the intended audience and language when planning a search-led page. Note whether the results are tutorials, product pages, local providers or comparison guides. This is a clue to user expectations, not a command to reproduce the same headings.
Compare the proposed topic with your own inventory. If a current page already answers the same question for the same reader, an update may be more useful than a new URL. Distinct pages need distinct jobs; swapping “small business” for “small team” is not much of a content strategy.
Collect recurring customer questions from authorised sources and label them as observations. Do not invent search volume, customer interviews or competitor performance. If you have no demand data, call the topic a hypothesis and explain why it is relevant to the audience.
Assign the question to a page before drafting
Put the proposed question beside the live URL that currently answers it. Read that page’s opening, main headings and next action. If the reader, task and answer are the same, brief a targeted update and list the missing evidence or example. If the task differs, write one sentence explaining the boundary between the two URLs. “One is for owners deciding whether to buy; the other is for staff performing the setup” is a usable boundary. A small change in wording is not.
Brief gate: Existing URL reviewed: [URL]. Its current job: [decision]. Proposed job: [decision]. Overlap: [same / distinct / uncertain]. Action: [update / new page / park]. Evidence needed: [source or authorised observation]. Link between pages: [reader’s next question and destination]. This gives the writer a page assignment rather than a pile of phrase variants. The keyword cluster map provides the fuller assignment worksheet.
If the proposed page is distinct, put its scope boundary in the opening and its brief. If overlap remains uncertain, park the commission until someone reads the live pages and checks the searcher’s task. Do not ask a writer to solve that ambiguity by producing two drafts.
Give claims an evidence contract
For each important assertion, specify the source and the type of support needed. A product limit needs current official documentation. A personal test needs a real setup, date, steps and observed result. An economic example needs assumptions and a calculation. An opinion should be presented as a recommendation with its trade-off.
Tell the writer what cannot be claimed. Useful examples include: no invented hands-on experience, no price from an undated screenshot, no guaranteed ranking improvement and no customer result without permission and context. An AI-generated draft does not become evidence because it sounds comfortable with the subject.
Google’s people-first content guidance emphasises usefulness and reliability for readers. Use that as a quality principle; the detailed brief and scoring method here are our editorial choices, not Google’s prescribed template or a guarantee of search visibility.
A worked brief: should a service site use a CMS?
Primary question: does the team need structured editing for repeatable content, or would a simpler update process solve the problem? Reader: an owner with staff biographies and several service pages, currently dependent on a developer for routine updates.
Scope: compare editing workload, repeatable fields, ownership and acceptance tests. Exclude a full platform migration tutorial and pricing promises. Distinct value: a table of content types, who edits them, how often they change and whether consistent fields are needed.
Proposed outline: short answer; cases where simple pages remain enough; signs structured content helps; an illustrative content inventory; a controlled editing trial; operating cost and ownership; next step. Evidence: current platform documentation for specific capabilities, and clearly labelled examples for the workflow.
On this site, that question already has a CMS versus static pages guide. The brief would therefore support improving that page rather than creating a competing version. Checking your inventory is part of the work, not an obstacle to publishing.
Build an outline around decisions
Start with the answer and its conditions. Put the most important choice before background definitions. Follow with evidence, a worked application and the limitations that could change the recommendation. End with a specific next action.
Specify the purpose of every table or diagram. A comparison table should use criteria that change the decision. A process diagram should clarify order or responsibility. Decorative boxes repeating the same sentence in three colours do not make the article three times more useful.
Do not set a word count as the primary acceptance gate. A complex subject may need depth; a narrow answer may not. Require enough detail to perform the task and remove repetition that does not help. A short summary can sit above a detailed procedure so readers choose their depth.
Review the draft with a practical acceptance test
- Read only the opening: can you identify the reader, answer and main condition?
- Follow the procedure as a reader: is an essential decision or input missing?
- Check each factual claim against its cited source and review date.
- Recalculate example numbers and distinguish assumptions from results.
- Navigation: verify headings and any copyable template. Follow each internal link and check that its label describes the destination.
- Inspect mobile reading, tables and meaningful image descriptions.
- Confirm the article’s job differs from existing content.
Return a draft when its central recommendation has no evidence, its example cannot be followed or it claims a test that never happened. Small grammar edits cannot repair an unsupported conclusion.
Plan the route into the article too. Record which existing page should link to the new guide and why its reader would need it. Use the internal linking checklist to review both directions before publication.
Close the brief with maintenance responsibility
Approved question and audience:
Existing page to update or proposed new page:
Required sources and review date:
Original example or tool to include:
Claims to avoid:
Primary next action:
Fact reviewer and publication owner:
Triggers for review: product changes, broken links, reader questions or contradictory evidence.
Connect topic research to our keyword workflow, then use the brief to keep the writing focused on useful decisions.
Useful detail: Give a writer a claim to verify, not a word-count target
Google’s generative-AI guidance warns against producing many pages without adding user value and emphasizes accuracy, quality and relevance.
For a small-service content brief, add one evidence task that the writer must complete. A concrete new check is more reviewable than a request to make the article longer.
Try this:
- Name one reader decision the existing page cannot settle.
- Require a current source and a worked, clearly hypothetical example where needed.
- Reject an added section if it repeats existing advice without changing the reader’s next action.
Source: Google Search Central: generative AI content guidance. Checked October 3, 2026. The practical check is a PSL suggestion.
Source and review date
Google Search Central: helpful, reliable, people-first content, checked September 29, 2026. All templates and the hypothetical brief are Practical SaaS Lab editorial recommendations.
Related practical guides: Content Refresh Checklist: Update, Merge or Leave the Article Alone?. Service Landing Page Brief: What to Write Before You Start Designing.
