A topic cluster is a set of pages about one subject, joined by links that follow the questions a reader actually asks next. One pillar page covers the subject broadly. Each cluster page covers a narrower question and points back. The point of the structure is a clear site architecture, not a pile of posts that happen to share a tag.
Build one pillar page for the broad subject. Give every supporting question its own cluster page only when that question has a different search intent. Link each cluster page to the pillar with anchor text that describes the destination. Link sibling pages only when the reader needs them. Do not publish two URLs that answer the same query.
What is a topic cluster?
Search engines and answer engines do not rank a website as a single blob of “expertise.” They retrieve pages. A topic cluster is how you make those pages legible as a set. The pillar is the overview. The cluster pages are the specific answers: a how-to, a comparison, a template, a definition, a troubleshooting note. Together they are cluster content. Apart, they are just posts.
HubSpot popularized this hub-and-spoke model, and Semrush’s pillar-page guide still describes the same shape: a broad page, deeper pages, and links in both directions. Those guides are useful as a definition. They are weaker as an operating method. HubSpot’s older research treated more internal links as the thing that moved impressions. That is not a rule you can copy in 2026. Google’s documentation on links says crawlable links help Google discover pages and understand what they are about. It does not say that repeating one anchor, or linking every page to every other page, improves rankings.
A topic cluster SEO plan starts from questions, not from a keyword list dumped into URLs. The primary query for the pillar might be “product team rituals.” A cluster page might target “how to run an async standup.” Those are different jobs. Publishing both is cluster content. Publishing “async standup guide” and “how to run an async standup” as two URLs is duplication.
What a pillar page is responsible for
A pillar page strategy gives the broad page four jobs:
- Answer the broad query. A person who searches the head term should leave with a working overview, not a table of links and a promise that the real answer is elsewhere.
- Name the subtopics. The overview should show the parts of the subject, in language a newcomer can follow.
- Link to the cluster pages that exist. Link the ones you have published. Do not link drafts, and do not invent URLs.
- Stay the overview. When a section starts to need its own examples, steps, and objections, that section is a cluster page, not another thousand words on the pillar.
The pillar is not a category page with a thin introduction. It is also not the place to paste every cluster article in full. Readers who want the overview should get it. Readers who want the procedure should land on the procedure. That split is what makes the content hub understandable to a person who arrives from search, and to a system that is trying to quote one passage.
Put the pillar where it can be crawled. Google’s own notes on pillar-style hubs, echoed in publisher docs such as HubSpot’s, warn against hiding the body behind a form. The same idea applies here. If the only copy on the URL is a signup wall, you do not have a pillar page. You have a gate.
Topic cluster versus a content silo
A content silo is a folder habit. Everything about billing lives under /billing/, and the parent template links down to children. Children link up to the parent. Siblings often never mention each other. The URL tree is tidy. The reading path is not.
A topic cluster does not require a shared folder. The pillar can live at /product-team-rituals and a cluster page at /async-standups. What matters is the link, because the link is what a person clicks and what a crawler can follow. Crawlable links are ordinary HTML anchors with a real href. A button that only runs JavaScript, or a link stuffed into an image without text, is a weaker path. A breadcrumb can show Home, then the section, then the article. That row is the “you are here” path. It does not replace the links in the paragraph.
| Question | Content silo | Topic cluster |
|---|---|---|
| What is the parent? | Often a category or index with little of its own teaching | A pillar page that answers the broad query |
| How are URLs grouped? | By folder | By subject, regardless of folder |
| Do sibling pages link? | Usually no | When the next question is real |
| What does the anchor say? | Often “read more” or the file name | A description of the destination page |
| What goes wrong | People cannot move sideways to the page that finishes the thought | Too many sibling links, or two pages chasing one query |
How to build a topic cluster
Work in this order. Skipping to “write eight posts” is how sites end up with overlapping URLs and no overview.
1. Name the subject in the reader’s words
Write the broad query the way someone would type or speak it. “Product team rituals” is a subject. “Synergistic operational cadence” is not a query. If you cannot imagine a person searching it, it is not a pillar yet. It might be a slide title.
2. List the distinct jobs, not the synonyms
Collect questions from your own support inbox, sales calls, the “people also ask” boxes, and the headings of pages that already rank. Group them by the job: learn the idea, follow steps, compare two options, copy a template, fix a failure. Synonyms of the same job belong on one URL. Different jobs can become cluster pages.
3. Check what you already published
Open your sitemap before you open a blank document. If a URL already answers the question, improve that URL. A second page will compete with it. Labeling every URL keep, update, merge, or leave is the SEO content audit, and it belongs at the start, not after both pages have been indexed. The SEO content brief has a field for the closest existing URL when you do draft something new.
4. Decide the pillar from the pages you will actually link
A pillar that links to three future ideas and no live pages is an outline. Publish the pillar when at least a few cluster pages exist, or publish the pillar with a short overview and add links as the cluster pages go live. Do not leave a block of empty anchors.
5. Write each cluster page from a brief
Each cluster page needs its own search intent, its own outline, and its own sources. The pillar’s outline is not a brief for the cluster page. The cluster page will be the thing an answer engine quotes, because it is the specific answer. The content brief template is the handoff, whether a person writes the draft or a model does.
6. Add the links in both directions, then stop
From the pillar, link the cluster page at the moment you mention that subtopic. From the cluster page, link the pillar once, near the place where a reader might want the wider map. Add a sibling link only for the next question. Then stop. A page with forty internal links in the last paragraph is not a cluster. It is a directory.
A topic cluster example
Take a small company that sells software for product teams. The subject they can honestly cover is how those teams run the week. The pillar query is broad: product team rituals. The pillar page explains what a ritual is, which meetings are worth keeping, and how the pieces fit. It does not include a full standup script, a full retro agenda, and a full Scrum-versus-Kanban essay. Those are cluster pages.
- How to run an async standup. Intent: do the task. The page is a procedure.
- Sprint retro questions. Intent: copy a resource. The page is a template with notes on when each question fails.
- Scrum vs Kanban for a six-person team. Intent: choose. The page compares the two for one team size, not for every company on earth.
- Why status meetings run long. Intent: understand a problem. The page explains causes. It does not pretend to be the standup procedure.
Notice what is not a separate page: “async standup best practices,” “async standup guide,” and “asynchronous daily standup tips.” Those are the same intent as the procedure. One strong page beats three thin ones. Also notice the comparison is narrowed to six people. “Scrum vs Kanban” with no situation is a different, harder query, and a vague page will not be the one worth citing.
This is the same shape BloGoose uses when it proposes pillar topics from a site you already have, then builds a calendar around them. The product did not invent the model. The work is choosing pillars that match the site, instead of importing a generic list. The automated SEO pipeline is the production version of steps 3 through 6: read the sitemap, refuse duplicate topics, draft the page, and link only URLs that exist.
One search intent per URL
Search intent is the job behind the query: learn, do, compare, buy, or find a specific site. Two queries can share words and still be different jobs. “Async standup” might be someone wanting a definition. “Async standup template” is someone wanting the agenda. If the results for those queries look different, one page that tries to be both a glossary and a template will satisfy neither.
Before you add a cluster page, search the query and write down the format of the results. If the page that ranks is a template, your cluster page should be a template with original commentary, not a 2,000-word essay that hides the template at the bottom. If the results are comparisons, write a comparison with a situation, a criterion, and a recommendation. Matching the format is not copying the pages. It is answering in the shape the question requires.
Topical authority, as a phrase, gets used as if it were a score you can buy. What you can actually build is coverage: the important questions in the subject have a page, the pages do not contradict each other, and a person can move between them. That is site architecture. It shows up over time as more of your URLs earning their own queries in Search Console. It does not show up as a badge.
Pillar page internal links
Internal links do three practical things. They help people continue. They help crawlers find the next URL. They tell both what the destination is about, through the anchor and the sentence around it. Google’s starter guidance on internal links is the same idea: link to your own relevant pages, and use anchor text that helps someone decide to click.
Use these rules:
- Describe the destination. “How to run an async standup” is an anchor. “Click here” is not. “Topic cluster” is fine when the destination is this kind of guide. It is a poor anchor when the destination is a pricing page.
- Vary the wording. The pillar can say “the standup procedure.” A related page can say “how we run async standups.” Both can point at the same URL. You do not need one frozen phrase on every page. Older cluster guides that insist on identical anchors are optimizing for a crawler from 2016.
- Put the link where the subtopic is explained. A list of twelve links after the conclusion is easy to crawl and easy to ignore. A link in the paragraph that raised the question gets used.
- Link up once. The cluster page should point at the pillar. Pointing at it five times in one article does not make the pillar “stronger.” It makes the article noisy.
- Do not link what you do not have. A planned URL that 404s wastes the crawl and the click. Wait until the page is live.
Supporting cluster pages should also link out to primary sources when they state a rule. A page that only links to itself looks closed. A page that cites Google’s helpful-content guidance when it talks about who the page is for is easier to trust, including for systems that prefer sources they can check.
How cluster content shows up in answer engines
Answer engines retrieve passages and then compose an answer. They are more likely to quote a page that states one claim cleanly than a page that covers twelve topics in the hope of matching a broad query. That is why the cluster page, not the pillar, is often the page that gets cited. The pillar still matters. It is the map, and the links tell a retrieval system which specific page belongs to the subject.
Write the cluster page so a passage can stand alone. Open the section with the answer, then explain it, then give the example. Use a table when you are comparing. Use a list when the reader is following steps. Name the entities in full the first time: “a topic cluster,” not “this model,” if the previous heading is three scrolls away. Those habits are the same ones in the answer engine optimization guide. The cluster is the information architecture. The passage is what gets quoted.
Do not add a block of hidden keywords, a fake “authority score,” or a statistic you cannot source. Generative engines repeat specific numbers. An invented percentage becomes a citation you do not want. If you do not have a measurement from your own site, say what to measure instead of borrowing someone else’s lift.
What to measure after you publish
Judge the cluster by URLs, not by a single sitewide chart.
- Index coverage. Is each new URL indexed, or is it excluded as a duplicate or as crawled-but-not-indexed? A cluster page that is not indexed is not helping the pillar.
- Queries per URL. In Search Console, the pillar and a cluster page should not both depend on the same query. If they do, one of them is in the wrong job. Merge or retitle.
- The links you intended. Crawl the pillar and confirm the cluster URLs are real HTML links, not buttons that go nowhere.
- Whether people continue. If the pillar’s links are not clicked, the anchor is vague or the link is in the wrong place. That is a writing problem, not a “domain authority” problem.
Give it time. A new cluster does not rearrange a competitive head term in a week. What you should see sooner is the specific cluster pages picking up their long-tail queries, because those queries had a page written for them.
How BloGoose plans the cluster from your site
BloGoose reads the site and the sitemap first, then proposes a few pillar topics you can edit. The calendar is built around those pillars, with a search intent on each title, so two articles are less likely to chase one query. When a draft is written, internal links are taken from URLs that already exist. That is the practical version of the rules on this page: one subject, distinct jobs, no invented links.
If you want the production path, read how the pipeline turns a pillar into a month of articles. If you want the page-level handoff, use the SEO content brief before the draft starts. If you want the passage itself to be easy to cite, use the AEO guide on answer-first sections.
Plan the cluster from the site you already have
Connect a site, confirm the pillar topics, and let the calendar follow them. You can review every draft before it publishes.
Start the 1-day trialQuestions about topic clusters
What is a topic cluster?
A topic cluster is a group of pages about one subject. One pillar page covers the subject broadly. Each cluster page covers a narrower question. Internal links connect the cluster pages back to the pillar, and connect related cluster pages when a reader would actually follow that link.
What is a pillar page?
A pillar page is the broad page at the center of a topic cluster. It explains the subject, answers the main query, and links to cluster pages that go deeper. It is a real article or guide, not a category folder.
How is a topic cluster different from a content silo?
A content silo organizes URLs in a parent-and-child tree, and sibling pages often do not link to each other. A topic cluster is a reading path: the pillar and the cluster pages link according to the next question a person has, even when the URLs do not share a folder.
How many cluster pages should one pillar have?
Start with the distinct questions people ask, not a quota. Many useful clusters have between four and twelve cluster pages. Add a page only when it has its own search intent and does not repeat a URL you already have.
Should every cluster page use the same anchor text?
No. Anchor text should describe the page it points to, in the words of the sentence around it. Repeating one exact phrase on every page is unnecessary, and it reads as if the links were placed for a crawler rather than a person.
Do topic clusters help pages get cited in AI answers?
They can, because each cluster page is an extractable answer to one question, and the links tell both people and machines which page is the overview. A cluster does not guarantee a citation. The page still has to be accurate, specific, and worth quoting.