Turn a keyword list into a site structure

A keyword export is a list of searches. A site structure is a set of pages, each responsible for one job, linked so that a visitor can move between them. The distance between those two things is clustering, and skipping it is why so many sites end up with four hundred posts, no clear hierarchy, and several pages fighting over the same query.

This guide covers how to group a keyword list, how to turn the groups into a structure, and how to find the places where your existing site is already competing with itself.

Clustering is a decision about pages

A cluster is a set of keywords that all belong on one page. That is the whole definition, and it is worth holding onto, because it makes the test concrete: if two keywords would be answered by the same text, they are in the same cluster, and if they need different pages, they are not.

It also means the output is a page list, not a word list. Groups that describe a topic without saying which page carries it are not finished. Every cluster needs a URL at the end of the row, even when that URL is a proposal for a page that does not exist yet.

Group by the results page, not by shared words

The tempting method is string matching: put "keyword tool", "free keyword tool", and "keyword tool online" together because they share words. That produces groups that look tidy and behave badly, because the words are not what Google is matching on.

Two keywords sit in one cluster when the pages ranking for them are the same pages. When Google serves one set of results for a pair of queries, it has decided they are the same question, and one page can win both. When the results differ, the queries are different jobs regardless of how similar they look on paper.

That is why "keyword tool" and "best keyword tool" usually split. The first returns tools. The second returns comparisons and listicles. One cluster, two clusters — the results page decides, and it usually decides for two.

You do not need to check every pair. Intent labels do most of the sorting, and a handful of results-page checks on the borderline groups settles the rest. Intent mapping before clustering is what keeps the groups honest, because intent and cluster boundaries are mostly the same boundaries.

Name the cluster, and the page names itself

A cluster needs a name that states the job, not the vocabulary. "Cluster 7" is unusable. "Choosing a keyword tool" is a page.

The test is whether you can write the name as a single line that a writer could work from. If the name needs an "and" to cover what is in the group, the group is probably two clusters wearing one label. Split it and name each half.

Those names then become the working titles, and the set of names becomes a table of contents for the site. Read down the list and you can see the gaps: topics with no cluster, clusters with no page, and clusters whose page is a thin post that was never meant to carry the job.

From clusters to a hub

Where several clusters sit under one broader topic, the broader one becomes a hub page and the rest become pages linked to it. The hub covers the topic at the level a searcher would want an overview, and each linked page covers one part properly.

Two rules keep this from turning into a tangle.

• Link on intent adjacency, not on recency. A page links to the pages that answer the question a reader has next, which is a relationship between topics and has nothing to do with publication dates.
• One page per cluster, everywhere. The hub does not target a spoke's keywords and a spoke does not target the hub's. When two pages both want a cluster, one of them is mislabeled.

The map, and the cannibalization it prevents

The artifact that holds all of this together is unglamorous: one row per cluster, carrying the cluster name, the primary keyword, the intent, the target URL, and a status. It is the only thing that stops the same cluster being claimed twice by two people who never spoke.

The failure it prevents is cannibalization: two of your pages targeting one intent, Google alternating between them, and both ranking below what either could manage alone. You can find the existing damage in your own data. Open Search Console and look at its report with both the query and the page dimension switched on, then read any query that splits its impressions across two of your URLs as a candidate.

The fixes are short. Fold the weaker page into whichever one is doing the work and redirect it, or aim that page at a separate intent entirely and retitle it around that. Then add the surviving cluster to the map so the decision does not get relitigated in six months. Search Console discovery runs that check across every page at once.

Do it with an agent

Connect the Doverity MCP and the clustering runs against your saved keywords and your own query data in one pass. This prompt does it end to end; the keyword clustering skill is the same workflow written for the agent.

Using the Doverity MCP:

1. Load my keywords with list_saved_keywords for tag [tag]. If the tag
is empty, run research_keywords for "[topic]" first.
2. Pull get_search_console_performance with dimensions ["query","page"]
and flag every query where two or more of my URLs are splitting
impressions.
3. Cluster the keywords by intent and by the page type that ranks for
them. Call get_serp_results only on the borderline groups.
4. Give each cluster one target URL: an existing page where one fits,
otherwise a proposed path and working title.
5. Output a table of cluster, primary keyword, intent, target URL, and
status, followed by the merge-or-redirect list from step 2.

Ask before it writes tags back. The table is the thing you want to review; the tagging can wait until you have.

Keyword clustering FAQ

How many keywords should a cluster hold?

However many are answered by one page, which is usually a handful and occasionally thirty. The count is a by-product, not a target. If a cluster holds a hundred keywords, read them, because either the page is a broad one with real depth or the group needs splitting — and the only way to tell is to look at whether all of those queries want the same answer.

What is a keyword map?

One row per cluster, with the cluster name, primary keyword, intent, target URL, and current status. It is the working record of which page owns which search, and it is what tells you, before anyone writes anything, that the new page someone proposed already has an owner.

How do I fix keyword cannibalization?

Find the query, pick the page that should own it, and fold the other into it with a redirect. Keep whichever page is stronger and closer to the intent, not whichever is older. Where the two pages genuinely serve different readers, retitle and rewrite the weaker one against a different intent instead, then record both decisions on the map so the split sticks.

Do I need a tool to cluster keywords?

You need keyword data and a way to see which pages rank together. A spreadsheet and a results-page check can do it for a few hundred keywords. Past that, an agent doing the grouping against live data is faster and more consistent, and Doverity includes it with keyword research rather than selling clustering as a separate product.