Merging two websites: Why doesn’t Google treat this like a standard migration?

What is the fundamental difference between migration and merging?

A standard migration involves moving a site from domain A to domain B without changing its architecture or content. Google follows 301 redirects, transfers signals (PageRank, authority), and the process is relatively predictable.

The merging, on the other hand, combines two distinct entities into one. This implies reworking the site structure, deciding where to place each piece of content, and creating a new hybrid structure. Google has to re-crawl everything as if it were discovering a brand new site—gone is the comfort of simple redirection.

Why does Google need to massively re-crawl during a merger?

Because the engine can't simply transfer signals from point A to point B. It has to understand the new relationship between the merged contents: are they competing? complementary? redundant?

The relevance signals (internal links, semantic clusters, page depth) change drastically. A page that was deeply buried in site A may become central in the new structure—or vice versa. Google must reevaluate each URL in its new context.

How does the merging structure impact processing speed?

Martin Splitt emphasizes that architectural choice is crucial. There are two approaches: mixing contents (integrated approach) or creating distinct sections (modular approach).

The modular approach—where each old site retains its own section—facilitates crawling: Google can process each block separately. The integrated approach—where contents are mixed by theme—requires a more detailed analysis of cannibalization signals and semantic consistency, which slows down the process.

• Merging = new site in Google's eyes, not just a simple move
• Massive re-crawling is unavoidable—expect several weeks or even months
• The chosen structure (mixed or modular) directly affects recovery speed
• Relevance signals must be rebuilt, not just transferred
• Crawl budget is critical: a merged site with 50k pages requires careful management

Does this statement align with what we observe in practice?

Absolutely. Mergers consistently cause traffic fluctuations that are much more violent than a standard migration. We often see drops of 30-50% for 2-3 months before stabilization—whereas a well-executed migration limits damage to 10-15% over 3-4 weeks.

What Google doesn’t mention: the real issue isn’t technical but editorial. Merging two sites often means merging two SEO strategies that cannibalize each other. You end up with three pages fighting for the same keyword, "divorce lawyer Paris." Google has to untangle this mess—and that takes time.

What nuances do we need to consider regarding this claim?

Splitt talks about "processing speed" without providing numbers. [To be verified]: are we talking weeks, months, quarters? The answer depends on factors he doesn’t mention: site size, available crawl budget, quality of merged contents.

Another blind spot: the issue of backlinks. Merging two sites means merging two link profiles. If site A has 5000 backlinks pointing to /services/ and site B has 3000 to /offerings/, what happens to that authority when we merge into /offers/? Does Google dilute, consolidate, or ignore it? Splitt remains vague.

In which cases might this logic not fully apply?

If one of the two sites is nearly dead (negligible organic traffic, minimal crawl budget), the merger behaves more like a migration with content increase. Google primarily treats the dominant site and gradually absorbs the other.

Another exception: merging subdomains into a main domain. Technically it’s a merger, but if blog.site.com migrates to site.com/blog/, Google handles this more quickly than a true merger of two distinct domains—the authority signals are already partially shared.

What concrete steps should be taken before merging two sites?

First, audit potential cannibalization. Identify all semantic duplicates: if both sites target the same queries, decide which version to keep. Favor the one with the best organic traffic history, not the one that "looks" better written.

Next, map out the redirects upstream. Unlike a standard migration, where it’s a 1:1, here you might have 2:1 (two old URLs to one new), 1:0 (obsolete content that we abandon), or 1:new (refined content). Each choice impacts the crawl budget and processing speed.

How to structure the merger to minimize SEO impact?

The modular approach (distinct sections) is safer but less elegant. It preserves existing thematic silos and facilitates post-merger tracking—you can measure the performance of each old site separately.

The integrated approach is riskier but potentially more performant in the long term. It requires a comprehensive editorial overhaul: merging complementing contents, removing redundancies, and creating a coherent new semantic architecture. That said, the recovery time will be longer—and that’s where many clients struggle.

What mistakes should absolutely be avoided during a site merger?

Never launch a merger during a high-traffic commercial period (Black Friday, sales, product launch). The temporary loss of visibility can cost a fortune. Plan in the off-season.

Also, avoid merging without bolstering the crawl budget beforehand. Submit a new combined XML sitemap, increase the frequency of content updates, and optimize server response times. Google must have the resources to digest this large content quickly.

• Conduct a comprehensive semantic cannibalization audit (tools: Ahrefs, SEMrush, Screaming Frog)
• Map all redirects (2:1, 1:1, 1:new) in a thorough mapping file
• Choose between a modular approach (distinct sections) and integrated approach (mixed contents) based on available resources
• Prepare a merged XML sitemap and submit it via Search Console before the switch
• Plan the merger outside of critical commercial periods to endure temporary traffic dips
• Monitor daily crawl budget and 404 errors post-merger for at least 90 days