When preparing an article for search, I do not begin by counting keyword repetitions. I ask what the person searching is trying to solve. Do they need a definition, comparison or practical method? The brief should turn that need into a plan the writer can actually use.
Give the page one primary question
Content strategy is a broad subject; choosing content pillars is a more specific task. Rather than expecting one page to cover every related issue equally deeply, choose the central question and organise supporting questions around it.
I also state what a reader should be able to do afterwards, such as complete a worksheet for selecting pillars. That outcome keeps headings from becoming a list of loosely related topics. It gives the editor a practical way to check whether the promised answer is complete.
Identify the additional value
Google’s guidance emphasises helpful, reliable material created for people and states that it has no preferred fixed word count. I use that as an editorial check: does the article merely repeat definitions, or provide a method, example or comparison that makes the reader’s task easier?
An original contribution need not claim a new research discovery. A clearly labelled illustrative worksheet or careful decision framework can help. Inventing a client experience that never happened is not a legitimate way to create apparent expertise.
Record the brief’s essential fields
| Field | What it gives the editor |
|---|---|
| Main question | The page’s central answer |
| Reader context | Knowledge level and intended use |
| Supporting questions | A logical section sequence |
| Contribution | Example, worksheet, method or observation |
| Sources | Claims requiring verification |
| Related pages | Material to link to instead of repeat |
A focus keyword can help organise the work. Forcing it into every heading can make the article harder to read. Section titles should describe what the section actually explains rather than act as repetitive keyword containers.
Separate evidence from judgement
Check a primary source before describing a current platform rule or technical feature. Present a working preference as a preference. “I start with this table” makes a different claim from “every team must use this table.” Keep that distinction visible.
Place source links near the relevant material and record a review date internally. Platform-dependent information can change. A bibliography does not automatically validate every conclusion the writer draws from a source, so review the reasoning as well as the citation.
Test the promised answer before publication
Can someone arriving through the title find the answer it promises? Is the example sufficient to apply the method? If another page already answers the same question better, should the pieces be combined or given clearer separate roles?
My final pass removes repetition, clarifies conditions and adds useful connections to related guides. Length should follow from that work. The objective is a clear and sufficient answer, not a ranking guarantee or a word-count target disconnected from the reader’s need.