Pourquoi les codes HTTP mixtes sabotent-ils votre migration de domaine ?

Qu'est-ce qu'une réponse HTTP incohérente en migration ?

Une migration de domaine implique de déplacer l'ensemble de votre contenu d'un domaine source vers un domaine cible. La pratique standard consiste à mettre en place des redirections 301 permanentes depuis chaque URL de l'ancien domaine vers son équivalent sur le nouveau.

Le problème survient quand certaines pages de l'ancien domaine continuent de renvoyer un code 200 (OK), indiquant au bot que le contenu est toujours actif à cette adresse. Google reçoit alors des signaux contradictoires : une partie du site dit « je déménage » (301), l'autre dit « je reste ici » (200).

Pourquoi cette incohérence perturbe-t-elle Google ?

Les robots d'exploration s'appuient sur les codes de statut HTTP pour comprendre l'architecture de votre site et décider quelles URLs indexer. Un 301 signale un déplacement définitif : Google transfère les signaux de ranking (backlinks, autorité, historique) vers la nouvelle URL.

Un code 200 indique que la page est l'URL canonique. Si Google voit du 200 et du 301 cohabiter sur un même domaine en migration, il ne sait plus quelle version privilégier. Résultat : dilution des signaux, indexation fragmentée, ralentissement du transfert d'autorité.

Quels cas de figure génèrent ce type d'incohérence ?

Souvent, cette situation naît d'une migration partielle mal planifiée. Par exemple, vous migrez les pages produits mais laissez le blog sur l'ancien domaine avec un 200. Ou encore, les redirections sont configurées au niveau serveur pour certaines sections seulement, et d'autres échappent au filet.

Autre cas classique : les pages orphelines ou oubliées (anciennes landing pages, archives, URL de test) qui restent accessibles en 200 parce qu'elles n'étaient pas dans l'inventaire de migration. Google les crawle toujours, et le signal est brouillé.

• Cohérence totale : 100 % des URLs de l'ancien domaine doivent renvoyer un 301 vers le nouveau domaine.
• Risque de dilution : des codes 200 résiduels créent une compétition interne entre anciennes et nouvelles URLs.
• Audit pré-migration : inventoriez toutes les URLs crawlables avant de basculer, pas seulement celles dans le CMS.
• Monitoring post-migration : surveillez les codes HTTP renvoyés par l'ancien domaine dans la Search Console et les logs serveur.
• Durée de transition : maintenez les 301 pendant au moins 12 mois pour que Google consolide pleinement le transfert.

Cette recommandation est-elle vraiment nouvelle ?

Non. La nécessité d'utiliser des redirections 301 cohérentes lors d'une migration est un principe SEO établi depuis des années. Ce qui est intéressant ici, c'est que Google reformule explicitement le problème en termes de « compréhension de la migration ».

Ça confirme que le moteur ne se contente pas de suivre les redirections mécaniquement : il interprète l'intention de la migration en observant les patterns de codes HTTP. Un mélange 200/301 crée une ambiguïté sémantique pour l'algorithme, pas juste un problème technique.

Quelles nuances faut-il apporter à cette règle ?

Première nuance : la consigne parle de « toutes les pages », mais en pratique, il faut distinguer les pages crawlées activement des URLs zombies sans backlinks ni trafic. Si une vieille page de test sans lien entrant reste en 200, l'impact réel est négligeable.

Deuxième point : certains praticiens laissent intentionnellement quelques pages stratégiques en 200 sur l'ancien domaine pendant une courte période de transition, pour éviter une rupture brutale de service. C'est un pari risqué. [A vérifier] : Google ne quantifie pas à partir de quel pourcentage de pages en 200 la « perturbation » devient critique. 5 % ? 20 % ? Aucune donnée officielle.

Dans quels cas cette règle peut-elle être contournée ?

Techniquement, jamais. Mais la réalité terrain montre que certaines migrations partielles réussissent malgré une cohabitation temporaire. Par exemple, un sous-domaine isolé (blog.ancien-domaine.com) qui reste actif en 200 pendant que le domaine principal migre, si les deux sont traités comme des entités distinctes par Google.

Autre cas : une migration en plusieurs phases où vous migrez d'abord une section pilote, observez le comportement de Google, puis étendez. Pendant cette phase, les sections non migrées restent en 200. C'est un compromis entre prudence technique et risque SEO. Si vous choisissez cette voie, documentez tout et surveillez les fluctuations de ranking quotidiennement.

Que faut-il faire concrètement avant de migrer ?

Première étape : inventaire exhaustif de toutes les URLs de l'ancien domaine. Ne vous fiez pas uniquement au sitemap XML ou aux URLs listées dans le CMS. Crawlez le site avec Screaming Frog, Oncrawl ou Botify pour capturer les pages orphelines, les URLs paramétrées, les anciennes redirections internes.

Ensuite, mappez chaque URL source vers son équivalent cible. Pour les pages sans équivalent direct (contenus obsolètes, doublons), décidez si vous redirigez vers une page parent pertinente ou vers la homepage. Évitez les redirections vers la racine sauf en dernier recours : Google les interprète parfois comme des soft 404.

Comment vérifier que toutes les redirections sont bien en place ?

Après déploiement des 301, recrawlez l'ancien domaine. Chaque URL doit renvoyer un code 301, pas de 200, pas de 302, pas de 404. Utilisez un outil de crawl configuré pour suivre les redirections et vérifiez que la chaîne aboutit bien au nouveau domaine.

Vérifiez aussi les codes HTTP dans les logs serveur de l'ancien domaine pendant les premières semaines. Si Googlebot reçoit encore des 200, identifiez les URLs concernées et corrigez immédiatement. La Search Console (section Couverture) signale souvent les incohérences, mais avec un délai de quelques jours.

Quelles erreurs éviter absolument ?

Erreur classique : configurer les 301 au niveau applicatif (CMS, .htaccess) mais oublier des sous-domaines ou des répertoires spécifiques qui restent actifs en 200. Si vous avez un blog sur blog.ancien.com et un shop sur shop.ancien.com, chacun doit avoir sa propre règle de redirection.

Autre piège : les redirections en chaîne. Si l'ancien domaine redirige vers un domaine intermédiaire qui redirige ensuite vers le nouveau, Google peut perdre des signaux en route. Redirigez directement de l'ancien vers le nouveau, en une seule étape.

• Crawlez l'ancien domaine pour dresser un inventaire complet des URLs actives.
• Créez un fichier de mapping 1:1 entre ancien et nouveau domaine.
• Configurez les 301 au niveau serveur (nginx, Apache, CDN) pour garantir la cohérence.
• Recrawlez l'ancien domaine après déploiement pour vérifier que 100 % des pages renvoient un 301.
• Surveillez les logs serveur et la Search Console pendant au moins 8 semaines post-migration.
• Maintenez les 301 actives pendant 12 mois minimum, même si le trafic sur l'ancien domaine chute à zéro.