Page purpose and content brief
Write the brief around the answer the reader needs.
An SEO content brief specifies a page’s reader task, required answers, evidence, exclusions, examples, links and checks before drafting begins. It gives the writer a supported assignment and gives the reviewer a way to judge the completed page.
Separate the brief from the research, outline and draft.
Research supplies observations and sources. The brief turns the accepted findings into an assignment. An outline arranges the proposed answer into headings and blocks. A draft contains the complete explanation. These outputs inform one another, but a list of headings is not a complete brief and a brief is not a substitute for the finished answer.
Begin with the page’s purpose and its place in the site. Name the audience, the situation prompting the visit and the decision or action the page must support. Confirm the existing or proposed owner so the writer does not unknowingly create a competing answer for the same task.
A brief can be revised when research reveals a missing condition or a scope problem. Record the revision and its effect on the draft. Do not keep an obsolete assignment in place simply because writing has started, and do not let the draft silently widen the promise beyond the evidence.
Write a reader task that can be evaluated.
A useful task statement names what someone needs to understand or do and the conditions affecting that need. “Explain entity disambiguation to an editor deciding which source describes a business” is more inspectable than “write about entity SEO.” It points to a concrete distinction and a reader decision.
List the required answers as questions or testable statements. Include definitions, decision criteria, necessary steps, constraints and the next route. Distinguish mandatory content from optional supporting detail. The writer should know what cannot be removed to meet a word target or make space for decoration.
If the assignment combines incompatible tasks, resolve the boundary before drafting. An introductory explanation can link to a specialist explanation without reproducing all of it. A sales action should not displace the answer promised by an educational title.
Specify sources and unresolved facts.
Attach each material claim to an appropriate source or a named request for confirmation. A source record should identify the document, its relevant location, the version or date and the scope it supports. Explain if a source is an official definition, a business confirmation, an observed test or an editorial interpretation.
Check the source’s limits. A document about one edition does not establish instructions for another; a company’s description of its service does not verify a competitor’s service. If sources disagree, preserve the conflict and assign the resolution instead of instructing the writer to choose a plausible answer.
A blocked fact should have a visible consequence. The brief can hold the relevant claim, reduce the scope or require confirmation before review. A blank source field is not permission for a writer or a model to invent missing specifications, credentials, demand figures or client outcomes.
Set exclusions, examples and link destinations.
Exclusions protect the page’s task. Name adjacent subjects that deserve their own treatment and claims that the evidence cannot support. Explain why each exclusion exists so a writer does not mistake a deliberate boundary for an accidental omission.
Give the worked example a job: demonstrate a distinction, apply a decision rule or show how to record an uncertainty. State which facts are invented for teaching and which come from evidence. Require enough detail for a reader to follow the reasoning rather than offering a decorative scenario with no outcome.
Specify contextual link destinations and the reason for each link. Include the parent collection, any prerequisite and a useful next answer. Identify incoming links that need to be added when the page is published. Do not fill the brief with unverified URLs or instruct the writer to link every repeated entity name.
Worked brief: distinguish a town, business and person.
The following is an original fictional assignment for an educational page. Its purpose is to help an editor avoid combining unrelated things because their names overlap. The invented records are Brookhaven, a town; Brookhaven Studio, a business; and Alex Brookhaven, a person. No real business, person or client is represented.
The required answer must define identity, name, alias, type and contextual evidence; explain why a shared word is insufficient for a merge; compare the three records; and show what to do when an identifying detail is missing. The example should end with separate records and an unresolved relationship, rather than inventing ownership or residence.
The writer should show an evidence request: confirm the business’s official identity and the person’s relationship to it before claiming a founder or employee connection. The town’s location does not establish the person’s residence. A source that mentions two records together does not automatically establish that they are the same thing.
| Brief field | Assignment |
|---|---|
| Reader task | Decide which record a source describes before adding a claim |
| Required answers | Identity, names, aliases, types, contextual clues, uncertainty and false equivalence |
| Evidence | Official vocabulary references for modeling; fictional records explicitly labeled |
| Exclusions | No biography, local offer, real customer story, ranking guarantee or invented ownership |
| Worked example | Three similarly named fictional records; keep separate and request missing relationship evidence |
| Links | Entity overview, entity disambiguation explanation and learning collection |
| Checks | Every claim refers to the intended record; source scope and unresolved facts remain visible |
Populate the example brief with source roles and acceptance criteria.
Assignment ID B17 is an educational explanation for an editor who has three similarly named records and needs to assign a claim to the correct one. Its parent is the entity learning collection. It owns the identity decision; it does not own a biography, company profile or local service offer. The intended completion is a set of three distinct records with an evidence request attached to the unresolved business-person relationship.
Use source S1, Schema.org’s data model documentation, for the distinction between types and properties. Use S2, W3C’s RDF concepts document, for the subject, predicate and object model and the distinction between a resource and a literal. Neither source verifies the fictional Brookhaven identities. Teaching cards F1–F3 below supply the invented example facts only.
F1 describes Brookhaven as a town in a fictional geographic record. F2 describes Brookhaven Studio as an organization in a fictional company record. F3 describes Alex Brookhaven as a person in a fictional contributor record. The cards provide no founder, employee or residence relationship. The example must keep that absence visible instead of inferring a connection from the shared word.
The proposed answer order is: define the identity problem; explain name, alias and type; compare the three records; test a candidate claim; record the missing evidence; then identify the next explanation. The centerpiece is a three-row comparison table with subject, type, identifying context and unsupported inference. Ordinary prose explains why the inference fails.
Use a link to the entity overview for surrounding concepts and a link to the disambiguation explanation for a fuller identity example. Request an incoming link from the entity collection when this assignment becomes a public page. The factual reviewer checks each statement’s subject and support; the editor checks the required answers and boundaries; page behavior review checks table headers, image alternatives and working routes. No search volume, client result or completed user study is claimed.
| Record | Supported teaching fact | Claim that remains unconfirmed |
|---|---|---|
| F1 / Brookhaven | Town; fictional geographic record | Location of the business or residence of the person |
| F2 / Brookhaven Studio | Organization; fictional company record | Founder or employment relationship to Alex Brookhaven |
| F3 / Alex Brookhaven | Person; fictional contributor record | Ownership of the business or residence in the town |
Choose checks that match the assignment.
Factual review checks the claims, examples and conditions against the specified evidence. Task review checks that the answer can be understood and used by the intended reader. Editorial review checks structure, clear references, language constraints and unnecessary repetition. Keep the responsible reviewer and the exact draft version attached to each result.
For the fictional assignment, a reviewer can point to each company, town and person statement and identify its subject. They can check that an alias is not inferred from resemblance and that the unresolved relationship remains unresolved. Those checks are more meaningful than counting how often a keyword appears.
Include page behavior checks when the brief specifies a table, image, link or interaction. The table needs meaningful headers and an accessible narrow layout. Images need appropriate filenames and text alternatives, while the explanation remains ordinary text. A proposed interactive tool requires a real, tested function; a static worksheet should say how it can be used without pretending to save data.
Hand off the brief with its decisions intact.
Before drafting, confirm the task, scope, owner, answer requirements, evidence, example and links. Keep open questions explicit and assign their resolution. After drafting, compare the complete page against those requirements rather than accepting a polished introduction as proof that the whole assignment is covered.
A brief should be detailed enough to prevent invention and omission, but it should leave room for clear explanation and a sensible reading order. There is no fixed word count or keyword density that makes every brief complete. Judge the assignment by the answer it enables and the evidence available to support it.
Sources and related learning
Google content quality documentation. Schema.org data model. RDF concepts.
The worked examples are fictional. They explain planning decisions and do not represent measured search or client outcomes.
Continue with semantic SEO learning and content composition. entity disambiguation example. entity overview.