What this workflow does
A content brief explains why a page should exist before it describes what to write. It identifies the reader, the task, the evidence and the site’s contribution. The outline comes later.
This order matters because a search-results summary can easily become a rewrite of what already ranks. Google’s people-first guidance asks whether content provides original information or analysis, demonstrates real knowledge and leaves readers able to achieve their goal. The brief should force those questions while changes are still cheap.
When to use it
Use the workflow after topic selection and before drafting. It also works when an existing page has become unfocused, overlaps another URL or needs a substantial update.
Do not assume every keyword cluster needs a new article. First decide whether the right action is to create, update, consolidate or decline the page.
Start with a page decision
Review the current site and record one decision:
| Decision | Use when |
|---|---|
| Create | The audience task is relevant, distinct and not served by an existing page |
| Update | The right page exists but its evidence, clarity or usefulness is incomplete |
| Consolidate | Several pages compete for the same task and one stronger destination can preserve their useful material |
| Decline | The topic is outside the site’s purpose, cannot be supported or would add little value |
Include the URLs reviewed and the reason for the decision. A brief without this check often creates duplication before the writer begins.
Define the reader and task
Use a specific audience statement:
This page is for [reader in a defined situation] who needs to [complete a task or make a decision]. After reading, they should be able to [observable outcome].
Avoid audience labels that are too broad to change the page, such as “everyone interested in SEO.” Record what the reader likely knows, what decision they face, the constraints that shape the answer and what would make the advice unsafe or incomplete.
Search intent is evidence about that task. It is not a substitute for audience research. Compare query language, related questions, current result types, first-party search data and support or sales questions where those sources are available.
Define the original contribution
Write one sentence that explains what this page will add. It may be:
- original research or a documented test;
- direct product or process experience;
- a primary explanation from the responsible organization;
- a clearer decision framework built from cited evidence;
- an expert review that identifies tradeoffs and limitations;
- a current reference that corrects outdated information.
“More comprehensive” is not a contribution unless the brief states what is missing and how the new page can supply it. Do not invent experience or expertise that the author does not have.
If the team cannot identify a contribution, return to the page decision. Updating a useful existing page may be better than publishing another summary.
Build the evidence plan
List every claim that requires support before drafting. Assign a source type and owner.
| Claim type | Preferred evidence |
|---|---|
| Product or policy fact | Current primary documentation from the responsible organization |
| Performance claim | Reproducible first-party test with method, sample and limitations |
| Industry or scientific claim | Relevant original research or authoritative source |
| Practical recommendation | Named experience, documented test or cited guidance |
| Time-sensitive fact | Dated source and a review trigger |
| Quote | Original transcript or publication with exact attribution |
The brief should distinguish known facts, working hypotheses and open questions. Writers should not fill empty evidence cells with plausible wording.
Add authorship and review requirements. Identify who can write from experience, who must fact-check technical claims and whether legal, medical, financial or product review is needed.
Review search evidence without copying it
Sample results for the main task and meaningful variants. Note the dominant page types, questions answered, gaps, source patterns and freshness needs. Record the market, language, device assumption and date.
Do not copy competitor headings into the outline or calculate an average word count. Use results to understand the current interpretation of the task. The page still needs its own structure and evidence.
Check whether the query has mixed intent. If one page cannot satisfy the main tasks cleanly, return the cluster for review rather than forcing all variants into one brief.
Write the page purpose
The purpose statement should contain:
- the reader and situation;
- the task or decision;
- the intended outcome;
- the page’s contribution;
- the boundary of what the page will not cover.
A useful purpose statement is testable. An editor should be able to remove a section that does not help the stated task.
Draft the title and main heading
Provide two or three title directions, not a pile of keyword variations. Titles should be distinct, concise and accurate. The visible main heading should make the page topic obvious and should not compete with several equally prominent headings.
Google may generate a title link from the <title>, visible heading and other signals. The brief should keep those signals consistent, while recognizing that the displayed title is not fixed.
Avoid:
- vague titles that hide the actual task;
- repeated terms or keyword lists;
- boilerplate that makes several pages hard to distinguish;
- claims such as “ultimate” or “best” that the page cannot support;
- dates that the editorial team will not maintain.
Plan the summary and meta description
Write a short page summary that states what the reader will find and what makes the page useful. It can inform the meta description, introduction and social copy, but each can be edited for its context.
Google primarily creates snippets from page content and may use the meta description when it describes the page better. Do not treat the meta description as guaranteed search-result copy. Make it unique to the page and accurate rather than chasing a rigid character count.
Build the outline
Order sections according to the reader’s decision process. Put prerequisites, definitions or safety information before steps that depend on them. Use descriptive headings that work as a scan of the page.
For each section, include:
| Brief field | What the writer needs |
|---|---|
| Reader question | The question or decision this section resolves |
| Required answer | The information that must be present |
| Evidence | Source, data, example or experience to use |
| Format | Prose, steps, comparison table, image, code or other useful form |
| Boundary | Claims to avoid or topics handled elsewhere |
| Link | Relevant internal or external source with a reason |
Do not add a heading solely because a keyword tool lists a phrase. Merge questions that share one answer and remove sections that do not advance the task.
Plan internal and external links
Choose internal links that help the reader prepare, verify or continue. Record the source or destination, suggested context and reader reason. Use descriptive anchor direction, but let the final sentence determine the exact wording.
Link to external sources when they let readers verify a claim or access primary documentation. Google’s link guidance says contextual external citations can help establish trust. Do not add nofollow to every external editorial source by default; reserve link qualifications for the cases Google documents, such as paid or untrusted links.
Add production requirements
Specify requirements that affect quality before the draft reaches design or development:
- author and reviewer with relevant experience;
- fact-check owner and source access;
- original images, diagrams or examples the page needs;
- descriptive alternative text for informative images;
- mobile treatment for tables, code and media;
- visible publication or update information when it helps readers assess freshness;
- structured data only when it matches visible content and an eligible page type;
- a review trigger for facts likely to change.
Do not change an update date unless the content changed meaningfully.
Acceptance criteria
A finished draft should pass these checks:
- The page serves the audience and task named in the brief.
- The introduction states the outcome without delaying the answer.
- The page contains the promised original contribution.
- Material claims have named, accessible evidence.
- Titles and headings are descriptive, distinct and natural.
- Keyword variants are used only where they help readers.
- Internal links support real next steps and use crawlable anchors.
- External citations give enough context to understand the destination.
- The page avoids copied structures, invented facts and thin scaled content.
- The meta description accurately summarizes the page.
- The author, reviewer and next review trigger are recorded where needed.
Brief template
Copy these fields into the editorial ticket:
Page decision: Create / Update / Consolidate / Decline
Working URL:
Primary reader:
Situation and task:
Desired reader outcome:
Original contribution:
Scope and exclusions:
Search evidence and date:
Existing pages reviewed:
Primary evidence:
Claims still needing support:
Author and reviewer:
Title directions:
Main heading:
Page summary:
Section plan:
Internal links and reader reasons:
External sources:
Media and accessibility needs:
Structured data eligibility:
Acceptance criteria:
Review trigger:
Open questions:
