Topic Clusters in SEO: The Pillar-and-Spoke Model

"Topic clusters" describes a specific way of organizing content: one broad pillar page that surveys a subject, and a set of narrower spoke pages that each answer one sub-question in depth, all tied together by a deliberate pattern of internal links. It is not a synonym for having a lot of pages about the same thing, and it is not achieved by dropping posts into the same folder or tag.

The model exists to solve two problems at once: it gives search engines, and readers, a legible map of how thorough your coverage of a subject actually is, and it stops your own pages from fighting each other for the same query. This is about the model itself: how a pillar and its spokes are supposed to relate to one another, how to decide where the pillar ends and a spoke begins, how the linking has to work for any of it to matter, and how to tell when it's actually functioning versus when it has quietly become a pile of loosely related articles that happen to share a tag.

The Model: One Pillar, Many Spokes

A pillar page covers a subject at survey depth. It defines terms, outlines the moving parts, and gives a reader who knows nothing a working understanding of the whole area, without trying to be the definitive answer to every sub-question inside it. A spoke page does the opposite: it picks one sub-question the pillar only mentioned in passing and answers it completely, with the kind of specificity a survey page can't afford without becoming unreadable.

Take email marketing as a pillar subject. The pillar page explains what email marketing is, the major moving pieces such as list building, segmentation, automation, deliverability, and testing, and how they fit together, a few paragraphs per piece, not a full treatment. The spokes are where the full treatment happens: one page on deliverability specifically, one on segmentation logic, one on automation workflows, one on subject-line testing. Someone who wants a complete answer to why their emails are landing in spam should land on the deliverability spoke, not scroll through a pillar that mentions deliverability in one paragraph.

• Pillar: broad coverage, shallow per sub-topic, built to be an entry point
• Spoke: narrow coverage, deep on one sub-question, built to be a destination
• Together they cover a subject the way a table of contents plus its chapters cover a book

Why the Model Works

The mechanism has three separate effects, and it's worth naming them separately because people usually only remember one.

First, it makes your coverage of a subject legible. A search engine, and a human skimming your site, can mostly only tell how thoroughly you've covered a topic by looking at what's connected to what. Twelve unrelated articles that happen to mention email marketing somewhere in the text don't read as authority on email marketing. Twelve pages explicitly linked from and to a shared pillar do: the link structure itself is the signal that says this is one coherent body of coverage, not twelve unrelated hits.

Second, it concentrates internal links instead of scattering them. Every spoke sends at least one contextual link up to the pillar, and the pillar sends a link down to every spoke. That means the pillar page, which is usually competing for the broadest and hardest term, accumulates internal link signal from every spoke under it, while each spoke gets a link from an established page instead of starting from zero. Compare that to a site where each article links wherever the writer happened to think of at the time: the link equity stays diffuse, and no page benefits consistently from the others.

Third, and this is the one people underrate, it stops your own pages from competing with each other. If email deliverability is loosely covered inside a general email marketing article and also has its own separate post with no relationship to the first, a search engine now has two or three pages on your own site it could plausibly rank for the same query, and it has to guess which one you actually want ranked. A cluster forces the decision up front: the pillar owns the broad term, each spoke owns one specific sub-query, and nothing else on the site is meant to compete for those same queries.

Choosing a Pillar Subject That Can Actually Sustain Spokes

Not every topic deserves a pillar. Before building one, try to list every sub-question a genuinely curious reader would ask next, without repeating yourself and without inventing a question nobody actually has. If you land on three or four, you don't have a pillar subject, you have one good article that would be diluted by splitting it. If you land on eight, ten, or fifteen distinct sub-questions, each of which could stand as its own page without cannibalizing the others, the subject is broad enough to sustain a real cluster.

A useful gut check: does each candidate spoke answer a question someone would type into a search box on its own, separate from the pillar term? How does email segmentation work is a real, independent search. What is email marketing, part two, is not; it's just the pillar article cut in half. The second kind of split doesn't make a cluster, it makes two thin pages competing with each other, which is the exact failure the model is supposed to prevent.

It also helps to check the other direction: is the pillar subject itself actually a subject, or is it already a sub-question of something bigger? Email deliverability is too narrow to be a pillar; it's a spoke of email marketing, or arguably a spoke of email deliverability and inbox placement if you wanted to go one level deeper, but on its own it doesn't have enough genuinely distinct sub-questions under it to need its own set of spokes. Pillars sit at the level where a newcomer needs orientation before they need depth; spokes sit at the level where someone already knows what they're asking about.

Splitting a Subject Without Inventing Distinctions

The most common way a cluster goes wrong isn't too few spokes, it's too many, because someone treated near-duplicate phrasings as separate sub-questions to hit a content quota. Email segmentation and how to segment your email list are the same spoke wearing two hats, not two spokes. If two candidate pages would answer the same question for the same reader, merge them; splitting them only means each one has half the depth, and they will likely end up cannibalizing each other anyway.

The test that actually works is asking whether a different reader, in a different situation, is the one asking each question. Someone asking about deliverability is worried about getting into the inbox at all. Someone asking about segmentation is worried about relevance once they're already there. Someone asking about automation is thinking about sequencing and timing, not content or inbox placement. Those are three different problems with three different bodies of practical advice, even though all three sit under email marketing. That's a real split. Email marketing tips versus email marketing best practices is not a real split; it's the same reader asking the same question two ways, and it belongs on one page.

When in doubt, write the spoke's one-sentence job description before you write the page: this page exists to answer this question for a reader who is trying to do this. If two spokes end up with the same job description, you don't have two spokes, you have one spoke and a duplicate.

The Interlinking Discipline That Actually Makes It a Cluster

Everything above is just planning. The cluster doesn't exist until the links do, and the links have to follow a specific pattern, not a loose one.

• Every spoke links up to the pillar at least once in the body of the page, not only in a breadcrumb or a related-posts widget at the bottom. A contextual link, where the pillar is mentioned naturally inside a sentence, carries more relevance signal than one buried in a navigation element.
• The pillar links down to every spoke. Usually this means a structured section, something like what's covered in this guide, with a link to each spoke, plus additional contextual links wherever the pillar's own text touches on a spoke's subject.
• Siblings link across to each other, but only where the connection is genuine. The deliverability spoke can reasonably link to the segmentation spoke if a sentence about list hygiene naturally leads there. It should not link to the subject-line testing spoke just because both happen to be spokes of the same pillar; that's a link for the sake of a link, and it dilutes the pattern instead of reinforcing it.
• Anchor text should vary and describe the destination rather than repeat the exact keyword every time. Linking to the deliverability spoke as more on deliverability, why emails land in spam, and inbox placement basics across different mentions reads naturally and still tells a reader, and a crawler, what the linked page is about.

Cannibalization: What the Model Is Actually Defending Against

Cannibalization is what happens when two or more pages on the same site are effectively trying to rank for the same query, so a search engine has to pick one, and often alternates between them or ranks both weakly instead of either one strongly. A cluster is designed to prevent this by giving every page, pillar and each spoke, one clearly assigned query it owns, but the design doesn't enforce itself. It still happens, usually in one of two ways.

The first is definitional drift: the deliverability spoke was written to own why do my emails go to spam, but over time, edits to the pillar page added a full paragraph answering that same question in detail, because the pillar felt incomplete without it. Now two pages on the site are both trying to answer it.

The second is scope creep in a new spoke: a new page gets added for an email deliverability checklist, which sounds distinct from the existing deliverability spoke but is actually answering the identical question under a different title.

To catch it, the practical check is to look at which pages are getting impressions for the same query in your search console data, or, with no analytics access at all, to reread the pillar and each spoke and ask, for every paragraph, which single page is supposed to own this. If the honest answer is either one, doesn't matter, that's cannibalization, whether or not it's currently costing you rankings. The fix is almost always to cut, not to add: trim the pillar's paragraph down to a summary and a link, or merge two near-identical spokes into one and redirect the loser.

How Deep to Go Before Starting the Next Cluster

There's a temptation to start a second pillar as soon as the first has three or four spokes, because breadth across subjects feels like more progress than depth on one. It's usually the wrong call. A half-built cluster, a pillar with three spokes when the subject genuinely supports ten, gives a search engine a thin, unfinished picture of your coverage, and it gives a reader who's clearly interested in the subject nowhere to go after the third page.

The signal that a cluster is actually finished, rather than abandoned early, is that new spoke ideas start failing the tests from earlier: the candidate sub-question turns out to be a rephrasing of one you already have, or it's too narrow to sustain a real page on its own, or nobody arriving from a search would actually be asking it that way. That's diminishing returns, and it's the point where starting the next pillar becomes the better use of time, not a fixed spoke count, and not a calendar deadline.

In practice this means resisting the urge to spread thin. One thoroughly interlinked cluster of ten pages, each answering a real question nothing else on the site answers, does more for a subject than three clusters of three pages each, all of which look started rather than finished.

The Caveat: Folders Don't Make a Cluster, Links Do

It's worth stating plainly, because it's the mistake that undoes everything above: nesting pages under a tidy URL path, something like /guides/email-marketing/deliverability and /guides/email-marketing/segmentation, does not create a topic cluster by itself. URL structure is a convenience for humans reading a sitemap or a site owner reasoning about their own content; it is not what tells a search engine these pages form a coherent body of coverage on a subject.

What creates the cluster is the actual link graph: the pillar linking down, the spokes linking up, the relevant siblings linking across. A pillar and ten spokes scattered across completely unrelated URL paths, but genuinely interlinked in the pattern described above, function as a real cluster. Ten pages under a beautifully organized folder, published with no links connecting them to each other, are just ten separate pages that happen to share a path prefix, no more connected, as far as a crawler or a reader is concerned, than if they lived in ten different folders.

Keep the tidy URLs if they help you manage the site. Just don't mistake them for the thing that's actually doing the work.