Pillar Pages and Topic Clusters: How to Build Them Correctly

A topic cluster is a small piece of information architecture: one page that covers a subject broadly, a set of pages that each cover one facet of it deeply, and links in both directions so that a reader, a crawler or a retrieval system can move from the overview to the detail and back. Most sites already have the raw material for several clusters. What they lack is the deliberate choice of which page is the overview, and the links that make the structure visible. This guide explains the model, walks through a worked example, and shows how SiteRank AI picks pillar candidates from a site's own data.

What a pillar page is

A pillar page is the single document that best represents a subject comprehensively. It covers every important facet of the subject at a level of detail that satisfies a reader who wants an orientation, and it links out to a supporting page wherever a facet deserves its own treatment.

Three properties define it:

• Breadth. It touches every subtopic in the cluster, even briefly.
• Position in the link graph. Supporting pages link up to it, and it links down to them. It tends to accumulate more inbound internal links than any other page on the subject, because it is the natural page to reference.
• Stability. Its URL and its subject do not change. Supporting pages come and go; the pillar persists and is revised.

A pillar is not simply the longest page on the subject. Length is a side effect of breadth, not a cause of authority, and SiteRank's pillar scoring treats it as the weakest of three inputs for that reason.

What a pillar page is not

Sites go wrong in predictable ways.

There is also a terminology trap: topical authority is a property of a site's coverage that a tool can compute and explain. It is not a Google metric, no engine exposes it, and no vendor number measures it. Building clusters improves coverage, connectivity and findability, which are real and observable. Whether that translates to ranking or citation is a separate question covered below.

Anatomy of a topic cluster

A topic cluster has four parts:

1. The pillar — the comprehensive overview.
2. Supporting pages — each one covers a single facet in depth. A supporting page should answer a narrower question than the pillar and answer it more completely than the pillar does.
3. Upward links — every supporting page links to the pillar, ideally from the body text with descriptive anchor text rather than from a sidebar widget.
4. Downward links — the pillar links to each supporting page at the point where it summarises that facet.

Lateral links between supporting pages are useful where two facets genuinely relate. They are not mandatory, and adding them everywhere produces the link-stuffing pattern that degrades both the reader's experience and the signal.

Worked example: a university admissions site

Consider a university with an admissions section that has grown over ten years. An inventory finds 38 pages about undergraduate admission. They include an "Apply" page, deadline pages for three intake periods, entry requirement pages by qualification type (A-levels, International Baccalaureate, national qualifications from twelve countries), pages on personal statements, interviews, contextual offers, fee status, English language requirements, deferred entry, and a scattering of news posts about open days.

The site's existing hierarchy says "Apply" is the top page. The link graph says otherwise: the entry requirements index has the most inbound links, because every department page links to it. Neither is a good pillar. "Apply" is a form gateway with 200 words of instructions; the requirements index is a list.

The correct cluster looks like this:

The pillar is new. It is perhaps 1,800 words, every section names its subject in the heading, and every section ends by linking to the supporting page. The twelve country pages link up to the international qualifications page, which links up to the pillar; that is a sub-cluster, and it is fine for a cluster to nest one level.

What changed for the reader: there is now one page to send an applicant to. What changed for crawlers and retrieval systems: the subject's pages are reachable from one hub within one or two links, each has descriptive inbound anchor text, and the hub is the page most likely to be surfaced for a broad question because it is the page that actually answers the broad question.

The same shape on a B2B software site

A B2B vendor selling payroll software has 60 pages of documentation and marketing about "payroll compliance". Blog posts on each statutory change, help-centre articles on configuring tax codes, a feature page, a webinar recording page, and a glossary.

The pillar here is not the feature page, which is written to sell. It is a guide to payroll compliance for the vendor's target market: what the obligations are, when they fall due, what goes wrong, and how software addresses each. The feature page becomes a supporting page linked from the "how software helps" section. The statutory-change posts are supporting pages for as long as they remain accurate; a superseded change should be marked as superseded and linked to its replacement, not quietly left as a cluster member.

The lesson is the same in both cases: the pillar is chosen by what a reader with the broad question needs, then confirmed by the link graph. Existing hierarchy and existing traffic are inputs, not answers.

How to build a cluster, step by step

1. Inventory the subject. List every indexable page about it. Exclude noindex pages, pages canonicalised elsewhere, and archives. A cluster built on pages that will never be indexed is a cluster on paper.
2. Name the facets. Group the pages by the narrower question each answers. If two pages answer the same question, that is a consolidation candidate, not two supporting pages.
3. Choose or write the pillar. If a page already covers every facet at overview depth, adopt it. If not, write one. Do not promote a supporting page to pillar by padding it.
4. Link upward from every supporting page, from within the body text, with an anchor that names the pillar's subject.
5. Link downward from the pillar at the point in the text where each facet is summarised.
6. Check the graph. After publishing, confirm every cluster member has at least one inbound content link and that the pillar has the most. Orphan pages inside a cluster are common and invisible without a crawl.
7. Revisit on a schedule appropriate to the subject. Admissions changes yearly; payroll compliance changes with legislation. Age alone is not staleness, but a superseded fact inside a pillar undermines the whole cluster.

How SiteRank AI picks pillar candidates

SiteRank's topic engine clusters a site's content locally using lexical similarity; no content leaves the site. Within each cluster it scores every member as a pillar candidate:

pillar score = 0.5 × normalised inbound links
             + 0.3 × centroid relevance
             + 0.2 × normalised word count

Each input is what it says:

• Inbound links (weight 0.5). The count of internal links from other content pages, normalised against the highest count in the cluster. This is the site's own signal of which page it treats as the reference. It carries half the weight because it is the input that reflects human editorial judgement across many pages rather than a property of one page.
• Centroid relevance (weight 0.3). How closely the page's term profile matches the cluster's centre. A page that sits at the middle of the subject's vocabulary is more likely to be the overview than one that sits at an edge.
• Word count (weight 0.2). Normalised against the longest page in the cluster. It is included because an overview that covers every facet is usually longer than a page that covers one, and it carries the least weight because length by itself proves nothing.

The result is a ranked list of candidates with the three inputs shown, not a verdict. The engine also reports a coverage band for each cluster (strong at eight or more documents, moderate at four or more, thin below that) and a connectivity band from mean inbound links per member. These bands summarise counts. They are not quality judgements, and the methodology page documents every threshold.

Cluster labels are derived from a shared taxonomy term where one exists, otherwise from the most distinctive terms. Generated labels can be wrong, and the interface says so; the user renames, merges and splits clusters before acting on them.

What the evidence supports

The honest summary: the practices inside cluster-building (linking, anchor text, comprehensive coverage, consolidation of duplicate intent) each have official support. The cluster as a unit does not, and the topical authority it produces is a property we compute, not a signal any engine has confirmed it reads.

What not to assume

• That a cluster needs a fixed number of pages. Coverage bands in SiteRank are descriptive. A subject with five genuine facets needs five supporting pages, not eight.
• That the pillar must rank for the head term. It often does, because it is the best answer to the broad question. If a supporting page ranks instead, that is information about what the query actually means, not a failure.
• That every content gap becomes a page. A gap found by comparing a cluster's scope to its members is often best closed by expanding an existing page. A gap proposed only by a model's imagination is a hypothesis and should be labelled as one.
• That similarity means duplication. Two pages with overlapping vocabulary may serve different intents or audiences. Cannibalisation is a candidate finding until a human confirms it.
• That word count is authority. It is the smallest input in the pillar score for a reason.

Key takeaways

• A pillar is defined by breadth of coverage and its position in the link graph, not by length or by the site's menu.
• Supporting pages answer narrower questions more completely than the pillar does, and link up to it from body text.
• Build from an inventory of indexable pages; exclude what will never be indexed.
• SiteRank scores pillar candidates at 0.5 inbound links, 0.3 centroid relevance, 0.2 word count, and shows all three inputs.
• Linking, anchor text and comprehensive coverage have official Google support. The cluster as a ranking or citation unit is emerging practice at best.

Official sources & further reading

• Google Search Central — SEO starter guide (Google)
• Google Search Central — Link best practices for Google (Google)
• Google Search Central — Creating helpful, reliable, people-first content (Google)
• Google Search Central — AI features and your website (Google)

Related reading

• Topical authority and website architecture
• Internal linking for SEO, retrieval and AI discovery
• Content freshness
• Structured organisation information
• Topical authority in SiteRank AI