How to Map Keywords to Pillar and Cluster Pages Without Overlap

Overlap is the quiet failure of most topic clusters. You build a pillar page and a set of supporting articles, publish them, and a few months later something looks wrong in your analytics.

Two or three of your own URLs keep swapping places for the same search. One week the pillar ranks, the next week a cluster page does. Neither ever settles into a strong position.

What you are watching is your own pages competing for one intent. Faced with two pages that answer the same question, a search engine tends to split the signals between them. Links and relevance that should back one strong page get divided across two weaker ones.

The technical name is keyword cannibalisation. The cause is almost always the same: nobody decided, in plain words, which query each page was allowed to own.

The fix is not more content, and it is not clever rewriting. It is a mapping discipline you apply before drafting, so every keyword resolves to exactly one page.

This guide walks through that mapping, from a raw keyword list to a cluster you can verify with a crawl. It assumes you have already chosen your pillars. If you have not, start with our complete guide to content pillars, then come back to divide the keywords.

Principle

One query, one page

Every rule here reduces to one instruction. Each page should target one distinct search intent, and no two pages in the cluster should target the same one.

The unit you assign is intent, not the exact words a person types. Two keywords that look different can express the same need, and when they do, they belong on one page.

Take how to build a topic cluster and steps to build a topic cluster. The wording differs, but the intent is identical. A reader typing either one wants the same walkthrough, and a search engine treats them as the same job.

Publishing a page for each does not double your coverage. It halves the strength of both and invites the cannibalisation you are trying to avoid.

So map intents, not strings. Give each page one primary query in plain words, then let it rank for every phrasing that shares the intent. One well built page can rank for dozens of related searches.

Fig. 01  One query, one page. Broad, umbrella phrasings resolve to the pillar. Each specific, long tail query resolves to a single cluster page. When every line lands cleanly on one node, you have a map with no contested territory.

Drawing the map

The order matters more than any single step. Most overlap comes from writing the pages first and sorting keywords afterwards, when every decision is a compromise with what you already published.

Reverse that. Sort the keywords first, set the boundaries on paper where changes are free, then write. Here is the full sequence, with the reasoning attached so you can adapt it.

Your keyword and performance data is the raw survey. The mapping turns it into boundaries.   

01 - Audit the pages you already have

Before you generate a single new keyword, inventory what exists. Most established sites already own five or six articles that touch the topic, written at different times by different people.

Those unplanned pages are the ones most likely to overlap later. List every existing URL on the subject, with the query each one currently ranks for from your analytics.

This does two jobs. It shows what is already covered, so you do not commission a duplicate, and it surfaces overlap that is already live and costing you rankings.

02 - Build one master keyword list

Now gather every phrase the topic could earn into one sheet. Pull seed terms, autocomplete variants, related searches, support inbox questions, sales objections, and terms competitors rank for.

Cast a wide net here. It is easier to discard a keyword than to discover a gap after the cluster is built.

Keep it as one list for the whole cluster, not a separate list per page. A single list is what makes overlap visible, because near duplicate phrasings end up side by side where you can catch them and merge them.

03 - Group the list by intent, not by wording

Sort the master list into groups. Every phrasing that wants the same answer goes in the same group, however differently it is worded. This is the heart of the method.

You are grouping by shared need, not shared words. welcome email examples and welcome email templates use different nouns, but a reader usually wants the same thing, so they belong together.

When you cannot tell, let the results decide. Search both phrases and compare the ranking pages. If they largely match, the intent is the same and the phrases are one group. If they diverge, split them.

04 - Name the single query each page owns

Give every intent group one primary query, written in plain words. That query becomes the page. Everything else in the group is a supporting phrasing the page will also rank for.

Treat the primary query as the page’s promise. It is the one thing no other page in the cluster may claim.

This is what makes the overlap check possible. A cluster where every page has a named query can be audited in minutes. Vaguely scoped pages cannot be audited, and they are the ones that drift into each other over time.

05 - Assign the umbrella to the pillar, the specifics to clusters

Now split the named queries. The broadest, category level query belongs to the pillar alone. Every narrower query becomes a cluster page covering one slice in depth.

The pillar answers the big question and points to the detailed pages. Each cluster answers one detailed question and points back up.

This guards against the most common collision of all. It is easy to build a pillar on email marketing and then commission a cluster on what is email marketing, at which point both chase the same broad intent. Keep the umbrella on the pillar and that overlap never forms.

06 - Run the overlap check before you write

With every page carrying one named query, read straight down the list and look for collisions.

If two primary queries are identical, that is an overlap. If one is a subset of another that serves the same need, such as email open rate under email open rate benchmarks, that is an overlap too. Either way, you caught it on paper.

The fix is almost free here. Merge the two intents, keep the broader query, and fold the narrower one in as supporting coverage.

Do it now. Merging two rows in a sheet takes a minute. Merging two live, ranking pages means choosing a survivor, migrating content, setting redirects, and waiting weeks for results to settle.

07 - Wire the links with distinct anchor text

Once the pages are written, connect them. Link every cluster up to the pillar, link the pillar out to each cluster, and add sideways links only where topics genuinely continue.

This two way wiring turns separate articles into a single unit that ranks as a group.

Watch the anchor text. The words in a link describe the page you point to, so link your send times cluster with anchor text about send times, not with a vague read more.

Specific anchors reinforce the one query, one page boundaries you drew. Generic ones blur them.

Decision

Same page or two pages?

Grouping by intent sounds simple until two keywords could go either way. When that happens, one question usually settles it: would a reader searching each phrase be satisfied by the same page?

If yes, they share a page. If no, they split. The table works through the cases that come up again and again, so you can match your borderline pairs to a pattern.

TABLE 01 / OVERLAP DECISION RULES

Grouping by intent is the work that decides where every keyword lives. Do it before you write.  

Fixing overlap you already have

If your cluster already exists, you cannot just redraw the map on paper. Two live pages may already be splitting the rankings for one intent. That needs a deliberate repair, not a fresh plan.

Start by choosing which page survives. Pick the stronger one overall: better backlinks, more complete content, or the cleaner URL.

Move anything useful from the weaker page into the survivor, then point the weaker page at it so their signals combine. For a page you are retiring, a permanent redirect passes its value along. For near duplicates you must keep reachable, a canonical tag names the version to index.

Google’s guidance on how to consolidate duplicate URLs sets out which signal to use in which case, and how strong each one is.

Do not fix overlap by rewriting both pages to be more different. That treats the symptom. Two pages built for one intent keep drifting back together. Consolidate to one, and the split resolves at the root.

Linking

Anchors that keep the boundaries clean

The map only holds if the internal links express it. A search engine reads a link’s anchor text as a statement about the target page.

So link your send times cluster with anchor text about send times. Vague anchors like click here or learn more tell the crawler nothing about which page owns which intent, and ambiguity is what you spent seven steps removing.

Two mechanics sit underneath this. First, the links must be crawlable. Google follows a standard HTML anchor with an href attribute, not a button or a script driven click that only behaves like a link.

If your links are built with click handlers, the crawler may never follow them, and the cluster falls apart from the engine’s view. Google’s reference on crawlable links and anchor text is worth checking your templates against.

Second, each anchor should name its specific destination, so the wording and the link topology together show how your pages relate.

Verify before you publish

Run this once the map is drawn, and again before anything goes live. Overlap creeps back in during the gap between planning and publishing.

Each item is a place a collision commonly hides. Every box you can honestly tick is a ranking problem you will never have to repair.

▪     Every page has exactly one primary query written next to it in plain words.

▪     No two primary queries are the same, and none is a plain subset of another that serves the same intent.

▪     The broadest, category level query belongs to the pillar and to no cluster page.

▪     Each cluster page targets a specific slice that the pillar does not try to own outright.

▪     Every cluster links up to the pillar, and the pillar links out to every cluster.

▪     Anchor text names the specific destination rather than repeating a generic phrase.

▪     Any pre existing pages that competed for a mapped intent have been consolidated into one.

The whole method in three lines

Map intents, not keyword strings, so every phrasing wanting the same answer lands on one page.

Give the pillar the broad umbrella term and each cluster a specific slice. Read down your named queries and resolve any collision before you write.

Where two live pages already compete, consolidate them into one strong page rather than making two weak ones look different.

Overlap is cheap to prevent and expensive to repair. Draw the boundaries once, verify them, and the cluster compounds instead of cannibalising itself.