Pourquoi masquer des redirections à Googlebot peut ruiner votre migration de site ?

Pourquoi un site cacherait-il ses redirections à Googlebot ?

Cette pratique vient souvent d'une mauvaise compréhension des user-agents ou d'implémentations JS qui ne s'activent que côté client. Certains CMS ou frameworks modernes déclenchent des redirections via JavaScript après le rendu initial — Googlebot les rate si le JS n'est pas exécuté correctement.

D'autres cas relèvent de configurations serveur intentionnelles : detection du user-agent pour servir du contenu différencié. Parfois, c'est une tentative maladroite d'éviter que les bots suivent certaines URLs pendant une migration progressive. Sauf que priver Googlebot des redirections, c'est lui dire de rester sur l'ancienne version du site.

Qu'est-ce qui se passe concrètement lors d'une telle migration ?

Les utilisateurs arrivent sur l'ancien site, sont redirigés vers le nouveau. Googlebot arrive sur l'ancien site, n'est pas redirigé, continue de crawler l'ancienne structure. Il indexe ou maintient l'ancien contenu, ignore le nouveau, et les signaux de ranking restent bloqués sur l'ancien domaine ou les anciennes URLs.

Résultat ? La migration n'existe pas aux yeux de Google. Vous perdez du trafic organique sur les nouvelles pages qui ne sont jamais crawlées, l'ancien site reste en index avec du contenu obsolète ou supprimé, et votre stratégie de consolidation tombe à l'eau.

Quelle est la portée réelle de ce problème ?

Gary Illyes parle d'escalations — donc des cas suffisamment graves pour remonter directement à l'équipe Search. Ça signale une erreur récurrente dans les migrations techniques, pas un bug isolé. Les équipes de dev web intègrent parfois des redirections côté client sans vérifier le comportement côté serveur.

• Les redirections doivent être visibles à tous les user-agents, y compris Googlebot
• Les redirections JavaScript ou côté client sont risquées en migration si Googlebot ne les exécute pas
• Une redirection 301/302 HTTP au niveau serveur reste la méthode la plus fiable pour une migration
• Tester la migration avec un user-agent simulé Googlebot est indispensable avant le basculement

Cette déclaration est-elle cohérente avec les pratiques observées ?

Complètement. On voit régulièrement des migrations qui s'effondrent parce que les redirections sont implémentées via JavaScript, Meta Refresh tardif, ou pire, via des règles serveur qui excluent explicitement les bots. Les devs pensent parfois bien faire en « protégeant » les bots de redirections pendant une phase de test — sauf qu'ils oublient de réactiver pour Googlebot.

Ce qui est intéressant, c'est que Gary ne parle pas d'un bug Google ici. Il pointe une erreur de configuration côté webmaster. Ça renforce le message de responsabilité : si Googlebot ne voit pas la redirection, il ne la suit pas. Point final. Pas de rendering miraculeux qui rattrape tout.

Quelles nuances faut-il apporter ?

Googlebot exécute du JavaScript dans certains cas, donc une redirection JS peut être suivie — mais [À vérifier] car le rendering n'est pas garanti pour toutes les pages, et le délai entre crawl HTML et rendering JS peut être de plusieurs jours. Compter là-dessus pour une migration, c'est jouer à la roulette russe.

Deuxième nuance : les redirections côté client (Meta Refresh avec délai zéro, redirection JavaScript immédiate) sont techniquement supportées par Google, mais restent moins fiables que les 301/302 HTTP. En migration, la fiabilité prime sur l'élégance technique.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre migration est purement côté frontend (SPA qui change de route sans changer d'URL serveur), vous n'avez pas besoin de redirection HTTP. Mais là encore, assurez-vous que Googlebot voit bien les nouvelles URLs via le rendering ou via des liens internes classiques.

Pour les migrations partielles ou progressives, il peut être tentant de rediriger seulement certains utilisateurs — mais jamais au détriment des bots. Si Googlebot ne suit pas, vous cassez l'indexation. Mieux vaut migrer en bloc ou utiliser des canonical tags pour signaler la version préférée pendant la transition.

Comment vérifier que Googlebot voit mes redirections ?

Utilisez l'outil d'inspection d'URL dans Google Search Console. Testez l'URL d'origine : si Google affiche une redirection et suit vers la nouvelle URL, c'est bon. Si l'outil affiche le contenu de l'ancienne page sans redirection, vous avez un problème.

Autre méthode : simulez un crawl avec un user-agent Googlebot via curl ou un outil comme Screaming Frog en mode « Googlebot smartphone ». Vérifiez que le code de statut HTTP est bien 301 ou 302, et que l'en-tête Location pointe vers la nouvelle URL. Si vous obtenez un 200 avec du contenu HTML, votre redirection est invisible pour Googlebot.

Quelles erreurs éviter absolument ?

Ne configurez jamais de règles serveur qui servent des redirections seulement à certains user-agents (sauf si vous savez exactement ce que vous faites et que vous incluez explicitement Googlebot). Ne comptez pas sur des redirections JavaScript sans test préalable avec l'outil d'inspection d'URL.

Évitez les Meta Refresh avec délai supérieur à zéro — Google peut les suivre, mais avec un délai et une fiabilité moindre. Pendant une migration, chaque jour compte pour transférer les signaux de ranking. Une redirection 301 HTTP serveur est immédiate et sans ambiguïté.

Que faut-il faire concrètement avant et après une migration ?

• Implémenter les redirections au niveau serveur (Apache, Nginx, CDN) avec codes 301 pour migration permanente
• Tester chaque URL critique avec l'outil d'inspection d'URL de Search Console avant le basculement
• Simuler un crawl complet avec un user-agent Googlebot pour vérifier que toutes les redirections sont visibles
• Surveiller les logs serveur post-migration : Googlebot doit recevoir des 301/302, pas des 200 sur les anciennes URLs
• Vérifier dans Search Console que les anciennes URLs disparaissent de l'index et que les nouvelles sont crawlées
• Configurer des alertes sur les erreurs 404 et les pages orphelines pour détecter les redirections manquantes