Keyword Clustering: Why SERP Overlap Beats String Similarity

Search “keyword clustering” and page one is a row of tool vendors teaching the same procedure: export your keyword list, group the ones that look alike, assign each group a page. The procedure is not wrong so much as it dodges the only question a content plan actually turns on: which of these queries can one page win at the same time? Grouping by what the words look like — shared stems, shared modifiers, embedding similarity — answers a different question, and it answers it badly. Two queries belong on the same page when Google returns substantially the same results for both. Not when they rhyme.

That is the thesis of this guide: the unit of clustering is SERP overlap, not string similarity — and once you cluster that way, the cluster (never the keyword) becomes the unit of the entire content plan. This sits under our agentic SEO pillar as the planning layer: it decides what pages exist before the find → fix → verify loop ever touches them.

What keyword clustering actually is — and what it is for

Keyword clustering is the step between a keyword list and a content plan. A raw list of a thousand candidate queries is unusable: you cannot build a thousand pages, and you should not — most of those queries are the same demand phrased differently. Clustering compresses the list into groups that share intent, so each group maps to exactly one page. Done well, it answers three questions at once: how many pages the plan needs, what each page must cover, and which query in each group is the head term the page is judged by.

The failure mode is deciding “shares intent” by proxy. The proxies on offer are lexical (do the strings share words?) and semantic (do their embeddings sit close together?). Both measure language. Neither measures the thing you are actually betting a page on — how Google resolves the query. The only public, per-query record of that resolution is the SERP itself, which is why the overlap method works: it reads Google’s answer instead of guessing at it.

The two clustering methods — only one measures intent

Every clustering approach in circulation reduces to one of two families. They sound interchangeable in a tool’s feature list. They produce materially different plans.

Lexical and semantic clustering: grouping by what words look like

Lexical clustering groups queries that share tokens — “crm software,” “crm software pricing,” “best crm software” land together because the strings overlap. Semantic clustering upgrades the comparison to embeddings: queries whose vectors sit close in meaning-space cluster even without shared words. Both are cheap, fast, and run entirely offline — which is exactly why the volume-pricing of most tools favors them. And both inherit the same blind spot: they model the question and ignore the answer. Language similarity is a guess about intent. Sometimes the guess is right. The problem is you cannot tell which times, because the method contains no check against reality.

SERP-overlap clustering: grouping by what Google already decided

SERP-overlap clustering asks a blunter question: when real users type these two queries, does Google return substantially the same top results? If the top ten for query A and query B share several URLs, Google — with all its query-understanding machinery and years of click data — has already concluded the two express one intent, satisfiable by one page. You are not inferring intent from language; you are reading the verdict of the system that will judge your page anyway. That verdict is the ground truth every other method is trying to approximate.

Why string similarity gets intent wrong

The failure runs in both directions, and each direction costs a different way. Direction one: similar strings, different intents. “Coffee grinder” and “grind coffee” share nearly every token; one SERP is product listings, the other is how-to content. A lexical clusterer merges them, you build one page trying to serve both, and the page ranks for neither — Google reads mixed intent as answering no one well. Direction two: different strings, one intent. “Best CRM for small business” and “small business CRM reviews” barely correlate as strings, but their SERPs are close to identical. A string-based method splits them into two pages, and now you have written two thin pages competing against each other for one slot — keyword cannibalization, manufactured by your own methodology.

The second failure is the expensive one, because it compounds. On a site we audited, the property ranked deep — pages four to eight — for dozens of long-tail variants of the same commercial question, with no single page built to answer it. String-clustered, those variants looked like a dozen separate topics deserving a dozen separate briefs. Their SERPs told the opposite story: heavy overlap, one intent, one strong page required. The string method would have multiplied the site’s existing problem by twelve. The overlap method collapsed it into one fix.

Merge what should be split and the page ranks for nothing. Split what should be merged and your pages cannibalize each other. String similarity commits both errors — and cannot tell you when.

The SERP-overlap method, step by step

The method is simple enough to run by hand on a small list and mechanical enough to delegate on a large one. Five steps.

1. Assemble the candidate list. Seed keywords, their expansions, and — the step most guides skip — the queries your own Search Console already shows impressions for. Your GSC is the one keyword source that reflects demand you are already eligible for; cluster it first.
2. Pull the live top 10 for every query. Not cached rankings from a database — the current SERP, because overlap is only meaningful between results captured in the same window.
3. Score every pair by shared URLs. Count how many of the top ten results two queries have in common. The working convention: 3 or more shared URLs out of 10 means the queries share intent and belong on one page. Raise the threshold to 4–5 when the stakes of a wrong merge are high (commercial money pages); keep 3 for informational long-tail.
4. Cluster around hubs. Take the highest-volume unclustered query as the hub, attach every query that clears the overlap threshold against it, remove the cluster from the pool, repeat. Each finished cluster is one page: the hub is the primary keyword, the members are the subtopics, headings, and FAQ entries the page must cover.
5. Reconcile against pages that already exist. Map every cluster to a URL — an existing page to strengthen, a set of cannibalizing pages to consolidate, or a gap to build. This is where the plan stops being a spreadsheet and becomes a task list.

A note on what the threshold buys you. It converts a fuzzy editorial judgment — “do these feel like the same topic?” — into a reproducible test with a number attached. Two people running the method on the same list get the same clusters. That reproducibility is what lets clustering be delegated to an agent at all: the instrument that reads the SERPs is the same one covered in our guide to SERP analytics, pointed at pairs of queries instead of one.

The cluster — not the keyword — is the unit of the content plan

Here is the reframe that makes the method worth the SERP calls. Once clusters exist, every planning decision that used to be made per keyword gets made per cluster, and every one of them improves. Demand: a hub at 480 searches a month looks marginal alone, but a cluster aggregates the volume of every member — the long tail is not competition for the head term, it is the same page’s upside. Difficulty: you assess winnability once, against one SERP, instead of hand-waving across forty. Cannibalization: it cannot occur by construction, because one intent maps to one URL. Measurement: the page is judged on the whole cluster’s clicks, which is the honest unit — a page that ranks for its hub and thirty variants is succeeding even if any single variant looks small.

The zero-click era sharpens the case rather than weakening it. When an AI Overview or an answer engine composes a response, it selects a small number of sources per intent — and a site that scattered one intent across five thin pages has five weak candidates where it needed one strong one. Consolidating a cluster into a single authoritative page is as much a citability play as a ranking play; the mechanics of that shift are covered in our guide to zero-click SEO.

Where clustering sits in a closed loop

A cluster map is not a deliverable; it is an input. The failure pattern with clustering — as with every planning artifact in SEO — is that it gets produced once, admired, and abandoned: a beautiful spreadsheet nobody reconciles against reality again. In a closed loop, each cluster becomes a task with a testable claim attached at creation time: the page this cluster maps to, the fix or build it needs, the expected impact, and the metric that will judge it — clicks or position on the hub query, committed before the work ships. Roughly three weeks after the page lands, the metric gets re-read and the task is confirmed or reopened. That contract — find, fix, verify — is the mechanism described in our guide to closed-loop SEO; clustering is simply its planning stage done at the right resolution.

The verification argument also settles which clustering method to use. A string-based cluster produces an untestable plan — if the page underperforms, you cannot tell whether the execution failed or the grouping was wrong from the start. A SERP-based cluster carries its own evidence: the overlap that justified the merge is on record, so a page that fails to move gets diagnosed against a documented hypothesis instead of a hunch. Plans built on measured overlap can be audited. Plans built on similar-looking strings can only be defended.

Honest limits: where SERP clustering breaks

The method has real costs and real edges, and pretending otherwise is how tools oversell it. It costs one live SERP pull per query — trivial for two hundred keywords, a budgeting decision for twenty thousand; the sane pattern is a cheap string-based rough cut first, with SERP overlap confirming or splitting the merges that matter. SERPs are also volatile: an overlap measured today is a snapshot, not a deed, so clusters on queries you care about deserve re-checking quarterly — and any time a page that was winning starts slipping, because a cluster that splits in the wild is a common, silent cause. And thin SERPs lie: on low-volume queries Google sometimes returns near-identical results for genuinely different intents simply because little content exists, so treat overlap on sparse SERPs as a weaker signal and let the threshold rise. None of these limits argues for retreating to string similarity. They argue for treating clustering the way this whole discipline should be treated — as a measurement that decays, on a re-measurement schedule, not a one-time artifact.

The fastest way to see your own clusters is to start from the queries you already have. A free SEO report connects your Search Console and surfaces the pattern this guide keeps pointing at: the long-tail variants you already rank for that no single page owns — the clusters hiding in your own data, waiting to be consolidated. If you would rather have the whole loop run for you — clustering, consolidation, and the three-week verification that proves it worked — book a call.