When two blog posts overlap, we judge them by what each one helps a reader do, not by whether they share a keyword. Leave both alone when they complete different reader tasks. Differentiate them when the tasks differ but the answers have drifted into each other. Merge them when either post could fully serve the same reader doing the same thing.
It is normal for several URLs from one site to rank for the same terms. Search Engine Journal’s cannibalization guidance separates that ordinary overlap from actual problems, such as declining aggregate clicks or visitors landing on a page written for a different stage. Two of your URLs appearing for one query is a reason to compare their answers. It is not evidence that one page is suppressing the other.
Choose by task, scope and performance
Start by writing one sentence for each post that says what the reader should be able to do after reading it. Then compare what each body actually delivers, because titles can hide overlap: two differently titled tutorials may still give the same answer. Understanding a concept and fixing a specific problem, on the other hand, are different tasks. We put this test first because changing a duplicate article’s keywords does not give it a separate purpose.
| Criterion | Leave both alone | Differentiate | Merge |
|---|---|---|---|
| Reader task | Each post completes a different task. | The tasks differ, but their boundaries are blurred. | Either post could fully answer the same task. |
| Answer scope | Each main answer belongs on its own page. | One post repeats the other’s main answer or addresses the wrong stage. | The main answers substantially duplicate each other. |
| Performance interpretation | Shared queries without demonstrated loss or wrong-stage landings do not justify a change. | Wrong-stage landings or shifting selection with declining performance warrant closer inspection. | Page-level data helps choose the survivor. Duplication alone does not prove ranking harm. |
| Editorial action | Keep both and link where the next task is relevant. | Remove the repeated answer and link to the page that owns it. | Preserve unique useful material in one page and redirect the retired URL. |
Use Search Console to see which page Google selects
Search Engine Journal’s analysis describes two ways to compare the pages. In the Search Console Performance report, filter by the shared query and open the Pages tab. Then compare impressions, clicks and average position for the two URLs across several months rather than in a single snapshot. For a larger archive, export query-page pairs through the Search Analytics API and inspect the same pattern there.
When those metrics alternate between the two URLs, Google is shifting which page it selects for the query. Switching by itself, without a demonstrated loss, does not show harm. What matters is whether the pair’s combined clicks or overall positions have declined, and whether the page Google selects answers the task behind the query. Even when a decline coincides with the switching, the report alone does not establish that the overlapping content caused it.
At Blogent, we plan articles from customer questions, customer needs and search demand, drawing on connected Google Search Console data when it is available. Performance data can point you to a pair worth reviewing, but the answers on the two pages decide whether they should stay separate. Our guide to using Search Console data for blog automation covers the wider planning workflow. If you are still designing hubs and planning topics from scratch, our guide to building content hubs that scale covers that job, while this page deals with overlap between pages you already have.
Leave both alone: a canonical tag explainer and a troubleshooting post
Take an illustrative pair: an explainer on what canonical tags do, and a troubleshooting post about fixing a page where Google chose a different canonical. Both may appear for canonical-tag queries, but they serve different readers. One wants to understand the concept. The other has a specific status to resolve, and the explainer alone does not fully answer that.
Keep both as long as those boundaries hold and there is no demonstrated performance loss or wrong-stage landing. The explainer can point readers who have that specific problem to the troubleshooting post, which in turn can link back for conceptual background without reproducing the full explanation. The shared canonical-tag vocabulary stays, because both posts need it to do their jobs.
Differentiate: choosing a CMS versus setting up WordPress
The second illustrative pair is a guide that helps a small business choose a blog CMS and a WordPress blog setup checklist. Their tasks are distinct and follow one another: choose the platform, then configure it. Now suppose the checklist includes a substantial CMS comparison. It sends a reader who is ready to set up WordPress back into a decision the other guide already covers.
We would cut the comparison from the checklist, keep the WordPress setup steps and link to the CMS guide for readers who have not yet chosen a platform. The CMS guide stays focused on the choice and points readers who pick WordPress to the checklist as their next step. Each page then answers its own question completely.
Merge: two answers to writing a meta description
For the merge case, consider two illustrative posts called How to Write a Meta Description and Meta Description Tips. If both teach the same reader how to write a meta description, the different titles do not make them different tasks. We would consolidate them into one answer and let the site’s page-level performance data, rather than the titles, guide which URL survives.
The point of consolidating is a better surviving answer. If the tips post has a useful example, or answers a relevant question the tutorial skips, move that material into the surviving article before redirecting. Keep whatever advances the writing task, and drop passages that only repeat advice already covered.
Once the other post is permanently retired, send its URL to the survivor with a server-side 301 redirect. Google’s long-standing redirect guidance, published in the context of cross-domain canonicalization, favors a permanent redirect when content moves. The retired URL then leads to the merged article, and the site no longer keeps two competing answers accessible.
A canonical tag fits a different situation: duplicate or substantially duplicate URLs that must remain accessible to users. Google’s canonicalization documentation explains that canonical signals are suggestions, and Google can select another URL when signals conflict. For a post you intend to retire, a canonical tag is no substitute for the redirect. Nor should you add one to a URL that already returns a 301. As explained in a Search Central Help Community discussion, crawlers process the redirect before reading the page’s HTML.
Complete the merge without losing useful material
We treat a merge as an editorial change followed by a URL change: first complete the surviving answer, then bring the rest of the site into line with its URL. Updating links and sitemap entries matters because conflicting signals can affect which URL Google selects as canonical.
Example of using the shortcode function through Blogent
- 1. Inventory both answers. Mark the useful examples, data, steps and answered questions that appear in only one post and serve the shared task.
- 2. Edit the surviving article. Work that material in where it belongs and cut the repetition, instead of appending the retired post wholesale.
- 3. Put the 301 redirect in place. Send the retired URL to the completed surviving article.
- 4. Repair internal links. Change links to the retired article so they point directly to the survivor.
- 5. Update the sitemap. Remove the retired URL’s entry and make sure the surviving URL is listed.
