Aisha.REditor
Many content problems are created before the writer begins. A brief with unclear purpose, overlapping scope or unsupported factual expectations can produce a polished article that still needs substantial rework. A short pre-assignment review catches those problems earlier. For a small UK agency, the review should not become an elaborate committee or another place for vague preferences. Its job is to confirm that a meaningful reader problem exists, that the correct destination has been chosen, that sufficient evidence can be gathered and that the writer knows what an acceptable answer must contain. The writer should be able to challenge the plan rather than being asked to implement an unworkable outline without question.
Check that the reader and task are specific
The brief should identify who needs the page and what they should understand or decide. Labels such as ‘business owners’ may be too broad unless the subject genuinely applies to that whole audience.
Ask the commissioning editor to describe the reader's situation. What information do they already know? What uncertainty brought them here? What decision should become easier after reading? A business owner comparing SEO providers needs scope, qualifications and working arrangements, while a technical colleague validating redirects needs reproducible instructions and known failure conditions. Both could use the phrase ‘SEO migration’, but they would not benefit from identical articles. An audience label should connect to a real task rather than function as a decorative persona paragraph.
Write a single outcome statement: after reading, someone can decide whether this real service matches their needs, or can check whether an old URL reaches an appropriate successor. Test the proposed title, H1 and outline against that outcome. If they promise three unrelated answers, narrow the task or decide which subject belongs elsewhere. Use search results as context when relevant, but do not infer an exact purchasing intention from a keyword alone. Readers can arrive from internal navigation, social links or customer support and still need a complete answer.
Compare the idea with existing pages
Search the site's current content for the same reader need. If a suitable page already exists, decide whether it should be updated instead. New URLs should have a distinct editorial job rather than merely a different keyword variation.
Review the published text, not only a list of titles. An old guide may cover the proposed question under a different heading, while another page may share terminology without answering the same task. Record the most relevant existing resources, their actual audience and what the new brief would add. If an article already contains the correct core guidance, a targeted update may provide more value than duplicating it. If two guides have substantially overlapping examples, consider a separate consolidation decision with approved source and URL handling.
Distinguish a service destination from an educational guide. The first should represent a real offer and help a visitor assess suitability; the second should teach the promised subject without withholding the answer behind a sales prompt. Both may coexist when they are genuinely different. Google's canonical guidance describes duplicate URL signals; it does not decide how many editorial pages a business should create. Do not assume a canonical tag fixes the underlying problem of repetitive briefs.
Challenge required claims and examples
If the brief expects statistics, named products, legal points or other factual material, identify where reliable evidence will come from. Remove requirements that would force the writer to invent specificity or rely on unverifiable claims.
For each material fact, ask who can verify it. Google documentation can establish what Google publicly advises about supported search features, but not whether a named agency achieved specific results. A company's own authorised service record can establish what it offers, but does not prove it is the best provider. Product feature descriptions need the actual current vendor reference, relevant version and availability conditions. A statistic needs a source, period, population and meaningful unit. If none is accessible, remove the number rather than filling the gap with a confident estimate.
Distinguish illustrative scenarios from customer case studies. A hypothetical migration involving a fictional small shop can explain a redirect decision if clearly labelled as an example. It should not be described as an agency project or proof of performance. Similarly, a generic diagram cannot establish current software behaviour, and a historical search screenshot cannot establish current rankings. The brief should give the writer permission to state uncertainty where the evidence does not establish the claimed result.
Review the proposed structure for template habits
Headings should follow the logic of the topic. If the outline could be reused unchanged for almost any article, rethink it. Distinct structure helps the finished piece answer its particular problem rather than sounding mass-produced.
Assess the progression of the reader's task. A troubleshooting article may need symptoms, prerequisites, tests, interpretation and safe next actions. A purchasing comparison might need use cases, limitations, selection criteria and an honest decision table. A governance guide could need decision owners, approvals, evidence and handover requirements. A generic sequence of ‘Benefits, Why Important, Tips, Conclusion’ is not wrong in every setting, but it rarely carries the precise substance needed for complex practical questions.
Ask each proposed H2 what new information it contributes. If the answer is only another variation of the main phrase, replace it with a specific question. Reserve space for examples and failure cases where they genuinely clarify the advice. Do not use a word-count target as a reason to repeat generic facts. A mandated long article should use its space to unpack decision conditions, sources, caveats and implementation details that a reader can actually use.
Clarify the role of commercial references
Decide whether a service mention or call to action genuinely belongs in the reader journey. Do not require promotional material in every article. Editorial usefulness should remain the primary reason for the page to exist.
A guide may explain how to evaluate a website audit and, near the relevant decision, link to a genuine service if the business offers it. The explanation itself should remain available and complete. A commercial page may need clear factual description of deliverables, exclusions, customer obligations and a working contact route. The brief should not invent an office address, client testimonial or qualification to make the promotion more persuasive. Have an authorised operational contact approve material service statements.
Google's people-first content guidance supports reliable answers primarily made for users, not content generated solely to attract search traffic. It does not prescribe an exact ratio of editorial information to commercial text. The test is whether the content meets the reader's actual task and any promotional statements are relevant and truthful. If there is no legitimate offer to link, do not manufacture one.
Give the writer room to improve the plan
A brief is a starting point, not a prohibition on judgement. Invite the writer to flag evidence gaps, better section logic or a mismatch in intent before drafting. Early challenge is cheaper and more useful than repairing a structurally wrong article later.
Specify a feedback route before assignment. The writer should identify unclear terms, unsupported claims, duplicate page proposals and missing source material in the early research stage. A change to the central purpose should be referred to the commissioning editor rather than silently implemented. Smaller improvements to headings or examples may be editorial decisions within the approved scope. Record which changes need renewed client factual approval.
Make disagreement constructive. If the writer believes two proposed sections repeat the same answer, ask for a revised structure showing the reader's decision sequence. If the required comparison has only one genuine option, consider another comparison or explain why a table is inappropriate rather than inventing a rival. If a source contradicts an expected claim, document the mismatch and correct the brief. A writer who can challenge weak inputs helps protect publication quality.
Assign sources and reviewers before drafting
Specify what evidence is already available, what must be researched and who can approve subject-specific material. This avoids the common situation in which a complete draft reaches a client who then rejects its central factual assumptions. A brief might list official platform documentation, an approved service description, a relevant industry standard and unresolved claims. Use each source only for facts it can actually support.
Set separate roles for editorial readability, operational truth and technical correctness. One person may perform several roles in a small team, but do not imply that a named editorial persona proves real credentials or specialist review. A writer can deliver a technically comprehensible guide while still needing an authorised product owner to verify current service limits. For regulated topics, identify any required qualified reviewer instead of asking a general editor to improvise legal or healthcare advice.
Plan visual and comparison requirements honestly
Where a diagram materially helps, identify its intended role, original source and reuse rights. Do not assign a generic image search as if every result were free to reuse. Verify the creator, licence, caption and alt text. A conceptual sitemap can illustrate page relationships without claiming to depict an actual client site. A screenshot of current software should be checked against the version discussed and should not expose personal customer data.
A comparison table should support a real decision with comparable rows, clear column headers and useful source context. Do not ask a writer to invent scores, prices or benchmark percentages. If the content distinguishes updating an existing page from publishing a new one, explain the reader-purpose, source, maintenance and navigation trade-offs. Place the comparison in a responsive, accessible component when the publishing standard requires it. FAQ questions should address genuine residual uncertainty instead of restating the introduction five times.
Define acceptance beyond the draft document
Write down the review standard before the work starts: the answer matches the intended reader, material facts are verified, existing content is not unnecessarily duplicated, and required components are accurate. Then name who approves and publishes it. A draft approved in a document is not the same as a successful public release.
After a Production database UPDATE and native READ-BACK, the stored article, comparison and FAQ may all be correct, but a cache or template can still display an old version. Public acceptance should inspect the actual canonical URL, H1, body, images, links and any contact journey. Test responsive layouts and keyboard interaction where applicable. The W3C WAI tutorials describe relevant accessibility patterns, not certification of a particular site. Record blocked frontend checks rather than claiming a full pass without evidence.
Use a short pre-assignment decision record
A practical sign-off can be a small set of fields: proposed URL or existing page, primary reader question, independent purpose, best related page, factual source owner, required research, comparison or visual need, approvals and acceptance. Mark items as approved, requires clarification, consolidate with existing or decline. Avoid an elaborate meeting if the team can resolve the decision with a concise written review.
Preserve the reasons for important changes so another editor does not recreate a rejected duplicate proposal next month. When a source cannot be obtained, narrow the scope or postpone the specific claim. When the proposed topic genuinely deserves its own resource, give the writer freedom to deliver the best factual explanation rather than a fixed list of keywords and boilerplate headings. A clear pre-assignment review turns the brief into a useful starting point and keeps avoidable mistakes out of the drafting and publishing pipeline.