Keyword Clustering Tool

What clustering is actually for

One page per keyword produces a library of thin pages that overlap each other. One page for twenty loosely related keywords produces a page with no clear subject. Clustering is how you find the join: group the terms that a single page can genuinely satisfy, and separate the ones that cannot share a page no matter how comprehensive you make it.

That is the useful framing. The framing you will usually see instead is that clustering prevents "keyword cannibalisation", which is worth unpicking, because it is not a term Google uses and the mechanism it describes is not quite what happens.

What Google actually does when two of your pages overlap

Google does not penalise you for having two similar pages. It clusters them, which is a word worth noticing on a page about clustering.

The canonicalization documentation, last updated 20 August 2026, describes the process directly. When Google indexes a page it determines the primary content, or centrepiece, of that page. If it finds multiple pages that seem to be the same, or whose primary content is very similar, it clusters them together, then chooses the one that its signals suggest is the most complete and useful for searchers and marks that as the canonical. The rest are duplicates.

Three consequences follow, and they are more specific than "cannibalisation is bad":

1. You do not choose the winner. The documentation is explicit that a rel="canonical" annotation is a hint, not a rule, and that Google may pick a different page than you do. So the outcome of publishing five overlapping pages is not that they share the traffic. It is that one of them gets it and you do not get to say which.
2. The losers get crawled less. The canonical is crawled most regularly and duplicates less frequently, deliberately, to reduce crawl load. So a page that loses the clustering decision also becomes slower to update in the index, which makes it harder to fix.
3. Quality is judged on the canonical. Google says it uses the canonical page as the main source to evaluate content and quality. Your four weaker pages are not dragging the good one down directly, but they are not helping it either, and they are consuming the attention you spent writing them.

Also worth saying, because the panic around this topic is overdone: the same document states that some duplicate content on a site is normal and is not a violation of Google's spam policies. Overlap is a planning inefficiency, not an infraction. There is a real line, and it is elsewhere. The spam policies, last updated 15 May 2026, define doorway abuse to include creating substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy. Splitting one subject across twelve near-identical pages to catch twelve query variants is what that sentence is describing. Two posts with some overlap is not.

The four search intents

The rule that does most of the work: two keywords with different intent cannot share a page, however similar the words are. AI chatbot pricing and best AI chatbot differ by one word and want two entirely different documents, one with numbers and one with a table of options. Meanwhile how to fix a 429 error in Make and Make.com rate limit exceeded share almost no vocabulary and want exactly the same page.

That asymmetry is the whole reason string similarity is not enough on its own.

Worked example: clustering a real 117-post library

Here is the method run against something real rather than a hypothetical list. This site has 117 published posts. Grouping them by the first token of the slug gives the actual topic distribution:

Two things fall straight out of that table, and one of them is uncomfortable.

The uncomfortable one. The conventional rule, which this tool has recommended for as long as it has existed, is that a cluster of ten or more terms wants a hub: one pillar page plus supporting posts, all linked to each other. There are five clusters here above ten, and there is no hub page for any of them. Not one. The library grew post by post, each one clustered correctly at the keyword level, and the structural layer that is supposed to sit above the clusters was never built. That is the most common way this fails in practice, and pointing at somebody else's site to illustrate it would have been dishonest when the example was sitting right here.

The second one. Thirteen posts belong to no group at all. Under the same conventional rule, a cluster of one to three terms should be folded into an existing page rather than given its own. Some of those thirteen are genuinely standalone subjects. Some are almost certainly a paragraph inside a post that already exists.

The pair the arithmetic missed

Now the part worth the arithmetic. Inside the chatbot group there are two posts:

• ai-chatbot-lead-qualification-questions, titled AI Chatbot Lead Qualification Questions
• lead-qualification-bot, titled How to Build a Lead Qualification Bot

Score those with Jaccard similarity on the title tokens, which is what a cheap clustering script does. Drop the stop words how, to and a, and you have:

• Set A: ai, chatbot, lead, qualification, questions (5 terms)
• Set B: build, lead, qualification, bot (4 terms)
• Intersection: lead, qualification (2 terms)
• Union: ai, chatbot, lead, qualification, questions, build, bot (7 terms)
• Similarity: 2 / 7 = 0.29

Now normalise one synonym before scoring, treating bot and chatbot as the same entity, which they are:

• Set A: ai, bot, lead, qualification, questions (5 terms)
• Set B: build, lead, qualification, bot (4 terms)
• Intersection: bot, lead, qualification (3 terms)
• Union: ai, bot, lead, qualification, questions, build (6 terms)
• Similarity: 3 / 6 = 0.50

One synonym substitution took the score from 0.29 to 0.50, a 72% increase. A clustering threshold of 0.4, which is a common default, puts those two pages in separate clusters before normalisation and in the same cluster after it. The pages are the same pages either way. Only the measurement changed.

This is why token-overlap clustering alone is not safe. It cannot see that bot and chatbot are one entity, that 429 and rate limit describe one error, or that GHL and GoHighLevel are one product. Every one of those blind spots produces a pair of pages that will end up in the same cluster inside Google's index while sitting in different clusters in your content plan.

The fixes, in order of how much they cost you:

1. Normalise entities before you score. Product names, abbreviations, and singular against plural. Ten minutes of substitution list, applied every time.
2. Check the intent before you split, not after. If two terms score low but share intent and share an entity, look at them by hand.
3. Compare the actual results pages. If two queries return substantially the same top ten, Google has already told you they are one page. Nothing you infer from the strings beats that.

From clusters to a plan

That last row is the one to take seriously, because it follows directly from the canonicalization documentation. If you publish fourteen posts about a subject and no page that owns the subject, then when a searcher asks the broad question, Google chooses whichever of the fourteen it considers most complete. It will usually be a page you wrote about something narrow.

Once the clusters are settled, run the primary term of each through the Keyword Research and Intent Analyzer to confirm the content type, then hand each cluster to the Content Brief Generator so the writer has the whole cluster in front of them rather than one term.

If clustering reveals pages you already published that should have been one page, you have two mechanical jobs: point the weaker page at the stronger one with the Canonical Tag Generator, or merge and redirect it with the 301 Redirect Rule Generator. Prefer merging. A canonical tag is a hint, and consolidating the actual content is the thing that makes the surviving page better rather than merely preferred.

Common mistakes

Clustering by keyword volume instead of by intent. Volume tells you whether a cluster is worth writing. It tells you nothing about which terms belong together.

Trusting a similarity score without normalising entities first. The worked example above is exactly this mistake, found on my own site, and the difference was 0.29 against 0.50 on one substitution.

Clustering only new keywords. The overlap that costs you is nearly always with pages you already published, because those are the ones already competing. Run the cluster against your existing URLs, not just the research list.

Building the supporting posts and never the hub. Five clusters over ten posts here and no hub for any of them. It is the most common structural gap in a library that grew organically, and it happens precisely because every individual decision was reasonable.

Splitting a cluster to catch more query variants. Publishing near-identical pages for how to build a lead qualification bot and build lead qualification bot is the pattern the doorway policy describes as substantially similar pages standing in for a browseable hierarchy. One page, both phrasings inside it.

Assuming Google will honour your choice of canonical. It is documented as a hint. If you need a specific URL to be the one that ranks, merge the others into it and redirect. Then there is nothing to choose between.

Treating overlap as an emergency. Google says plainly that some duplicate content is normal and not a spam violation. Two posts with an overlapping paragraph is a tidy-up, not a crisis.

Frequently Asked Questions

How many keywords should go in one cluster?

Four to ten is the range that reliably works, because that is roughly how many distinct questions one page can answer while still having an obvious subject. Below four you are usually looking at a section of a larger page. Above ten, the page starts losing the clear centrepiece that Google's indexing process is looking for, and a hub with supporting pages does the job better.

Is keyword cannibalisation a real ranking penalty?

No, and it is not a Google term. What Google documents is canonicalization: it clusters pages whose primary content is very similar and picks one as canonical, and it states that some duplicate content on a site is normal and not a spam policy violation. The real costs are that you do not control which page wins, the others get crawled less often, and you spent writing time producing pages that were consolidated away.

Can I just use a similarity score to cluster automatically?

You can start there, but not finish there. String similarity cannot tell that bot and chatbot, or GHL and GoHighLevel, are the same entity. On two real posts of mine the score went from 0.29 to 0.50 after normalising a single synonym, which is enough to cross a typical 0.4 threshold. Normalise entities first, then check anything that scores near your threshold by hand.

What is a good similarity threshold?

There is no correct value, and anyone quoting one without saying what corpus and what preprocessing produced it is quoting a number that will not transfer to your list. Thresholds around 0.4 are a common starting point, but the threshold is only meaningful relative to your normalisation, your stop-word list and whether you are scoring titles, slugs or full text. Set it, look at the borderline pairs by hand, and adjust.

Should keywords with different intent ever share a page?

Rarely, and only when one intent is clearly dominant and the other is a single question the reader might have on the way. A commercial best X term and a transactional X pricing term want different pages, because one needs a table of options and the other needs numbers. Trying to serve both usually produces a page that does neither well.

Do I need a pillar page for every cluster?

Only for the large ones. Under about ten terms, the dedicated page is the pillar. Over ten, you want a page that owns the broad subject and links out to the specifics, otherwise the broad query gets answered by whichever narrow post Google judges most complete. This site currently has five clusters above ten posts and no hub for any of them, which is a fair illustration that the gap opens quietly.

How do I fix pages that are already competing?

Decide which one should survive, then make it the better page by moving the useful parts of the others into it, and 301 redirect the rest. That is more work than adding a canonical tag and it is more reliable, because a canonical is a hint Google may decline while a redirect is not. Use a canonical when both URLs genuinely need to stay reachable for users.

Does clustering help with AI answer engines as well as search?

The same structural logic applies, for a slightly different reason. An answer engine extracting a response wants a page with an unambiguous subject and a self-contained answer in it. Five overlapping partial treatments of a subject give it five weak candidates. One complete page gives it one strong one. Nobody has published a reliable measurement of how much this matters yet, so treat it as a reason to prefer consolidation rather than a quantified benefit.

Where this tool stops

This tool clusters a list you paste into it. It has no idea what is already on your site.

That is the gap that matters, because the overlap that costs you something is almost never between two keywords you have not written about yet. It is between the post you are about to commission and the one you published fourteen months ago and forgot. Clustering a research list catches the first problem. Nothing you paste in catches the second.

Doing that properly means reading your own library rather than your keyword list: pull every published URL with its title and headings, normalise the entities, score every pair, and surface the ones above your threshold along with the ones just below it that share an entity. Then keep it running, so the check happens before a brief is issued rather than during an annual audit that never gets scheduled. That is how the 0.29-against-0.50 pair above was found, and it is a scheduled job rather than a piece of insight.

It is also unglamorous automation of exactly the kind I build: an n8n or Make.com workflow that reads your CMS or sitemap, does the arithmetic, and puts a short list in front of a human who can make the call. The same shape as the pipelines in how to automate lead generation, applied to your own content instead of your prospects, and closer in spirit to the filtering logic in how to build a lead qualification bot: the value is in what it stops you doing.

If your library has grown past the point where you can hold it in your head, that is the fixable part. You can see how I work on Upwork or Fiverr, or book a consultation and bring a sitemap.