From Search Console Queries to a Content Backlog: An AI-Assisted Clustering Workflow

How do you turn Search Console queries into a content backlog?

You export the queries, clean them, group them by intent, check every group against the pages you already have, and score what survives. The check is the step that decides whether a group becomes a new article, an edit or a merge.

The short version of this page:

• Five steps: export, clean, cluster by intent, check against your existing pages, score.
• A language model can propose the groups, but only the live results and your own Pages view can confirm them.
• The cannibalization check sits before scoring, so a topic you already cover never gets a second page by accident.
• The scoring model is Kanso's design. No source read for this page tests it, and no result is claimed.
• The worked example uses invented figures, because no Search Console data from Kanso was supplied for this page.

export → clean → cluster by intent → check against existing pages → score → backlog

What do the pages that rank for this already cover?

The two ranking guides read in full for this page list where to look in Search Console, and neither shows how to group queries, compare them with existing pages or rank the result. The table records what each page covers, as read on 28 October 2026.

The Skillfloor guide tells readers to look at search queries, top pages, click-through rate, traffic trends and gaps where the site does not rank well. That is a list of reports, and it stops before the point where a writer has to decide what to make.

Only two of the ten organic results were analysed in full, so this page makes no claim about the other eight. It does not need to: the gap it fills is a process with the existing-page check built in, which the two guides read do not contain.

How the process was put together: the export and reading steps follow Google's own description of the Performance report. The consolidation step follows Google's guidance on duplicate URLs. The clustering, the gates and the score are Kanso's design, and each is labelled as such where it appears.

Step 1: What should you export from Search Console?

Export the queries table and the pages table for the same date range, because the later steps need both. Google describes the Search performance report as showing traffic from Google Search with breakdowns by queries, pages and countries, and trends for impressions, clicks and other metrics.

1. Fix one date range and write it at the top of your sheet. Use the same length every time, so runs can be compared.
2. Show clicks, impressions and average position beside every query, then export the queries table.
3. Export the pages table for the same range, so each URL has its own impressions and position.
4. For your most important queries, open the query and look at its Pages view. Record every URL that appears.

Two cautions come from Google's help pages. In the Performance report overview, values shown as ~ or - in the report become zeros in a downloaded file, so a zero in your export is not always a true zero.

The second concerns position. Search Console Help says average position is the average of the topmost result from your site, and that in a table it covers the row you are looking at. A query that sits at 14.2 in your sheet may have been 8 on some days and 30 on others.

Search Console can only list queries that produced an impression. A topic your site has no page for, and so never appeared for, is invisible here. That is a limit of this whole method, and it is why Kanso's weekly growth checklist also asks you to collect questions from sales calls, support tickets and communities.

Step 2: How do you clean the export before clustering?

Remove or separate everything that is not a content opportunity, so the clustering step sees only queries a page could answer. Three removals do most of the work.

• Branded queries. Google's branded queries filter was announced on 20 November 2025 and, per Google, splits branded from non-branded queries automatically. Google says non-branded queries show how new people find you, which is the signal a content backlog wants.
• Near-identical variants. Plural and singular forms, word-order swaps and typos can be merged into one row, summing their impressions. Keep the list of merged forms, because the variants are often useful as headings.
• Queries that are not about your business. A query can appear because of a loose match. Delete it, or park it in a separate tab, instead of letting the clustering step build a group around it.

Keep the impressions and position for each row you merge. You will need them in step five, and recomputing them from the raw export is where arithmetic mistakes creep in.

Step 3: How do you cluster Search Console queries by intent with AI?

You give a language model the cleaned list and ask it to label each query's intent and group queries that share one, then you verify the groups against the live results. Treat the output as a first draft of the groups, because nothing in the sources read for this page measures how accurate a model's grouping is.

A clustering group is the set of queries one page should answer. If two queries want different pages, they belong in different groups even when they share most of their words.

Google's Query groups card in Search Console Insights launched on 27 October 2025 and clusters similar queries into one intent. Google notes it is available only to properties with a large volume of queries, so a small site will often have to cluster for itself.

Pages exist that sell this step as a product. Their titles describe grouping keywords by search result and clustering with knowledge graphs, and iPullRank has a post titled Clustering vs. Classification. Kanso read none of them, so it cannot say how well they work.

When you use a model, ask for three things per query: a one-line statement of what the searcher wants, the kind of page that would satisfy it, and the group it belongs to. Asking for the intent in words makes a wrong grouping easy to spot.

• Open the live results for the three largest groups and read the top results.
• Open them for any group that mixes a how-to question with a buying query.
• Split a group by hand if its queries pull toward different kinds of page.

Step 4: How do you check each cluster for cannibalization before it reaches the backlog?

Map every cluster to the URLs of yours that already appear for its queries, and let the number of matching URLs decide what kind of job the cluster is. Skip this step and a backlog sorted by impressions will, sooner or later, ask for a page you already have.

Keyword cannibalization is two or more of your own pages competing for the same search query. It is industry shorthand, not a Google term, and Kanso's weekly growth checklist notes that two pages ranking for one query is only a problem when the pages do the same job and neither performs.

1. Take the head query of the cluster, the one with the most impressions.
2. In the Performance report, filter to that query and open the Pages view. Count the URLs that appear, and note each one's position.
3. Repeat for the cluster's second-largest query. A URL that shows up for only one of them still counts.
4. List the titles of your published pages and look for any whose subject matches the cluster, even if Search Console shows no impressions for it yet.
5. Read the live results once more. If they want a different kind of page than the one you have, record that.
6. Write down the cluster's situation using the table below.

When two URLs do the same job, the fix is to choose the page that should win, merge the useful content into it and redirect the other. Google's guidance on canonicalization calls a redirect a strong signal that the target should become canonical, rel=canonical a strong signal as well, and a sitemap entry a weak one.

The existing-page check also covers pages that rank for a query nobody targeted. A stray section on a broad page can collect impressions for a topic, as in the worked example below, and it is a clue that the topic deserves its own page and not that it is already covered.

Step 5: How do you score what is left?

Score each surviving cluster on demand, fit and room with three small integers, and use the total only to order the list. The scale is deliberately coarse, because a precise-looking number would claim more than the evidence supports.

Two gates come before the score. A cluster whose check shows two competing URLs is handled as a consolidation, and a cluster with a fit of 0 is dropped from the blog backlog whatever its demand. The gates exist because a high score on the wrong kind of job is worse than a low score on the right one.

score = demand + fit + room (maximum 7), after the cannibalization gate and the fit gate

Treat the seven-point scale as a starting point. Replace the demand cut-offs with ones that fit your own list once you have run the workflow a few times.

What does the workflow do to a list of eight queries?

Applied to eight queries, it produces four clusters and three backlog jobs, and it sends one cluster away from the blog entirely. Every number below is invented: Kanso supplied no Search Console data from its own property for this page, so the site, the queries and the figures only illustrate the method.

Step 3 groups them into four clusters, and step 4 maps each to URLs. The impressions in each cluster are summed in the table.

Cluster B is the one a query-by-query list would get wrong. “Client onboarding process steps” and “how to onboard a new client” are served by two blog posts that alternate in the results, so a new article would add a third competitor. Cluster D is the other: both queries return product pages, so an article would compete with the site's own product page.

The arithmetic is short. The eight queries total 2,400 + 1,900 + 800 + 1,100 + 1,300 + 600 + 2,000 + 900 = 11,000 impressions, and the three clusters on the backlog hold 4,300 + 1,900 + 1,900 = 8,100 of them, which is 8,100 ÷ 11,000 = 73.6%. The other 2,900 (26.4%) belong to cluster D.

The same list would have produced eight briefs if every query were treated as a topic. The workflow produces three jobs: improve a page, merge two and write one.

What does a finished backlog row hold?

A backlog row holds the cluster, the page that owns it, the action and the reason the cluster ranks where it does, so that anyone can reopen the decision. The six fields below are Kanso's suggestion, not a standard.

For a new page, the next document is a brief. Kanso's content brief template with a filled example shows the fields a writer needs, including a topics-to-avoid line that is where the result of step four belongs.

For an improve job, go to the striking-distance workflow and apply its do-not-touch rules before you open the page. A cluster that passes the cannibalization check can still be one to leave alone.

How often should you re-run the workflow?

About once a month is a sensible default, because Google suggests checking your Search Console account around once every month or when you change the site's content. Use a date range of the same length each time and keep the old sheets, so you can see which clusters moved.

Re-run it earlier after a large publish or consolidation, since both change which URLs own which clusters. The first run is the longest, because the cleaning rules and the cluster labels are being set. Later runs mostly update numbers and check whether last month's decisions held.

Record what you changed and when. No source read for this page says how long a change takes to show in Search Console, so this page does not either.

Where does Kanso fit in this workflow?

Kanso's Writer Agent drafts articles from Search Console opportunities, which fits the new-page outcome after steps one to five are done by you. Here is what the agents relevant to this workflow do, as their pages describe them.

• The Writer Agent turns Search Console opportunities into long-form article drafts in your brand voice, for you to review and publish yourself.
• The SEO Agent audits your site and Search Console data, and turns what it finds into recommendations and tracked tasks for your approval.

The limits matter for this workflow. According to the turn Search Console data into content page, the Writer Agent keeps queries with enough impressions where your site is not on the first page, picks the one with the most impressions, and does not remember past topics.

In the invented example, that query would be “client onboarding checklist”, which already has a page. The page lists no check against your existing pages, so run step four yourself and use the draft where the check says new page.

Kanso does not publish, does not write internal links or slugs, and makes no promise about rankings or traffic. Plans are on the pricing page.

What is documented, what is analysis and what is missing?

The Search Console facts are documented by Google, the workflow, gates and score are Kanso's analysis, and any evidence that the workflow improves results is missing. The lists keep the three apart.

• Documented: the Performance report shows traffic by query, page and country, with trends (Google Search Central, read 28 October 2026).
• Documented: average position is the topmost result from your site, averaged over the row (Search Console Help).
• Documented: Query groups cluster similar queries into one intent and are limited to properties with a large query volume (Google Search Central Blog).
• Documented: a redirect and rel=canonical are strong canonical signals and a sitemap entry a weak one (Google Search Central).
• Reported, not confirmed: a Content Ideas (experimental) feature seen on selected properties in December 2022 (Botpresso).

• Analysis: the five-step order, and the choice to run the cannibalization check before scoring.
• Analysis: the five situations, the two gates and the demand, fit and room score.
• Analysis: asking a model for each query's intent in words and verifying a sample against the live results.
• Analysis: the worked example, whose figures are invented.

• Missing: any measured result of this workflow, from the sources or from Kanso. No Kanso property is analysed here.
• Missing: an accuracy figure for AI keyword clustering, and a tested set of score cut-offs.
• Missing: a first-hand read of the clustering tools named above, which were seen only as titles.

Search Console content ideas: frequently asked questions

Sources

• How To Use Search Console, Google Search Central
• What are impressions, position, and clicks?, Search Console Help
• Performance report (Search results): Overview and basic setup, Search Console Help
• What is URL canonicalization, Google Search Central
• Introducing Query groups in Search Console Insights, Google Search Central Blog
• Introducing the branded queries filter in Search Console, Google Search Central Blog
• Using Google Search Console to Generate New Content Ideas, Skillfloor
• New Google Search Console Feature: Content Ideas (experimental), Botpresso
• Keyword Clustering Tool: Group Keywords by SERP (search result title only), Keyword Insights
• Keyword Clustering with AI Knowledge Graphs (search result title only), InfraNodus
• Clustering vs. Classification: How to Speed Up Your Keyword Research (search result title only), iPullRank