Specify the deliverable before the outline
Name the reader, their prerequisites and the action they should complete after reading. Write one sentence defining what the article will not cover. This boundary keeps a brief from expanding into several loosely connected topics. Record the publication location and language so examples and terminology fit the intended audience.
Identify the closest existing article and explain the proposed contribution. If the contribution cannot be stated clearly, resolve the page decision before commissioning a draft. The brief should guide work already judged useful, not manufacture a reason to publish around a keyword.
Connect important claims to usable evidence
Create a claim register containing the proposed statement, source URL, relevant section, date checked and limitations. Open each source and verify that it supports the actual claim rather than simply discussing the same subject. Prefer authoritative documentation for product behavior, and note versions or regional scope where relevant.
Label observations, recommendations and hypothetical examples separately. A writer should be able to tell which statements are established facts and which need further investigation. Do not paste private customer records into the brief. Use authorized, anonymized evidence where necessary and keep any unsupported result out of the proposed narrative.
Turn evidence gaps into explicit assignments
For each unresolved claim, assign an owner and the specific check required. Examples include verifying a menu path, confirming a file format or obtaining permission to describe a case. Specify whether the draft can proceed without that claim or must wait. An empty citation field is not an instruction to invent a plausible answer.
Organize the outline around the reader’s decisions, not around a list of search phrases. Google’s guidance asks for helpful, reliable material with original value. Explain the original contribution the writer should produce, such as a decision worksheet or a carefully bounded example, and make clear that source paraphrasing alone does not complete the assignment.
Illustrative brief: a handover checklist
Imagine the assignment is a checklist for a website owner preparing a technical handover. The brief names the reader’s access level, excludes password sharing and asks for a record of system owners, documentation locations and outstanding issues. This is a fictional editorial assignment rather than a claim about a completed customer project.
The evidence register supports any product-specific statement separately. The example uses invented non-sensitive system names and is labelled illustrative. Acceptance requires a usable checklist, an explanation of unresolved access questions and no claim that collecting documents alone makes the handover complete. The writer knows what to deliver and what not to promise.
Review the brief as a contract for the draft
Have a reviewer check that each required section advances the task and that every consequential factual claim has evidence or a visible investigation step. Add acceptance checks for source accuracy, example labels, language quality and links. Agree who can approve unresolved changes in scope before the writer starts.
Save the brief version used for drafting and record later amendments. An SEO audit can supply page inventory or technical context, but it cannot automatically validate the claims in a brief. When reviewing the finished article, use the same reader task and evidence register. A completed outline or citation list is preparation, not proof of a trustworthy article.