Erreur de redirection dans Google Search Console

TL;DR — « Redirect error » dans Google Search Console signifie que Google a tenté de suivre une redirection pour votre page sans y parvenir. La redirection est cassée et la page n’a pas été indexée : il faut corriger le problème. Ne confondez pas ce statut avec « Page with redirect », qui décrit généralement une redirection normale et fonctionnelle.

Signification de « Redirect error »

Ce libellé indique que Google a rencontré une redirection qu’il n’a pas réussi à suivre jusqu’à une destination. Evidence for this claim Google reports Redirect error when it could not process a redirect to a destination. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Le rapport cite les chaînes trop longues, les boucles, les URL devenues trop longues et les URL de redirection incorrectes ou vides. Evidence for this claim Google lists overly long chains, loops, excessive redirect URL length, and bad or empty redirect URLs for this report status. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

Dans le rapport Indexation des pages de Google Search Console — sous « Indexation » dans le menu — Google regroupe par motif les URL qu’il n’a pas indexées. Redirect error est l’un de ces motifs.

Google a trouvé sur votre URL une règle envoyant les visiteurs vers une autre adresse, mais n’a pas atteint la destination finale. La redirection peut mener à une longue chaîne, deux pages peuvent se renvoyer en boucle ou la cible peut être vide ou invalide. Google abandonne alors et la page ne peut pas être indexée.

La confusion la plus fréquente

Un autre statut s’appelle « Page with redirect ». Il ne signifie pas la même chose :

• Redirect error = redirection cassée que Google n’a pas pu suivre. Vous devez la corriger.
• Page with redirect = redirection normale et fonctionnelle. Google l’a suivie ; l’URL n’est simplement pas la version principale et n’est donc pas indexée, tandis que sa cible peut l’être. Ce n’est pas une erreur et aucune action n’est généralement nécessaire.

Ne vous inquiétez donc pas devant « Page with redirect » : c’est souvent le comportement attendu. « Redirect error » indique, lui, un vrai dysfonctionnement.

Comment intervenir

L’objectif est presque toujours identique : rediriger directement vers la page finale en un seul saut, sans chaîne ni boucle.

1. Ouvrez l’inspection d’URL dans Search Console ou visitez l’URL pour reproduire le problème.
2. Repérez le saut cassé : boucle, mauvaise adresse ou chaîne trop longue.
3. Remplacez-le par une seule redirection 301 vers la page finale fonctionnelle.
4. Mettez à jour vos liens internes pour viser directement cette page.
5. Dans Search Console, cliquez sur Validate Fix pour demander un nouveau contrôle.

Pour les quatre causes exactes de Google, la trace en ligne de commande et les limites de sauts documentées, passez à l’onglet Avancé.

TL;DR — « Redirect error » est un statut Page Indexing de Google Search Console : Googlebot a tenté de suivre une redirection sans réussir à la résoudre, donc la page n’est pas indexée. Google nomme quatre causes : chaîne trop longue, boucle, URL dépassant la longueur maximale, ou URL incorrecte/vide dans la chaîne. Ce statut décrit une redirection cassée, contrairement à « Page with redirect », qui correspond à une redirection fonctionnelle et non canonique. Tracez la chaîne avec curl -IL, l’inspection d’URL, Lighthouse ou un crawler, puis réduisez-la à un saut direct adapté à l’intention, mettez à jour les liens internes et lancez Validate Fix. La documentation Google actuelle publie une limite de 10 sauts et recommande au plus 3, en tout cas moins de 5. Les déclarations datées de Mueller en 2014 et 2020 évoquent environ cinq sauts par crawl ; les observations similaires de Patrick sont indépendantes. Visez toujours un seul saut.

Emplacement de ce statut

« Redirect error » apparaît sous Page Indexing → « Why pages aren’t indexed ». Il s’agit d’un échec de crawl ou de suivi, pas d’un jugement de qualité ni d’une pénalité : Google n’a simplement pas pu atteindre une destination à indexer.

Les quatre causes exactes de Google

Il s’agit des causes documentées dans Search Console, pas d’une taxonomie universelle de tous les bugs de redirection. Evidence for this claim Google reports Redirect error when it could not process a redirect to a destination. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google recommande par ailleurs des chemins courts et directs. Evidence for this claim Google lists overly long chains, loops, excessive redirect URL length, and bad or empty redirect URLs for this report status. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

La documentation Page Indexing énumère précisément : une chaîne trop longue, une boucle, une URL de redirection qui dépasse finalement la longueur maximale, ou une URL incorrecte ou vide dans la chaîne. Les corrections se rattachent toutes à l’un de ces quatre modes d’échec.

« Redirect error » ou « Page with redirect » : la distinction essentielle

Ces deux statuts Page Indexing sont différents :

• Redirect error — Google n’a pas pu suivre la redirection. La page ne peut pas être indexée : elle est cassée et doit être corrigée.
• Page with redirect — Google a pu suivre la redirection. L’URL est non canonique et redirige ailleurs ; elle ne sera pas indexée, mais la cible peut l’être selon l’évaluation de Google. Ce n’est généralement pas une erreur.

Si d’anciennes URL volontairement redirigées en 301 apparaissent sous « Page with redirect », le système fonctionne comme prévu. Réservez vos efforts à « Redirect error ». Un tableau comparatif figure dans l’onglet Cheat Sheets.

Les quatre causes et leur correction

1. Chaîne de redirections trop longue. A → B → C → D → … au lieu de A vers la destination finale. Chaque saut ajoute latence et risque de panne. Correction : faites pointer l’URL d’origine directement vers la cible finale en une seule 301 et supprimez ou mettez à jour les règles intermédiaires.

2. Boucle de redirections. A → B → A, ou cycle plus long. Le navigateur affiche ERR_TOO_MANY_REDIRECTS. Les causes typiques sont des règles HTTP↔HTTPS, www↔sans-www ou slash↔sans-slash qui se contredisent. Correction : choisissez une forme canonique dans chaque dimension et faites pointer toutes les règles dans un seul sens.

3. URL de redirection dépassant la longueur maximale. Une règle qui ajoute sans cesse des paramètres ou réinjecte sa propre sortie fait grossir la cible, parfois en parallèle d’une boucle. Correction : trouvez la règle, supprimez les paramètres inutiles et redirigez vers une URL finale propre et fixe.

4. URL incorrecte ou vide dans la chaîne. Une valeur Location relative est valide en HTTP et n’est pas un problème en soi. Le saut casse si Location est vide, ne se résout vers aucune URL réelle ou contient une valeur inutilisable. Correction : tracez la valeur exacte puis faites émettre une cible valide et résoluble ; une URL absolue est plus sûre, mais le défaut tient à l’impossibilité de résoudre la valeur Location, non à sa forme.

Combien de redirections Google suit-il réellement ?

Les nombres sont souvent répétés sans contexte. La documentation actuelle de l’infrastructure de crawl indique : “By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits.” (traduction) « Par défaut, les robots Google suivent jusqu’à 10 sauts, mais les robots de certains produits peuvent avoir des limites différentes. » Elle précise que Googlebot suit généralement 10 sauts pour le web, tandis que Google Inspection Tools n’en suit aucun.

La documentation actuelle sur les migrations recommande d’éviter les chaînes ou, si elles sont inévitables, de les limiter à 3 au maximum et moins de 5. Dix est la limite technique publiée ; 3 à 5 est la recommandation d’implémentation.

Le nombre de cinq sauts vient d’éléments datés. Lors d’un hangout de 2014 à 46:03, John Mueller décrivait Googlebot suivant jusqu’à cinq redirections pendant un crawl et reprenant le reste lors du crawl suivant. En 2020, il a indiqué environ 5 sauts par tentative de crawl et conseillé moins de 5 pour les URL souvent explorées. Ces déclarations sont un contexte historique représentatif, pas une garantie actuelle de reprise ni de calendrier.

Après des années de corrections, mon seuil pratique se situe aussi autour de 5 sauts, et j’ai observé indépendamment Google reprendre des chaînes plus longues. Ce sont des observations de terrain, pas une limite de plateforme ni la source de la déclaration de Mueller.

Le conseil pratique ne change pas : redirigez directement vers la destination finale en un saut. Vous évitez toute question de limite et accélérez aussi le parcours des internautes.

Diagnostiquer une erreur de redirection

Vous devez voir la redirection sur laquelle Google bloque :

• Inspection d’URL — GSC. Le test en direct suit la redirection et teste la cible, mais n’affiche ni le chemin ni le nom de la destination finale. Un autre outil, « Google Inspection Tools », ne suit explicitement aucune redirection. Utilisez l’inspection pour le verdict global, pas pour la trace.
• curl -IL ou un vérificateur de redirection affiche chaque saut et code d’état. Les commandes figurent dans l’onglet Scripts.
• Lighthouse est cité par Google comme outil de débogage web.
• Un crawler — Ahrefs Site Audit, Screaming Frog ou Sitebulb — détecte chaînes et boucles à l’échelle du site.
• Le navigateur affiche immédiatement ERR_TOO_MANY_REDIRECTS pour une boucle.

Correction étape par étape

1. Reproduisez la redirection avec curl, un vérificateur ou le navigateur et repérez le saut cassé : boucle, cible trop longue, mauvaise URL ou chaîne.
2. Remplacez la chaîne ou la boucle par un saut direct vers la cible finale, en choisissant selon l’intention. Déplacement permanent → 301 ou 308 ; déplacement temporaire → 302/303/307. Si l’ancienne URL doit rester, rendez un vrai 200 ; si le contenu a disparu sans remplacement, 404/410 peut être préférable à une redirection forcée.
3. Mettez à jour les liens internes pour viser la destination finale.
4. Retestez avec curl ou l’inspection afin de confirmer un saut propre ou un accès direct en 200.
5. Lancez Validate Fix. Cette action met un nouveau contrôle en file ; elle ne réindexe pas immédiatement et dépend du prochain crawl de Google.

Là où ces erreurs se concentrent : les migrations

La plupart naissent lors de migrations : HTTP→HTTPS, consolidation www/sans-www, changement de domaine ou de CMS et modification du slash final. Les couches de règles s’empilent et forment chaînes ou boucles. Tenez une table de redirections et faites pointer chaque ancienne URL directement vers sa nouvelle URL finale, jamais vers une cible intermédiaire qui redirige encore.

À propos des 301 et 302

L’erreur ne dépend pas du type de redirection, mais de l’impossibilité de la suivre. Les redirections 3xx ne perdent pas de PageRank et Google peut traiter une 302 durable comme une 301. Pour un déplacement permanent, préférez néanmoins une 301 afin d’envoyer le signal canonique le plus clair. Choisissez le type adapté et gardez un seul saut.

Statuts et concepts connexes

« Page with redirect » est le statut normal et fonctionnel décrit plus haut. Une chaîne de redirections est la cause sous-jacente la plus courante, et tous ces statuts se trouvent dans le rapport Page Indexing. Pour le contexte global, consultez le hub consacré à l’indexation.

Résumé IA

Version condensée de l’onglet Avancé :

• « Redirect error » signifie que Google n’a pas pu suivre une redirection et n’a donc pas indexé la page. C’est un échec de crawl, pas une pénalité.
• Quatre causes définies par Google : chaîne trop longue, boucle, URL dépassant la longueur maximale, ou URL incorrecte/vide.
• À distinguer de « Page with redirect ». La première est cassée ; la seconde est une redirection fonctionnelle et non canonique, généralement normale.
• Corrections : chaîne → un saut direct adapté à l’intention ; boucle → régler les conflits HTTP/HTTPS, www et slash ; URL trop longue → arrêter l’ajout de paramètres ; mauvaise URL → tracer la valeur réelle et émettre une cible résoluble.
• Nombre de sauts : la documentation Google actuelle publie jusqu’à 10 pour Googlebot et aucun pour Google Inspection Tools, tout en recommandant au plus 3 et moins de 5. Les déclarations de Mueller en 2014/2020 évoquent environ 5 sauts par crawl ; le seuil similaire de Patrick est indépendant. Visez un saut.
• Diagnostic : inspection d’URL, curl -IL, Lighthouse et crawler à grande échelle.
• Processus : reproduire → trouver le saut cassé → créer un saut direct ou la réponse non-redirection adaptée → mettre à jour les liens → retester → Validate Fix, qui attend ensuite le recrawl de Google.
• Les migrations concentrent les erreurs. Chaque ancienne URL doit viser directement sa cible finale, jamais une destination intermédiaire.

Documentation officielle

Documentation de première main des moteurs de recherche.

Google

• Rapport Page Indexing — définition de « Redirect error », quatre causes, statut distinct « Page with redirect » et recommandation de Lighthouse.
• Redirections et Google Search — types, préférence pour les redirections serveur et signaux canoniques permanents ou temporaires.
• Effet des codes HTTP sur les robots Google — plafond actuel, jusqu’à 10 pour Googlebot, et absence de suivi par Google Inspection Tools.
• Crawl et indexation — hub des redirections, canoniques et contrôles de crawl.
• Outil d’inspection d’URL — le test en direct suit la redirection sans exposer son chemin.

Bing / Microsoft

• Consignes Bing Webmaster — usage des 301 pour les déplacements permanents et évitement des chaînes.
• Gestion des 301s, 302s et canoniques — 2011 — ancien article encore cité recommandant de viser directement la destination finale.

Citations des sources

Déclarations publiques de Google. Chaque lien mène directement au passage cité.

Google — les quatre causes d’une « Redirect error »

• “Google experienced one of the following redirect errors: A redirect chain that was too long; A redirect loop; A redirect URL that eventually exceeded the max URL length; A bad or empty URL in the redirect chain.” (traduction) « Google a rencontré l’une des erreurs suivantes : chaîne trop longue, boucle, URL dépassant finalement la longueur maximale, ou URL incorrecte/vide dans la chaîne. » — Google, aide du rapport Page Indexing. Accéder à la citation

Google — « Page with redirect », le statut sans erreur servant de comparaison

• “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL. A canonical URL with a redirect can be indexed.” (traduction) « Il s’agit d’une URL non canonique redirigeant vers une autre page ; elle ne sera donc pas indexée. La cible peut l’être ou non selon l’évaluation de Google. Une URL canonique avec redirection peut être indexée. » — Google, aide du rapport Page Indexing. Accéder à la citation

John Mueller, Google — nombre de sauts suivis

• Lors d’un hangout de 2014, Mueller a décrit Googlebot suivant jusqu’à cinq redirections pendant un crawl, puis reprenant le reste au crawl suivant. Voir à partir de 46:03
• “Search engines just follow the redirect chain (for Google: up to 5 hops in the chain per crawl attempt).” (traduction) « Les moteurs suivent la chaîne ; pour Google, jusqu’à cinq sauts par tentative de crawl. » Phrase relayée par Search Engine Journal en 2020. Accéder à la citation
• “The only thing I’d watch out for is that you have less than 5 hops for URLs that are frequently crawled.” (traduction) « Je veillerais seulement à rester sous cinq sauts pour les URL fréquemment explorées. » Phrase relayée par Search Engine Journal en 2020. Accéder à la citation

Google — plafond actuel par défaut dans la documentation de l’infrastructure de crawl

• “By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits.” (traduction) « Par défaut, les robots Google suivent jusqu’à dix sauts, mais certains produits peuvent avoir d’autres limites. » — Google, documentation mise à jour le 4 février 2026 et vérifiée le 18 juillet 2026.
• “Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn’t follow redirects.” (traduction) « Googlebot suit généralement dix sauts pour le web, tandis que Google Inspection Tools ne suit aucune redirection. » — même source, vérifiée le 18 juillet 2026. Source

Google — recommandation pratique actuelle pour une migration

• “ideally no more than 3 and fewer than 5.” (traduction) « idéalement pas plus de trois et moins de cinq ». Source

Checklist de correction d’une erreur de redirection

Suivez ces contrôles pour chaque URL ou template signalé « Redirect error » :

• Confirmer qu’il s’agit de « Redirect error » et non de « Page with redirect », généralement normal.
• Reproduire avec curl -IL ou un vérificateur et lire chaque saut et code.
• Identifier l’une des quatre causes : chaîne trop longue, boucle, URL trop longue ou URL incorrecte/vide.
• Pour une boucle, régler les conflits HTTP↔HTTPS, www↔sans-www et slash.
• Pour une chaîne, la réduire à une seule 301 vers l’URL finale.
• Pour une URL trop longue, arrêter l’ajout de paramètres et viser une cible propre.
• Pour une URL incorrecte/vide, tracer d’abord Location puis produire une cible résoluble ; le seul caractère relatif n’est pas un défaut.
• Confirmer que la destination finale renvoie 200, pas une autre redirection ni une 4XX/5XX.
• Mettre à jour les liens internes vers l’URL finale.
• Retester : une redirection propre ou un accès direct en 200.
• Cliquer sur Validate Fix, en sachant qu’il met un contrôle en file.

Aide-mémoire sur les erreurs de redirection

Comparer « Redirect error » au statut « Page with redirect »

Les quatre causes Google → diagnostic → correction

Nombre de sauts : ce qui est réellement établi

Tracer une chaîne de redirections et trouver le saut cassé

Le moyen le plus rapide de comprendre l’échec est de suivre la chaîne et de lire chaque saut et code d’état.

macOS / Linux

# -I = headers only, -L = follow redirects: prints each hop's status + Location
curl -sIL https://www.example.com/old-page/ | grep -i -E '^(HTTP/|location:)'
# Example of a healthy single hop:
#   HTTP/2 301
#   location: https://www.example.com/new-page/
#   HTTP/2 200
#
# A chain shows multiple 3xx lines before the 200.
# A loop never reaches 200 — you'll see the same URLs repeat (curl stops at its
# --max-redirs limit, default 50).

Pour obtenir une ligne par URL et code :

curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old-page/
# Add --max-redirs 10 to cap how far curl will follow (useful for catching loops):
curl -sIL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old-page/

Windows — PowerShell

# Follows redirects and reports the final status; -MaximumRedirection caps the chain
Invoke-WebRequest -Uri "https://www.example.com/old-page/" -MaximumRedirection 10 |
  Select-Object StatusCode, @{n='FinalUrl';e={$_.BaseResponse.ResponseUri}}

# To see each hop, disable auto-follow and inspect the Location header one step at a time:
Invoke-WebRequest -Uri "https://www.example.com/old-page/" -MaximumRedirection 0 -ErrorAction SilentlyContinue |
  Select-Object StatusCode, @{n='Location';e={$_.Headers.Location}}

Lecture de la sortie

• Un 3xx puis un 200 = un saut propre. Bon.
• Plusieurs 3xx avant le 200 = une chaîne à réduire à une 301.
• Les mêmes URL répétées sans 200 = une boucle.
• Un 3xx vers une 4XX/5XX ou un Location vide/inutilisable = une URL incorrecte ou vide à corriger.

Une fois obtenu un trajet direct 301 → 200, retestez puis lancez Validate Fix dans Search Console.

Réserve : -I envoie une requête HEAD, pas GET. La plupart des serveurs et CDN redirigent de la même manière, mais certaines configurations ou middlewares varient selon la méthode. En cas d’écart, relancez sans -I avec curl -sL afin de confirmer le comportement de GET avant de conclure.

J’ai une « Redirect error » : que dois-je corriger ?

Les quatre causes aboutissent au même symptôme, mais leurs corrections diffèrent. Tracez d’abord la chaîne avec curl ou le Redirect Checker, puis suivez l’arbre.

Quelle que soit la branche, l’état final est identique : une 301 directe vers une URL renvoyant 200. Retestez avec le Redirect Checker ou curl -IL avant de cliquer sur Validate Fix.

Erreurs courantes qui provoquent « Redirect error »

• Faire passer l’ancienne adresse par une adresse provisoire au lieu de viser la nouvelle directement. C’est le cas le plus fréquent. Pendant une refonte, viser une adresse qui renvoie déjà ailleurs crée immédiatement une chaîne. Cette règle vaut pour le passage au HTTPS comme pour un changement de sous-domaine, de domaine ou de système de gestion de contenu. À faire : pointez toujours l’adresse d’origine directement vers la destination finale.
• Empiler des règles de canonisation sans vérifier leur ordre. HTTP→HTTPS, www→sans-www et slash final peuvent rediriger séparément ; si deux règles se contredisent, elles forment une boucle. À faire : choisissez une forme canonique pour chaque dimension et vérifiez que toutes les règles vont dans le même sens.
• « Corriger » une redirection en en ajoutant une autre devant. Cette rustine allonge généralement la chaîne au lieu de la raccourcir. À faire : remplacez toute la chaîne par une seule 301 directe, sans ajouter de saut.
• Confondre « Redirect error » et « Page with redirect », puis modifier une redirection fonctionnelle. Ce dernier statut signifie que Google a suivi avec succès une URL non canonique vers sa cible. À faire : intervenez seulement sur les URL signalées « Redirect error ».
• Rediriger vers une URL qui renvoie elle-même 404s, 5xxs ou porte noindex. Même un saut propre ne sert à rien si la cible ne renvoie pas 200 ou n’est pas indexable. À faire : vérifiez que la cible finale renvoie un vrai 200 et est indexable avant de créer la redirection.
• Laisser les paramètres de suivi ou de requête s’ajouter à chaque saut. Une règle qui réinjecte sa propre sortie peut faire dépasser la longueur maximale à l’URL. À faire : retirez les paramètres inutiles et visez une URL propre et fixe.
• Cliquer sur Validate Fix en pensant que l’effet est immédiat. Cette action met un nouveau contrôle en file ; elle ne réindexe pas aussitôt. À faire : retestez d’abord vous-même avec curl ou le Redirect Checker avant d’attendre le recrawl.

Prouver que la redirection est réellement corrigée

Exécutez ces tests après avoir réduit une chaîne, cassé une boucle ou corrigé une URL incorrecte ou vide, avant de compter sur la confirmation de Search Console.

Test 1 : un seul saut 301 vers un statut 200

• Test à exécuter — Collez l’ancienne URL dans le Redirect Checker ou lancez curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' <url>.
• Résultat attendu — Exactement un saut 301 (ou 308), vers une URL finale qui renvoie 200.
• Interprétation d’un échec — Plusieurs lignes 3xx avant le 200 montrent que la chaîne subsiste ; la réapparition d’une même URL signifie que la boucle n’est pas corrigée.
• Fenêtre de surveillance — Immédiate : les codes d’état n’ont pas besoin de se stabiliser.
• Déclencheur de retour arrière — Un saut supplémentaire apparaît ou le statut final est 4XX/5XX au lieu de 200.

Test 2 : aucune boucle ni croissance incontrôlée de l’URL

• Test à exécuter — Utilisez le Redirect Chain Mapper sur l’URL concernée ou lancez curl -sIL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' <url> ; une faible valeur de --max-redirs provoquera une erreur si la boucle persiste.
• Résultat attendu — Le schéma montre un seul saut direct, sans URL répétée, et la cible ne s’est pas allongée par ajout de paramètres.
• Interprétation d’un échec — Des URL répétées indiquent qu’une règle de canonisation conflictuelle subsiste ; une cible trop longue indique qu’une règle ajoute encore des paramètres.
• Fenêtre de surveillance — Immédiate.
• Déclencheur de retour arrière — La boucle réapparaît ou la longueur de l’URL augmente lors d’un nouveau contrôle quelques jours plus tard.

Test 3 : vérification en lot après une migration

• Test à exécuter — Soumettez toute la liste des anciennes URL au SEO Migration Planner & Validator ou au Redirect Checker en lot.
• Résultat attendu — Chaque ancienne URL associée atteint en un saut la nouvelle URL prévue, avec un statut 200.
• Interprétation d’un échec — Une URL qui présente encore plusieurs sauts, une boucle ou une cible autre que 200 signale que cette ligne du plan n’a pas été appliquée ou vise la mauvaise destination.
• Fenêtre de surveillance — Immédiate pour le contrôle des sauts.
• Déclencheur de retour arrière — Plus d’une poignée d’URL échouent au contrôle en lot : le plan de redirection lui-même, et non une seule règle, comporte probablement une erreur systémique.

Test 4 : réindexation dans Search Console

• Test à exécuter — Cliquez sur Validate Fix pour les URL concernées dans le rapport Page Indexing, puis surveillez leur statut.
• Résultat attendu — L’URL quitte « Redirect error », idéalement pour « Page with redirect » s’il s’agit d’une ancienne URL non canonique, ou l’URL finale apparaît comme indexée.
• Interprétation d’un échec — Si « Redirect error » demeure après la validation, la redirection en production ne se résout pas comme lors de votre test, ou Google ne l’a pas encore réexplorée.
• Fenêtre de surveillance — Validate Fix met un contrôle en file, sans réindexation instantanée. Le délai dépend entièrement du calendrier de recrawl de Google pour cette URL, qui n’est pas publié : n’attendez pas un délai fixe.
• Déclencheur de retour arrière — La validation échoue ou le statut réapparaît lors d’un crawl ultérieur après avoir d’abord disparu.

Outils pour tracer et corriger les erreurs de redirection

• Redirect Checker — collez une URL pour voir chaque saut, son code d’état et la destination finale. C’est le moyen le plus rapide de confirmer qu’une URL signalée suit désormais un trajet propre 301 → 200.
• Redirect Chain Mapper — représente le trajet saut par saut, afin qu’une chaîne ou une boucle soit visible immédiatement sans lire les en-têtes bruts ligne par ligne.
• Bulk HTTP Status Code Checker — contrôle plusieurs URL à la fois pour repérer les erreurs dans tout un site ou un plan de redirection.
• SEO Migration Planner & Validator — conçu pour les migrations, là où naissent la plupart de ces erreurs. Associez chaque ancienne URL directement à sa nouvelle cible finale et validez le plan avant et après la mise en ligne.
• Google Search Console — Inspection d’URL. Le test en direct suit la redirection et teste l’URL finale, sans afficher le trajet saut par saut ni nommer la cible. Associez-le à curl -IL ou à un vérificateur pour localiser la rupture.
• curl -IL en ligne de commande permet de tracer manuellement les sauts. Les commandes se trouvent dans l’onglet Scripts.
• Ahrefs Site Audit / Screaming Frog / Sitebulb. Ces crawlers font ressortir toutes les chaînes et boucles d’un site, y compris celles qui n’ont jamais donné lieu à un ticket d’assistance.

Prompts pour analyser une erreur de redirection

Fournissez à ces prompts de vraies traces de redirection. Un modèle de langage ne peut pas vérifier un trajet à partir de la seule URL.

Diagnostiquer une trace cassée

Analysez cette trace de redirection saut par saut. Repérez la première boucle, valeur Location incorrecte ou vide, chaîne excessive ou destination sans succès. Recommandez une seule redirection directe entre l’URL de départ et l’URL finale prévue qui renvoie 200. Trace : [coller les statuts et les valeurs Location].

Examiner un plan de redirection avant son déploiement

Examinez ce plan de redirection des anciennes URL vers les nouvelles. Signalez les auto-redirections, boucles, sauts multiples, destinations conflictuelles, cibles mal formées et pages non pertinentes. Renvoyez les associations corrigées et une checklist de validation. Plan : [coller les lignes].

Transformer les résultats d’un crawl en groupes de correction

Regroupez ces erreurs de redirection selon leur motif source commun et la règle ou le template probablement responsable. Pour chaque groupe, indiquez les preuves, la modification de configuration minimale, le nombre d’URL touchées et un test après déploiement. N’inventez pas de cible lorsque la destination prévue ne figure pas dans les données. Lignes : [coller l’export du crawl].

Testez vos connaissances : Redirect error

Cinq questions sur la signification de « Redirect error » et sa correction. Choisissez une réponse à chaque question, puis vérifiez.

Journal des modifications