Keyword clustering: how to group keywords into pages

What is keyword clustering?

Keyword clustering is splitting a collected keyword list into groups so that each group can be covered by a single page. You group by intent overlap, not by word similarity: if the person typing query A and the person typing query B want the same thing, those queries belong on one page. The group itself is called a keyword cluster.

The practical test is the SERP. Enter both queries in Google and compare the first ten results: a noticeable overlap means Google treats them as one topic, so one page can rank for both. Different results mean different clusters and different pages.

Keyword clustering or keyword grouping: is there a difference?

In practice, no. Keyword grouping, keyword clustering and "building keyword groups" describe the same operation: taking a flat list of queries and splitting it into sets that one page can serve. The words come from different corners: "grouping" from paid search, where you group keywords into ad groups, and "clustering" from the tools that automate it. They have drifted into being synonyms.

Two terms underneath them are worth keeping straight. A keyword cluster, or keyword group, is the result: one set of queries carrying one intent. Keyword clustering is the process that produces those sets. And neither is the same as keyword research: research gives you the list, clustering decides what to do with it.

The one place where the difference still bites is paid search, where a group is cut much finer than an SEO cluster — more on that below.

Why keyword grouping beats one page per keyword

Keyword grouping exists because the alternative does not survive contact with a real site. "One page per keyword" sounds logical, but any service has dozens of close phrasings, and a site of a hundred nearly identical pages gains nothing. The opposite happens instead: the pages start competing with each other, and Google picks one of them, rarely the one you would have picked.

The other extreme is more common: every keyword in the topic is piled onto a single service page in the hope that it will collect everything. That does not work either: the page becomes vague, answers none of the questions precisely, and loses to competitors who have a dedicated answer for each intent.

Clustering is the search for the middle ground between these two. This is the step where keyword research stops being a spreadsheet and becomes a site structure built from keyword research: you can see how many pages you need, what each of them is about and what is missing.

How to group keywords: semantic, SERP-based and intent-based

There are four ways to group keywords: by words, by meaning, by SERP overlap and by intent. They carry standard names, they produce different results, and I use all four, but in a specific order.

The working sequence is this. A draft grouping first — by words or by meaning, whichever your tool gives you. Then SERP clustering on top of it, because that is the only signal that is not my opinion: it relies on how Google has already divided the topic. Then a manual check of the boundaries, because automation does not know that two different terms mean the same service in your niche, or that the same term means different things for you and for a competitor.

The threshold nobody names. SERP clustering comes down to one number: how many of the top ten URLs two queries must share to count as one cluster. Three out of ten is loose and gives large clusters and few pages; five out of ten is strict and splits the same list into roughly twice as many. Neither is correct: it is a business decision, not a setting with a right value. On a small site I deliberately keep it loose: one strong page beats three thin ones, and thin pages are what small sites die of.

Intent is the check that runs across all four methods, and the four types are worth naming, because a cluster that mixes them is broken by definition:

• informational — "how to choose an air conditioner"; Google's quality rater guidelines call this a Know query;
• commercial — "air conditioner installation price";
• transactional — "order air conditioner installation"; a Do query in the same wording;
• navigational — a brand or a specific site; a Website query.

Commercial and transactional live together comfortably. Informational and commercial almost never do.

One cluster = one page = one intent

The rule is simple and broken constantly. All keywords inside a keyword group must share one intent. A classic case of mixing:

• "buy kitchen table": the person is ready to buy, and Google fills that SERP with category and product pages;
• "how to choose a kitchen table": the person is still comparing, and the results are guides and roundups;
• "standard kitchen table dimensions": the person needs one factual answer, and the results are tables and reference pages.

These are three clusters and three pages: a category or product page, a guide article and a reference piece. Merging them into one page produces text that is too long for a buyer and too promotional for someone still deciding.

Commercial modifiers deserve a separate check. "SEO services" and "SEO services pricing" are almost always one cluster, while "SEO services" and "what is SEO" are not, even though they share words. That is why I never rely on shared words where intent decides.

How many keywords should be in a keyword cluster

The answer clients dislike: as many as the meaning allows. A keyword cluster is defined by its intent boundary, not by a count. What actually varies is the type of page it feeds.

What is worth controlling is not the size of a cluster but its consistency. If the group contains phrases the page would have to answer in different ways, size stops mattering: split it. Two hundred consistent variants are fine; four that mix a buyer with a researcher are not.

Keyword clustering examples: 24 queries into 5 pages

Abstract rules are easy to agree with and hard to apply, so here is a keyword clustering example small enough to read in full. Twenty-four queries collected for an air conditioning company: twenty-two of them grouped into five clusters, two thrown away.

Three decisions in that table are the ones worth copying.

"Installation" and "installation cost" stayed together. The results are nearly identical — the same service pages rank for both — so the price question belongs on the service page rather than on a page of its own.

"Repair" left the installation cluster even though the same company does both jobs and the words overlap heavily. The top ten shares almost nothing between them, and a page trying to sell an installation and reassure someone with a broken unit does neither well.

The sizing questions became a calculator, not an article. Google fills that SERP with tools, and text for "how to choose". When the top is full of interactive results, a well-written article is the wrong format no matter how good the writing is.

The two discarded queries were a competitor's brand name and "air conditioner for a car" — a different business entirely. Cleaning those out before grouping is much cheaper than discovering them inside a finished cluster.

When to split a cluster and when to merge

Whether to split a cluster or merge two of them comes down to a handful of signals. These are the ones I use on live projects:

Split when:

• commercial and informational intent are mixed in the group;
• the SERPs for queries inside the group barely overlap;
• the page is already written but stalls on page three or four for part of the queries while ranking fine for the rest;
• Search Console shows queries with clearly different expectations hitting the same page.

Merge when:

• two pages fight over the same query and Search Console shows both ranking unstably;
• the pages differ only by a synonym in the title;
• the site is small and splitting leaves you with two thin pages instead of one solid one.

The second case is cannibalisation. It is expensive: impressions get divided between the pages, internal links get diluted, and both versions stay weaker than one page would have been. How to spot keyword cannibalization in Search Console data and what to do with the losing page is covered in a separate article. Often the problem dates back to a time when the structure was built without keyword research and pages were added as ideas came up.

Keyword clusters vs topic clusters

The two terms get swapped constantly and mean different things. A keyword cluster is a group of queries that one page answers. A topic cluster is a group of pages — a pillar page plus supporting articles linked back to it — covering one subject area.

They stack rather than compete: keyword clustering decides what each page is, topic clustering decides how those pages relate to each other. The order matters, and the common failure is doing the second without the first — a pillar page and ten satellites built around a topic nobody searches for in those words.

The part usually left unsaid: on a services site of twenty pages a pillar structure is more often harmful than useful. It inserts a layer of thin hub pages between the visitor and the service, and the link equity it is meant to concentrate had nowhere else to go anyway. Pillars start paying off when there is genuinely more material than a menu can hold.

Grouping keywords for Google Ads is a different job

The same phrase means two things depending on the channel, and a good share of the people searching for keyword grouping mean the paid one. In SEO a cluster feeds one page. In Google Ads a group feeds one set of ads, and it gets cut much finer: the closer the queries inside an ad group are to each other, the closer the ad text can be to the query, and that shows up directly in relevance and in what a click costs.

So an SEO cluster is the input for ad groups, not the output. "Air conditioner installation" and "air conditioner installation cost" live on one page and usually in two ad groups, because one ad can lead with the service and the other with the price. Copying a twenty-query SEO cluster into a single ad group is the standard route to a campaign where every ad is vaguely relevant to everything. Which of the two channels to build first is a separate question — Google Ads or SEO, which to start first.

Tools: what to cluster keywords with

Almost every guide on what to cluster keywords with is published by a company that sells a clustering tool, and the recommendation is always the same one. I do not sell one, so here is a neutral view of what the options actually are.

The part vendors leave out: on three or four hundred queries, doing it by hand in a spreadsheet is often faster than setting a tool up, because most of the time goes into checking boundaries and you would be checking them either way. Automation starts earning its place at roughly a thousand queries, or when the same job has to be repeated every month.

Can you cluster keywords with ChatGPT?

For fifty to a hundred queries, yes — a language model groups them faster than a person and usually sensibly. Past a few hundred it starts dropping keywords and inventing ones you never gave it, and nothing in the output tells you which of the two happened. The deeper limit is that the model has no SERP data: it groups by meaning, and meaning is exactly the signal that fails on pairs like "seo services" and "what is seo". The reliable way to use models here is embeddings plus cosine similarity — semantic clustering with a number you can tune — followed by a SERP check on the boundaries.

What keyword grouping changes on real projects

An honest limit first: there is no universal figure like "correct keyword grouping gives +N%" — too much depends on the niche and the state of the site. But the recurring patterns are worth naming.

First: on sites where the structure was built from inside the company, clustering almost always reduces the number of pages rather than increasing it. Half the sections turn out to be named after internal terms nobody searches for, while half of the real demand is not covered at all.

Second: the most expensive mistakes happen not in small clusters but at the top level: when two major landing pages are built for the same intent. It is not obvious at first, because both rank somehow, and the problem surfaces in Search Console months later.

Third: clustering is not a result yet. Even a perfectly grouped keyword set gives nothing if the pages are not indexed or the site is technically broken. That is why right after grouping I check why Google is not indexing the pages, and only then move on to content.

The mistakes that come back most often, in one list:

• grouping by a shared word instead of a shared intent — the SERP disagrees, and the page ranks for half its group;
• clusters cut too fine, producing five thin pages where one would have ranked;
• grouping done once and never revisited, while the results for those queries have moved on;
• no internal links between the pages of one topic, so every page starts from zero;
• a cluster assigned to a page that already ranks for a different one — cannibalisation created by the fix instead of solved by it.

Multilingual sites: clusters do not transfer between languages

Clusters do not transfer between languages, and on a multilingual site that makes this separate work rather than a translation. Estonian and Russian search for the same topic means different competitors, different phrasings and a different number of queries. Clusters overlap partially: some groups match, some break apart differently, and a few exist in one language only.

A small illustration of how it breaks. In Estonian, "kolimisteenus" (moving service) and "kolimine" (moving) look like one topic to anyone reading the words. The first returns companies, the second returns guides on how to pack: one commercial cluster and one informational one, out of a pair any translator would have merged.

Transferring the grouping from one language to another mechanically is a typical mistake. The result is a structure built for demand that does not exist in that language. The right way is to collect keywords for each language separately and redraw the cluster boundaries against that language's SERP, and if the language in question is one you do not speak, I described that step by step in keyword research in Estonian. The final section tree usually ends up similar: the languages differ, the business does not. I covered the choice of the priority language in more detail in the article on which language to target for SEO in Estonia, and once the trees do diverge, tying the versions together correctly becomes a hreflang job rather than a clustering one.

How to do keyword clustering step by step

The sequence I follow to do keyword clustering on a live site:

1. Collect the raw keyword set and clean out competitor brands and irrelevant phrases. Where the list comes from is its own job — keyword research covers it — and the source people skip is Search Console, which already knows what the site is being shown for.
2. Export it in a workable shape: query, search volume, and the top ten URLs if your tool gives them. Without those URLs there is nothing to compare.
3. Make a draft grouping — by shared words or with an automated tool. This is only a blank.
4. Check the doubtful pairs against the SERP. Unsure whether it is one cluster or two — compare the top 10 for both queries.
5. Label the intent of each group: informational, commercial, transactional, navigational.
6. Map clusters to pages — existing and missing ones. One group, one page, no exceptions. This step is what people mean by keyword mapping.
7. Find the overlaps — two pages for one cluster. Decide: merge with a redirect, or separate by meaning.
8. Prioritise — start with the commercial clusters closest to an enquiry.

From clusters to a content plan

After this you no longer have a keyword table but a task list: which pages to create, which to rewrite, which to merge. Three columns hold it — cluster, target URL, status: exists, rewrite, create. On a small market I order that list by money rather than by volume: a cluster of four queries in front of a paying service beats a cluster of forty in front of nothing. If the site is still being designed, build this map into the section structure during web development — changing URLs later costs more. And if the structure already exists and you suspect it was not built around demand, it makes sense to start SEO with rebuilding the keyword set.

Inside each page the main query of the cluster goes into the title, the H1 and the first paragraph, and the rest of the cluster belongs in the H2s and in the text where it fits naturally. The remaining phrasings do not have to appear verbatim at all — they describe what the page is about, they are not a checklist to tick off.

How to tell it worked

Not by the position of one keyword. Watch two numbers in Search Console instead: how many distinct queries the URL is shown for, and the total impressions of that URL. A correctly assembled cluster grows both. A reasonable horizon is six to ten weeks, less on a page that is brand new. The warning sign is impressions growing while clicks stay flat — the page is being shown for the whole group and satisfying none of it, which usually means the cluster mixed two intents after all.