Keyword clustering: turning a raw export into site structure

An export of twelve thousand queries answers none of the questions a site actually faces: how many pages to build, and what each one is about. The list is raw material. The structure is the result. Clustering sits between them, and most of the damage done in a search programme happens here rather than in the copy or the links.

Why cluster at all when you already have the list

Queries sit flat in an export; a search engine answers them with pages. One page might cover thirty queries, or fail to cover two if they are about different things. Without clustering, the decision about which queries belong together is made by eye, and every content plan downstream inherits that guess.

The cost is concrete. Split what the engine treats as one topic across several pages and those pages compete with each other, none of them gaining enough weight. Merge what the engine treats as separate topics onto one page and it answers no query completely, losing to narrower competitors.

Clustering is a way of asking the search engine what it considers one topic, instead of deciding on its behalf.

What to collect before you start

Clustering operates on a finished keyword set, and the quality of that set determines everything after it. The minimum worth starting with:

• Search volume per query, or there is no way to tell which cluster deserves attention.
• Current positions, if the site already ranks. A cluster where two of ten pages sit in the top 30 behaves differently from one starting at zero.
• The SERP for each query, at least the first ten URLs. This is the raw material for SERP-based clustering, and it is the slowest part to gather.
• An intent marker. Queries with different intent almost never share a page, however similar their wording.

A set without volume clusters exactly the same way, but there is nothing to weigh the output against. You end up with forty clusters, three of which carry all the traffic, and no way to tell which three.

One more precondition, usually remembered too late: the site has to be in a state to accept new pages. If half the current ones are not indexed, a structure of forty clusters lands on top of an unsolved problem: run the technical audit first, then the keyword work.

Three clustering methods and when each works

Only three methods see real use, and confusing them is the most expensive mistake available.

By words

Queries are grouped by shared words and word forms. The fastest method and the least reliable: "pizza delivery" and "pizza recipe" land in the same group, though they are entirely different SERPs. Useful for a first pass to strip junk out of a keyword set; not useful for designing structure.

By meaning

Queries are grouped by semantic proximity, by hand once and now usually by a language model. The method separates intent well: "buy" from "how to choose", "reviews" from "setup guide". But a model has no knowledge of how a particular SERP behaves, and will confidently merge what the engine keeps apart.

By SERP

Two queries count as one topic when their result pages overlap strongly enough. This is the only method grounded in the engine's own behaviour rather than an assumption about it. It is also the most expensive: you need the SERP for every query.

What works in practice is a combination. Words clean the set, meaning marks up intent, and the SERP makes the final call on where a cluster ends.

SERP clustering: what actually happens

The mechanics are simpler than they sound. Take the first ten URLs for each query. For every pair of queries, count how many URLs match. Above a chosen threshold, the two queries are linked. Linked queries are then assembled into groups.

The detail that matters is how those groups get assembled, and there are two approaches with different consequences.

Soft clustering: a query joins a group if it links to at least one member. Groups come out large and loose: a chain of A–B, B–C, C–D links will glue A to D, which share nothing at all.

Hard clustering: a query joins a group only if it links to every member. Groups are small, dense, and numerous. But each one is genuinely about a single thing.

For designing site structure, hard clustering is the safer default. Soft clustering produces a tidy picture of ten large clusters and hides three different topics inside each.

Threshold: three, five, or eight

The threshold is how many URLs must match before two queries count as one topic. It changes the output more than the choice of tool does.

• At 3 of 10 the grouping is broad. Clusters come out large and the structure flat, which works for informational sections where one substantial article really does cover a topic.
• At 5 of 10 you get the working default for most commercial projects: strict enough not to merge separate intents, loose enough not to breed near-duplicate pages.
• At 8 of 10 almost every query becomes its own cluster. That is worth doing in narrow niches with homogeneous SERPs, where the differences between queries genuinely matter.

The threshold cannot be guessed in advance. Standard practice is to run the set at all three and look at which one produces a cluster-size distribution that makes sense for the niche.

What to do with single-query clusters

After hard clustering, a large share of the set will sit in clusters of one. That is a normal outcome rather than a failure, and volume sorts it out.

• High volume and a cluster of one probably means its own page, and a competitive one. The SERP does not overlap with its neighbours because the topic stands alone.
• Low volume means the query folds into the nearest cluster by meaning as an additional phrase. It does not earn a page.
• Zero volume takes the query out of the set. These inflate the report and return nothing.

The mistake seen most often is building a page for every single-query cluster. That is how sites end up with eight hundred pages, forty of which get traffic.

Turning a cluster into a page

A cluster is not yet a brief. Getting from one to the other takes four decisions, each readable from the same SERP data you already collected.

1. Page type. Look at what ranks in the top ten for the cluster's head query: product pages, listings, articles, roundups. The engine has already shown which format it treats as a valid answer. Arguing with it costs more than agreeing.
2. Head query. The highest-volume query in the cluster, and the basis for the heading and the title.
3. Subtopics. The remaining queries, grouped by meaning, become subheadings. A language model earns its place here, because turning a list of queries into readable headings is something it does well.
4. Length. The average length of the pages already in the top ten, not a number from a general recommendation.

Going from structure to finished material is covered separately in our write-up on building a content workflow with AI.

Common mistakes

Four recur in nearly every project.

Word clustering sold as SERP clustering. Most fast free services do the former. The check is easy: if the service never asks for a region and returns instantly, it did not look at a SERP.

One region for the whole set. Commercial SERPs differ enough between cities that clusters diverge. A regional project has to be clustered in its own region.

Clustering once and calling it done. SERPs shift, topics merge and split. A live project's keyword set is worth rebuilding every six months, more often in fast-moving niches.

Mixing commercial and informational queries in one cluster. Even with high SERP overlap, this usually means the engine has not settled yet, while the queries stay different.

What does the work, and what it costs

Collecting SERPs is the paid part in any scenario, because it runs into service limits. The tools that genuinely cover the stages:

Prices from the gbseo.ru catalogue as of 19 September 2026; "retail" is the vendor's own price for the same subscription. The full set of nine tools costs 4 999₽ a month against 36 700₽ at retail. The calculator on the homepage prices any subset.

It is worth naming what the tools do not do. No service picks your threshold, and none decides whether a single-query cluster deserves a page. Those are judgements, not calculations.

A sequence that holds up

1. Build the keyword set with volume; strip obvious junk by words.
2. Pull SERPs for every query in the right region.
3. Run hard clustering at thresholds of 3, 5, and 8, and compare the distributions.
4. Pick a threshold; sort single-query clusters by volume.
5. For each cluster, read page type from the top ten and set the head query and subtopics.
6. Roll it into a content plan, prioritised by volume and current positions.

Six steps across a few thousand queries takes two or three working days. That is comparable to writing one long article, and it decides whether the next twenty are written for nothing.

FAQ

Can you cluster without collecting SERPs?

Yes, but it will be word or meaning clustering, with all their limits. Fine for a rough pass over a large set; not enough for designing structure.

Which threshold for a new project with no data?

Start at 5 of 10 with hard clustering. It is the safe setting: it will split a topic sooner than merge two, and separated clusters are easier to combine later than merged ones are to untangle.

Do Yandex and Google need separate clustering?

If the project works in both, yes. The result pages differ and the clusters diverge, especially on commercial queries. A workable compromise is to cluster on the project's primary engine and use the second to check borderline cases.

How long does a clustering result stay valid?

About a year in stable niches. Where SERPs reshuffle often, sets get rebuilt quarterly. The signal that it is time: pages in a cluster start losing ground to material in a different format.

What if a cluster comes out with a hundred queries?

Check whether it was soft clustering. A hundred queries in one dense cluster is rare; usually it is a chain of links that glued several topics together. Run it hard and see how many groups it breaks into.