Tu viens de pousser une vague de redirections (migration, rebrand, refonte, normalisation trailing slash…) et Google Search Console se met à te spammer “Redirect error”. Dans la foulée, des pages qui rankaient disparaissent, et tu vois débarquer du “Crawled – currently not indexed”. Là, beaucoup de gens font la même erreur : ils bricolent des règles de redirect à chaud, ça “réduit” l’erreur… et ils créent une deuxième panne plus profonde.
Ce que je te propose ici, c’est un triage en 4 passes, très terrain : d’abord on classe ce que Google rencontre vraiment (chaînes, boucles, 301/302, paramètres, http/https). Ensuite on ré-aligne le contrat canonical + sitemap + maillage interne. Puis on arrête de deviner et on regarde les logs Googlebot. Et seulement après, on déroule un plan de correction par priorité, sans “tout toucher”.
“Redirect error” dans GSC : ce que ça veut dire (et ce que ça ne veut pas dire)
Le libellé “Redirect error” est frustrant parce qu’il ne te dit pas grand-chose. Ce n’est pas “une page qui redirige”, c’est “Google n’arrive pas à suivre correctement la redirection jusqu’à un état stable”. Ça peut être une boucle, une chaîne trop longue, une redirection vers une URL qui re-redirige dans un sens inattendu, un mélange http/https ou www/non-www qui fait ping-pong, un target qui répond parfois 200, parfois 403, parfois 5xx. Et parfois c’est juste une règle qui marche dans ton navigateur mais pas pour Googlebot (UA différent, géoloc, WAF, rate limiting).
Important : un pic de “Redirect errors” n’implique pas forcément que ton site est “pénalisé”. Dans la majorité des cas que je vois, c’est plus bête et plus violent : Google gaspille son crawl budget à tourner en rond ou à retomber sur des URL non canonicals, et il finit par réduire la confiance dans l’état “indexable” de tout un segment. Le symptôme “désindexation” vient souvent après, pas avant.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Passe 1 : classifier tes redirections (pour arrêter de corriger au hasard)
La première chose à faire, c’est de prendre un échantillon d’URLs qui remontent en “Redirect error” (pas 1, pas 2000 : une trentaine bien choisie, incluant des pages importantes et des pages random) et de vérifier le chemin exact côté HTTP. Tu veux savoir : combien de hops, quels codes, et où ça finit. Si tu te contentes de “ça redirige vers la bonne page dans Chrome”, tu es aveugle.
# Suivre les redirections et voir chaque hop
curl -sIL https://exemple.com/ancienne-url | sed -n '1,20p'
# Variante plus verbeuse si tu suspectes un comportement différent selon UA
curl -sIL -A "Googlebot" https://exemple.com/ancienne-url | sed -n '1,40p'Ce que tu cherches en priorité, c’est la chaîne et la boucle. Une chaîne classique : http → https, puis non-www → www, puis ajout d’un slash, puis suppression d’un paramètre, puis redirection “marketing” vers une nouvelle structure. Sur le papier c’est logique. Pour Google, c’est du bruit, et si une étape est instable, tout s’écroule. Une boucle typique : une règle de normalisation qui s’auto-contradit selon le trailing slash, ou selon un paramètre (ex : tu rediriges ?utm vers une URL sans paramètre, mais ton app réinjecte ?utm via un script ou via une règle CDN).
Ensuite, regarde la nature des codes. Une migration “propre” est majoritairement en 301. Les 302 ne sont pas “interdits”, mais en masse ils peuvent ralentir la consolidation des signaux, surtout si tu mixes 302 temporaires et 301 permanentes sur les mêmes patterns. Et attention aux 307/308 : ils ne sont pas mauvais, mais ils apparaissent souvent quand quelqu’un a empilé des couches (app, reverse proxy, CDN) sans vérifier le résultat final.
Enfin, la catégorie qui tue en silence : la cohérence hôte + protocole. Si tu as encore des liens internes en http, des canonicals en https, et des redirections conditionnées par un header (X-Forwarded-Proto mal géré, par exemple), tu peux obtenir des chemins différents selon que la requête passe par le CDN, par ton load balancer ou directement par le backend. GSC te le remontera sous forme de “Redirect error” sans te faire un dessin.
Passe 2 : recoller le contrat canonical + sitemap + maillage interne (sinon Google n’a aucune chance)
Une fois que tu as compris la mécanique des redirections, tu dois vérifier la cohérence des signaux “déclaratifs”. Parce que même si tes redirects sont techniquement corrects, tu peux quand même envoyer à Google un message contradictoire : “voici l’URL que je veux indexer” (canonical), “voici les URLs importantes” (sitemap), “voici ce que je link partout” (maillage interne), “voici où je redirige” (301). Si ces quatre-là ne racontent pas la même histoire, Google finit par arbitrer tout seul. Et c’est rarement en ta faveur quand tu es déjà en situation instable.
Le point le plus fréquent que je corrige : des pages qui redirigent, mais qui ont encore des canonicals pointant sur l’ancienne URL (ou pire, sur une URL qui redirige). Un canonical devrait viser une URL finale qui répond 200, stable, indexable. Si ton canonical vise une URL qui fait 301, tu demandes à Google de faire un détour permanent. Ça marche parfois. En période de turbulence, ça amplifie les erreurs.
Le sitemap, même combat. Un sitemap n’est pas “une liste de tout ce qui existe”, c’est une liste de ce que tu veux faire crawler et potentiellement indexer. Si ton sitemap contient des URLs qui redirigent, tu forces Google à crawler des détours. Si ton sitemap contient des versions non préférées (http, non-www, avec slash quand tu préfères sans, ou avec des paramètres), tu recrées une duplication au moment où tu as justement besoin de clarté. Dans un triage, je préfère un sitemap un peu plus petit mais propre, que “complet” et contradictoire.
Le maillage interne est souvent le vrai coupable. Après une migration partielle (services migrés, blog plus tard, ou cohabitation de deux domaines pendant des semaines), tu te retrouves avec des liens internes qui pointent encore vers des URLs qui redirigent, ou vers l’ancien domaine. Résultat : Googlebot passe son temps sur des 301 au lieu d’entrer directement dans tes hubs. Et quand tu cumules ça avec un gros volume, tu as le cocktail parfait pour voir des pages basculer en “crawled currently not indexed” simplement parce que Google n’arrive pas à stabiliser “la version canonique”.
Passe 3 : les logs Googlebot (parce que GSC seule te fait tourner en rond)
GSC te donne des indices. Les logs te donnent la réalité. Quand tu as un pic de “Redirect errors”, la question n’est pas “est-ce que j’ai une belle règle de redirect”, c’est “qu’est-ce que Googlebot a réellement reçu, à quelle fréquence, et est-ce que ça tient dans le temps”.
Si tu as accès aux logs du CDN/reverse proxy (Cloudflare, Fastly, Nginx, ALB…), filtre sur Googlebot (idéalement en validant les reverse DNS si tu veux être carré, mais en triage tu peux déjà commencer avec l’UA). Tu veux repérer les patterns : des séries de 301 en rafale, des alternances 301/302, des 403/429 (WAF, rate limit), des 5xx sur le target final, et des URLs qui tournent en boucle.
# Exemple très simple sur un access.log Nginx (à adapter au format)
# Objectif : voir les hits Googlebot et les codes HTTP associés
zgrep -h "Googlebot" /var/log/nginx/access.log* \
| awk '{print $9" "$7}' \
| sort \
| uniq -c \
| sort -nr \
| head -n 40Ce genre de sortie te donne vite une “top liste” des URLs problématiques côté Googlebot, et surtout les codes dominants. Si tu vois des 429 ou des 403 sur des URLs qui devraient juste faire 301 puis 200, tu tiens une piste très concrète : ce n’est pas un souci de SEO “abstrait”, c’est un blocage ou une instabilité d’infra. Et oui, ça peut provoquer des désindexations indirectes, parce que Google arrête de faire confiance au segment.
Autre chose que j’aime vérifier : est-ce que Googlebot recrawl en boucle les anciennes URLs (celles du sitemap historique, ou des backlinks), ou est-ce qu’il arrive déjà bien sur les nouvelles. Si ton crawl reste coincé “avant” les redirections, c’est souvent que ton maillage interne et ton sitemap ne poussent pas assez fort les URLs finales. Tu as mis des 301, mais tu n’as pas donné à Google une carte simple du nouveau monde.
Passe 4 : plan de correction par priorité (money pages d’abord, pas l’ego)
Quand tu as des “Redirect errors” à grande échelle, tu as envie de “nettoyer tout le site”. Mauvaise idée. Tu corriges d’abord ce qui protège ton business et ce qui structure le crawl.
Je commence par les pages qui comptent vraiment : pages service, pages catégorie, pages produit, landing pages qui convertissent. Celles-là doivent avoir un chemin simple et stable : une URL finale en 200, un canonical qui pointe dessus, des liens internes qui y vont directement, et aucune dépendance à un paramètre ou à une règle de rewrite exotique. Si tu as besoin de faire un arbitrage, préfère une redirection claire et moche à une redirection “élégante” qui dépend de trois couches et d’un header.
Ensuite viennent les hubs et la navigation. Souvent, ce qui fait mal n’est pas une vieille URL du blog, c’est un menu, un footer, des breadcrumbs qui pointent vers des URLs qui redirigent encore. Chaque lien interne vers une URL non finale est un multiplicateur de crawl inutile. Corriger le maillage interne est parfois plus rentable que de micro-optimiser tes règles de redirect.
Pour le blog, je suis pragmatique : si tu as 10 000 articles, tu ne vas pas “rendre parfait” chaque redirection en 24 heures. Tu t’assures que les patterns sont bons (structure, slash, http/https, domaine) et tu t’occupes en priorité des contenus qui prennent du trafic, qui ont des backlinks, ou qui servent d’entrée vers des pages business. Le reste peut attendre, tant que les règles globales ne créent pas de boucles.
Et surtout : ne fais pas de migration “en deux sites” qui dure. Si tu la fais, fais-la vite et propre. La cohabitation prolongée, avec des pages services sur un nouveau domaine et un blog sur l’ancien, c’est un excellent moyen de brouiller les signaux, de créer des canonicals croisés, et de te retrouver avec des clusters d’URLs où Google ne sait plus quoi indexer.
Les erreurs qui provoquent le plus souvent un carnage (même quand “ça marchait hier”)
La première, c’est la redirection qui dépend d’un environnement. Typiquement : en interne tout est en https, mais le backend croit recevoir du http parce que X-Forwarded-Proto est mal transmis, donc il redirige encore et encore. Sur certains chemins ça passe, sur d’autres ça boucle. Et GSC te sort ça en “redirect error” sans aucune pitié.
La deuxième, c’est le mélange des normalisations. Tu veux gérer www/non-www, http/https, trailing slash, et la casse des URLs, et tu fais ça à la fois dans le CDN et dans l’app. Ça te donne deux systèmes qui “corrigent” chacun à leur manière. Résultat : chaîne, ou boucle. Tu choisis un endroit où la vérité est appliquée, et tu fais le reste en mode passif.
La troisième, c’est le sitemap “automatique” qui liste des URLs non canonicals parce que ton CMS ou ton générateur n’a pas été reconfiguré après la migration. Le sitemap devient alors une usine à crawl inutile. Et comme Google lui fait confiance pour découvrir, tu amplifies ton propre problème.
La quatrième, c’est le canonical mis “par habitude” sur toutes les pages, sans vérifier qu’il pointe sur une URL finale en 200. J’insiste parce que je le vois tout le temps : canonical vers une URL qui redirige, canonical vers une URL qui renvoie 404, canonical vers l’ancien domaine. Sur une petite portion du site, Google peut compenser. Sur une migration, ça devient un accélérateur de désindexation.
“Et si c’était une Spam Update ?” Oui, parfois ça amplifie… mais ça se vérifie
Quand ça arrive en même temps qu’une mise à jour anti-spam, la tentation est forte : “Google m’a tapé”. En mars 2026, Google a effectivement déployé une Spam Update sur une fenêtre courte (moins de 24h d’après les annonces publiques), et tu peux voir des timings qui se chevauchent avec des chantiers de migration. Mais ce n’est pas un diagnostic, c’est un contexte.
Le bon réflexe, c’est de chercher des signaux de spam concrets plutôt que de supposer. Si tu as une action manuelle, un problème de sécurité, ou des messages explicites dans GSC, tu ne seras pas dans le flou total. Si tu n’as rien de tout ça, et que tes logs montrent surtout des boucles, des chaînes, des 429/403 côté Googlebot, ou une instabilité sur les targets finaux, tu as probablement un problème technique qui suffit à expliquer la casse.
Là où une Spam Update peut “amplifier”, c’est quand ton site est déjà fragile. Si tu as des pages faibles, massivement dupliquées, du contenu généré sans contrôle, des pages doorway, ou des signaux de link spam, Google peut être moins tolérant au moment où tu lui demandes en plus de digérer une migration. Mais encore une fois, ce n’est pas une excuse pour ne pas corriger l’infrastructure. Tu dois d’abord retrouver un état stable : URLs finales cohérentes, signaux alignés, crawl propre. Sinon tu n’arriveras même pas à séparer “algo” de “tech”.
Conclusion : vise un état stable, pas une suppression d’alertes dans GSC
Le piège avec “Redirect errors”, c’est de vouloir faire disparaître l’alerte. Ce que tu veux vraiment, c’est un système d’URLs où Google peut crawler sans détour, comprendre l’URL canonique sans hésiter, et consolider les signaux sans se heurter à des règles contradictoires.
Si tu ne devais retenir qu’une idée : ne change pas 15 choses en même temps. Mesure une tranche, corrige une cause racine, vérifie dans les logs, puis seulement tu élargis. C’est comme ça que tu évites la migration “héroïque” qui se transforme en semaine de panique.
