What is the difference between a pillar page and a service page?

For an organization that sells services, they should usually be the same page. Creating a separate long guide as the pillar splits attention away from the page you actually want buyers to reach. Make the service page the most complete statement of what you do in that area and let articles support it.

How many articles should a topic cluster have?

As many as there are distinct, genuinely useful questions a buyer of that service asks, and no more. A tight cluster of a handful of strong articles beats a long list of thin ones that overlap. Start with the questions that come up most in sales conversations.

What is keyword cannibalization and how do I fix it?

It is when several of your pages compete for the same search, so search engines split their attention and none ranks as well as one strong page would. Fix it by merging pages that answer the same question into the one with the better history and redirecting the rest, or by rewriting one page to answer a clearly different question.

How often should we update old blog content?

Review your most important pages on a regular schedule and the rest less often, and review immediately when a service, regulation or fact changes. Only update the visible date when the content has actually changed. Some pages will need rewriting, and some should be retired.

How to Build SEO Topic Clusters That Support Services

What a cluster is for

A topic cluster is a group of pages about one subject, organized around a central page and connected by deliberate links. The idea has been around for years under various names: pillars, hubs, silos. The names matter less than the purpose.

For an organization that sells services, the purpose is specific. Each cluster should make it obvious, to a buyer and to a machine, that you understand one service area deeply: what it involves, what it costs to get wrong, how to choose a provider, what the options are. Search engines and AI assistants both look for sources that cover a subject thoroughly and consistently. A single good article is a data point. A well-organized cluster is a pattern.

What a cluster is not for: traffic for its own sake. A library that ranks for hundreds of loosely related questions can look impressive in a report and produce no inquiries at all. Every article should earn its place by helping someone who might plausibly buy the service it supports.

Start from services, not keywords

The common way to build clusters is to open a keyword tool, find a high-volume topic, and generate a list of related phrases. The result is a cluster shaped by what the tool happens to know about, not by what your organization sells.

Turn it around:

List your services as a buyer would name them. Five to eight is typical for an established firm. Each one is a candidate pillar.
Make the service page the pillar. Not a separate “ultimate guide”. The service page is the page you want people to land on, and it should be the most complete statement of what you do in that area. Articles support it.
Collect the real questions. Ask the people who take inquiries, write proposals and handle objections. What do prospects ask before they call? What do they get wrong? What do they ask in the second meeting? These are better cluster topics than anything a tool will suggest.
Then check demand. Use Search Console and keyword data to see how people phrase those questions and which ones have meaningful search interest. Demand data refines the list; it should not invent it.

A cluster built this way also tends to be the content that AI assistants find useful, because it answers the questions people actually put to them. SEO and AI search visibility as one strategy explains why the two goals line up.

Map each article to one intent

Buyers ask different questions at different stages, and each stage needs a different kind of page. A simple map for a service cluster:

Problem: “Why are our inquiries down even though traffic is up?” The buyer has a symptom and no name for it yet.
Options: “Audit or ongoing SEO?” “In-house or agency?” The buyer knows the category and is weighing approaches.
Cost and scope: “What drives the cost of a website rebuild?” Decision content that explains without publishing rates.
Selection: “How do we choose a provider?” Questions to ask, red flags, what to put in an RFP.
Proof: case studies and worked examples.

Give each article exactly one primary question and one stage. When an article tries to answer the problem, the options and the selection questions at once, it usually answers none of them well, and it collides with every other article in the cluster.

An illustrative example

A regional engineering consultancy offers environmental assessment, structural engineering, municipal infrastructure and project management. Take municipal infrastructure as one cluster. The pillar is the service page. Supporting articles might answer: how a municipality should scope an infrastructure study, what funding programs usually require from an engineering report, how to compare engineering proposals in a public procurement, and what goes wrong in asset management plans. Four articles, four questions, four stages. Each links to the service page, and each links to at least one sibling where the reader’s next question naturally leads.

Link deliberately

Internal links are how the cluster becomes visible as a cluster. They tell search engines which pages belong together and which page is the centre, and they move readers to the next useful page. A few rules that hold up:

Every article links to its pillar, in the body text, where the service is genuinely relevant. Not only in the footer.
The pillar links out to its strongest articles, so the relationship runs in both directions.
Articles link to siblings where the reader’s next question lives. Three to six well-chosen links beat twenty automatic ones.
Anchor text describes the destination. “The website migration checklist”, not “click here” or “read more”.
Cross-cluster links are fine when they serve the reader. A measurement article linking to a paid advertising article is normal; clusters are a way of organizing, not a set of walls.

Prevent overlap before it happens

Overlap is the most common way content libraries go wrong. Two or three articles answer the same question in slightly different words, usually because different people wrote them in different years. Search engines then have to choose between them, often alternate, and none ranks as well as one strong page would. AI assistants see three slightly inconsistent answers from the same source, which does not help your credibility either.

The prevention is a simple register: a spreadsheet with one row per URL, listing its cluster, its primary question, its intent stage, its owner and its last review date. Before anything new is commissioned, someone checks the register. If the question is already answered, the job is to improve that page, not write another one.

When overlap already exists, decide page by page:

Merge when two pages answer the same question. Keep the URL with more search history, fold in the best of the other, and redirect the weaker one.
Differentiate when two pages are close but could answer different questions. Rewrite one to a distinct angle and link them to each other.
Retire pages that are wrong, obsolete or serve no buyer, with a redirect to the closest useful page.

The redirect decisions matter. The website migration SEO checklist covers how to handle them without losing search history.

Governance keeps it working

A cluster is not a project you finish. Facts change, services evolve, regulations move, and an article that was accurate two years ago can quietly become the reason an AI assistant gives a prospect the wrong answer about you. Governance is what prevents that:

An owner per cluster, usually the person closest to that service, who signs off on accuracy.
A review schedule. Pillars and high-traffic articles more often; the long tail less often. Put the dates in the register.
A trigger list: a service change, a regulation change, a rebrand or a new case study prompts a review of the affected cluster, whatever the schedule says.
Honest dates. Show when an article was last updated, and only change that date when the content actually changed.
Retirement as a normal outcome. Removing a page that no longer helps anyone is maintenance, not failure.

Drafting assistance from AI tools can speed up production, but it raises the stakes on review. The AI content vs human content article covers where it helps and where it hurts.

How to tell it is working

Judge a cluster as a unit, not article by article. In Search Console, group the pillar and its articles and look at the trend in non-branded impressions and clicks over quarters. Look at whether visitors who land on articles go on to the service page. Most important, ask whether inquiries for that service mention the content, and whether sales conversations have become easier. For AI answers, sample the cluster’s questions periodically and note whether your pages are cited; measuring AI search visibility explains how to do that without pretending to more precision than exists.

Restructuring an existing library into service-led clusters is one of the more valuable things an established organization can do with its search program, and it is often a better first step than publishing anything new. The Squeeze is a small example: content clusters were part of a complete digital foundation that produced 58% organic growth over six months, documented in the case study.