Cluster Keyword

I start with a single seed keyword — say "running shoes". From there I pull every variant my tools will give me: autosuggest from Google, queries from Search Console, related terms from Ahrefs or Semrush, and the "People Also Ask" box. I dump them all into a spreadsheet. The column headers are: keyword, search volume, keyword difficulty, and — most importantly — the top 10 URLs from the SERP.

Then I look for URL overlap. If "best running shoes" and "running shoes for flat feet" both show the same Runner's World guide in positions 1 through 4, they are the same cluster. I colour-code those rows and assign them a tentative primary keyword — usually the term with the highest volume or best intent match. If the SERPs share fewer than, say, three of the same URLs, I split them into separate clusters. This is the method that Ahrefs and Semrush both describe, and I have found it far more reliable than grouping by semantic similarity alone.

Once the clusters are stable, I decide on content structure. For a broad term like "running shoes", I create a pillar page that covers the category. Each sub-cluster — "best running shoes for marathons", "trail running shoes for beginners" — gets its own supporting article. I link from the pillar to each supporting article using anchor text that matches the cluster term. This avoids cannibalisation because every page owns a distinct set of intents and SERP positions.

I use a spreadsheet for the first pass, then run the clusters through a tool like the [Keyword Rank Checker](/keyword-rank-checker/) to verify that the pages I already have actually rank for terms I am about to combine. If a page already ranks top 5 for a secondary term, I keep that term on the existing page rather than moving it. Numbers matter: one client saw a 28% increase in organic click-through after I re-clustered their top 50 terms using this SERP-overlap method instead of a tool's automatic grouping.

The biggest trap is trusting keyword similarity tools without checking the SERPs. I once clustered "SEO tools" and "SEO software" because they sound identical. The SERPs told a different story: "SEO tools" returned listicles and comparison posts, while "SEO software" showed SaaS category pages and pricing tables. I had to split them and lost three weeks of ranking progress. Now I never group two terms unless I can see at least half the same URLs in their top 10.

Another watch-out is intent drift within a cluster. Even if the SERPs overlap, the user journey may differ. For example, "how to run a marathon" and "marathon training plan" might share some URLs, but the first implies beginner curiosity and the second implies a searcher ready to commit. I check the [Intent SEO](/intent-seo/) of each term by scanning the featured snippets and People Also Ask boxes. If the dominant content type shifts from informational to transactional, I split the cluster.

Also watch your own ranking data. A keyword that you already rank well for should stay on its current page unless the page is clearly underperforming. I have seen practitioners reassign a strong term to a new page and then watch both pages compete for the same snippet. Use the Keyword Rank Checker to see where each term lives before you move anything.

Finally, don't treat clustering as a one-off exercise. I used to build clusters and forget them. Six months later, the SERPs had shifted — Google had added video carousels, new competitors had entered, and some of my cluster terms now belonged to different topics. I now schedule a cluster review every quarter and re-run the URL-overlap check for any term that shows a significant change in [SERP Ranking](/serp-ranking/).

I used to cluster keywords by string similarity and synonym matching. I thought that because LSI keywords exist, Google must want me to group "keyword research" and "keyword analysis" on the same page. I was wrong. The SERPs for those two terms are nearly identical — same guides, same tools — so they do belong together. But other pairs like "keyword research" and "keyword difficulty" have completely different SERPs. I learned the hard way that SERP overlap is the only signal I trust, not semantic proximity.

My second mistake was over-clustering. I once threw 40 terms into a single cluster for "content marketing". The result was a monstrous pillar page that tried to cover strategy, writing, promotion, and measurement. It ranked for nothing. I had to break it into six separate clusters, each with its own primary keyword and supporting articles. Now I limit a cluster to about five to eight terms, and I always check that the primary keyword can support the breadth of intent in the group.

I also ignored [Long-tail Keywords](/long-tail-keywords/) when clustering. I treated them as separate projects. But many long-tail terms share SERPs with their head term — especially question-based queries. For example, "how to optimise a page for a keyword" shares top URLs with "keyword optimisation". Now I always include long-tail variants in the same cluster spreadsheet before deciding on content structure.

Finally, I used to think that once a cluster was built, I was done. I did not monitor the [SERP](/serp/) for changes. Last year a cluster I had built for "best running watches" collapsed when Garmin launched a new product line and the top 10 URLs completely changed. My pillar page dropped from position 3 to position 9. If I had been checking monthly ranking data from the Keyword Rank Checker, I would have spotted the shift earlier and updated the cluster. I now treat clustering as a living process, not a static spreadsheet.