A topic cluster is an editorial and information-architecture model: a group of related pages with distinct jobs and useful links between them. It can make a complex subject easier to learn and maintain. It does not create authority merely by increasing page count, repeating keywords or drawing a hub-and-spoke diagram.
Google documents a named topic authority system for newsy queries in specialized areas. The broader SEO idea of “topical authority” is an industry planning concept, not an official score shown to site owners. Use clusters to help people and organize evidence—not to manufacture a metric.
The cluster operating model
| Component | Owns | Quality test |
|---|---|---|
| Topic boundary | The connected problem space and audience | Can the publisher prove and maintain it? |
| Pillar or hub | Orientation, model and routes to deeper tasks | Does it guide rather than repeat every detail? |
| Supporting page | One distinct question, decision or workflow | Would the task still deserve its own URL? |
| Evidence | Experience, expertise, data, method and sources | Does each page add more than a summary? |
| Internal paths | Useful movement between related tasks | Does every link help the reader predict the next page? |
| Maintenance | Ownership, overlap control and update triggers | Can the cluster stay coherent after publication? |
1. Choose a boundary the site can defend
Start from the site's primary purpose, real audience and proven capability. The content strategy should explain why this subject matters to customers or practitioners, what the business can contribute and who will maintain changing facts. Traffic potential alone is not a defensible reason to enter a topic.
Define the boundary using connected decisions, not loose semantic similarity. “SEO for service businesses” can connect technical foundations, content, authority and measurement. An unrelated viral technology story does not belong merely because it contains the word AI. Record the audience, market, language, risk level, exclusions and adjacent subjects owned elsewhere.
Raise the evidence and review threshold for health, finance, legal, safety and other high-impact topics. Use the content trust framework to decide whether first-hand experience is enough or qualified expertise and current primary sources are required. A wide cluster without suitable competence increases risk rather than trust.
| Boundary test | Include when | Exclude or route elsewhere when |
|---|---|---|
| Audience | The same customer or practitioner group needs it | It attracts a different audience with no useful journey |
| Problem chain | It supports a connected decision or dependent task | Only the vocabulary looks related |
| Capability | The site can explain, demonstrate or review it responsibly | The topic requires expertise the publisher lacks |
| Business fit | It supports a real service, product, mission or customer outcome | The only rationale is estimated traffic |
| Maintenance | An owner can keep key facts and links current | The update load cannot be supported |
2. Give every URL one primary job
Inventory existing URLs before creating the map. Group queries by the audience task and expected page format, then compare them with current pages. Use search-intent analysis and the content gap framework; keyword similarity alone cannot decide page boundaries.
The pillar is an orientation page, not automatically the longest page or the page targeting the highest-volume phrase. It should explain the overall model, answer the essential starting questions and send people to distinct deeper tasks. Supporting pages should solve those tasks without repeating the pillar introduction at length.
Assign create, improve, consolidate, redirect or no-page decisions. Two queries can share one URL when the task and useful answer are materially the same. Separate URLs when users need different decisions, formats, evidence or journey stages. Document each approved page in an SEO content brief.
| Page role | Primary job | Do not use it to |
|---|---|---|
| Pillar or hub | Orient the reader and route deeper work | Repeat every supporting guide in full |
| How-to guide | Complete one defined workflow | Answer every adjacent concept |
| Decision or comparison page | Help choose using explicit criteria | Hide commercial conflicts or trade-offs |
| Service page | Explain fit, scope, process, proof and enquiry | Carry the whole educational cluster |
| Case study | Document one real project, method and bounded outcome | Make an anonymous or invented proof claim |
- Primary audience, problem space, market and language are explicit.
- The cluster supports a real service, product, mission or customer outcome.
- Capability, evidence and maintenance limits are documented.
- Existing URLs, redirects and legacy content are inventoried.
- One pillar or hub provides orientation without duplicating every guide.
- Every supporting URL owns one distinct audience task.
- Create, improve, merge and no-page decisions are recorded.
- Original contribution and required sources are assigned per page.
- Internal paths follow real prerequisites and next steps.
- Each page has an owner, priority and review trigger.
3. Connect useful paths and original evidence
Use internal links to continue the reader's journey: pillar to deeper task, supporting page back to the wider model, and supporting page to another guide only when a dependency is real. Follow Google's link and internal-linking principles. Links should be crawlable, use descriptive anchor text and appear where the destination is genuinely useful.
Do not force every page to link to every other page. A dense web of templated anchors can make navigation noisy and obscure hierarchy. Provide a clear route from the main navigation or hub, contextual links within the answer, and a useful recovery path. Check for orphaned pages and links that point through avoidable redirects.
Authority claims need visible substance. Add first-hand project decisions, original data, calculations, screenshots, interviews, templates, tested workflows or expert review where suitable. Cite current primary sources for changing rules. A cluster made from rewritten competitor summaries is still a collection of summaries, however neatly it is linked.
| Path | Reader value | Implementation check |
|---|---|---|
| Navigation or hub → pillar | Enter the subject from a predictable place | Crawlable link and descriptive label |
| Pillar → supporting guide | Move from orientation to one deeper task | Anchor names the task, not “read more” |
| Supporting guide → pillar | Recover the wider model and adjacent choices | Link appears where context is needed |
| Guide → dependent guide | Continue a prerequisite or next action | Dependency is explicit and destination is distinct |
| Guide → service or tool | Offer help at a relevant decision stage | CTA is accurate, useful and not forced |
4. Publish and maintain the cluster as one product
Publish according to dependencies and evidence readiness, not a target number of articles per week. Often the pillar, key service page and essential foundational guides come first; narrower support follows when its task and evidence are ready. Do not release thin placeholders merely to make the diagram look complete.
Maintain a cluster inventory with URL, role, audience task, owner, source dates, internal paths, performance baseline and next review trigger. Review the group when a product, service, policy, algorithm documentation or important source changes. Use the pruning and consolidation framework when page roles overlap or facts decay.
Measure whether people and search systems can discover the right pages and whether those pages help the intended task. Segment Search Console by page and query, then combine visibility with internal clicks, qualified enquiries, conversions, links, assisted journeys or support use where relevant. Follow the measurement guide; no cluster structure guarantees ranking.
| Signal | Question | Possible action |
|---|---|---|
| Two pages appear for the same task | Is intent or page-role overlap real? | Differentiate, consolidate or change links |
| Pillar earns visits but guides are unseen | Are routes and labels useful? | Improve placement, anchor and next-step explanation |
| Supporting guide performs but pillar does not | Does the pillar add orientation or only repeat? | Clarify the model, navigation and unique role |
| Facts, offers or processes changed | Which connected pages are now inaccurate? | Update the affected cohort and record dates |
| No useful audience or business outcome | Does this topic still fit the boundary? | Improve, merge, reroute or stop maintaining it |
- Approve the topic boundary, exclusions and accountable owner.
- Reconcile existing URLs before approving new pages.
- Prioritize foundational pages by dependency and evidence readiness.
- Create an evidence-led brief for every approved page.
- Publish with accurate authorship, metadata, links and dates.
- Crawl the cluster and test representative user journeys.
- Save page and query baselines plus relevant business outcomes.
- Review overlap, orphaning, stale facts and broken paths together.
- Improve, consolidate, redirect or retire with documented reasons.
- Record the next trigger and keep the map aligned with the live site.
Common mistakes
- Treating topical authority as an official Google score.
- Applying Google’s documented news topic-authority system to every ordinary webpage without qualification.
- Calling a category archive or article list a topic cluster.
- Choosing topics only from traffic estimates.
- Publishing one page for every keyword variation.
- Making the pillar the longest page by default.
- Using the same intent and introduction across pillar and guides.
- Creating supporting pages before checking existing URLs.
- Copying competitor clusters without matching your audience or capability.
- Generating thin pages with AI to fill every apparent gap.
- Linking every page to every other page with templated anchors.
- Leaving pages orphaned or linked only through JavaScript controls.
- Never reviewing overlap, facts or reader paths after launch.
- Promising rankings because the cluster diagram is complete.
Frequently asked questions
What is a topic cluster?
It is a group of related pages with distinct audience jobs, usually including an orientation page and deeper supporting pages connected by useful internal links. It is an editorial architecture model, not a required Google feature.
What does topical authority mean in SEO?
Practitioners commonly use it to describe perceived depth, credibility and relevance around a subject. Google does not provide a general topical-authority score for site owners, so use the term as a planning concept rather than a guaranteed ranking metric.
Is Google’s topic authority system the same as the broad SEO concept?
Do not assume so. Google’s documented named system helps identify expert sources for newsy queries in specialized topic areas and considers signals such as topic or location relevance, original reporting and source reputation. The industry uses the same phrase more broadly.
Does every cluster need a pillar page?
A clear orientation page is often useful, but Google does not require a page labelled “pillar.” If another existing page already provides the model and routes, do not create a duplicate solely to satisfy a diagram.
How many pages should a topic cluster contain?
Only as many as distinct, useful audience tasks justify and the publisher can maintain. There is no universal minimum or maximum.
Should every cluster page link to every other page?
No. Link where the destination is a useful prerequisite, deeper explanation, next action or wider context. Preserve hierarchy and avoid noisy templated linking.
Can one page support more than one cluster?
Yes when it genuinely helps both journeys. Keep one primary page purpose, avoid duplicating the URL and link from each relevant context only when useful.
Can AI build a topic cluster map?
AI can help group inputs and surface candidate questions, but a responsible person must verify intent, page overlap, evidence, business fit, risk and maintenance capacity. Do not automatically publish every generated node.
How should a topic cluster be measured?
Measure discovery and usefulness at page, query and journey level: relevant impressions and clicks, internal-path use, qualified actions, links, conversions and maintenance quality where appropriate. Do not reduce the cluster to one authority score.
When should cluster pages be merged?
Merge when pages serve materially the same audience task and one combined page can answer it better without harming a distinct journey. Plan the preferred URL, redirect, internal-link updates, canonical and sitemap changes before launch.
Official references
- Google: Creating helpful, reliable, people-first content
- Google SEO Starter Guide
- Google: How Search works
- Google: Understanding news topic authority
- Google: Link best practices
- Google: Canonicalization overview
- Google Search Console Performance report
- Google: Spam policies—scaled content abuse
- Google: AI features and your website
Industry workflow references
These practitioner resources were reviewed for topic-cluster terminology, hub structures and planning examples. Google’s named topic authority system is described only within the documented news context. Statements about people-first content, site organization, links, canonicalization, scaled content and Search Console are grounded in the official Google references above. Third-party authority scores and claimed causal effects are not presented as Google rules.
- Ahrefs: How to Build a Topic Cluster
- Ahrefs: Content Hubs for SEO
- Ahrefs: Topical Authority Guide
- Semrush: Topic Clusters for SEO
- Backlinko: SEO Marketing Hub
Jack can audit existing URLs, define cluster boundaries, assign page roles, plan evidence and build useful internal paths before new content is commissioned.



How Google Ranking Evolved: From PageRank to Modern Search SystemsSeptember 2, 2026
Google AI Content and SEO: What Is Allowed, What Is Spam, and How to Publish SafelySeptember 2, 2026
Google Florida Update (2003): What We Know, What Remains TheorySeptember 2, 2026