Recently Updated: 18 min read

Keyword Clustering from Search Console Page Queries

Keyword Clustering from Search Console Page Queries

A keyword cluster built from Search Console is the set of queries one existing page already appears for, sorted into four outcomes: keep on this page, stretch the page to cover, split to a new page, or drop. You export the page's queries, test each row against what the searcher wants and what your page answers, and write the outcome next to it. The result is a table you can hand to a writer. The examples follow a single business: a dog training school with one page for its puppy classes.

Clustering is a working method, and the grouping decisions are yours.

Why start from the queries a page already earns

A keyword tool hands you long lists of phrases that nobody has tested against your page. The Performance report hands you the phrases your page has already been shown for. That difference changes what a cluster is for. Instead of deciding what to write, you decide what an existing page should be allowed to claim, and what it should stop trying to be.

What the report records

According to the Search Console help page for the Performance report (Opens in a new tab), impressions count the number of times your site appeared in Search results, clicks count the number of times a user clicked your site from Google Search results, CTR is clicks divided by impressions, and average position is the average position of the topmost result from your site. The Queries dimension groups the table by the search query users typed. The page describes the dimension as the thing that defines how the data in the table is grouped.

Cluster, topic cluster, keyword list

A keyword list is an unsorted dump. A cluster is the part of that dump one page can answer. A topic cluster is a set of pages tied together under a parent subject. Grouping one page's queries concerns the middle one. For the step before it, deciding which keyword belongs to which page, see keyword mapping.

Pulling the query list for one page

The raw material is one export per page. Keep it narrow: one URL, one search type, one date range.

Setting the page filter

Google's help page on advanced filtering and comparison (Opens in a new tab) says you add a filter with the "Add filter" label at the top of the report and then choose Queries or Pages. Choose URLs containing and type the address. The match is not case-sensitive but is otherwise exact, including any spaces. A "Matches regex" option also exists. If the page has parameter or trailing-slash variants, type the part of the address they share. If your interface is not in English, the labels may look different.

Choosing dates and search type

The Performance report help page says the default date range is the past three months, and the search type options are Web, Image, Video and News. Start with Web. Queries that arrive through image or video results may reflect a different searcher, so pull them as a separate export and merge them later if they belong. Practical suggestion: for a page tied to a season, add a second export from the same weeks one year earlier.

Exporting and reading the zeros

The report has an export button for chart and table data. The help page states that values shown as "~" or "-" in the report will be zeros in the downloaded data. A zero in your spreadsheet may therefore stand for a value the report could not show. Do not delete a zero row until you have looked at it in the report.

What filtering does to the totals

The filtering page warns that filtering by query or URL can affect the report totals, because of data truncation and the omission of anonymized queries. The rows in your spreadsheet are a sample of what the page was shown for, not a complete ledger. Label the cluster table accordingly, for example "based on queries visible in the export".

Example scenario: the puppy classes page

Example scenario: a dog training school has one page called "Puppy classes". Its export shows these queries. The table carries no counts, only outcomes.

QueryWhat the searcher wantsDoes the page answer itOutcome
puppy training classesA class to bookYes, schedule and bookingKeep
puppy classes near meA nearby classYes, location blockKeep
how much are puppy classesPricePartly, price in a paragraphStretch: add a price table
how to stop puppy bitingA method to try at homeNoSplit: guide post
adult dog obedience classesA class for an older dogNoSplit: separate class page
dog daycare pricesA service the school does not offerNoDrop

Reading the table

The first two rows are the page's core. Both ask for a class, and the page offers one. The third row asks about price. The page mentions it, but a searcher scanning for a figure has to dig for it, so the page stretches to include a price table. The fourth row wants a method, not a class, and a class page cannot be the best answer to it. The fifth row comes from a different reader: someone with an older dog. The last row names a service the school does not sell, so no page of yours should chase it.

The four outcomes and how to choose between them

Each query gets exactly one outcome. The outcomes differ in cost, so the order of the questions matters.

OutcomeTestCost to you
KeepThe page already answers the query in a visible sectionNone
StretchOne sentence, one table or one section would answer it for the same readerAn edit
SplitThe searcher wants a different answer, a different format, or is a different readerA new page
DropThe query asks for something you do not offerNone, and no page

A decision rule for borderline rows

Decision rule: price the fix. If the missing answer fits in a sentence or a section and the reader stays the same, stretch. If it needs its own title, its own format and a different reader, split. If you cannot price it, mark the row "undecided" and look at it again in the next export. Practical suggestion: cap the undecided rows at a handful, otherwise the table stops being a decision tool.

Why a stretched page can still fail

Stretching only works while the page keeps one job. Add a price table, a location block and a method section for puppy biting to a class page and it becomes a general puppy page that serves no reader well. If a stretch needs a fourth or fifth unrelated section, treat that as a split.

When a query deserves its own page

Google's page on creating helpful, reliable, people-first content (Opens in a new tab) includes the question "Does the content provide substantial value when compared to other pages in search results?" For clustering, that question works in both directions. It tells you not to open a thin page for every stray query, and it tells you when a stretched page is no longer the best answer to a query.

Signals that point to a split

Practical suggestion: treat two or more of these as a split signal. The query asks a different question. The answer needs more than a section on the existing page. A different reader arrives with the same query. The answer needs its own title, imagery and internal links.

Signals that point to a stretch

The query is a different wording of a question the page already answers. The missing piece is a number, a definition or a comparison. The searcher would not mind finding the answer on this page. These cost an edit, not a page.

Splitting without competing with yourself

A new page for a query the old page already earns impressions for can pull that query away from a page that served it. Before you split, decide which page owns the query afterwards, link from the old page to the new one with a descriptive anchor, and trim the old page's treatment of the query to a short pointer. For cases where two pages already appear for one query, read the Performance report query and page analysis.

When two of your pages appear for one query

The Performance report help page explains that if two results from the same site appear for one query, they count as a single impression in the chart total. The table aggregates Queries, Countries, Devices and Dates by property, while Pages and Search appearance aggregate by page. The page also says chart and table totals can differ because of those differences.

What this means for the cluster table

A query row in a per-page export tells you the page was shown for the query, not that it was the only page shown. To see whether two of your pages share a query, run the same query filter in the other direction: filter by the query and open the Pages dimension. If both pages appear, decide which page the cluster belongs to and write the other page's pointer into the plan.

Choosing the owner

The owner is the page that answers the query more directly for the searcher's task. Practical suggestion: read both pages as the searcher would, from the top, and note where each page first gives the answer. The page that answers sooner and more completely owns the cluster. The other page keeps a link and a short mention.

The cluster table template and checklist

One table per page is enough. Each column exists to prevent a specific mistake.

ColumnWhat goes in itMistake it prevents
Cluster nameThe searcher's task in one phraseNaming clusters after a keyword
Lead queryThe phrase with the highest impressionsChoosing by instinct
Supporting queriesOther wordings of the same taskSpawning a page per wording
Where the page answersHeading or table that holds the answerClaiming coverage without checking
Missing pieceWhat the page lacks for this queryVague "improve content" tasks
OutcomeKeep, stretch, split or dropUndecided rows piling up
Decision dateWhen you decidedRe-arguing old calls

Checklist before you hand the table over

  • The page filter catches the right address and the search type is Web.
  • You noted that "~" and "-" values become zeros in the export.
  • Every row has an outcome and a one-line reason.
  • Stretch rows name the exact section or table that will be added.
  • Split rows name the reader and the format of the new page.
  • Drop rows say why the query is out of scope.
  • Rows where two of your pages appear are flagged for an owner decision.
  • The table says it is based on queries visible in the export.

Turning the table into page edits and a content plan

The table produces three kinds of work: edits to the existing page, briefs for new pages, and a list of queries you have decided to ignore. Keep them apart, because they move at different speeds.

Edits to the existing page

Stretch rows turn into edits. Place the answer where the searcher expects it. If the query is about price, a short table near the top beats a sentence in the third paragraph. Do not copy the query into a heading to look relevant. A heading that answers the question serves the reader, while a heading that repeats the phrase serves nobody.

Briefs for new pages

Split rows turn into briefs. Each brief names the searcher, the question, the format and the link back to the original page. Before you commission a new page, compare the idea with what already ranks for the query, and ask the helpful content question again: would this page add something the existing results lack. If the answer is no, the row goes back to stretch or drop. For a ranked work list of queries stuck on the second page, see the page two queries work list.

The ignore list

Keep the drop rows in the table. They record that you saw the query and chose not to chase it. A future colleague who finds "dog daycare prices" in the export will see the decision instead of repeating the debate.

How cluster width changes with page type

The same four outcomes apply to every page, but a product page, a category page and a guide carry clusters of very different width. Matching the cluster to the page type keeps each page doing one job.

Page typeCluster widthDog training example
Single class pageNarrow: name, schedule, price, location"Puppy classes" with price and booking
Category pageMedium: group of classes, how to choose, price range"Dog training classes" with a chooser
How-to guideWide: a process and its related questions"How to stop pulling on the leash" and the follow-up questions
FAQ pageScattered: short, unrelated questionsCancellation, vaccination proof, what to bring

Keeping a class page narrow

A class page answers one booking decision. A how-to query such as "how to stop puppy biting" pulls it toward advice, and the page starts to read like a blog post with a booking button. The class page cluster should contain only queries that end in a booking, a price or a location.

Letting a guide run wide

A guide may answer several neighbouring questions on a single page, as long as one reader is served. The cluster for a leash-pulling guide can include the cause, the equipment question and the first week of practice. It should not absorb the price of classes, which belongs to the category or class page.

When the shown page does not match the query

If the guide appears for a price query, the searcher may be looking for a fee table and not finding one. Either add a short price section that links to the class page, or strengthen the class page so it answers the price query directly. The export tells you about the mismatch only when you read the Pages dimension next to the query.

A finished cluster is also an outline. The lead query becomes the question the introduction answers, and the supporting queries decide which sections and table rows exist.

Answer the lead query in the first paragraph

For the price cluster, the first paragraph says what a class costs and what the figure covers, in one or two sentences. A searcher who reads only that paragraph still leaves with the answer. The rest of the page carries the detail.

Spread supporting queries across sections

Supporting queries decide which table rows and section headings exist. "Puppy classes near me" becomes a location block. "How much are puppy classes" becomes a price table. Giving every supporting query its own heading pads the page and repeats the same information, so tie only a few supporting queries to each section.

Pointers for queries that moved elsewhere

For each split row, prepare a sentence on the existing page that points to the future page, even if it is not written yet. When the new page is published, adding the link takes seconds. Write the anchor so it names the topic of the target page.

Checking the cluster by comparing two periods

After you edit a page, export again with the same filter and compare. The filtering help page says you can compare data over different time periods, such as this week and last week, that comparing adds a Difference column, and that only one comparison can run at a time. It also advises Weekly or Monthly granularity when you compare two date ranges.

What to compare

Look for new query rows that match the section you added, for movement in rows you kept, and for whether dropped queries still appear. A new row that matches a new price table is a useful sign. It is not proof that the table caused it, because demand moves on its own.

Reading the difference honestly

Write the finding as "after the edit, the table shows X" instead of "the edit produced X". A booking season, a news story or a competitor change can all shift the difference column. A year-over-year comparison for the same weeks removes the seasonal part of the noise.

What the data cannot tell you

Search Console lists the queries your site was shown for. A query that earned no impression is invisible to it, and a page that went live a few days ago has too little data to cluster.

Missing queries

The filtering page says anonymized queries are omitted when you filter by query or URL. A phrase missing from your table does not prove the page was not shown for it. State conclusions as "among the visible queries".

No promise of ranking

Finishing a cluster table and making the edits does not guarantee a higher position for any query. The table improves the match between page and reader. Whether positions follow is something you measure afterward.

Testing your own grouping

Manual clustering is subjective. Give twenty rows to two people, have them mark outcomes independently, and discuss the rows where they disagree. Disagreement signals that the outcome definitions are loose, so tighten the wording of the tests before you scale the method to more pages.

Mistakes that quietly ruin a cluster table

Grouping by shared modifier

"Puppy classes near me" and "puppy classes online" share two words and ask for different things. Modifiers such as a place or a format change the task. Group by the task, not by the shared words.

Blending branded queries into discovery

Queries that contain the school's name come from people who already know the school. Mixed into the cluster, they inflate the lead query and hide what strangers search for. Tag them in their own column and analyze them separately.

Treating an export as permanent

A table from last spring describes last spring. Refresh it when the page changes or a season turns. Practical suggestion: put the export date in the file name and in the table header.

Merging two readers into one cluster

"Puppy biting" and "adult dog lunging" may both mention training, but they come from different owners with different problems. If one page tries to serve both, it serves neither. Separate clusters keep the plan honest.

A ninety minute session for one page

Practical suggestion: split the work into four blocks. In the first fifteen minutes set the filter, export the data and save a read-only copy. In the next thirty, mark every row with its outcome and a reason. In the next thirty, name the clusters, pick the lead queries and write the missing piece for every stretch row. In the last fifteen, move the splits into the content plan and the drops into the ignore list. For a page with hundreds of rows, start with the hundred rows with the highest impressions and note that the rest were skipped.

Which page to try first

Pick a page that is shown for a wide spread of queries but earns few clicks. It will yield the largest number of decisions. A page with a single clear job teaches the method faster and is a safer first run.

Who should be in the room

Someone who knows the offer should mark the rows. A trainer can tell at a glance that "puppy biting" is a home method and "obedience classes" is a booking intent. A writer alone would guess.

Frequently Asked Questions

How large is a cluster?

The documentation has no statement on a number. A cluster is as large as the set of queries one page can answer for one kind of searcher, so two queries can already form one.

How do I see the queries for one page in Search Console?

The advanced filtering page says you add a filter at the top of the report and choose URLs containing, then view the Queries dimension. If your interface is not in English, the labels may look different.

Why do I see zeros in my export?

The Performance report help page says values shown as ~ or - in the report become zeros in the downloaded data. Check the row in the report before treating a zero as real.

What if two of my pages show up for the same query?

Filter by the query and open the Pages dimension to confirm. Then choose the page that answers the query more directly as the owner, and link from the other page to it.

Is this different from clustering by overlapping search results?

The documentation has no statement on clustering by search result overlap. Sorting the queries your own page already receives is a different method, and overlap-based grouping is something tools offer.

When should I redo the table?

Practical suggestion: redo it after you change the page or when a season turns, using the same filter so the exports can be compared.

Conclusion

Sorting the queries one page already receives into keep, stretch, split and drop gives you a decision for every row and a brief for every real gap. The value lies in the evidence: queries Google has already shown your page for, tested against the searcher's task and the answer your page gives. Remember the limits. Anonymized queries are omitted, "~" and "-" values become zeros in the export, and a finished cluster table carries no promise about rankings.

If the stretch rows and split rows from your table need drafting, you can have the articles written for you.

0 Comments

No comments yet for this article.

Post a comment

Please log in to leave a comment. Login