Cluster queries by topic & intent

Group query variants into useful themes for content planning and performance monitoring.

Derived analysis Partially automatable Advanced

Query clustering groups many reported search phrases into stable themes that can be monitored and mapped to content. It is useful because one page can appear for numerous wording variants, while a row-by-row review overweights tiny differences.

Search Console provides query rows and, for eligible sites, AI-generated similar-query groups in Insights. A custom topic or intent taxonomy remains a derived analysis: Google does not expose a universal search-intent label in the Performance report.

Questions clustering can answer

A well-designed cluster model can show:

Which topics generate the most reported clicks and impressions?
Which themes are growing or declining?
Which clusters have visibility but weak click capture?
Which pages serve each topic or intent?
Which clusters map to no suitable page?
Where do several pages overlap on one need?
How does performance differ by country, device, or brand segment?

It cannot reveal every search because privacy filtering and top-row limits omit queries. It also cannot prove the user’s internal motivation.

Start with Google’s Insights query groups

The Insights report can group similar queries for sites with enough query data. Google documents these rules:

The group name is its best-performing query.
Group clicks are the sum of the queries in the group, not only the named query.
Insights shows a few highest-click examples, not necessarily every member.
A one-query group can have no example list.
Not all queries are guaranteed to be grouped.
Clicking a group opens the Performance report for deeper analysis.

Use Insights for rapid discovery and editorial conversation. Do not treat the generated group name as a formal topic taxonomy or assume the grouping is stable enough for financial reporting. The feature is rollout- and data-dependent.

Decide the purpose before choosing clusters

Different business questions require different grouping levels.

Topic clusters

Group searches about the same subject:

Search Console setup
Indexing problems
XML sitemaps
Core Web Vitals

Use for editorial coverage and topical trend reporting.

Intent clusters

Group by the job implied by the query:

Learn or understand.
Troubleshoot.
Compare or evaluate.
Buy, subscribe, or request a demo.
Navigate to a known brand/page.
Find a local provider.

These categories are hypotheses. Many queries support several intents, and short queries are especially ambiguous.

Modifier clusters

Preserve modifiers that materially change the need:

how to, why, error, fix
best, review, vs, alternative
price, cost, free, enterprise
Year, version, model, platform, industry, or location

Brand clusters

Separate brand, product-brand, competitor, and non-brand demand. Google’s built-in branded classification is AI-powered, can mislabel queries, and has property/history limits, so document whether you use Google’s filter or a rule-based dictionary.

Page-purpose clusters

Group around the page that should satisfy the need: product, category, documentation, support, comparison, editorial, local landing page, or account navigation.

A useful taxonomy can include several fields rather than one label:

topic + intent + modifier + brand class + locale + confidence

Export a defensible dataset

For a small property, export the Performance Queries table. For repeatable work, use the Search Analytics API. For large sites and the most complete available dataset, use BigQuery bulk export.

Include:

Query.
Page when page mapping matters.
Date or week.
Clicks.
Impressions.
CTR.
Average position.
Country and device only when needed.

Adding dimensions makes rows more granular and can increase sparsity. The API returns top rows rather than every underlying record; request up to 25,000 rows per call with offsets, while recognizing internal limits remain.

Save the raw extract unchanged. Classification should be reproducible without re-downloading a moving date range.

Normalize cautiously

Search Console query matching is case-insensitive, but exports can still benefit from analytical normalization.

Safe or usually safe steps:

Trim leading/trailing whitespace.
Normalize repeated whitespace.
Store a lowercase analysis key while retaining the original query.
Standardize known brand misspellings in a separate derived field.
Parse stable product/version/location entities.

Potentially destructive steps:

Removing stop words such as not, without, or near.
Stemming words until different concepts merge.
Discarding word order.
Removing numbers, model names, years, or locations.
Translating every query into one language without preserving the original.

cancel subscription and subscription without cancellation fee should not collapse because both contain subscription and cancel.

Build a hierarchical taxonomy

Start with 10–30 durable top-level topics, not hundreds of micro-clusters. Add subtopics only when they lead to different decisions.

Example:

Technical SEO
├── Indexing
│   ├── Not indexed diagnosis
│   ├── Canonical problems
│   └── Request indexing
├── Crawling
│   ├── Robots.txt
│   └── Crawl budget
└── Sitemaps
    ├── Creation
    └── Fetch errors

Each cluster should have:

A unique stable ID.
A human-readable name.
Inclusion and exclusion rules.
Positive and negative examples.
Intended page or content owner.
Review status and confidence.
Taxonomy version and effective date.

Names can change without changing IDs, preserving trend continuity.

Rule-based clustering with regex

Regex works well for transparent, bounded classes.

Question form

^(who|what|when|where|why|how|can|does|is|should)\b

Commercial investigation

\b(best|review|reviews|compare|comparison|vs\.?|alternative|alternatives)\b

Transactional language

\b(buy|price|pricing|cost|discount|quote|demo|trial)\b

Troubleshooting

\b(error|issue|problem|fix|broken|not working|troubleshoot)\b

Search Console regex uses RE2, is partial and case-insensitive by default, and does not support lookahead, lookbehind, or backreferences.

Rules can overlap. Decide whether multiple labels are allowed. If every query must have one primary intent, document precedence, for example:

navigational → transactional → comparison → troubleshooting → informational → unknown

Precedence is a reporting convention, not a statement about Google’s interpretation.

Semantic or AI-assisted clustering

Embeddings or language models can group wording that regex misses, such as make pages appear on Google and index my new article.

Use a controlled workflow:

Define the taxonomy and examples first.
Classify a representative sample manually.
Run the model with a fixed prompt/model/version.
Require a confidence value and allow Unknown/Mixed.
Compare model results with the reviewed sample.
Examine errors by language, query length, brand, and intent.
Route low-confidence and high-value rows to human review.
Store the assigned label, confidence, model version, and review result.

Do not let the model invent new cluster names on every monthly run if the goal is trend reporting. Discovery and production classification are separate phases.

Human review is essential for

One- or two-word queries.
Brand names that are ordinary words.
Negation and safety-sensitive topics.
Multilingual or code-switched queries.
Competitor and comparison phrases.
High-revenue clusters.
Queries that could map to several pages.
Newly emerging terms outside the taxonomy.

Aggregate metrics correctly

For every cluster:

cluster clicks = sum of member clicks
cluster impressions = sum of member impressions
cluster CTR = cluster clicks / cluster impressions

Do not average row CTRs. A query with one impression should not have the same weight as a query with 100,000 impressions.

Average position must also be impression-weighted when calculated from query rows:

cluster position = sum(query position × query impressions) / cluster impressions

Even then, position remains an aggregation-sensitive diagnostic metric, not a fixed cluster rank.

When page is included, summing rows can differ from property-level totals because page and property aggregation count multiple site results differently. Compare clusters consistently over time rather than forcing them to reconstruct the chart.

Map clusters to pages

Create a query-cluster-to-page table:

Cluster	Intended page	Leading reported page	Action
Sitemap fetch errors	Troubleshooting guide	Troubleshooting guide	Maintain
Sitemap creation	Complete sitemap guide	Homepage	Improve/create page
Brand login	Login page	Homepage	Clarify navigation/result
Product alternatives	Comparison page	Several articles	Review overlap

Classify the relationship:

Covered: an appropriate page performs.
Underperforming: correct page has visibility but weak results.
Unmapped: relevant impressions exist but no suitable destination.
Overlapping: multiple pages serve the same inferred need.
Irrelevant: visibility does not match the site’s audience or offering.

An unmapped cluster is not automatically a content brief. Confirm business relevance, sustained demand, expertise, and the ability to provide original helpful value.

Avoid one-page-per-keyword production

Google advises thinking about the terms different readers may use, but also says its language matching systems can understand many query variants even when exact wording is absent.

Do not create separate thin pages for every cluster or phrase. Google’s spam policies prohibit scaled content created primarily to manipulate rankings without adding value.

Create a new page when the cluster represents a distinct user goal that deserves a complete independent resource. Otherwise improve an existing page or section.

Monitor clusters over time

Use a stable weekly or monthly table:

Current clicks and impressions.
Absolute and percentage change.
CTR percentage-point change.
Impression-weighted position.
Leading page and its share.
Brand/non-brand mix.
Device and country concentration.
Classified-query coverage rate.
Unknown and low-confidence share.

Compare equivalent periods and maintain the same taxonomy version. If a rule changes, backfill historical data or mark a reporting break.

Track classification coverage separately:

classified click coverage = clicks in classified visible queries / clicks in all visible query rows

Do not call this total Search coverage because hidden queries are absent.

Discover emerging themes

Maintain an Unknown/Other queue. Rank it by:

Absolute clicks.
Impression growth.
Repetition across related phrases.
Business relevance.
Lack of a suitable page.

Review monthly. Promote a theme to the formal taxonomy only when it is durable and decision-relevant; otherwise the taxonomy will churn with news and one-off terms.

What clustering can and cannot prove

It can provide:

A repeatable summary of visible query performance.
Topic and intent hypotheses.
Page mapping and overlap signals.
Growth and decline at a more stable level than individual phrases.

It cannot provide:

Every query, because privacy filtering applies.
Google’s internal understanding of the query.
Certain user intent.
Total market demand.
A guarantee that a new page will rank.
Causal proof that cluster-focused edits changed performance.

Describe the taxonomy as your analytical model.

Quality checklist

The business question determines the grouping level.
Raw queries and extracts are preserved.
Normalization does not remove meaning.
Topics, intent, modifiers, and brand are separate where useful.
Unknown and multi-intent labels are allowed.
Rules and model versions are documented.
High-value and low-confidence rows receive human review.
CTR and position are aggregated correctly.
Hidden-query and page-aggregation limits are disclosed.
New content is created for distinct helpful needs, not keyword variations.