How to Cluster Search Console Queries: I Tested 5 Ways

By Ugur Saritepe · September 22, 2026

To cluster Search Console queries, group each one under the page that already ranks for it. In September 2026 I scored that against four LLM configurations on three real sites, using maps I had built by hand as the answer key. The free method won on two of them, and lost on the third for a reason worth knowing.

What I was trying to do, and what I expected

I run TrafficTriage, which builds a topical map for a site: the query clusters it already serves, and what each cluster is missing. Today I assemble that map by hand from a Search Console pull. I wanted the server to do it, so I built a command-line harness and pointed it at two of my own sites and one customer's, with my hand-built maps as the answer key.

My first instinct was that a language model would do the grouping. That is what the tools sell, and in October 2025 Google shipped Query groups in Search Console Insights, which groups similar queries with AI and publishes no accuracy figure for it. So I ran the models first.

The LLM runs, scored

One call per run, 138 queries from game-scout.app, the same input every time. f1 is measured against my hand-built map for that site, so 100% would mean perfect agreement with me.

run                        placed   dupes   f1      cost
4o-mini, query strings     92/138   3 made up  77.8%   $0.003
4o-mini, query ids         71/138   0          26.3%   $0.002
4o, query ids             136/138   1          89.4%   $0.053
4o-mini, batched (40)     124/138   1          81.0%   $0.004

gpt-4o was good: 89.4%, 91.0 precision and 87.8 recall, 46.8 seconds, about five cents. It reproduced 20 of my 30 clusters exactly, choosing its own ids and labels. That felt like the answer.

Then I gave it 591 rows instead of 138 and it stopped partitioning altogether: 589 queries claimed 2,597 times, with a single cluster holding 528 of them. Batching fixed that, and it is also the only shape that fits, because the account's gpt-4o limit is 30,000 tokens a minute and a 591-row prompt asks for roughly 24,000 of them. A thousand-row prompt cannot even be retried inside its own minute.

The objection that turned out to be the finding

While I was writing this up, the site's owner side of me pushed back on the whole premise. This is what I typed at the time:

The argument is that Google has already done the grouping. Every impression in Search Console is a query paired with the page that served it. If two queries land on the same URL, Google has already decided they belong to the same intent, and paying a model to rediscover that is paying for arithmetic.

So I measured it.

Grouping by the page that already ranks

Same metric, same answer key, no model and no cost. One row per site:

site              f1      precision   recall   groups vs mine
game-scout.app    93.1%   100%        87.2%    40 vs 30
traffictriage     100%    100%        100%      7 vs 26
a customer site   51.3%   100%        34.5%    44 vs 11

Read the precision column before the f1 column. It is 100% on all three sites. That means the method never merged queries that belong apart. Only recall moves, and recall failing means the method split something I had joined, which is a much cheaper mistake to find and fix than two topics silently welded together.

The traffictriage.com row is the weakest evidence in the table and I am not going to dress it up: that property is small, so 7 groups against my 26 is agreement on a thin slice rather than a hard test. game-scout.app at 93.1% on 138 queries is the row doing the work.

The site it lost on, and how to tell if yours is that site

The customer site scored 51.3%, and the reason is specific rather than random. On that site one page ranks for many genuinely different intents. Grouping by page therefore piles all of those queries into one cluster, where I had separated them by hand. Precision stayed at 100% because nothing unrelated got joined; recall fell to 34.5% because a third of what I would have separated stayed merged.

That gives a usable test. Grouping by the ranking page works when:

• your pages are roughly one-topic-each, so a URL is a reasonable proxy for an intent;
• you have enough pages that the site's structure already encodes your topics, which on game-scout.app is about 50 list pages;
• you want the map to describe what you have, not to propose what you are missing.

It breaks down when:

• a few broad pages absorb many intents, which is the normal shape for a small site or a tool with one landing page per language;
• you want clusters for pages that do not exist yet, which no method reading your own Search Console data can give you.

The bigger problem was the input, not the method

Halfway through, I asked how 138 queries could possibly represent the site, and the answer was worse than I expected:

game-scout.app took 66,321 impressions in the 28 days to 17 August 2026. The 138 queries in my committed map carry 8.6% of them. Worse, the cut is not the biggest 138 queries. Rows come back sorted by clicks, so the zero-click tail is alphabetical, and the 250-row limit lands mid-alphabet: the last query row was alaskan road truckers ps5 and the last page row was tourist-bus-simulator. Everything after "a" in the zero-click tail was never seen at all.

Two things follow that are worth knowing whatever tool you use. First, a page with no query rows is normal and not a fault: 174 of the customer site's 417 pages, 42% of them, had zero query rows, because Google withholds rare queries for privacy. No row limit fixes that. Second, page totals and the sum of a page's query rows disagree by 20 to 600 times on game-scout.app. One of my clusters totalled 974 impressions at page level and 11 at query level. If you threshold a cluster on its query sum, you are measuring the sample, not the cluster.

Which pages to keep turned out not to need a per-site rule, because traffic is a power law. game-scout.app's list pages earn 1,000 to 6,000 impressions each and its individual game pages earn 1 to 30, so an impressions cut selects the list pages without anyone writing down that list pages matter. On the customer site the top 10 pages of 417 carry 47.5% of impressions, the top 50 carry 73.5% and the top 100 carry 82.9%.

One thing a topical map cannot do

A separate session the same week found that my published map's 52 clusters across 15 groups matched the site's own internal registry exactly, because the map's group layer is seeded from that registry. The map cannot surface a topic the site has never heard of. Anything built from your own Search Console data has the same ceiling by construction: Search Console only reports queries you already get impressions for.

That is worth saying plainly because the obvious next move is wrong. Google's spam policies name building a page per query variation as both a violation and ineffective, and a cluster map full of coverage gaps is a very easy way to drift into doing exactly that by accident. A cluster telling you it is missing four page types is a prompt to think, not a work order.

What to do with this

1. Pull query and page together, not queries alone. The pairing is the grouping. A query-only export throws away the one signal you need.
2. Group by the URL, then read the merges. Any cluster that looks too broad is a page absorbing several intents, which is a finding about that page rather than a failure of the method.
3. Check your sample before you trust the map. Compare the impressions your clustered queries carry against your site total. If it is single-digit percent, as mine was, the map describes a corner of your site.
4. Reach for a model only for the leftovers. Queries on pages that absorb many intents are the part that needs judgment. That is a much smaller prompt than your whole query list, which also means it will not fall apart at 591 rows.

What I have not fixed

The method that won this test is not the method my own product uses. As of 22 September 2026 the topical map is still assembled by hand from a 250-row pull, and the design that would change that is sitting on a branch nobody has merged. My own published map is built from 138 queries that carry 8.6% of the site's impressions, and the cut that produced them is alphabetical rather than by size. I have not fixed that either.

I should also be clear about what the scoreboard means. The answer key is my own hand-built maps, so f1 measures agreement with me, not correctness. Three sites is three sites. The five cents for the gpt-4o run came from remembered pricing I flagged at the time and never confirmed against an invoice. What I am confident of is narrower than the table looks: on a site whose pages are mostly one topic each, paying a model to group your queries buys you nothing that the page dimension was not already telling you for free.

There was a second thing I typed that day, which is the reason this ran at all:

The eval was the cheapest way to settle that. It cost about six cents in model calls and it ended with the free method winning, which is not the outcome I was building toward.

If you want to see the cut your own site is working from, the free triage report checks whether your pages are readable and indexable in the first place, which is upstream of all of this. More of the AI-assistant SEO series works through my own numbers the same way, including what happened when I built hub pages for these clusters and why average position is another Search Console number that does not mean what it looks like.

FAQ

How do I cluster Search Console queries?

Group each query under the page that already ranks for it. Search Console gives you that pairing for free in the query plus page dimension. Scored against hand-built maps on three sites in September 2026, that method reached f1 93.1% on one site and 100% on another, against 89.4% for a gpt-4o run on the same input that cost $0.053 and took 47 seconds.

Do I need AI to build a topical map?

Not for the grouping step. On two of the three sites I tested, grouping by the ranking page matched my hand-built map better than the best LLM run did. AI earned its place on the third site, where one page ranked for many different intents and grouping by page merged things a human would separate.

What is Query groups in Search Console?

A Search Console Insights feature Google announced in October 2025 that groups similar queries using AI. Google's announcement does not say what method it uses, publishes no accuracy figure, and names no minimum query volume. It is a view on your data, not an export you can build a content plan from.

Why does Search Console show so few queries for my site?

Two separate cuts. Google withholds rare queries for privacy, so a page can have real impressions and zero query rows. Then the API or tool you pull with applies a row limit on top. On one site I checked, 174 of 417 pages had no query rows at all, and the 250-row pull was an alphabetical slice of the zero-click tail.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works