Topic clusters

What are topic clusters?

A topic cluster is a content architecture pattern: a long-form pillar page broadly covers a topic, and a set of narrower spoke pages each drill into one sub-topic. The pillar links out to every spoke; every spoke links back to the pillar. The structure was popularized by HubSpot's content marketing framework around 2017¹ and became standard SEO practice through the 2020s.

The classical SEO rationale was PageRank concentration: many internal links flowing toward the pillar boosted its ranking authority. In the AI search era, the value proposition has shifted toward topical clarity, retrieval-friendly content organization, and entity coherence: a well-built cluster can make topical relationships clearer and may improve the likelihood that engines retrieve relevant pillar or spoke pages for queries about the topic. Practitioners commonly observe clustered content earning citations across both pillar and spokes more reliably than equivalent isolated pages, though the independent effect of cluster structure vs cluster-level content quality has not been isolated by public study, and citation behavior varies by engine, query, and source authority.

Status in 2026

Mainstream but interpreted differently than in the 2017-2019 SEO playbooks when HubSpot's framework first dominated practice. Spoke pages now need to be cite-able as standalone answers. Embedding-based retrieval and RAG systems typically chunk content at paragraph or sentence boundaries and score retrieved passages individually, so thin spokes that exist only as PageRank funnel may underperform in AI-search retrieval²; exact chunking and scoring behavior varies per engine and is not vendor-documented (see the sub-document retrieval entry for parallel discussion). The 2026 best practice combines the original hub-and-spoke structure with DefinedTermSet-style schema markup for glossary-style clusters; this can make the cluster's collective scope more explicit and machine-readable at the schema layer, though whether engines treat schema-marked clusters as categorically distinct from interlinked content with the same topical coverage has not been isolated by public study.

How to apply

Topic clusters are signal-stacking applied across a content family rather than a single page. Three concrete moves:

• Define the spoke set before writing the pillar: list 15–30 sub-topics that fall under the pillar's domain. Each becomes a candidate spoke. A pillar without a defined spoke set tends to become a sprawling page that ranks for nothing in particular.
• Make every spoke independently cite-able: each spoke should answer a real user query and stand alone in retrieval. Don't write spokes as funnel bait; write them as standalone answers that happen to live in a cluster. FAQPage JSON-LD remains a valid schema vocabulary for question-and-answer structure where the spoke has real Q&A content, but no longer earns SERP rich results (Google fully deprecated FAQ rich results for all sites on May 7, 2026; see the FAQ schema entry); ship it for the underlying Q&A structure's machine readability rather than for SERP visual treatment.
• Wire the cluster with DefinedTermSet for terminology hubs: if your cluster is a glossary or jargon set, mark the pillar as DefinedTermSet and link each DefinedTerm spoke via hasDefinedTerm. This can make the cluster's collective scope more explicit and machine-readable at the schema layer; it does not guarantee that engines will treat the cluster as a recognized entity collection. Recognition still depends on consistency, source trust, and the kind of content-level signals discussed on the entity-based SEO and knowledge graph entries.

What to skip: classical "PageRank funnel" thinking. The 2026 cluster goal is topical clarity and retrieval coverage, not link equity concentration. Spokes that exist only to feed the pillar tend to dilute rather than strengthen the cluster.

How to measure cluster effect on AI citation

Because the lift from cluster structure (vs cluster-level content quality) is not isolated by public study, the only reliable answer for any specific topic is to measure it directly. A practitioner protocol:

• Fix a cluster-level prompt set before build-out: pick 15-30 user-question prompts that cover the pillar topic plus its main sub-topics. Lock the set; rotation breaks comparability across the measurement window.
• Record citations per page-role separately: for each prompt, log whether the pillar was cited, whether any spoke was cited, whether a brand mention appeared without citation, and which engine surfaced what. Aggregating "the cluster was cited" hides whether the pillar is doing the work, the spokes are, or only one outlier spoke is.
• Compute cluster-level citation share and attribution rate: roll up to the topic-cluster level rather than treating each URL independently; this is what makes the cluster framing operationally distinct from individual-page tracking (see the citation share and attribution rate entries).
• Compare 4-8 weeks before vs after material build-out: ship the spoke set with measured Day-0 baseline, then re-probe weekly. Treat the trend line as the signal, not any single probe.
• For Microsoft Copilot specifically: Bing Webmaster Tools' AI Performance dashboard (public preview since 2026-02-10) surfaces per-page citation counts and grounding queries, the only vendor-native measurement source for any AI surface as of mid-2026.

This loop turns "cluster lifts citation" from a confident causal claim into a verifiable observation specific to your topic, audience, and engine mix.

How it relates to other concepts

• The hub-and-spoke pattern's hub is pillar content: pillar is the page, cluster is the structure.
• Plausible contributor to Knowledge Graph signals when the cluster is wired with consistent Organization + DefinedTermSet schema; the independent effect of cluster structure on KG entity recognition vs equivalent un-clustered topical coverage has not been isolated.
• The content-architecture layer of entity-based SEO: entity-based SEO is the "how" of marking entities; topic clusters are the "where" (the page-set scope across which the entity work compounds).
• For terminology clusters specifically, DefinedTerm schema + DefinedTermSet form the schema-layer backbone.
• Operates through sub-document retrieval at the engine side: clusters matter for AI search partly because retrieval scores passages individually, so a well-structured spoke is more retrievable than an equivalent paragraph buried in the pillar.
• Direct content-strategy enabler of GEO at scale. Single pages compete passage-by-passage; clusters give the topic a larger surface area at the passage level.