How to Find Keyword Cannibalization in Google Search Console

Finding two pages associated with the same query is the beginning of an investigation. It does not establish that either page is suppressing the other. Search Console can help you inspect query-to-page relationships, but only if you keep the report’s filters and aggregation clear. This guide explains a careful workflow and how to prepare data for a local overlap report.

The examples are fictional. Their clicks and impressions illustrate calculations rather than actual site performance. Before changing an existing page, combine the report with a content review, a clear understanding of visitor needs, and compatible trends. An automated match should never be your sole reason to merge, redirect, or delete a useful resource.

Set a consistent investigation scope

Open the Search results Performance report for the relevant property. Choose a date range that contains enough activity for your question, then record the search type, country, device, and any other filters. Comparing a mobile-only page sample with an all-device query total can create a misleading story even when both numbers came from the same property.

Start with a specific query you already have a reason to investigate: perhaps two articles claim the same editorial task, or a page inventory reveals repeated briefs. A broad query can reasonably connect to several parts of a website. Choosing it merely because it has many impressions does not turn every associated page into a cannibalization problem.

Google’s dimensions documentation explains that groupings affect the report. Keep the selected query and page context visible in your notes. When you compare time periods, use the same dimensions and recognize that new pages, seasonality, inventory changes, and broader demand can influence the pattern.

Filter one query, then inspect its pages

Apply an exact query filter rather than a broad contains filter when you need one precise relationship. Then inspect the Pages tab under that filter. The page rows now have the selected query as context. Record each relevant page, its available metrics, and the scope of the export. Do not remove the query filter and assume the next table still describes the same thing.

A fictional query such as coffee grinder cleaning might show a general cleaning guide, a support article, and a product page. Open each page and describe its job. The support article could address a particular mechanism while the guide explains routine care. Their common query association is a reason to inspect the distinction, not evidence that the site must keep only one.

If you investigate several exact queries, repeat the process consistently. Save the source query with each page export before stacking rows together. It is better to build a small, correctly scoped dataset than a large one containing invented query-to-page pairs. You can expand coverage later when you have a reliable workflow and understand what the exports omit.

Prepare a query-to-page file without inventing joins

The Keyword Cannibalization Checker requires a query and its associated page URL on every row. A typical file has query, page, clicks, impressions, ctr, and position headers. Optional metrics may be blank or unmapped. At minimum, the relationship between query and page must be established by the source context rather than guessed from the spreadsheet layout.

A normal export may contain separate Queries and Pages sheets. These are independently grouped tables. The first query is not necessarily associated with the first page, and the second rows have no guaranteed relationship either. Joining them by row position creates false data. Keep the selected exact query with the page rows from its filtered export, or obtain a legitimate combined query-and-page dataset through your own reporting process.

Google’s export help describes table exports limited to 1,000 rows. An exported sample may therefore omit relationships on a larger site. Some queries are also not available in the reporting data. Absence from your file is not proof that a query or page had no activity, and the checker cannot restore missing coverage.

Read the overlap report as a review queue

Upload the CSV or XLSX, map the required fields, and inspect the preview. Confirm that the source rows use compatible filters and non-overlapping slices. Review rejected rows before trusting the summary. A malformed page field or missing query can reduce coverage precisely where you wanted to investigate.

For a fictional query, suppose a guide has 18 clicks from 600 impressions and a support page has 9 clicks from 300. Both have a 3% CTR in those supplied rows. That equality does not show that visitors preferred one over the other; the contexts and number of opportunities differ. Read the page roles and inspect comparable trends before proposing a content change.

Repeated rows for the same query and URL are combined by summing complete clicks and impressions. CTR is recalculated from those totals, rather than averaging percentages. Average position is impression-weighted only when compatible weights exist. If a position has no supporting weight across repeated rows, the report leaves the aggregate unavailable rather than inventing precision.

Check the source before trusting an aggregate

If you append the same export twice, the checker cannot reliably distinguish an accidental duplicate from a legitimate repeated observation. It will sum those rows. Likewise, overlapping date exports can double-count activity. Keep a source manifest with the date range and filters for every file. Remove duplicated extracts before treating the total as a meaningful site measurement.

Do not sum totals that describe different aggregation scopes and then compare the result with the property’s chart as though they were identical. Your local report is a calculation over supplied rows. Keeping that distinction visible is especially important when sharing an export with someone who did not prepare the dataset.

Decide whether the pages actually compete

Compare the visitor task, content type, audience, and next action for each URL. Are both pages trying to provide the same complete answer, or does one offer an explanation while another enables a purchase? Does the broad query conceal several reasonable needs? A useful page should not be removed merely because a more general page also appears.

Then inspect time patterns under compatible filters. A destination change may follow a content update, availability change, or shift in search context. A single average position cannot explain the cause. Record your hypothesis and the evidence that would support or weaken it before changing the site. This protects you from turning an overlap report into a sequence of speculative redirects.

When roles are unclear, use the keyword mapping workflow to assign a task to each page. Use the search-intent grouping guide when similar wording masks different needs. Those editorial steps often reveal whether differentiation or consolidation deserves further investigation.

Make a measured change and keep a record

For genuinely redundant content, plan the strongest useful destination, preserve unique information, review relevant links, and decide whether a redirect is appropriate. For different tasks, improve the distinction through the content itself and sensible navigation. A title edit alone cannot create a meaningful difference between two otherwise interchangeable pages.

Document what changed and why, then revisit comparable periods with the same reporting scope. Keep the original dataset and the new observations. The outcome you want is a clearer website with useful page roles. Search Console helps you observe relationships, while your content review determines what those relationships mean and what action, if any, is justified.