A topic cluster is one pillar page covering a broad subject plus a set of supporting pages covering its subtopics, all connected by deliberate internal links. It works because it gives search engines a clear map of what your site knows, keeps closely related pages from competing, and concentrates authority on the page you want ranking.
Here’s the mild opinion, up front: most pages published as “pillar pages” are just long blog posts with nothing behind them. Four thousand words, a table of contents, no supporting pages, no internal links in either direction. That’s not a cluster. That’s a long post wearing a costume.
The structure only pays off when the supporting pages actually exist and actually link. This piece covers what a cluster really is, how to plan one that isn’t decorative, and how to audit the one you probably already half-built.
What is a topic cluster in SEO?
A topic cluster is a group of pages on one site covering a single subject at different levels of specificity, joined by internal links. The pillar page covers the broad topic and links out to each supporting page; every supporting page covers one subtopic in depth and links back to the pillar. That reciprocal linking is the part that makes it a cluster rather than a collection.
The definition matters because the word gets used loosely. A pile of related posts published over three years with no linking between them isn’t a cluster — it’s an archive. A single enormous page that covers everything with no children isn’t a cluster either. What distinguishes the structure is that the pages are planned together, scoped so they don’t overlap, and wired together on purpose.
Think of the pillar as the map and the supporting pages as the territory. The pillar tells a reader — and a crawler — what the full shape of the topic is and where each piece lives. The supporting pages do the actual work of answering specific questions in enough depth to satisfy someone who arrived with exactly that question.
Why do topic clusters work?
They work for three reasons that stack: they build recognisable topical depth, they create short crawl and equity paths between related pages, and they force you to scope pages so they stop competing with each other. None of those is magic on its own. Together they change how a site performs on a topic.
Topical depth. A site with one post about a subject looks like a site that mentioned it. A site with a pillar and eight well-scoped supporting pages looks like a site that covers it. Search engines have plenty of ways to notice the difference, and covering a subject completely tends to lift the whole set rather than only the newest page.
Link paths. Internal links move authority and they move crawlers. A supporting page five clicks from the homepage with two inbound internal links is a weak page structurally, no matter how good the writing is. Inside a cluster, every supporting page is one hop from the pillar, and the pillar is usually one or two hops from the homepage. That’s a meaningful difference in how quickly new pages get discovered and how much equity reaches them. If you want the mechanics, our piece on how to structure links between your own pages goes deeper than there’s room for here.
Less cannibalization. Planning a cluster forces you to write down what each page is for. That single act prevents most of the overlap that happens when people publish reactively — three posts that all half-cover the same query, none of which ranks because Google can’t tell which one is the answer.
How do you plan a cluster from keyword research?
Start with a head term broad enough to have genuine subtopics but narrow enough that you could realistically be one of the better resources on it. Pull the related queries, group them by the underlying question rather than by wording, and each surviving group becomes one supporting page. The head term becomes the pillar.
-
Pick the head term honestly
It should be something your business actually has standing to talk about, with a SERP you could compete on within a year. “Insurance” is not a topic you own. “Public liability insurance for tradespeople” might be.
-
Pull every related query you can
Keyword tools, People also ask, autocomplete, your own Search Console query report, and — the most underrated source — the questions your sales team gets asked repeatedly.
-
Group by question, not by keyword
“How much does X cost”, “X price”, and “X cost per unit” are one page, not three. Merge ruthlessly at this stage; every merge you skip becomes a cannibalization problem later.
-
Check intent per group
Some groups will be informational, some commercial. Note which is which now, because it decides the format of each supporting page and whether it belongs in the blog or in the service section.
-
Write a one-line scope for every page
One sentence: “This page answers X and nothing else.” If two scope lines could be swapped without anyone noticing, you have one page, not two.
-
Map the links before you write
Pillar links down to every child. Every child links up to the pillar. Children link sideways only where a reader would genuinely want the jump — not by default.
What’s the difference between a pillar page and a cluster page?
The pillar targets the broad head term, summarises every subtopic without exhausting any of them, and exists partly to route readers onward. Cluster pages target specific long-tail queries, go deep on one thing, and exist to be the final answer for someone who arrived with that exact question.
| Attribute | Pillar page | Cluster (supporting) page |
|---|---|---|
| Purpose | Cover the whole topic and route readers to depth | Fully answer one specific question |
| Query breadth | Broad head term, higher volume, harder SERP | Narrow long-tail, lower volume, winnable |
| Typical length | Longer, but summary-heavy rather than exhaustive | As long as the question needs, often shorter than the pillar |
| Outbound internal links | Links to every supporting page in the cluster | Links up to the pillar, plus 1-2 relevant siblings |
| Inbound internal links | From navigation, homepage, and every supporting page | From the pillar and any genuinely related sibling |
| External links you’d point at it | Most of them — this is the page worth building authority on | Occasionally, when a supporting page has its own demand |
| Update cadence | Whenever a subtopic is added or removed | When the underlying facts change |
One consequence of that last row is worth stating plainly: because the pillar is where you concentrate external authority, it’s usually the page worth spending link budget on. Supporting pages inherit some of it through the internal links. That’s a much better use of money than pointing links at eight separate long-tail pages, and it’s part of why deciding how many links a site actually needs each month gets easier once the cluster structure exists.
What does a cluster structure actually look like?
Here’s an illustrative example — a hypothetical site selling home EV charger installation, not a real client. The pillar targets the broad topic and seven supporting pages take the subtopics that came out of the grouping exercise.
Pillar: /home-ev-charging/ — “Home EV charging: how it works, what it costs, and what to install”. Covers the whole subject at summary depth and links to all seven children.
Supporting pages: /home-ev-charging/installation-cost/ (what a full install actually costs and what changes the price), /home-ev-charging/3-pin-vs-7kw/ (charging speed compared honestly, including when the slow option is fine), /home-ev-charging/tethered-vs-untethered/ (the cable decision), /home-ev-charging/no-driveway/ (options for flats and on-street parking), /home-ev-charging/solar-integration/ (charging from a domestic array), /home-ev-charging/grants-and-schemes/ (what funding exists and who qualifies), /home-ev-charging/installation-process/ (what happens on the day, survey through certification).
Notice what makes this a cluster rather than a list. Each child answers a question someone genuinely types, none of them overlaps another, the pillar summarises each in a paragraph and links onward, and every child links back. The cost page and the grants page link sideways to each other because a reader on one plausibly wants the other. The solar page doesn’t link to the tethered-vs-untethered page, because nobody making that jump would thank you.
The test for whether you’ve built a real cluster
Delete the pillar page’s links. Can a reader still find every supporting page in under three clicks from the homepage? If not, the internal linking was doing real work and the cluster is genuine. If yes — if every page was already reachable and the pillar changes nothing — you’ve built a table of contents, not a structure.
How do you avoid keyword cannibalization inside a cluster?
Give every page a written scope before you write it, keep primary keywords non-overlapping, and let the pillar mention subtopics without trying to rank for them. When two pages start trading positions for the same query in Search Console, that’s cannibalization, and the fix is nearly always to merge rather than to differentiate harder.
The most common failure is a pillar that got greedy. Someone writes 800 words on cost inside the pillar, then publishes a dedicated cost page, and now the two compete. The pillar should cover cost in two or three sentences and hand off. That restraint feels wrong while you’re writing — you know more, you want to say it — and it’s exactly what makes the structure work.
Watch for these signals: two URLs appearing for the same query on different days, a page whose impressions grew while its clicks fell after a sibling was published, or a page you meant to be primary that Google keeps skipping in favour of an older one. Any of those means the scoping was too loose somewhere.
How do you audit a cluster you’ve already built?
Work through the structure page by page and check the links in both directions, the scope overlaps, and the query data. Most existing “clusters” fail on the same two points: the pillar links down but the children never link up, and two or three children cover the same ground.
- List every page you consider part of the cluster in one document
- Confirm the pillar links to every single one, in body copy rather than only a sidebar
- Confirm every supporting page links back up to the pillar within the first half of the page
- Write the one-line scope for each page as it exists now, not as intended
- Flag any two scopes that overlap by more than about a quarter — merge candidates
- Export queries per URL and check for two pages ranking for the same term
- Check crawl depth: no supporting page should sit more than three clicks from the homepage
- Identify the obvious gaps — subtopics the SERP suggests exist and you haven’t covered
- Decide where external links should point — usually the pillar, occasionally a high-demand child
Expect the audit to produce merges as often as it produces new page ideas. A cluster of six well-scoped pages beats a cluster of fourteen with overlapping middles, every time. If you’d rather not do this page-by-page yourself, mapping and rebuilding cluster structures is part of what our content structure and optimization work covers.
Key takeaways
- A cluster is a pillar plus scoped supporting pages joined by links in both directions — not one long post.
- It works through topical depth, shorter internal link paths, and enforced non-overlap between pages.
- Plan it from grouped queries, and write a one-line scope per page before writing a word of copy.
- The pillar summarises and routes; supporting pages go deep and hand authority back upward.
- Cannibalization inside a cluster usually means a greedy pillar — cover subtopics briefly and hand off.
- Concentrate external links on the pillar and let internal links distribute to the children.
How many supporting pages does a cluster need?
However many genuine subtopics exist — commonly five to twelve. Padding a cluster to hit a number produces thin pages that dilute the structure. If you can only find four real questions, build four pages and add more when the topic gives you reason to.
Does a pillar page have to be long?
Not for its own sake. It has to cover every subtopic at summary depth, which usually lands somewhere between 1,500 and 3,000 words, but a 4,000-word pillar that exhausts each subtopic is actively harmful — it leaves the supporting pages nothing to rank for.
Should the pillar live in the blog or the main site?
Wherever the intent points. Commercial head terms usually belong in the service or category section where conversion paths exist; informational head terms belong in the blog. Putting a commercial pillar in /blog/ is a common reason a well-built cluster underperforms on revenue.
Can a page belong to two clusters?
Yes, and it’s normal at the edges — a pricing page might sit under two product topics. Keep one cluster as the primary owner so the page has a clear home, and treat the second relationship as a sibling link rather than a second parent. Checking which pages are actually attracting external links often reveals which cluster a shared page really belongs to.