By Mehdi HassanHow do topic clusters and pillar pages fit into site architecture?
Topic clusters and pillar pages fit into website architecture as a second hierarchy alongside your main navigation. The main navigation organizes the pages buyers use to evaluate you: product, solutions, pricing. Topic clusters organize the educational content that brings buyers in earlier, grouping articles under hub pages that each cover one core topic.
Most advice about clusters is about writing: pick a topic, write a long pillar post, write supporting posts, link them. That works until you have fifty articles and someone forgets to add the links. The angle of this article is the build side: designing hub templates and CMS structure so the cluster holds together automatically. For the wider structure your clusters sit inside, see our website information architecture guide.
If you want the content and keyword side in depth, our guide to building topic clusters on a marketing site covers topic selection and writing. This one covers the templates and the wiring.
What is a pillar page, structurally?
Structurally, a pillar page is a hub: a page that introduces a topic, answers its main question directly and routes readers to the detailed article for each sub-question. It's both a page worth reading and a directory of the cluster. Each child article links back to it, and children link to each other where it helps the reader.
Element | Pillar (hub) page | Cluster (child) article |
|---|---|---|
Scope | The whole topic, broadly | One sub-question, in depth |
Links out | To every child, grouped logically | To the hub early, plus a few siblings |
Template | Hub template with a cluster index | Standard article template |
Breadcrumb | Blog or Resources, then the hub | Blog or Resources, then hub, then article |
Updates | Index updates when children are added | Content updates on its own schedule |
This article is itself a child in a cluster: it links to its hub early and to sibling articles where they're relevant. That pattern, repeated across every article, is what makes the cluster legible to readers, search engines and answer engines.
How do you design a pillar page template?
Design a pillar page template as a distinct page type with its own layout, not as a long blog post. It needs to do two jobs at once: give a complete overview a reader can stop at, and make the rest of the cluster easy to scan and enter. Those jobs need components a standard article template doesn't have.
- A direct answer at the top. A short summary that answers the topic's main question, which is also what answer engines tend to quote. Our guide to answer-first page structure covers how to write it.
- A table of contents. Built from the H2s, so long hubs stay navigable.
- Section-to-child links. Each section ends with a link to the child article that goes deeper.
- A cluster index. A grouped list or table of every child article, pulled from the CMS.
- Breadcrumbs. So readers and crawlers can see where the hub sits.
- A soft conversion block. One offer that fits the topic, placed where the reader is most convinced.
How should the CMS model topic clusters?
The CMS should model topic clusters as a relationship between content, not as text links typed into articles. Give each article a reference field that points to its hub, and let the templates use that relationship to build breadcrumbs, back-links and the hub's index. When an editor publishes a new article and picks its hub, every link updates itself.
Create a hub collection or flag
Either a separate Hubs collection or an is-hub field on articles. A separate collection is cleaner when hubs need different fields.
Add a hub reference to articles
A required reference field on each article that points to its hub. One hub per article keeps the structure clear.
Add an optional grouping field
A short field such as Group lets the hub's index sort children into logical sections instead of one long list.
Render the relationships in templates
The article template shows the breadcrumb and a link to the hub; the hub template queries its children and renders the grouped index.
Add related-article blocks
Show a few sibling articles at the end of each child, pulled from the same hub, so readers move sideways through the cluster.
Validate before publishing
Check that every article has a hub, that links point to published pages and that the hub index contains no orphans.
If you're setting up collections from scratch, our content modeling guide covers how to structure references and fields for a SaaS site. The same approach powers directories such as a SaaS integrations page, where a hub lists every integration and each detail page links back.
For example, suppose a SaaS company wants a cluster on onboarding
For example, suppose a SaaS company that sells onboarding software wants a cluster around customer onboarding. The hub, /blog/customer-onboarding, covers what onboarding is, the stages, the metrics and the common mistakes, with a short section on each.
Ten child articles go deeper: an onboarding checklist, email sequences, onboarding metrics, onboarding for enterprise accounts and so on. Each sits at /blog/its-slug, with no nested folders. In the CMS, each child references the onboarding hub and has a Group value such as Planning, Execution or Measurement.
The hub template renders those three groups as a read-next table. Each child shows a breadcrumb back to the hub and three related siblings. When the team publishes an eleventh article, they pick the hub and group, and it appears in the right place without anyone editing the hub.
What URL structure should pillar pages use?
Pillar pages and their children should use flat URLs, typically /blog/hub-topic and /blog/child-topic, with the hierarchy shown through links and breadcrumbs instead of nested folders. Nesting children under their hub in the URL, such as /blog/onboarding/checklist, looks neat but breaks when an article moves to a different cluster or a hub is split in two.
Flat URLs mean you can reorganize clusters by changing a CMS reference, with no redirects. Our URL structure best practices explain why stable, shallow paths matter more than encoding today's grouping into the address.
How do you choose pillar topics for a SaaS site?
Choose pillar topics that sit where the problems your product solves meet what your buyers search for. A hub should attract readers who could plausibly become customers, and it should lead naturally to your product and solutions pages. Topics chosen only for search volume bring traffic that never converts.
- Start from your messaging: the problems on your home and product pages are your first hub candidates.
- Check that each topic has enough real sub-questions for several useful child articles.
- Avoid hubs that overlap heavily; two hubs covering nearly the same topic split your authority.
- Map each hub to the product or solutions page it should send readers to. Our SaaS sitemap template shows where those pages live.
How do you audit an existing cluster structure?
Audit a cluster by checking whether every article belongs to a hub, links to it, and appears in its index, and whether hubs overlap. A quick crawl plus a CMS export usually shows the gaps quickly.
- List every article with its hub reference, or note that it has none.
- Crawl the site and check that each child links to its hub and each hub links to all its children.
- Look for orphan articles with no internal links pointing at them.
- Compare hub topics and their top queries in Search Console for overlap.
- Check that hubs link onward to the right product or solutions pages.
Our on-page SEO audit guide covers the internal-link checks in more detail.
