Topic Clusters: What They Are and How to Build One (2026)

• A topic cluster is a pillar page plus supporting pages that each answer one narrower question on the same subject.
• The pillar, the supporting pages, and the links between them are the whole model. Drop the links and you have a list of posts.
• Give each search intent one page. Two pages that answer the same question compete with each other.
• Put links in the body, inside a sentence about the other page. A sidebar or a related-posts card does not replace that link.
• Build one by auditing what you have, picking a pillar you can cover, mapping one page per intent, linking on publish day, and measuring the group in Search Console.
• Search engines and AI assistants can only use pages they can retrieve. A linked cluster gives them a connected set of answers.
• This page defines the model. The 90-day sprint guide owns the week-by-week plan for the supporting articles.

A topic cluster is a content model, not a folder in your CMS. Three parts make it work: a pillar page, supporting pages, and the internal links between them. Leave one out and you have a list of posts, not a cluster.

Pillar page

The pillar page covers the whole topic at overview depth. It names the subject, answers the broad question, and links to every supporting page from the body. It does not try to be the final word on every subtopic. When a subtopic needs its own search, it needs its own page, and the pillar points there.

Supporting pages

A supporting page answers one narrower question. A reader who searched that question should get the answer on that page, without reading the pillar first. The page links back to the pillar, because the pillar is the overview of the subject that question belongs to. Where two supporting pages genuinely relate, they link to each other in the sentence where that relationship comes up.

Internal links

Internal links are how the three parts become one cluster. A link inside a paragraph, surrounded by sentences about the other page, tells a reader and a crawler why the two pages belong together. A related-posts card, a sidebar, or a footer list does not do that job. Keep those if you want them. They do not replace the link in the body.

Search engines have to tell which page on your site answers which part of a subject. A cluster does that on purpose: the pillar covers the whole topic, each supporting page covers one question, and the links say which is which.

A calendar of unrelated posts does not. Each post may be fine on its own. Nothing on the site connects the posts into one subject.

How do clusters prevent keyword cannibalization?

Keyword cannibalization is what happens when two pages on your site target the same search intent. You force the search engine to guess which URL is the answer. A cluster avoids that by giving each intent one URL. The pillar owns the broad query. Each supporting page owns one narrower query. If a draft would answer the same question as a page you already have, merge it into that page or aim it at a different question. Do not publish both.

How do AI answers pull from clusters?

An AI assistant can cite a page only if it can retrieve that page. Retrieval starts with indexing. A page that is not in the index cannot be quoted. Once a page is indexed, the assistant lifts a passage that answers the question in front of it.

A cluster helps in two plain ways. Each supporting page is written to answer one question, so a passage on that page can stand alone. The links mark which page is the overview and which pages answer the narrower questions. Unlinked posts do not provide that map. Stating the answer in the first sentences under a heading makes the passage easier to lift. None of this guarantees a citation. It makes the page usable if an assistant retrieves it.

Build it in five steps: audit what you already have, pick a pillar you can cover, map one page per intent, link in the body on the day you publish, and measure the group in Search Console. For the week-by-week plan that produces the supporting articles, use how to create long-tail content clusters. This page stays on the model so the two URLs do not split one intent.

Step 1: Audit what you have

List every URL you already have on the subject. Tag each one with the question it answers. Look for three things: a question with no page, a page with no in-body links, and two pages answering the same question.

Do this before you write anything new. More URLs do not make a cluster. The topical authority audit is the checklist for that inventory.

Step 2: Pick a pillar you can win

Pick a subject you can cover completely, and a subject a buyer of your product actually asks about. A broad head term you cannot surround with real supporting pages is a weak pillar. A narrower subject you can finish is a strong one.

Search the pillar query before you commit. Read the top results. If they are thin and do not link out to subtopics, you have room. If they already cover the subject in depth, narrow the pillar. A topic that never connects to what you sell will bring visits you cannot use, so weigh that alongside demand.

Step 3: Map one page per intent

Open a spreadsheet. One row per question. Keep columns you will actually use: the question, the query a person would type, the intent (learn, compare, or buy), the page that will answer it, and whether that page already exists.

Search the query and look at what ranks. If the results are guides, write a guide. If they are comparisons, write a comparison. Match the format the results already reward, unless you have a clear reason not to.

Then check the rows against each other. Two rows with the same intent become one row. The walkthrough for that sheet is how to create a topical map.

Step 4: Link in the body on publish day

When you publish a supporting page, the body should already link to the pillar, with anchor text that names the pillar's topic. The pillar should already link to the new page, in a sentence about that subtopic, not in a list dumped at the bottom. If a sibling page discusses the same idea, add that link in the sentence where the idea comes up.

Do this on publish day. A cleanup pass you plan for later is how the links never get added. Anchor text and which sideways links are worth adding are covered in internal linking for topical authority.

Step 5: Measure the cluster in Search Console

In Search Console, look at the URLs in the cluster as a group. Read three things: which of those URLs are indexed, which queries the group earns impressions for, and whether the average position of those queries is moving. One URL's ranking is not the cluster's ranking.

If a page is crawled and not indexed, fix links and overlapping intents before you write the next page. A fuller monthly scorecard is in measuring topical authority.

If you want an agent to draft the map, the briefs, and a first pass at the links, that workflow is a content cluster with AI agents. You still pick the pillar, and you still approve every link.

The Topical Authority hub is the pillar for this subject on our site. Each supporting guide owns one question:

• Topical authority vs domain authority: key differences
• How to build topical authority: the 90-day founder sprint
• How to create a topical map: 5 easy steps
• This page: what a topic cluster is and how to build one
• Internal linking for topical authority: the Hub–Spoke–Mesh method
• Measuring topical authority: 5 essential metrics
• Topical authority audit: a 7-step checklist
• B2B topical authority strategy: the authority grid for SaaS founders
• Topical authority for ecommerce: a 5-step system
• Topical authority case studies: 5 real examples
• Topical authority service: what to expect
• Topical relevance in link building: a proven guide

In February 2026 I published a 13-article cluster on this site. Five months later, Google had indexed none of those 13 pages. The pages pointed at each other only from a sidebar. Two of the pages split one search intent. So now each guide links in the body and owns one intent.

These failures break the model. They are structural. Clearer sentences on the same broken structure do not fix them.

• Links only in a sidebar or a related-posts widget. The body never mentions the other pages, so the cluster exists in the template and not in the content.
• Two pages for one intent. You split one question across two URLs. Merge them, or point one of them at a different question.
• A pillar that answers every subtopic in full. The supporting pages then have nothing distinct to cover. The pillar should give the overview and link out.
• Supporting pages with no link back to the pillar. Each one is on its own, even if it sits in the same category.
• Measuring pages one by one. You watch a single URL and miss that the rest of the cluster was never indexed.
• Repeating another page's query. On this site, the sprint guide owns the plan for the supporting articles. This page owns what a cluster is. Link to the other page instead of writing it again.