You type "keyword clustering" into Google and you get about four million results telling you to "group keywords by topic." Thanks. That's like telling someone to cook a risotto by "combining the ingredients." The real question, the one that eats your afternoon, is which signal decides that two keywords belong together—and what you do when they don't want to sit in the same bucket.
Here's the part nobody tells you upfront: there is no single correct clustering. A cluster is a bet on how a search engine understands intent, and search engines disagree with each other more often than you'd think. Get that into your head and the whole process gets easier.
Key Takeaways
- Cluster by search intent and SERP overlap, not by how much the words look alike.
- A practical working size is 8 to 15 keywords per cluster; below 5, you have a page, not a topic.
- When a keyword sits between two clusters, put it where the SERP looks most similar and keep a note on why.
- Semantic clustering groups synonyms. SERP clustering groups intent. You usually need the second one to decide page structure.
- Validation happens after publishing: track average position per cluster, not per keyword.
- Cluster mainly around one page per intent. Two pages chasing the same intent is cannibalisation waiting to happen.
How to cluster keywords by topic without guessing
Most tutorials start with the tool. I'd start with the opposite: why you're clustering at all. If it's to fill a spreadsheet, stop. If it's to decide which page you're going to write next and which existing page you're going to expand, then clustering is doing its job.
There are two families of method, and they answer different questions.
Semantic clustering vs SERP clustering
Semantic clustering groups keywords by meaning. It uses the words themselves—sometimes embeddings, sometimes plain lexical similarity—and it's fast, cheap, and works offline on ten thousand rows at once.
SERP clustering groups keywords by the pages that actually rank for them. Two keywords land in the same cluster when their top results overlap heavily. It's slower, needs data, and it reflects how engines currently treat intent rather than how a dictionary treats words.
Which one wins? In my opinion, SERP overlap—and I'll take the argument. Here's why. Take "how to cluster keywords" and "keyword grouping methods." Semantically, near-identical. Open the two result pages and you'll often find different intent: one wants a definition, the other wants a workflow. Merge them and your page tries to serve two audiences and serves neither properly.
| Method | Signal it uses | Best for | Main weakness |
|---|---|---|---|
| Semantic (embeddings) | Meaning of the words | Large lists, fast triage, first pass | Ignores intent; merges different jobs |
| Lexical / n-gram | Shared words and phrases | Spotting obvious duplicates | Blind to synonyms |
| SERP overlap | URLs in common across results | Deciding page structure | Needs reliable ranking data |
| Hybrid | Meaning first, SERP to confirm | Production workflows | More steps, more time |
What is a keyword cluster?
A keyword cluster is a set of search queries that share one intent and can be served by one page without that page contradicting itself. That's it. No mystique.
The word "topic" in "topic cluster" gets used loosely to mean two things: a small cluster around a single page, and a large cluster around a pillar page with several supporting articles. Confusing the two is where a lot of content plans go wrong—you end up with eleven pages all roughly covering the same thing, and Google picks one to rank while you wonder what happened to the other ten.
A working process I actually use
I tried the fully automated route first. Uploaded roughly two thousand keywords to a clustering tool, set the similarity threshold, hit run, exported. The output looked beautiful and was, in practice, close to useless. The tool had merged "how to cluster keywords" with "keyword clustering tool" because both contain the same three words. Different beasts. One is a how-to, the other is a shopping query.
Here's what replaced it.
Step 1: build the pool from queries, not guesses
Pull real queries. Your own site search, your Search Console data, autocomplete, the question suggestions on a competitor's page. I keep a raw list of around 300 to 600 queries per topic area. Not thousands. You don't need thousands to start; you need the ones close enough to your site to ever rank.
Step 2: run embeddings for a first pass only
An embedding pass gets you from 600 rows to maybe 40 loose groups in a few minutes. Treat those groups as proposals, never as decisions. If you're doing this without a paid tool, a free clustering tool with a similarity slider will do fine for a list this size—just don't trust its default threshold.
Step 3: confirm each group against the SERP
Now the slow part, and the one that pays. For each proposed group, check whether the top results for its keywords are broadly the same pages. Rules I use:
- Same three or more URLs in common across two keywords: merge them.
- No overlap at all: split. No debate.
- Partial overlap: this is an ambiguous case. Hold it aside; you'll see how to handle it below.
- One keyword brings back a totally different content type—a video, a product page, a forum thread—where the others bring back guides. That keyword belongs somewhere else.
Step 4: name the cluster with the intent in mind
Give every cluster a label that describes the job to be done, not the words it contains. "Clustering methods explained" is a label. "Keyword + cluster + how" is a bag of words. The label is what you'll hand to a writer, and it's what keeps a ghost cluster from sneaking into your plan.
The ambiguous cases that nobody writes about
Every real keyword list has orphans and overlaps, and every clean tutorial pretends it doesn't. So let's do the awkward part.
A keyword sits between two clusters
Put it where the SERP overlap is strongest and keep a one-line note explaining your reasoning. That note matters more than the decision. Six months later, when the page isn't ranking, the note tells you whether the hypothesis was wrong or the execution was.
A keyword fits nowhere
You have three options and you should pick deliberately: park it in a "backlog" list and revisit later, build a small standalone page for it if the volume justifies the effort, or drop it. Most keywords belong in the backlog. A cluster of one isn't a cluster; it's a page idea. That's fine, just call it what it is.
Two clusters keep bleeding into each other
Then you probably have one cluster that you've split in two, or two pages competing for the same intent. Merge the clusters, then decide which single page should own them. Two pages on the same intent is the fastest route to cannibalisation I know, and it's harder to spot than obvious duplication because both pages look perfectly reasonable in isolation.
How to tell a cluster is working
Publishing is where most people stop measuring. Which is a shame, because the cluster is the unit that should be judged, not the individual keyword.
Three numbers I watch, roughly three months after a cluster goes live:
- Coverage: how many of the cluster's keywords your page appears for at all. Rising coverage means the page is being understood as relevant to the topic, not just one phrase.
- Average position across the cluster, not the best-performing keyword. The average tells you whether the page is drifting upward as a whole or just catching one lucky query.
- Internal clicks. If nothing links to the cluster from your existing content, you're leaving the job half done. Add the link from a related page; it's often the cheapest change available.
If coverage climbs while average position stays flat, the page is being seen but not chosen. That's a title and snippet problem, not a clustering one. Knowing the difference saves weeks of pointless rewriting.
Clustering for AI answers, not just blue links
Something shifted over the past couple of years that's worth naming. People increasingly get an answer assembled from several sources rather than a list of pages to click. The consequence for clustering is straightforward and slightly uncomfortable: a cluster needs to be extractable, not just comprehensive.
In practice that means concrete definitions that stand alone, one claim per paragraph, and a clear answer near the top of the page rather than buried under five hundred words of warm-up. Vague clusters—the ones where nobody could say what question the page answers—become invisible in that environment. Sharp ones get quoted.
Whether your audience arrives through a search results page or an AI summary, the underlying work is the same: one intent, one page, one clear answer. That hasn't changed.
Should I cluster before or after I write?
Before. Cluster a topic before you commit to a page outline, so you know which intent the page is being written to serve. Clustering after the fact is a diagnostic exercise, useful for finding cannibalisation but expensive in rewrites.
How many keywords should a cluster contain?
For a single page, aim for eight to fifteen queries. Fewer than five and you probably have a page idea, not a cluster. More than twenty and you should check whether you've actually merged two intents together.
Do I need a paid tool?
No. A free clustering tool with an adjustable similarity threshold handles a few hundred keywords. What you can't automate away is the SERP confirmation step, and that's where the real decisions get made.
Which brings me back to the thing worth remembering. Clustering isn't a sorting exercise. It's an argument about what your reader wants, and you're allowed to be wrong. Make the call, write the note explaining why, and let the data correct you. The people who get good at this aren't the ones with the best tool—they're the ones who keep a record of their reasoning and actually revisit it.
