Should I worry about cannibalization between two identical sites?

Why does Google talk about identical HTML content?

Precision matters here: John Mueller explicitly mentions identical HTML content, not just the visible text. Google compares the complete source code of the pages, including meta tags, scripts, and DOM structures. Two sites may visually display the same content but have different HTML signatures depending on the CMS, theme, or plugins used.

This distinction is crucial during migration. If you duplicate a WordPress site to a new domain with the same theme and configuration, Google will detect a perfect duplicate. Conversely, redesigning the layout or changing the CMS may be sufficient to avoid this scenario, even if the textual content remains similar.

What does determining a canonical URL mean in this context?

Google does not merely note the duplicate: it applies its canonicalization process to choose which version to display in the results. This choice relies on several signals: domain age, link profile, usage data, explicit canonical declarations. The engine tries to guess your intent.

The problem? This automatic determination is never guaranteed. Google may favor the old domain while you want to promote the new one, or vice versa. Without a clean 301 redirect or clear canonical tag, you lose control and allow the algorithm to decide for you. It’s a risky gamble.

In what scenarios does this situation arise?

The typical cause: a poorly executed domain migration. The company launches the new site, forgets to take down the old one or set up redirects. Result: two active domains with strictly identical content for weeks or even months. Google indexes both, then arbitrarily decides which to keep.

Another common case: publicly accessible test or staging environments. An agency creates a pre-production version without blocking it via robots.txt or authentication. If this version replicates the production site’s content with the same HTML structure, Google detects it and creates an unintended canonicalization conflict.

• Migrations without 301 redirects: old and new domains active simultaneously with identical content
• Indexable staging environments: test versions crawled by Google, creating unintentional duplicates
• Poorly configured multilingual mirror sites: identical HTML content without appropriate hreflang or canonical tags
• Partial redesign: new domain launched with only a few redesigned pages, the rest copied as is
• Reuse of identical templates: two companies using the same theme with similar content without sufficient customization

Does this statement align with field observations?

Absolutely. Cases of failed migration with loss of rankings have been documented for years. When a site migrates without redirects and keeps the old domain active, there is consistently a phase of confusion during which Google indexes both versions. Then, gradually, one disappears from the index in favor of the other.

What is less predictable is which version Google will favor. In 70% of observed cases, it is the old domain that retains the positions, while the new one remains invisible. Why? Probably due to its history, existing link profile, and accumulated authority signals. However, I have also seen the opposite: Google suddenly switches to the new domain, draining the old of its organic traffic overnight.

What nuances does Google not mention here?

The statement remains vague on the similarity threshold needed to trigger the duplicate. How many HTML differences are required for Google to consider two sites distinct? Is changing 20% of the code enough? 50%? [To be verified]: no official documentation quantifies this threshold, and empirical tests yield varying results across sectors.

Another point not addressed: the duration of the confusion phase. When Google detects two identical versions, how long does it take to decide? Observations show an average of 2 to 8 weeks, but it can extend over several months if the signals are conflicting. During this time, your rankings fluctuate dramatically, with no apparent logic.

Does this rule apply to sites in different languages?

Technically yes, but Google manages language versions differently. If you duplicate your French site to an English domain with basic automatic translation, the HTML may remain nearly identical (same structure, same tags, only the text changes). Google will detect the structural similarity.

However, correctly implemented hreflang tags signal to Google that these are intentional language versions, not unwanted duplicates. The engine then applies geo-targeting logic rather than pure canonicalization. However, be cautious: poor automatic translation may be penalized for low-quality content, regardless of the technical duplicate.

What should you do during a domain migration?

The only reliable approach: implement permanent 301 redirects from each URL of the old domain to its new counterpart. No shortcuts, no global redirect to the homepage. Each page must point to its exact equivalent on the new domain. This method transfers authority and avoids any canonicalization conflicts.

Once the redirects are in place, keep the old domain active for a minimum of 6 months. Google needs this time to transfer all historical signals. Turning off the old domain too early cuts short the authority transfer and causes you to lose some of the SEO juice accumulated. Monitor Search Console: when crawls of the old domain drastically decrease, you can begin considering its closure.

How to manage test environments without creating duplicates?

Always block the crawling of staging environments via robots.txt with a global Disallow: /. Better yet, protect them with basic HTTP authentication or IP whitelisting. I've seen too many sites where the test version ranked better than production because it was accidentally indexed with a clean external link profile.

Add a meta robots noindex tag in the header of all staging pages, as double security. If Google crawls despite the robots.txt (which can happen when someone links to staging), the noindex prevents indexing. Regularly check via a site:staging.yourdomain.com search to detect any leaks.

What strategy to adopt if both domains are already indexed?

First, identify which domain Google is currently favoring. Use the Search Console of each domain: the one receiving the most impressions and organic clicks is likely the one Google considers canonical. If it's the wrong domain, you need to force the switch.

Immediately implement 301 redirects from the undesired domain to the one to promote. Simultaneously, add a self-referential canonical tag on all pages of the target domain, explicitly signaling "this is the version to index." Request manual reindexing of the main pages through Search Console to speed up the process. Expect 3 to 6 weeks before full stabilization.

• Map all URLs: create an exact match old domain → new domain before migration
• Implement 301s: redirect page by page, no global redirect to the homepage
• Block test environments: robots.txt + noindex + authentication on staging/dev
• Check canonicals: self-referential canonical tags only on the main domain
• Monitor Search Console: track crawls and impressions of both domains for 6 months
• Disavow if necessary: if the old domain had toxic links, disavow them before migration to avoid transferring the penalty