Pillar pages and topic clusters: how to architect a content hub

Most B2B content programs publish more posts and wonder why rankings stay flat. Fifty blog posts, each chasing a different keyword, give search and AI answer engines no reason to treat your site as an authority on anything, and the architecture that fixes it is the step most teams skip.

A pillar page is an ungated hub that covers the core questions around a broad topic and links out to deeper articles on its subtopics. A Content Cluster is that pillar plus its supporting spokes, tied together with dense internal links.

Organize the two well and Google and answer engines like ChatGPT and Perplexity can connect the subject to your site. We run this structure by hand for the B2B companies we work with, and treating a topic as a managed portfolio of pages beats treating it as a content backlog every time.

Let's pull that thread all the way through, from what these two pieces actually are to why they compound and how you build and measure a hub yourself.

What is a pillar page

The hub in that structure is the pillar page, a resource that covers a broad topic at a high level and links out to more detailed content on each subtopic. It answers the main question a reader has about a subject, then routes them to spoke articles that go deep on the specifics. It stays ungated, with no email wall, no gate, and no interruption between the reader and the answer.

A standard blog post targets one narrow query and lives in a chronological feed. A pillar page targets a whole topic, sits at a permanent URL, and acts as the organizing center for everything you publish about that subject. The line is coverage. The pillar covers the broad topic, and the spokes beneath it target the long-tail queries.

A pillar page also differs from a landing page. A landing page exists to convert against a single offer. A pillar page exists to teach a topic in full and earn trust across search and answer engines. HubSpot's practical test for whether a subject qualifies as a pillar topic is whether it can support 20 to 30 related posts. If you can only think of three, the scope is too narrow to anchor a hub.

A pillar on its own only gets you so far, though. Its real leverage shows up in the cluster you build around it.

How the Content Cluster model works

The Content Cluster model puts one pillar page at the center and surrounds it with spoke articles, each covering a single subtopic in depth. The pillar is the hub. The spokes are individual pages that answer specific questions the pillar raises but doesn't fully resolve. Every spoke connects back to the pillar, and the pillar connects down to every spoke.

HubSpot's Anum Hussain and Cambria Davies documented the topic cluster research in 2015, launched cluster experiments in 2016, and published the formal methodology in 2017. Their finding was direct. The more interlinking they did, the better the placement in search results, and impressions rose with the number of links created.

The interlinking is the mechanism that makes a cluster behave like one, so let's start there.

Bidirectional internal linking

Links flow both directions in a Content Cluster with the pillar linking down to every spoke, and every spoke linking up to the pillar. That passes authority through the structure and tells search engines the pages belong together. Google's links guidance says it uses links to judge the relevance of pages and to find new pages to crawl, and that every page you care about should have a link from at least one other page on your site.

The guidance asks for anchor text that is descriptive, concise, and relevant to both the page it sits on and the page it points to, because that context tells Google what the linked page is about. Descriptive internal anchors between pillar and spoke are what make the topical relationship legible.

Linking does have a ceiling of usefulness at scale. A Zyppy internal-link study of 23 million internal links found that URLs with 40 to 44 internal links received roughly four times the clicks of pages with 0 to 4, but traffic began to decline after about 45 to 50 links. A separate Zyppy anchor-text analysis found a -0.337 correlation between aggressive internal anchor text variation and traffic after recent Google updates. Dense linking works but keyword-stuffed, mechanical linking gets filtered.

But linking is just one half of the model. The other half is discipline about how many URLs you point at a given query.

One URL per subtopic

The model also assigns one URL to each subtopic, which removes the competition the old blog approach creates. Four separate posts targeting the same query compete against each other in the same results. Search Engine Land's keyword cannibalization guide notes that the top two Google positions earn nearly three times the clicks of the third. Splitting your ranking signal across four URLs weakens all four.

When you consolidate that signal into a single authoritative URL per subtopic, search engines have one clear page to rank for the query. They stop having to guess which of your pages to rank, and the ranking volatility and lower click-through that come with cannibalization go away.

So that's the structure, here's why it compounds instead of just sitting there as a tidy diagram.

Why the architecture compounds

Clusters compound because you route related pages through one hub and hand search engines a coherent path across the topic. When every spoke links to the pillar and backlinks accumulate on that hub, engines follow that concentrated path through the cluster, and the whole can rank better than any single page alone. Fifty unconnected posts pass no authority to each other. Fifty organized as pillars and spokes behave like a portfolio. Each new spoke strengthens the hub, and the hub lifts every spoke.

Topical authority

That compounding builds toward topical authority. Ahrefs defines it as when search engines recognize your site as the expert source on a specific subject, not just for individual keywords, but for the full range of related queries within a topic.

Google does not label this. John Mueller has stated plainly that Google doesn't evaluate a site's authority or assign an authority score, and a March 2024 Google post warned that third-party authority scores don't correspond to any Google signal. What the 2024 Google API leak did surface were internal attributes named siteFocusScore and siteRadius, which measure topical concentration and semantic coherence algorithmically. The leak suggests Google measures topic focus. The Content Cluster model is one way to make that focus visible across a site.

Traditional search is only half of who's reading now, though. Answer engines lean on the same structure, and here's how that shows up in the data we watch.

Search and AI answer engines

Structured hub content aligns with the citation patterns answer engines appear to use. Those are domain-level authority, page-level internal links, and evidence that the wider site knows the subject.

• Domain-level authority matters. Indexably's AI citation analysis found that domain-level factors account for 77% of predictive importance in AI citation, versus 23% for page-level factors. Answer engines are asking whether your whole site knows the subject, which is precisely what a Content Cluster demonstrates.
• Internal links matter at the page level. In AIPlusAutomation's citation regression of over 100,000 citation events, internal link count carried the largest standardized coefficient among page features (β = 0.73, OR = 2.07).
• Search rank and AI citation are diverging. In mid-2025, 76% of AI Overviews citations came from top-10 organic results, but by early 2026 that had fallen to between 17% (BrightEdge) and 38% (Ahrefs), according to an AI sourcing analysis. A search overlap study found only 12% of AI-cited sources overlap with Google's organic top 10.
• Engines weight differently. Perplexity emphasizes freshness and community sources like Reddit, while ChatGPT leans toward high-authority publishers.

Types of pillar pages

Knowing why the architecture works still leaves you a format choice to make. Two pillar formats dominate, and which one you reach for depends on whether your value comes from teaching the topic or from organizing access to it.

The 10x content pillar is a deep guide that covers a broad topic in full on a single page and links down to spokes for depth. It's the format we reach for on most B2B topics where you want to demonstrate expertise and earn citations, and it runs long. Most pillar pages land in the 3,000 to 5,000 word range, calibrated to what the results actually reward.

The resource pillar curates links across a domain, functioning as an organized directory rather than a single continuous read. Choose it when the value is aggregation, a hub that points to templates, calculators, guides, and other references.

Choose the 10x guide when you're building authority on a subject you can teach with genuine depth. Choose the resource pillar when the reader's job is finding the right resource fast and your edge is curation.

Whichever format you land on, the page still has to hold together at length, and that comes down to a handful of structural elements.

Structural elements every hub page needs

A pillar page needs structural elements to stay navigable at length. A 4,000-word page without navigation is a wall.

Every pillar page should include:

• A clickable table of contents: anchor links to each major section so readers jump to what they need. Google and schema.org document no table-of-contents markup as a formal comprehensiveness signal. It earns its place through usability, not markup credit.
• A descriptive H1: one clear H1 stating the topic the page owns.
• Anchor-linked sections: each section addressable by a URL fragment, which supports the table of contents and clean deep-linking.
• Clear internal links to every spoke: descriptive anchors pointing down to each cluster article, and reciprocal links back up from the spokes.
• Breadcrumb schema: BreadcrumbList markup so Google can categorize the page in results.

On breadcrumbs, be precise about what the markup does. Google's breadcrumb documentation states that Google Search uses breadcrumb markup to categorize the page in search results, and Google limits its documented effect to search result appearance. BreadcrumbList requires an itemListElement array of ListItem objects. Each ListItem needs name and position. The item value is required except for the last breadcrumb. Google supports JSON-LD, RDFa, and Microdata.

Skip FAQ schema and question-stuffed headers. Write headers as plain statements of what the section covers, and let the content answer the questions readers actually have.

How to build a Content Cluster

With the format chosen and the page anatomy settled, we can get to the build. It follows an ordered process, and the sequence matters, because the scope decisions you make early on determine whether the whole structure holds together.

1. Choose the core topic. Pick a subject central to what you sell and broad enough to anchor a hub. Apply HubSpot's test. It should support 20 to 30 related posts.
2. Calibrate scope. Choose a topic you can cover credibly on one pillar and sustain with enough spokes to build authority. Check search volume for the pillar term and count the viable subtopics before committing.
3. Map subtopics. List every question and subtopic the pillar raises. Each becomes one spoke at one URL.
4. Audit and consolidate existing content. Before writing anything new, find what you already have on the topic.
5. Write the pillar. Cover the breadth of the topic, calibrated to what ranks. Link down to every planned spoke.
6. Publish the spokes. Each spoke goes deep on one subtopic, 800 to 2,000 words depending on the query, and links up to the pillar.
7. Interlink. Connect the pillar to every spoke and every spoke to the pillar, plus relevant spoke-to-spoke links where the topics relate.

The scope pitfall sinks more clusters than bad writing does. A pillar on email marketing is too broad to cover on one page and too broad to link coherently. A pillar on subject line A/B testing for transactional emails is too narrow to sustain 20 spokes. Calibrate to a topic wide enough to support the cluster and specific enough to own.

Auditing and migrating existing content

Auditing existing content before you build prevents the new cluster from competing with your own legacy pages. Work through a specific checklist.

• Identify cannibalization. Find pages already targeting the same queries as your planned pillar and spokes. Multiple pages competing for one query dilute the ranking signal you're trying to concentrate.
• Consolidate thin posts. Merge overlapping short posts into the single spoke or pillar that replaces them. Content merging paired with a 301 redirect consolidates link equity into the surviving URL.
• Set up redirects. Use 301 redirects from retired URLs to their replacements. The 301 passes most of the original page's SEO value forward.

Execute redirects carefully. Map every old URL to a destination before you flip the switch, and use rel=canonical only for technical duplicates. Ahrefs limits canonicalization to technical duplicates and rejects it as a keyword-cannibalization fix.

How to measure a Content Cluster

Once the cluster is built and interlinked, you have to measure it, and the right way is as an ongoing system across four categories. The cluster compounds over quarters, so the metrics should show a trajectory.

The KPIs that matter:

• Organic traffic to the cluster: aggregate sessions across the pillar and all spokes, tracked over time rather than per post.
• Ranking position: where the pillar and spokes rank for their target queries, and how ranking duration holds.
• Internal link click-through: whether readers move between the pillar and spokes, which confirms the architecture works for humans and not just crawlers.
• AI citation share: how often answer engines cite your cluster pages, tracked separately because AI citation and organic rank have diverged.

That last metric is the one most teams can't see. Buyers now research purchases inside ChatGPT and Perplexity, and if your cluster isn't cited there, a competitor's is. Checking manually across engines doesn't scale, and citation data doesn't live in your existing analytics. Our own CheckThat data, drawn from 2.6M+ AI responses across 5,800+ brands, shows citation and organic rank have split far enough that you have to track them separately.

You can run all of this by hand. Map the cluster, audit for cannibalization, interlink the pillar and spokes, then watch organic rankings, internal click-through, and AI citations page by page. It works, and we know it works because we ran exactly this loop by hand for the B2B companies we operate before we automated it.

It also turns into a standing job the moment the cluster grows past a dozen pages, which is why we built GrowthOS to operate it. An agent crawls and scores every page daily across technical health and intent-relevance, tracks how AI answer engines cite the cluster (AI visibility, powered by CheckThat), and feeds every edit back into the context layer so the portfolio gets more targeted each quarter instead of just larger. If you would rather operate the cluster than build it by hand, book a demo. GrowthX plans start from $6,000/mo.

Wherever you land, start by auditing what you already publish on your core topic. The cluster you build from consolidating and connecting existing pages usually outranks the one you build from scratch, and it clears the cannibalization holding your current pages back.