Pourquoi l'URL Inspection Tool affiche-t-il un code 200 même après redirection ?

La déclaration de John Mueller lève le voile sur un comportement de l'URL Inspection Tool qui peut surprendre au premier abord. Quand vous testez une URL qui redirige, l'outil n'affiche pas le code de statut de la redirection (301, 302, 307, etc.), mais directement un code 200 correspondant à la page finale.

Cette logique s'explique par la vocation même de cet outil : montrer ce que Googlebot indexe réellement. Une redirection n'est pas indexée — c'est la page de destination qui l'est.

Quelles redirections sont concernées par ce comportement ?

L'outil suit toutes les redirections HTTP classiques (301, 302, 307, 308) ainsi que les redirections JavaScript. Peu importe la méthode technique utilisée, si Googlebot peut suivre la chaîne de redirection, l'URL Inspection Tool fera de même.

Cela signifie qu'une redirection JavaScript bien implémentée sera traitée exactement comme une redirection serveur du point de vue de l'inspection. Mais attention — ce n'est pas une validation que toutes vos redirections JS fonctionnent correctement dans tous les contextes.

Que montre exactement l'outil après avoir suivi la redirection ?

L'outil affiche le rendu complet de la page finale, tel que Googlebot le voit. Vous obtenez la capture d'écran, le code source rendu, les ressources chargées — tout ce qui permet de vérifier que la page de destination est bien crawlable et indexable.

C'est précisément pour cette raison que le code retourné est toujours 200 : vous ne diagnostiquez plus la redirection elle-même, mais la page qui en résulte.

• L'URL Inspection Tool affiche toujours le statut de la page finale indexable, pas celui de la redirection
• Les redirections HTTP (301, 302, etc.) et JavaScript sont suivies automatiquement
• Le code 200 affiché correspond à la page de destination, pas à l'URL testée initialement
• Cet outil sert à valider ce qui sera indexé, pas à diagnostiquer des problèmes de redirection

Cette logique est-elle cohérente avec la réalité du crawl ?

Oui, et c'est même plutôt transparent de la part de Google. L'outil reproduit fidèlement le comportement de Googlebot face aux redirections. Dans la réalité, une redirection correctement configurée transmet le PageRank et fait indexer la page cible, pas l'URL source.

Le problème, c'est que cette logique peut masquer des chaînes de redirections inefficaces. Si vous avez trois redirections successives avant d'atteindre la page finale, l'URL Inspection Tool vous montrera juste la dernière — avec un beau code 200 — sans signaler la perte de crawl budget ni le temps de chargement rallongé.

Quelles nuances faut-il apporter dans la pratique ?

Soyons honnêtes : cet outil n'est pas conçu pour diagnostiquer des problèmes de redirection. Il vous dit « voilà ce que Google indexe au final », pas « voilà comment il y arrive ». Pour analyser finement vos redirections, vous devez utiliser des outils complémentaires.

Un crawler comme Screaming Frog ou OnCrawl vous montrera les codes de statut intermédiaires, les chaînes, les boucles. L'URL Inspection Tool, lui, fait comme si tout allait bien dès lors que la page finale est accessible. [A vérifier] : Google ne précise pas combien de sauts de redirection l'outil est capable de suivre avant d'abandonner.

Les redirections JavaScript sont-elles vraiment équivalentes aux redirections HTTP ?

Sur le papier, oui — du point de vue de l'indexation finale. Mais dans les faits, une redirection JavaScript reste plus lente et plus fragile qu'une redirection serveur. Elle dépend du rendu JavaScript, donc d'une seconde vague de crawl, et peut échouer si le JS ne s'exécute pas correctement.

Le fait que l'URL Inspection Tool les suive ne signifie pas qu'elles sont recommandées. C'est juste la confirmation que Googlebot sait les gérer — dans des conditions idéales.

Comment vérifier qu'une redirection est bien configurée ?

Ne vous contentez pas de l'URL Inspection Tool. Utilisez un crawler SEO complet pour identifier les chaînes de redirections, les boucles, et les temps de réponse. Un code 200 final ne garantit pas une configuration optimale.

Testez également avec des outils réseau (Developer Tools du navigateur, curl) pour voir les codes de statut intermédiaires. Une redirection directe (source → destination) est toujours préférable à une chaîne de plusieurs sauts.

Quelles erreurs éviter lors de la mise en place de redirections ?

Ne créez jamais de chaînes de redirections inutiles. Chaque saut rallonge le temps de crawl et dilue le PageRank transmis. Une redirection doit pointer directement vers la page finale, pas vers une autre URL qui redirige elle-même.

Évitez aussi de mélanger redirections HTTP et JavaScript sans raison valable. Si vous pouvez faire une redirection serveur 301, c'est toujours la meilleure option — plus rapide, plus fiable, mieux comprise par tous les bots.

• Utilisez un crawler SEO pour auditer toutes vos redirections et détecter les chaînes
• Vérifiez que chaque redirection pointe directement vers la page finale, sans intermédiaire
• Privilégiez les redirections serveur 301 aux redirections JavaScript quand c'est possible
• Testez vos redirections avec plusieurs outils (URL Inspection Tool + crawler + outils réseau)
• Surveillez les temps de réponse : une redirection ne doit pas ralentir significativement le crawl
• Documentez votre plan de redirection lors de migrations pour éviter les erreurs en cascade