Why do mixed HTTP codes sabotage your domain migration?

What does an inconsistent HTTP response mean during migration?

A domain migration involves moving all your content from a source domain to a target domain. The standard practice is to set up permanent 301 redirects from each URL of the old domain to its equivalent on the new one.

The problem arises when some pages from the old domain continue to return a 200 (OK) code, indicating to the bot that the content is still active at that address. Google receives conflicting signals: part of the site says "I'm moving" (301), while another part says "I'm staying here" (200).

How does this inconsistency confuse Google?

Crawling bots rely on HTTP status codes to understand your site architecture and decide which URLs to index. A 301 indicates a permanent move: Google transfers ranking signals (backlinks, authority, history) to the new URL.

A 200 code indicates that the page is the canonical URL. If Google sees both 200 and 301 coexisting on the same migrating domain, it becomes uncertain which version to prioritize. The result: dilution of signals, fragmented indexing, and a slowdown in authority transfer.

What scenarios create this type of inconsistency?

Often, this situation arises from a poorly planned partial migration. For example, you migrate product pages but leave the blog on the old domain returning a 200. Alternatively, redirects are configured at the server level for only certain sections, while others slip through the cracks.

Another classic case involves orphaned or forgotten pages (old landing pages, archives, test URLs) that remain accessible with a 200 because they weren't included in the migration inventory. Google still crawls them, leading to signal confusion.

• Total consistency: 100% of URLs from the old domain must return a 301 to the new domain.
• Dilution risk: residual 200 codes create internal competition between old and new URLs.
• Pre-migration audit: inventory all crawlable URLs before switching, not just those in the CMS.
• Post-migration monitoring: keep an eye on the HTTP codes returned by the old domain in Search Console and server logs.
• Transition duration: maintain 301s for at least 12 months to allow Google to fully consolidate the transfer.

Is this recommendation really new?

No. The need for consistent 301 redirects during migration has been an established SEO principle for years. What's interesting here is that Google explicitly rephrases the issue in terms of "understanding the migration."

This confirms that the engine doesn't just mechanically follow redirects: it interprets the intent of the migration by observing HTTP code patterns. A mixture of 200 and 301 creates semantic ambiguity for the algorithm, not just a technical issue.

What nuances should be considered regarding this rule?

First nuance: the guideline mentions "all pages," but in practice, it’s important to distinguish between actively crawled pages and zombie URLs with no backlinks or traffic. If an old test page without incoming links remains a 200, the actual impact is negligible.

Second point: some practitioners intentionally leave a few strategic pages as 200 on the old domain for a short transition period to avoid a sharp service disruption. This is a risky gamble. [To be verified]: Google does not specify from what percentage of pages at 200 the "disturbance" becomes critical. 5%? 20%? No official data.

In what cases can this rule be circumvented?

Technically, never. But on the ground, reality shows that some partial migrations succeed despite a temporary coexistence. For instance, an isolated subdomain (blog.old-domain.com) that remains active as 200 while the main domain migrates, if both are treated as distinct entities by Google.

Another case: a multi-phase migration where you first migrate a pilot section, observe Google's behavior, and then expand. During this phase, the non-migrated sections stay at 200. This is a compromise between technical caution and SEO risk. If you choose this path, document everything and monitor ranking fluctuations daily.

What should you do practically before migrating?

First step: perform a thorough inventory of all URLs from the old domain. Do not rely solely on the XML sitemap or the URLs listed in the CMS. Crawl the site with Screaming Frog, Oncrawl, or Botify to capture orphaned pages, parameterized URLs, and old internal redirects.

Next, map each source URL to its target equivalent. For pages without a direct equivalent (outdated content, duplicates), decide if you want to redirect to a relevant parent page or to the homepage. Avoid redirects to the root unless as a last resort: Google sometimes interprets them as soft 404s.

How can you check that all redirects are properly in place?

After deploying the 301s, recrawl the old domain. Every URL should return a 301 code, no 200, no 302, no 404. Use a crawling tool set up to track redirects and ensure that the chain leads correctly to the new domain.

Also, check the HTTP codes in the server logs of the old domain during the first weeks. If Googlebot still encounters 200s, identify the affected URLs and correct them immediately. Search Console (Coverage section) often reports inconsistencies, but with a delay of a few days.

What mistakes should be absolutely avoided?

A classic mistake: configuring the 301s at the application level (CMS, .htaccess) but forgetting specific subdomains or directories that remain active at 200. If you have a blog at blog.old.com and a shop at shop.old.com, each must have its own redirect rule.

Another trap: chain redirects. If the old domain redirects to an intermediate domain that then redirects to the new one, Google may lose signals along the way. Redirect directly from the old to the new in one step.

• Crawl the old domain to create a complete inventory of active URLs.
• Create a 1:1 mapping file between the old and new domain.
• Configure the 301s at the server level (nginx, Apache, CDN) to ensure consistency.
• Recrawl the old domain after deployment to verify that 100% of the pages return a 301.
• Monitor server logs and Search Console for at least 8 weeks post-migration.
• Keep the 301s active for a minimum of 12 months, even if traffic on the old domain drops to zero.