Fact-checked 17 July 2026. A topic cluster is a group of distinct, useful pages about one defined subject, connected through a pillar or hub and contextual internal links. The diagram does not create rankings. The value comes from satisfying related reader jobs with clear URL responsibilities, original information, and a navigable architecture.
Short answer: define the topic and audience, inventory existing pages, research the jobs and queries, cluster by intent rather than shared words, assign one purpose to each URL, select a true pillar, publish the minimum viable set in dependency order, link pages where the relationship helps, and measure the cluster as a portfolio.
What is a topic cluster?
A topic cluster usually contains:
- a pillar or hub: the best overview and navigation point for the wider subject;
- support pages: focused pages that solve distinct subproblems in greater depth;
- internal links: crawlable, descriptive paths that express the relationships;
- a topic boundary: a reason these pages belong together for a real audience.
“Content hub,” “pillar-and-cluster,” and “hub-and-spoke” are related models. The labels matter less than whether the pages are useful and distinct.
Google’s SEO Starter Guide says logical organisation can help users and search engines understand how pages relate, while also cautioning against reorganising a site without a real need. A cluster is an information-architecture choice, not a mandatory ranking format.
When a topic cluster is useful
Build a cluster when:
- the audience has several recurring, distinct jobs within one subject;
- one page would become unwieldy or shallow if it tried to serve them all;
- the site can contribute credible depth across the set;
- the relationships create useful reading or decision paths;
- the business is willing to maintain the pages;
- the subject fits the site’s primary purpose.
Do not build a cluster when the “subtopics” are only synonyms, the site has no experience to contribute, or the pages exist solely to occupy keyword variations. Google’s spam policies prohibit scaled content created mainly to manipulate rankings and add little value.
Step 1: define the topic boundary
Use a boundary statement:
This cluster helps [audience] solve [class of problems] so they can [outcome]. It includes [jobs/entities] and excludes [adjacent work] unless that work directly changes the outcome.
A “marketing” cluster is too broad for most sites. “SEO content operations for small marketing teams” is more defensible: research, intent, briefs, calendars, on-page work, links, and audits form one operating journey.
The boundary is the foundation of credible topical authority. Without it, a site can publish endlessly without becoming more useful.
Step 2: inventory the content you already have
Collect titles, URLs, canonical state, headings, full text, page type, primary job, categories, internal links, performance, and status. Then mark each existing page:
- potential pillar;
- distinct support page;
- overlapping/merge candidate;
- off-topic;
- outdated or untrusted;
- missing a clear role.
Starting from an imaginary blank site is a common cause of cannibalisation. A new cluster may need three refreshes and two new pages, not ten new URLs.
Step 3: research jobs, entities, and queries
Use customer language, Search Console, Keyword Planner, result-page research, sales/support questions, and subject expertise. Capture:
- what the audience needs to understand;
- what they compare or choose;
- what they implement;
- what fails and needs troubleshooting;
- what they measure;
- what changes over time;
- which entities and concepts are necessary to explain the subject accurately.
DMT’s keyword research guide provides a zero-cost map from demand evidence to URL decisions.
Step 4: cluster by intent and page requirement
Two phrases belong on one page when they share the reader, job, result format, and honest promise. Split when one requires a different decision, depth, tool, location, audience, or format.
| Potential phrase | Reader job | URL decision |
|---|---|---|
| SEO content strategy | Design the complete programme | Pillar |
| keyword research | Discover and prioritise demand | Support page |
| keyword research tool | Use or choose software | Separate tool/comparison if the site can deliver it |
| search intent | Choose the right page type and promise | Support page |
| content calendar | Plan production and governance | Support page with template |
Use the search intent framework to document the page-type evidence instead of clustering by shared nouns.
Step 5: assign one responsibility to every URL
Create a URL map with:
- proposed or existing URL;
- reader and job;
- primary and supporting query family;
- page type;
- unique contribution;
- pillar/peer relationships;
- create, refresh, merge, or reject decision;
- duplicate-check result;
- owner and review trigger.
Run title, slug, heading, and full-text similarity checks before drafting and again before publication. A keyword tool cannot see a nuanced intent difference, so retain editorial review.
Step 6: choose or build the pillar
A useful pillar:
- answers the broad job at the right depth;
- defines the subject boundary;
- provides a coherent framework or sequence;
- introduces support topics without duplicating their full treatment;
- links to the support pages where the reader needs depth;
- receives relevant links back from those pages;
- is maintained as the cluster evolves.
The page with the broadest keyword or most traffic is not automatically the pillar. Choose the page best suited to orient the audience.
Pillar, category, and landing page are different roles
| Page | Primary role | Common mistake |
|---|---|---|
| Pillar guide | Explain the wider subject and route readers to depth | Becoming a shallow link directory or duplicating every support article |
| Category/archive | List and filter items under a taxonomy | Being treated as a complete editorial answer without useful context |
| Commercial landing page | Explain an offer, proof, fit, and action | Absorbing informational jobs purely to target more keywords |
| Support article | Solve one focused subproblem deeply | Repeating the pillar introduction and never reaching depth |
One URL can blend compatible roles, but the primary job must remain clear. A category becomes a hub only when it genuinely orients readers; a service page becomes a guide only when it fully serves the information need.
URL structure should support management, not trigger migration
A clean folder such as /seo/ can make reporting and governance easier, but folders do not create topical relationships by themselves. Avoid changing established URLs solely to place every cluster page under a matching path. The migration cost, redirects, links, canonicals, sitemap changes, and performance uncertainty may outweigh the cosmetic benefit.
Use stable, descriptive slugs; connect the pages through navigation, breadcrumbs where appropriate, contextual links, and a maintained URL map. Report clusters using a lookup table if the physical paths are mixed.
Step 7: design the minimum viable cluster
Do not set an arbitrary target such as twenty support pages. Start with the smallest set that:
- delivers a credible pillar;
- solves the highest-value distinct jobs;
- creates a complete reader journey;
- can be produced and maintained to a high standard;
- has a coherent internal-link plan;
- can be measured within the site’s resources.
Mark secondary jobs as future candidates. Expand when evidence shows demand or a missing decision—not because the cluster diagram has empty space.
Step 8: sequence the publishing work
A reliable order is:
- refresh or publish the pillar;
- publish the foundational support pages that later articles depend on;
- add implementation, comparison, and troubleshooting pages;
- link established pages to the new URLs when contextually useful;
- publish measurement and audit pages to close the loop;
- run a final cluster-wide link and duplicate review.
Track dependencies in an editorial content calendar. Cross-linking ten URLs that do not yet exist can create temporary broken paths; either publish in quick succession and verify at the end or add links as destinations go live.
Step 9: create useful link relationships
Use three directions:
- up: support page to pillar for context;
- sideways: peer to peer for the next related job;
- down: pillar to detailed support or a natural action.
Anchors should describe destinations without repeating one exact phrase mechanically. Google’s link guidance recommends crawlable links and descriptive anchor text. DMT’s internal linking strategy includes opportunity scoring and an anchor ledger.
A worked cluster: SEO content operations
| Page | Responsibility | Primary relationships |
|---|---|---|
| SEO content strategy | Pillar and complete operating model | All support jobs |
| Keyword research | Discover, cluster, score, and map demand | Intent, topic clusters, brief |
| Search intent | Infer the job and choose page type | Keyword research, brief, on-page |
| Topic clusters | Design distinct URLs and architecture | Pillar, authority, internal links |
| Topical authority | Set coverage, evidence, and maintenance standard | Clusters, links, audit |
| SEO content brief | Turn research into an editorial contract | Research, intent, on-page |
| Content calendar | Control production, dependencies, and review | Brief, cluster, audit |
| On-page SEO | Optimise the individual page | Intent, brief, links |
| Internal linking | Express relationships and journeys | Clusters, audit, pillar |
| SEO/content audits | Diagnose and decide the next cycle | Every part of the cluster |
The pages share a subject but do not share one primary job. That distinction is the anti-cannibalisation design.
How to measure a topic cluster
Establish a baseline before publication and review:
- cluster-level clicks and impressions;
- relevant query breadth;
- pages earning meaningful visibility;
- movement into stronger position bands;
- which URL owns each intended query family;
- internal journeys and assisted outcomes;
- editorial links, citations, and repeat visitors;
- orphan, broken-link, and duplicate-intent counts;
- refresh debt and time since review.
Measure individual pages too. A cluster total can hide one successful page and nine unused ones. Conversely, a low-volume support page may be valuable because it completes a journey or earns trust.
Cluster reporting table
Maintain one row per page with cluster role, intended query family, index state, clicks, impressions, position band, internal inbound/outbound links, assisted outcome, backlinks/citations, last reviewed date, and next action. Add a summary row for totals and medians, but preserve the URL detail.
Compare pre-cluster and post-cluster periods carefully. New pages need time to be discovered and demand can change. Record publication and link dates so the trend is interpretable.
Maintain the cluster
Review when demand, products, terminology, result formats, links, or official sources change. Run a content inventory and audit to decide whether weak pages need refresh, repositioning, merging, or retirement.
When adding a new page:
- re-run the overlap check;
- state the distinct job;
- update the pillar and relevant peer links;
- update the URL map and anchor ledger;
- schedule a review and cluster-level measurement.
Common topic cluster mistakes
- Choosing a topic too broad for the site’s expertise.
- Making one page for every keyword variation.
- Calling the longest article the pillar without reviewing its job.
- Publishing the support pages with no useful links.
- Connecting every page to every other page.
- Copying competitor cluster maps without audience context.
- Measuring only the pillar.
- Expanding before maintaining the pages already live.
- Using thin AI content to fill perceived coverage gaps.
Frequently asked questions
How many pages should a topic cluster contain?
As many as needed to serve the important distinct jobs credibly—and no more. Start with a minimum viable set based on audience value and maintenance capacity, then expand from evidence.
Does every cluster need a pillar page?
A clearly orienting hub is useful for complex subjects, but architecture can vary. The essential requirements are distinct page responsibilities, understandable navigation, useful links, and strong content.
Should cluster URLs share a folder?
A folder can make management and reporting easier, but it is not the cluster itself. Do not change stable URLs solely to create a matching path. Links, page purpose, content, and navigation carry the relationship.
Do topic clusters prevent cannibalisation?
They can reduce it when designed around distinct reader jobs and one URL per intent. Poorly designed clusters create cannibalisation by turning synonyms into separate pages.
Can old content become a topic cluster?
Yes. Inventory the library, select or improve a pillar, clarify page responsibilities, merge overlap, fill genuine gaps, and add useful internal links. A cluster often begins as an audit and consolidation project.
About the author and methodology
This Digital Marketer Tayeeb guide is itself part of a live ten-article SEO content operations cluster. Its page responsibility, dependencies, cross-links, duplicate gate, and cluster-level measurement were defined before drafting, providing a first-party example of the method.
