How should we structure our topic clusters?

This is a content strategy question — the kind that usually shows up from content, SEO, editorial. It rarely has a one-line answer, because the honest version of “How should we structure our topic clusters” is a shortlist of rival explanations, not a single cause. The job is to work through that shortlist with evidence and stop as soon as one of them is confirmed — not to write a report that mentions all of them.

The rival explanations

Direct answer: A pile of related posts is not a cluster — five specific gaps (no ranking hub, cannibalizing URLs, chronological rather than semantic internal links, missing entities/questions, and a cadence that can't finish the planned width) each independently prevent topical authority from accumulating.

Treat these as competitors, not a checklist. The point of naming five up front is to stop the first plausible-sounding one from becoming the story before the others have been checked.

• We have posts on a topic but no hub that ranks or funnels.
• Cannibalising URLs split the cluster instead of supporting it.
• Internal links are chronological or sitewide, not semantic.
• Entities and questions Google groups are missing from the inventory.
• The publishing cadence cannot support a cluster of the planned width.

What the evidence has to show

Direct answer: A full URL inventory with GSC query maps, a content-gap analysis against the current cluster leader, AlsoAsked/entity coverage for the hub, an internal-link graph of inlinks versus orphans, and a realistic two-quarter editorial capacity check are what turn 'we have posts on this' into an actual cluster decision.

None of the five above survives on a hunch. Here is what actually needs pulling before any of them can be ruled in or out:

• Full URL inventory with query maps from GSC.
• Topic research + content-gap vs the current #1 cluster owner.
• AlsoAsked / entity list for the hub.
• Internal-link graph: inlinks to candidate hubs vs orphans.
• Editorial capacity for the next two quarters.

The decision rule

Direct answer: One hub per cluster. Supporting URLs must link up with descriptive anchors and must not target the hub’s primary query. If capacity cannot finish a cluster in 90 days, narrow the cluster rather than starting three.

What to tell the people around you

Direct answer: Leadership needs to approve one cluster architecture and a 90-day freeze on off-cluster briefs — not permission to start three clusters because they all sound promising.

The analysis is not finished until it produces something a non-specialist can act on. That means naming the situation, the cost of getting the first move wrong, and a specific ask — not a summary of the investigation.

• Situation — Topical authority is being treated as a site-architecture problem, not a word-count problem.
• So what — Scattered posts do not accumulate. A finished thin cluster beats an abandoned wide one.
• The ask — Approve cluster architecture and a freeze on off-cluster briefs for 90 days.

SEO designs IA. Editorial owns cadence. Dev implements nav/hub templates if needed.

How to act on this

1. Inventory every existing URL with its GSC query map to see which topics already have coverage without a hub.
2. Run a content-gap analysis against the current #1 cluster owner and pull the entity/question list a hub needs to cover.
3. Map the internal-link graph to find candidate hub pages with too few inlinks and supporting posts that are effectively orphaned.
4. Assign one hub per cluster, with every supporting URL linking up using descriptive (not generic) anchor text, and none of them targeting the hub's primary query.
5. Size the cluster to what a two-quarter editorial capacity can actually finish — narrow the scope rather than starting a second cluster in parallel.

Frequently asked questions

How many supporting pages does a cluster need before it counts as topical authority?

There's no fixed number — what matters is whether the hub and supporting pages cover the entity/question set a competitor's ranking cluster already covers, confirmed by the AlsoAsked/entity gap check, not a page count.

What should happen to posts that are cannibalizing the hub's target query?

Consolidate them onto the hub with a redirect, or re-target them at a genuinely different, non-competing query — leaving them live and competing with the hub only splits ranking signal.

Is chronological internal linking (newest posts linking to recent posts) good enough?

No — the graph needs to be semantic, meaning supporting pages link up to the hub and across to genuinely related supporting pages, not just to whatever was published around the same time.

What if we can't finish the planned cluster width in 90 days?

Narrow the cluster rather than launching a second one in parallel. A finished narrow cluster ranks; two half-finished wide ones both stall.

Who decides the freeze on off-cluster briefs?

Editorial and SEO agree the architecture and the freeze together, but leadership needs to actually approve it — an unenforced freeze just becomes the same scattered publishing pattern with extra steps.

Does every page on the site need to belong to a cluster?

No — some pages (legal, account, transactional) don't need topical cluster placement. The cluster discipline applies specifically to content built to earn organic search visibility on a shared topic.

Should an existing high-performing page ever be demoted from hub to supporting status?

Yes, if a newer or more comprehensive page is better positioned to serve as the hub — the architecture should follow the content's actual strength, not just which page was published first.

Sources

1. SEO essentials — Search Central
2. Beginner's Guide to SEO — Moz
3. Information architecture — Wikipedia
4. Content strategy — Wikipedia

Where nqzai fits

nqzai runs this same rival-hypothesis framework against your own connected Search Console, Analytics, and audit history, and returns a keep / change / stop decision with the evidence named — including which of the explanations above it could not test, and what to connect to close that gap. No extra cost for the analysis itself; it reads measurements already on file.

Ask nqzai: “How should we structure our topic clusters?”