Topic-cluster preflight: evidence to verify before publishing

Gate zero: prove a cluster is needed

Before approving a cluster, write the bounded subject, the audience state, and the set of decisions the proposed pages will enable. Attach the current URL inventory and identify the evidence gap that existing material cannot close. A keyword list alone fails this gate. So does a plan that cannot state why separate URLs are better than sections in one guide. Google’s starter documentation can ground discoverability and organization principles, but it does not make a topic-cluster pattern mandatory. Mark the gate PASS only when at least two genuinely distinct answer jobs exist and their relationship helps a reader navigate. Mark REVIEW when the evidence could fit one expandable page. Mark STOP when the proposal exists mainly to increase page count or repeat phrases across titles.

Evidence: Google Search Central; GOV.UK Service Manual

Assemble the preflight evidence

Record the ruling in a cluster release card; this becomes the first page of the audit packet and prevents later enthusiasm from rewriting the original reason.

Evidence: Google Search Central; Google Search Central

Answer-ownership checks

For every planned or existing URL, verify a one-sentence promise, a distinct completion state, required evidence, and an explicit exclusion. Compare neighboring rows side by side. PASS means a reviewer can explain why each destination deserves to remain separate without referring only to word count or target keywords. REVIEW means two pages differ in format but lead to the same decision. STOP means neither page has enough evidence to support its central answer. Check canonical intent as part of ownership: when variants or print views exist, document which URL should represent the content rather than leaving templates to improvise. This audit does not assume that a declared canonical will always be selected by a search engine; it asks whether the publisher’s own signal is consistent.

The evidence packet should contain the ownership table, annotated overlaps, and the person authorized to merge or retire material.

Evidence: Google Search Central; World Wide Web Consortium

Route and label checks

Open each destination from the interface instead of trusting a diagram. Verify that the link is a normal anchor with a usable destination, points to the final preferred URL, and uses words that disclose why someone would follow it. Then run one realistic task from a top-level entry and another beginning on a deep article. W3C’s link-purpose criterion addresses understandable destinations; Google’s crawlable-link guidance covers discoverability mechanics. PASS requires both routes to work without hidden instructions. REVIEW applies when the link functions technically but several plausible labels compete. STOP applies to scripted controls that do not expose a destination, loops, dead ends, or navigation that depends on returning to search results. Include keyboard and assistive-technology use in the route inspection rather than treating crawler access as accessibility.

Save the tested start point, link text, target, observed obstacle, and date; a bare check mark cannot be reproduced.

Evidence: Google Search Central; GOV.UK Service Manual; World Wide Web Consortium

Duplication and boundary checks

Read the pages as answers, not as strings. Highlight repeated definitions that are necessary for context separately from repeated conclusions, examples, and evidence that indicate competing ownership. Confirm that hubs summarize and route rather than swallowing the full value of every child. Look for unsupported branches created from singular/plural variants, tool modifiers, or audience labels that do not change the task. PASS means overlap has a documented purpose and each page contributes evidence another does not. REVIEW means the distinction depends on copy that could drift during the next edit. STOP means two URLs can exchange titles without changing what a reader learns. Do not use a similarity score as the final verdict; it is a prompt for editorial comparison. Conversely, polished prose does not excuse duplicated decision value.

Add planned consolidations, redirects, internal-link updates, and retained evidence to the release card before deletion or publication occurs.

Evidence: Google Search Central; GOV.UK Service Manual

Task-evidence packet

Recruit a few people who resemble the intended readers and give them concrete information tasks. Capture starting page, first choice, hesitations, destination reached, whether the answer settled the task, and the participant’s explanation. GOV.UK’s benchmarking guidance supports consistent realistic tasks and observable success measures. This audit uses those ideas qualitatively; it does not claim that a small sample represents all visitors. PASS means the proposed labels and routes support the tested jobs without coaching. REVIEW means completion occurs through unexpected paths that may still be valid. STOP means the correct destination can be found only after the evaluator explains the taxonomy. Attach notes including failures and contradictory cases. Avoid reporting only a percentage, because the reason for a wrong turn is what guides the next architecture decision.

No ranking, revenue, or conversion result should be inferred from this packet; it evaluates comprehensibility of a bounded route.

Evidence: Google Search Central; Google Search Central

Release ruling and maintenance trigger

Approve only when Gate Zero passes, answer ownership is recoverable, crawlable routes reach final URLs, link purpose is understandable, and no STOP finding remains. A REVIEW finding needs an owner, a due date, and a reason it does not undermine the release. The next action is to audit one proposed cluster with the release card and fix the earliest failed gate; do not compensate by adding more pages. Retain the prechange inventory and specify a rollback for merges or navigation edits. Limitations belong in the ruling: platform reports lag, search systems choose their own canonical, representative tasks cannot predict every audience, and resource-constrained sites may be better served by fewer answers. Schedule reassessment when a new reader job appears, a route repeatedly fails, or content ownership changes. The checklist is complete when another editor can reconstruct the decision and challenge it, not when every box has been made green.