Google announced Hummingbird in September 2013 at its fifteenth-anniversary event, and described it as a rewrite of the ranking engine built to understand what a query means rather than which words it contains. That is the moment the ground shifted under keyword-by-keyword content strategy. Four years later, in 2017, HubSpot published its topic cluster model and rebuilt its own blog architecture around pillar pages and supporting content, arguing that dense internal linking around a single subject was a stronger signal than a pile of unconnected posts.
Nine years on, most company blogs still operate as if neither happened. Forty posts, each chasing a separate keyword, none linking to each other, none making a coherent argument about anything. The site has content. It has no structure. And structure is what a search engine reads when it decides whether you are a source on a subject or a place where words happen to appear.
Here is how to build a topic cluster that produces rankings and citations rather than a content archive nobody visits.
A topic cluster is an argument, not a folder
The common misreading is that a topic cluster is a category. Make a folder called “email marketing,” put twelve posts in it, done. That is filing, not architecture, and it produces nothing.
A cluster is a set of pages that together make one complete argument about a subject, connected by links that reflect how the ideas depend on each other. The pillar page states the whole argument. Each supporting page takes one piece of it and goes deep enough to be the best answer on the internet for that narrow question. The links are the reasoning made visible.
Two things follow from that definition. The first is that a cluster is scoped by question, not by keyword volume. You are not assembling pages around search terms that happen to share a word. You are covering the full set of questions a person works through while solving one problem, in the order they hit them.
The second is that redundancy kills clusters. If three of your pages answer roughly the same question, you have split the signal three ways and given a crawler no clean choice about which one to surface. This is the most common defect I find when auditing a site: not thin content, but overlapping content, where four posts argue the same point with different titles.
There is a newer reason the structure matters, and it has nothing to do with rankings. AI answer engines assemble responses by retrieving passages from multiple sources and checking whether they agree. A site that covers one subject across several pages that reinforce each other reads as a consistent source. A site with one shallow post on the subject reads as a mention. When a model has to choose which source to name, internal coherence across your pages is one of the few things you control, and it is the thing most competitors have not bothered to build.
Before you build a topic cluster, do the ugly inventory. List every page you have on the subject. Write down the one question each page answers, in your own words, without looking at the title. Where two pages give the same answer, one of them dies or they merge. That exercise alone will improve a mature blog more than the next six posts.
Start with the Answer Spine, not the keyword list
Most cluster tutorials start in a keyword tool. Start in a conversation instead.
The Answer Spine is the ordered sequence of questions a real buyer moves through, from the moment they recognize the problem to the moment they choose a solution. Write it before you open any software. Six to ten questions, in order, phrased the way a person would say them out loud.
For a company selling inventory software to independent retailers, the spine might run: why is my stock count always wrong, what does bad inventory data cost me, do I need software or better process, what does inventory software cost, how do I choose between the options, how long does implementation take, how do I get my team to use it. That sequence is the skeleton of the cluster. Each question is a page.
Now bring in the keyword data, and use it for one job: naming. Search volume tells you which phrasing of a question people use, which is a wording decision, not a strategy decision. It should never generate the question set, because keyword tools show you what has been searched, not what your buyer is confused about. The most valuable questions in a category are often the ones with modest volume and heavy purchase intent.
The Answer Spine also tells you when to stop. A cluster is finished when every question on the spine has a page and no page has to reach for a reason to exist. Sites that keep publishing past that point start manufacturing questions nobody asks, which is how you end up with three hundred posts and forty that matter.
Validate the spine against real conversations before you commit to it. Three sources beat any tool here. Sales call recordings, where you can hear the question a prospect asks right before they stall. Support tickets, which show you the questions people ask after they buy, and those often turn out to be the questions they should have asked before. And the sales team itself, who can tell you in five minutes which four questions come up on every single call. If a question shows up in all three sources and has no page, that is your next piece of work, whatever the keyword tool says about it.
One more benefit. Because the spine is ordered, the internal linking design writes itself. Page three links forward to page four, because that is where the reader goes next.
The Five-Page Minimum
Below five pages, a cluster is not a cluster. It is two posts and a hyperlink.
The Five-Page Minimum is one pillar plus four supporting pages, and the reason for the floor is mechanical. Internal linking only becomes a signal when there is enough of it to describe a shape. One pillar with two children looks like a page with two links. One pillar with four children, each linking back, several linking laterally, produces a recognizable topical structure with a clear center.
The pillar page carries the broad question and has to stand on its own as an answer. This is where sites fail most often. They build a pillar that is a table of contents, six paragraphs of throat-clearing wrapped around links to the real content. That page ranks for nothing and gives a reader no reason to stay on it. Write the pillar as if it were the only page: answer the broad question in full, then point to depth where a reader would want more.
The supporting pages each own one question from the spine, and each one has to be able to rank on its own. If a page could not survive as a standalone article that someone links to from a forum, it is a section of another page pretending to be a URL.
Depth beats breadth at this stage. Five pages that are the best available answer to their question outperform fifteen pages that are adequate. This is more true now than it was five years ago, because AI answer engines retrieve passages rather than pages, and an adequate page contains no passage worth lifting.
When you build a topic cluster this way, you can extend it later without restructuring. Add page six when a new question appears on the spine. The architecture holds.
How do you wire the internal links?
Four rules, and they are not negotiable if you want the structure to read as a structure.
Every supporting page links to the pillar, using anchor text that describes the pillar’s subject rather than “click here” or the bare page title. The anchor text is a label you are attaching to the destination, so make it the label you want.
The pillar links to every supporting page, in the order of the Answer Spine, in the body of the page rather than in a sidebar widget. Links inside prose carry context that a menu or a sidebar module does not.
Supporting pages link to each other where the relationship is real. Page four links to page five because someone finishing the cost question needs the comparison question next. Do not force links to complete a diagram. A link nobody would click is a link that describes nothing.
Nothing in the cluster links out to unrelated pages on your site from inside the argument. Save the cross-sell for the end of the page. Links in the body should keep a reader inside the subject, because that is what the structure is meant to communicate.
A note on anchor text, because this is where careful people overcorrect. Vary the phrasing across links to the same destination. If eleven pages all link to the pillar with the identical five-word anchor, the pattern looks manufactured, which it is. Describe the destination the way the sentence needs it described, and let the phrasing shift. The point of anchor text is to tell a reader what they will get if they click. A link that reads well in the sentence it lives in is doing the job for both audiences at once.
There is a fifth practice that sits outside the four rules and matters more than any of them: keep the cluster crawlable and unambiguous. Clean URLs that reflect the hierarchy, a real HTML page rather than content assembled by script after load, structured markup that identifies the page type and its author, and headings that state the question the section answers. When an AI system retrieves from your site, it is looking for a passage that answers a question cleanly. A section headed with the question, answered in the first two sentences beneath it, is the easiest thing in the world for it to lift.
Where clusters break, and how to spot it early
The first failure is the orphan pillar. You publish the pillar, plan the supporting pages, and then priorities change. Six months later you have a lonely 2,400-word page linking to nothing. Publish the pillar last if you have to, or publish it with two supporting pages already live.
The second failure is cannibalization, which arrives when a supporting page starts outranking the pillar for the pillar’s own query. This means your pillar is weaker than its child, and the fix is to strengthen the pillar rather than weaken the page that is winning. Check this every quarter in your search console data.
The third failure is abandonment. A cluster is a living structure, and the questions on the spine change as the category changes. A cluster written in 2024 about a subject touched by AI is now describing a world that moved. Set a review date on every pillar and treat the refresh as part of the build, not as maintenance.
The fourth failure is the one nobody catches until it is expensive: building a cluster on a subject where you have no credibility. A structurally perfect cluster about a topic your company has no business commenting on will lose to a messy blog written by someone with real standing. Structure amplifies expertise. It does not manufacture it.
A fifth failure worth naming: treating the cluster as a marketing artifact instead of a company one. If the sales team has never read the pillar, if the product team disagrees with what it says, if nobody sends a cluster page to a prospect, you have built content that lives in isolation from the business. The strongest clusters I have seen get used internally before they get read externally. That usage is also the fastest quality check available, because a salesperson will tell you within a week which page is wrong.
Watch three signals in the first ninety days. Whether the pillar starts collecting impressions for the broad question, whether the supporting pages pick up long-tail queries you did not target, and whether your pages start appearing in AI-generated answers for questions on the spine.
That third signal is the one to build for, because the search that used to end on your page now ends in a summary that either names you or does not, and the sites that build a topic cluster with real structure are the ones getting named.