Pourquoi l'outil de changement d'adresse bloque-t-il les URL avec paramètres ?

Que vérifie exactement l'outil de changement d'adresse ?

L'outil de changement d'adresse de Search Console effectue une validation technique précise avant d'accepter une demande de migration. Il contrôle que la page d'accueil du site source redirige vers la page d'accueil du site cible, sans ajout ni modification.

Si la redirection pointe vers une URL comportant des paramètres d'URL (comme ?utm_source=migration ou ?ref=ancien-site), l'outil bloque la procédure. Cette vérification s'applique dès la homepage — peu importe que vos redirections internes soient parfaites.

Pourquoi cette restriction sur les paramètres ?

Google applique une logique de correspondance stricte pour éviter les abus et garantir que la migration est légitime. Un changement d'adresse doit signaler un déplacement pur et simple du contenu, pas une transformation ou une manipulation.

L'ajout de paramètres — même anodins comme du tracking — crée une URL différente aux yeux de Google. L'outil interprète cela comme une non-conformité à la règle du un-pour-un. Cette approche rigide évite que des sites tentent de migrer vers des structures ambiguës ou d'exploiter l'outil pour des usages détournés.

Cette règle s'applique-t-elle uniquement à la homepage ?

La déclaration de Mueller précise que la vérification se fait sur la page d'accueil. C'est elle qui sert de point de contrôle initial. Si cette redirection échoue à cause de paramètres, l'outil refuse d'aller plus loin.

Pour les pages internes, la tolérance reste floue. L'outil ne documente pas explicitement s'il vérifie chaque URL ou s'il se contente de la homepage. Dans la pratique, mieux vaut appliquer la règle partout : rediriger proprement, sans paramètres, pour éviter tout blocage.

• L'outil exige une redirection 301 stricte de la homepage vers la nouvelle homepage, sans ajout de paramètres
• Les paramètres d'URL — tracking, session, référence — cassent la logique un-pour-un et provoquent un refus automatique
• Cette vérification concerne explicitement la page d'accueil, mais la prudence recommande d'appliquer la même règle à toutes les redirections
• Aucune tolérance documentée pour les paramètres canoniques ou de tracking systématique

Cette restriction est-elle cohérente avec les observations terrain ?

Absolument. Les retours de praticiens confirment que l'outil de changement d'adresse rejette systématiquement les migrations où la homepage redirige avec des paramètres ajoutés. Aucune exception connue, même pour des cas légitimes de tracking interne.

Ce comportement s'aligne avec la philosophie Google de migration propre : un changement d'adresse doit être un déplacement, pas une refonte structurelle. La rigidité de l'outil force les SEO à nettoyer leurs redirections avant de soumettre.

Quelles zones d'ombre subsistent ?

Mueller ne précise pas si l'outil vérifie uniquement la homepage ou s'il audite un échantillon de pages internes. [À vérifier] : aucune documentation officielle ne détaille la profondeur de cette vérification.

Autre flou : que se passe-t-il si le paramètre existe déjà sur l'ancien site ? Si l'ancienne homepage redirige vers une nouvelle homepage avec le même paramètre (ex: ?lang=fr vers ?lang=fr), l'outil refuse-t-il quand même ? La déclaration ne le précise pas. Par prudence, supprimez tout paramètre sur la cible.

Dans quels cas cette règle pose-t-elle problème ?

Les sites utilisant du tracking systématique (plateformes e-commerce, SaaS) se heurtent à cette contrainte. Si leur architecture impose des paramètres de session ou de source, ils ne peuvent pas utiliser l'outil de changement d'adresse.

Alternative : gérer la migration manuellement via les redirections 301, sans passer par l'outil. C'est plus long, mais ça évite le blocage. Le risque ? Perdre l'effet de signal explicite que l'outil envoie à Google pour accélérer la réévaluation du nouveau site.

Que faut-il faire concrètement avant de soumettre un changement d'adresse ?

Vérifiez que la redirection 301 de votre ancienne homepage pointe vers la nouvelle homepage sans aucun paramètre. Testez avec un outil de vérification de redirections (Screaming Frog, curl, Redirect Path) pour confirmer que l'URL cible est propre.

Si votre plateforme ajoute automatiquement des paramètres (tracking, session, langue), désactivez-les temporairement ou configurez une exception pour la homepage. L'objectif : une redirection directe, sans ajout, vers https://nouveausite.com/ et rien d'autre.

Quelles erreurs éviter absolument ?

Ne redirigez jamais la homepage vers une URL contenant des UTM, des paramètres de référence ou de session. Même si ces paramètres semblent inoffensifs, l'outil les détecte et bloque la procédure.

Autre piège : rediriger vers une version canonique avec paramètre. Exemple : anciensite.com/ → nouveausite.com/?version=desktop. Même si la balise canonical pointe vers la version sans paramètre, l'outil vérifie la destination de la redirection, pas la canonical. Résultat : refus.

Comment vérifier que mon site est conforme ?

Avant de soumettre la demande dans Search Console, effectuez un test manuel. Chargez votre ancienne homepage dans un navigateur en navigation privée et observez la barre d'adresse après redirection. Si elle contient le moindre ? ou &, corrigez.

Utilisez également l'onglet Network des DevTools pour tracer la chaîne de redirections. Une chaîne propre : 301 direct de anciensite.com/ vers nouveausite.com/, statut 200 final, aucun paramètre en vue. Toute déviation signale un problème potentiel.

• Vérifier la redirection 301 de la homepage avec un outil dédié (Screaming Frog, curl)
• S'assurer que l'URL cible ne contient aucun paramètre (?utm, ?ref, ?session, etc.)
• Désactiver temporairement les paramètres de tracking automatique sur la homepage
• Tester la redirection en navigation privée pour confirmer l'URL finale
• Contrôler la chaîne de redirections complète via DevTools (Network)
• Documenter la configuration pour rollback rapide si nécessaire