Topic Cluster Mapper: Plan Content Around Pillar Topics

Most websites grow article by article, and after a year the result is a pile of posts with no visible structure: overlapping topics, competing pages, and internal links added wherever an author remembered them. Readers struggle to find the next useful article, and search engines struggle to tell which page should represent a topic. A topic cluster fixes this by organising content around a central pillar page, supported by cluster articles that each answer one specific question, all linked together in a deliberate pattern. The structure is simple, but planning it in advance is what makes it work.

The Topic Cluster Mapper helps you plan that structure: you enter a pillar topic and a list of supporting topics, and it arranges them into a map showing which articles belong to the cluster and how they should link to the pillar and to each other. It is a planning tool, not a publisher: it does not write articles or edit your site, and the map it produces is only as good as the topic list you feed it. The thinking you do before mapping — choosing the pillar, separating distinct questions, and spotting overlaps — is the real work, and this guide walks through it.

A pillar page is a broad, comprehensive guide to a topic: long enough to cover the subject properly, organised so a reader can find any subtopic quickly, and written for someone who wants the whole picture. A cluster article is narrower: it answers one question in depth, for a reader who already knows roughly what they need. The pillar links out to every cluster article, and every cluster article links back to the pillar. Cluster articles may also link to each other where genuinely relevant, but the pillar is the hub, and the pattern should be visible in the site's navigation and in the links themselves, not only in a planning document.

Choosing a pillar that can carry a cluster

A good pillar topic is broad enough to support at least five genuinely distinct subtopics, and specific enough that a reader knows what it covers from its title. "Gardening" is too broad for a single pillar; it would need many pillars, one per major area. "Growing tomatoes" is too narrow for a pillar with many subtopics; it is itself a cluster article inside a vegetable-gardening pillar. The sweet spot is a topic like "growing vegetables in small spaces", which supports subtopics on soil, containers, watering, varieties, pests and seasonal planning, each worthy of its own article.

Test a candidate pillar with three questions. Can you list at least five subtopics without straining? Would a reader who lands on the pillar find a link to the answer for each of those subtopics? And does the pillar overlap heavily with an existing page on your site? If the answer to the third question is yes, you have a cannibalisation problem to solve first: either merge the pages, refocus one of them, or choose a different pillar. Two pages competing for the same topic split attention and authority, and a cluster built on top of a duplicate only deepens the confusion.

Also consider search intent. A pillar usually serves a broad informational intent: someone wants to understand a topic. Cluster articles serve narrower intents: someone wants to solve a specific problem, compare options, or follow a process. Mapping intent to each article prevents the common failure where every article tries to answer everything. If two cluster articles serve the same intent, they are probably one article, and merging them produces a stronger page than keeping both.

Building the cluster list

Build the list from real questions, not from keyword brainstorming alone. Look at questions your readers actually ask: support messages, comments, forum threads, and the search queries that already bring visitors to your site. Group those questions by the job they serve, and let each group become a cluster article. A group with only one thin question may belong as a section inside the pillar rather than as its own article, while a group that keeps growing is a sign of a subtopic strong enough to stand alone.

Aim for a first cluster of five to ten articles. Fewer than five, and the structure barely differs from a single page with sections. More than ten in the first pass, and the project becomes too large to finish, which is how clusters die half-built. You can always extend a successful cluster later; finishing a small, coherent cluster teaches you more than starting a large, unfinished one. Order the articles by the reader's journey where a natural order exists — planning before planting, for example — and by importance where it does not, so the most useful articles are written first.

For each article, write a one-sentence brief before drafting: the question it answers, the reader it serves, and the one action or understanding the reader should leave with. A brief that cannot be written in one sentence usually describes two articles, and splitting it early saves a rewrite later. Record the briefs in the map, alongside the planned links, so that anyone writing an article can see where it fits and what it must not duplicate. The map is a working document, not a decoration: update it when an article changes scope, and retire entries for articles that are merged or removed.

Worked example: a small-space vegetable garden cluster

Suppose a gardening site wants a cluster on growing vegetables in small spaces. The pillar page is "Growing Vegetables in Small Spaces: A Complete Guide", covering the principles, the main methods, and links to every cluster article. The cluster list, built from reader questions, includes: choosing containers and raised beds, soil mixes for containers, watering small-space gardens, the best compact vegetable varieties, dealing with pests without chemicals, succession planting for continuous harvests, and growing herbs alongside vegetables. That is seven articles, each answering a distinct question, each with a clear brief.

The linking plan is straightforward. The pillar contains a section for each subtopic, summarising it in a paragraph and linking to the full article. Each cluster article opens by situating itself — "part of our guide to growing vegetables in small spaces" — and links back to the pillar, plus to one or two siblings where relevant: the watering article links to the soil article, because soil mix affects watering, and the pest article links to the herbs article, because some herbs deter pests. No article links to every other article, because indiscriminate linking would bury the useful links among noise. The result is a structure a reader can navigate without a map, and a search engine can follow without guessing which page represents the topic.

Six months later, the site reviews the cluster. The varieties article is the most visited, so it gains a follow-up on seed starting. The succession planting article overlaps with a new seasonal article, so the two are merged and the map updated. The pillar is refreshed with new links and a short update note. This maintenance is normal and healthy: a cluster is a living structure, and a map that never changes is a map nobody uses.

Common mistakes

The most common mistake is building the pillar last, after the cluster articles already exist. Without the pillar, cluster articles link nowhere central, and retrofitting a pillar means rewriting introductions and links across many pages. Build the pillar's outline first, even if the full pillar is written after a few cluster articles, so that every article knows its home from the start. A second mistake is making the pillar a mere table of contents: a list of links with no substance. A pillar must stand alone as a useful guide; readers who never click further should still leave with a solid understanding of the topic.

A third mistake is over-linking. Links should follow reader need, not a quota. An article that links to every cluster sibling dilutes the links that matter and looks manipulative. Link where the reader would genuinely want to continue, and let the pillar carry the full structure. A fourth mistake is never updating the map: articles get merged, renamed or removed, and the map quietly becomes fiction. Review the cluster whenever a member article changes significantly, and treat the map as part of the site's documentation rather than a one-off plan.

Companion tools support the surrounding work. The SEO Checker reviews individual pages for on-page issues before they join a cluster, and the Internal Link Opportunity Mapper finds additional linking opportunities across existing content. For the principles behind grouping topics and avoiding competing pages, see Topic Clusters and Internal Links.

FAQs

How many articles should a cluster contain? Start with five to ten. That range is large enough to demonstrate structure and small enough to finish. Extend successful clusters over time rather than launching with dozens of thin articles.

Can a page belong to two clusters? Occasionally, when a topic genuinely bridges two subjects, but treat it as an exception. Pages in two clusters blur the structure that makes clusters useful, so prefer a primary cluster and a single contextual link to the second.

Do clusters guarantee better rankings? No. Clusters improve organisation, navigation and topical coverage, which can support visibility, but rankings also depend on content quality, competition, and many other factors. Treat a cluster as good information architecture first and a search benefit second.