
Topic clusters are groups of pages that cover one subject from every angle, tied together by deliberate internal links: one broad hub page in the middle, detailed pages around it. Get this wrong and your own pages compete against each other for the same query; get it right and the whole group ranks better than any single page could on its own.
What a real cluster looks like
Forget the abstract hub-and-spoke diagrams for a second. Here is a cluster you could actually build for "email deliverability":
- Pillar: Email Deliverability: The Complete Guide (targets "email deliverability")
- Spoke: SPF, DKIM, and DMARC explained (targets "spf dkim dmarc")
- Spoke: How to warm up a new sending domain (targets "domain warmup")
- Spoke: Why emails go to spam and how to fix it (targets "emails going to spam")
- Spoke: Email blacklist removal, step by step (targets "email blacklist removal")
Every spoke links up to the pillar with descriptive anchor text. The pillar links down to every spoke from the section where that subtopic comes up naturally. Spokes also link sideways to each other when it helps the reader (the spam-folder page should absolutely link to the SPF/DKIM page). That link pattern is the cluster. Without it you just have five posts that happen to share a theme. This is the model NerdWallet used to dominate personal finance queries; we broke down their topic cluster playbook in a separate case study.
Cluster roles and who links to whom
| Page role | Query it targets | Links out to | Should receive links from |
|---|---|---|---|
| Pillar page | Broad head term ("email deliverability") | Every spoke in the cluster, from relevant sections | All spokes, main nav or category page, other pillars where topics overlap |
| Spoke / cluster article | One specific long-tail query | The pillar (always), 1–3 sibling spokes where relevant | The pillar, sibling spokes, external content that cites it |
| Glossary / definition page | "What is X" lookups | The pillar and the most relevant spoke | Any page in the cluster that uses the term |
| Comparison page ("X vs Y") | Decision-stage queries | Both option pages plus the pillar | Pillar and both option pages |
| Case study / data page | Proof-seeking queries, link bait | The pillar | Pillar and any spoke making a claim the study supports |
The one non-negotiable row is the pillar↔spoke pair. Everything else is judgment. For a deeper treatment of the linking side specifically, see our guide to internal linking strategy for topic clusters.
How to check it on your own site
- Crawl the site with Screaming Frog (free up to 500 URLs) and export the All Inlinks report. This is your ground truth for who actually links to whom, not who you think links to whom.
- Group your URLs into intended clusters in a spreadsheet: one column for URL, one for cluster name, one for role (pillar or spoke).
- Verify the two mandatory link directions. Filter the inlinks export: does every spoke have at least one contextual link to its pillar? Does the pillar link to every spoke? Mark the gaps.
- Hunt for cannibalization in Google Search Console: Performance report, filter by the head term, check whether multiple URLs from the same cluster collect impressions for it. If a spoke outranks the pillar for the head term, your targeting is inverted.
- Find orphans. Any page in your cluster sheet with zero internal inlinks in the crawl is dead weight. Link it in or fold its content into a spoke.
Common audit mistakes
- Clusters that exist only in the content calendar. The pages got published, the links never did. Fix: make the pillar link and the spoke-to-pillar link part of the publishing checklist, not a someday task.
- Pillar and spoke targeting the same keyword. If the pillar is "email deliverability guide" and a spoke is "what is email deliverability," they will fight. Fix: fold the definition into the pillar or repoint the spoke at a genuinely different query.
- Linking everything to everything. Forty links from every page dilutes the structure into mush and tells search engines nothing about hierarchy. Fix: link where a reader would want the link, cap sideways links at a handful per page.
- Building clusters for topics nobody searches. A beautiful twelve-page cluster on a zero-volume topic is still zero traffic. Fix: validate spoke queries in a keyword tool before writing, not after.
- Counting a bare category archive as a pillar. A paginated list of post excerpts is not a hub page. Fix: either build a real pillar or add substantial editorial content above the archive listing.
Frequently asked questions
How many pages does a topic cluster need?
Enough to cover the subtopics that actually have search demand, no more. Most working clusters run five to fifteen spokes. Three thin spokes will not move anything, and fifty spokes usually means several clusters wearing a trench coat.
Do topic clusters still matter now that AI answers so many queries?
Yes, arguably more. AI Overviews and LLM-based search pull from sources that demonstrate deep coverage of a topic, and a well-linked cluster is exactly how you demonstrate it. The structure that built topical authority for classic rankings is the same structure retrieval systems reward.
What is the difference between a cluster and a category?
A category is a CMS taxonomy; a cluster is an editorial and linking structure. Pages in the same category often share nothing but a label. Pages in a cluster share a pillar, a link pattern, and a coordinated set of target queries.
How long before a cluster shows results?
No honest fixed answer exists; it depends on your site's existing authority and how competitive the head term is. What you can verify early: within a few weeks of interlinking, GSC should show the pillar picking up impressions for a wider set of queries. If nothing changes in the impression profile after a couple of months, audit the links again.
Related reading
The hub page of a cluster is the pillar page, which has its own anatomy worth understanding before you build one. For a full build walkthrough, see building a topic cluster that actually ranks.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







