How We Avoid Keyword Cannibalization Across 490 Reviews

We publish a lot. As of this writing the site carries around 490 published reviews, and most of them live in the same handful of categories: dev tools, infrastructure, productivity SaaS. That density is the whole problem. Once you have forty articles that all orbit “self-hosted password manager” or “best note-taking app,” Google has to guess which one you actually want to rank. When it guesses wrong — or splits the vote across three of your URLs — you lose the position you’d have won with one clear page.

That’s keyword cannibalization: two or more of your own pages competing for the same query, diluting the link equity, click signals, and relevance that would otherwise concentrate on a single result. It doesn’t show up as an error. Nothing breaks. You just quietly underperform, and on a large blog you underperform across hundreds of queries at once.

Here’s the workflow we run to keep it in check.

How we detect it

The fastest signal lives in Google Search Console. Open the Performance report, switch to the Queries view, and click into a query you care about. Then add the Pages dimension. If a single search term is returning impressions for three or four of your URLs, that query is cannibalized — Google is rotating between your pages instead of committing to one.

We export the full query/page table roughly once a month and run a simple pivot: group by query, count distinct pages, and flag any query where more than one URL pulls meaningful impressions. The ones that hurt aren’t the long-tail phrases with two impressions each. They’re the mid-volume queries where page A sits at position 8, page B at position 11, and neither breaks the top five. Consolidate those signals and you often jump both pages’ worth of authority onto one result.

A second, cruder check: site search. Running site:pickuma.com self-hosted vpn in Google shows you, in ranked order, every page we have on a topic. If the top three look like near-duplicates, that’s a cluster worth auditing. It takes ten seconds and catches the obvious cases before they need a spreadsheet.

How we decide what to do

Once a cluster is flagged, every cannibalized group resolves to one of four moves. We pick based on whether the pages serve genuinely different intent or just overlap by accident.

Differentiate. This is the default when both pages deserve to exist. We rewrite titles, H1s, and the first 150 words so each page targets a distinct angle of the query. A “Tailscale review” and a “Tailscale vs WireGuard” page should never read like the same article — so we make sure the comparison page leads with the comparison and the review page leads with the verdict. Most of our clusters get fixed here, without deleting anything.

Consolidate. When two pages are 80% the same content chasing the same intent, we merge the stronger material into the better-performing URL and 301-redirect the weaker one. The redirect passes most of the lost page’s authority to the survivor. We do this surgically — a redirect is hard to walk back, and on this site the git history is our provenance record, so every merge is a deliberate, logged decision.

Canonicalize. Occasionally two pages must both exist for UX reasons (a category landing page and a deep review, say) but target overlapping terms. Here we set a rel=canonical from the secondary page to the primary, telling Google which one to index for the shared query while keeping both live for readers.

Re-link. Internal links are votes. If our “best mesh VPN” roundup links to four different VPN reviews using the same anchor text, we’re telling Google all four are equally relevant for that anchor. We fix anchors to point decisively — the page we want to rank for “mesh VPN” gets that anchor; the others get their own specific phrasing.

How we prevent it before publishing

Detection is cleanup. The cheaper fix is not creating the conflict in the first place. Before we draft a new article, we check it against a keyword map — a single source of truth listing every primary keyword we’ve already claimed and the URL that owns it. If a proposed topic’s primary keyword is already taken, the new piece either gets a sharper, narrower angle or doesn’t get written.

That map is just a database: one row per primary keyword, the owning URL, the target intent, and the publish date. The discipline matters more than the tool — but a tool that makes the map easy to query at draft time is what keeps the habit alive when you’re publishing every week.

The other half of prevention is internal linking discipline at publish time. Every new article links back to the canonical owner of its topic cluster, and the cluster owner links out to its supporting pages. That hub-and-spoke shape tells search engines exactly which page is the authority and which are the depth — the structure does the disambiguation for you, automatically, on every new post.

None of this is glamorous, and at fifty articles you don’t need any of it. At several hundred, it’s the difference between a blog that compounds and one that quietly competes with itself.