Redirections HTTP : détecter boucles, chaînes et liens suspects

⚡TL;DR

• Les boucles de redirection (ERR_TOO_MANY_REDIRECTS) sont causées par des configurations circulaires entre serveurs, CDN ou CMS.
• Les chaînes de redirection excessives (plus de 3 hops) diluent le SEO et ajoutent 100 à 500 ms de latence par hop.
• Les liens raccourcis (bit.ly, t.co) masquent la destination réelle et peuvent mener vers des sites de phishing.
• Le Redirect Checker de CaptainDNS détecte automatiquement ces trois problèmes en une seule analyse.
• Google suit un maximum de 10 redirections. Au-delà, la page n'est pas indexée.

Vous cliquez sur un lien et votre navigateur affiche ERR_TOO_MANY_REDIRECTS. Ou bien la page finit par charger, mais après un délai suspect de plusieurs secondes. Ou encore, un collègue vous envoie un lien raccourci bit.ly et vous hésitez avant de cliquer. Ces trois situations ont un point commun : elles impliquent des redirections HTTP que personne ne voit, mais qui peuvent cacher des problèmes graves.

Les redirections sont un mécanisme fondamental du web. Elles permettent de déplacer des pages, de forcer le HTTPS, de gérer les vanity URLs. Mais quand elles sont mal configurées, elles créent trois catégories de problèmes distincts. Les boucles empêchent complètement l'accès à la page. Les chaînes excessives dégradent le SEO et la performance sans que le visiteur s'en aperçoive. Les liens raccourcis masquent la destination réelle et servent de vecteur de phishing dans 1 cas sur 10 selon les recherches de Palo Alto Networks sur les domaines récemment enregistrés (NRD).

Ce guide couvre le diagnostic et la correction de ces trois problèmes. Chaque section explique le mécanisme technique, les symptômes observables, et les étapes concrètes pour résoudre la situation. L'objectif est de vous rendre autonome pour identifier et corriger tout problème de redirection, que vous soyez administrateur système, développeur ou responsable SEO.

Qu'est-ce qu'une boucle de redirection ?

Une boucle de redirection se produit quand une URL A redirige vers une URL B, qui redirige à son tour vers l'URL A. Le navigateur suit les redirections en cercle, sans jamais atteindre une page de contenu. Après un certain nombre de tentatives, il abandonne et affiche un message d'erreur.

Le cas le plus simple est le cycle à deux éléments : A redirige vers B, B redirige vers A. Mais les boucles peuvent impliquer trois, quatre ou cinq URLs intermédiaires avant de revenir au point de départ.

Comment le navigateur réagit à une boucle ?

Chaque navigateur impose une limite au nombre de redirections qu'il suit avant d'abandonner. Quand cette limite est atteinte, le navigateur affiche un message d'erreur spécifique.

Navigateur	Limite de redirections	Message d'erreur
Chrome	20	ERR_TOO_MANY_REDIRECTS
Firefox	20	"La page n'est pas redirigée correctement"
Safari	16	"Safari ne peut pas ouvrir la page"
Edge	20	ERR_TOO_MANY_REDIRECTS

Le navigateur ne fait pas de distinction entre une boucle (cycle) et une chaîne très longue (séquence linéaire). Dans les deux cas, si la limite est atteinte, l'affichage est bloqué. La différence est que la chaîne longue finira par aboutir si on augmente la limite, alors que la boucle ne terminera jamais.

Du point de vue de Googlebot, une boucle est fatale pour l'indexation. Google détecte le cycle, marque la page comme inaccessible, et les backlinks qui pointent vers elle perdent toute valeur SEO.

Anatomie d'une boucle : le cycle HTTP en détail

Voici le détail d'une boucle à trois éléments au niveau réseau.

1. GET https://captaindns.com/page-a
   → 301, Location: https://captaindns.com/page-b

2. GET https://captaindns.com/page-b
   → 302, Location: https://captaindns.com/page-c

3. GET https://captaindns.com/page-c
   → 301, Location: https://captaindns.com/page-a

4. GET https://captaindns.com/page-a   (retour au point de départ)
   → 301, Location: https://captaindns.com/page-b

... (le cycle se répète)

Chaque itération consomme une requête réseau. Chrome et Firefox coupent après 20 requêtes, soit 6 à 7 tours complets dans une boucle à 3 éléments. L'en-tête Location est le fil conducteur : c'est en le suivant que les outils de diagnostic reconstruisent la chaîne et détectent le point de retour.

Les 7 causes les plus fréquentes de ERR_TOO_MANY_REDIRECTS

Les boucles de redirection ne sont presque jamais intentionnelles. Elles résultent de conflits entre plusieurs composants qui tentent chacun de forcer une redirection. Voici les 7 causes les plus courantes, classées par fréquence d'apparition.

1. Conflit HTTP/HTTPS entre CMS et serveur

Symptôme : le site affiche ERR_TOO_MANY_REDIRECTS dès la page d'accueil.

Mécanisme : le CMS (WordPress, Joomla) est configuré pour forcer HTTPS dans ses paramètres internes. Simultanément, le fichier .htaccess ou la configuration Nginx contient une règle qui redirige HTTP vers HTTPS. Quand le CMS redirige vers HTTPS et que le serveur redirige cette requête vers HTTP (ou l'inverse à cause d'un proxy intermédiaire), une boucle se crée.

Diagnostic : vérifiez l'URL du site dans les paramètres du CMS (siteurl et home dans WordPress). Comparez avec les règles de redirection du serveur web. Si les deux forcent le protocole dans des directions opposées, vous avez trouvé la source.

Correction : choisissez un seul point de contrôle pour la redirection HTTP vers HTTPS. La meilleure pratique est de gérer cette redirection au niveau du serveur web (Nginx, Apache) ou du reverse proxy, et de configurer le CMS pour utiliser HTTPS dans son URL sans forcer la redirection lui-même.

2. Redirection www/non-www circulaire

Symptôme : ERR_TOO_MANY_REDIRECTS uniquement sur la variante www ou non-www du domaine.

Mécanisme : le DNS pointe www.captaindns.com vers le serveur A, et captaindns.com vers le serveur B. Le serveur A redirige vers la version non-www, le serveur B redirige vers la version www. Le navigateur rebondit indéfiniment entre les deux.

Diagnostic : testez les deux variantes séparément avec curl -I http://www.captaindns.com et curl -I http://captaindns.com. Si chacune redirige vers l'autre, la boucle est confirmée.

Correction : alignez la configuration des deux serveurs sur une seule version canonique. Si vous choisissez captaindns.com comme version canonique, configurez www.captaindns.com pour rediriger en 301 vers captaindns.com, et assurez-vous que captaindns.com ne redirige pas vers www.

3. Plugin de cache ou de sécurité WordPress

Symptôme : ERR_TOO_MANY_REDIRECTS après l'installation ou la mise à jour d'un plugin.

Mécanisme : certains plugins de sécurité (Really Simple SSL, Wordfence) ou de cache (W3 Total Cache, WP Super Cache) ajoutent leurs propres règles de redirection dans le .htaccess ou via des filtres PHP. Ces règles peuvent entrer en conflit avec les redirections existantes du thème, du CMS ou du serveur.

Diagnostic : désactivez les plugins un par un via FTP (renommez le dossier du plugin dans wp-content/plugins/). Quand le site redevient accessible, le dernier plugin désactivé est le coupable.

Correction : réactivez le plugin et ajustez ses paramètres pour éviter le conflit. Si le plugin force HTTPS et que votre serveur le fait déjà, désactivez la fonctionnalité dans le plugin. Si le plugin ajoute des règles .htaccess, vérifiez qu'elles ne dupliquent pas les règles existantes.

4. Cloudflare Flexible SSL combiné avec HTTPS forcé sur le serveur

Symptôme : ERR_TOO_MANY_REDIRECTS après l'activation de Cloudflare.

Mécanisme : le mode "Flexible SSL" de Cloudflare signifie que la connexion entre le visiteur et Cloudflare est en HTTPS, mais la connexion entre Cloudflare et votre serveur est en HTTP. Si votre serveur est configuré pour rediriger HTTP vers HTTPS, il redirige la requête de Cloudflare vers HTTPS. Cloudflare reçoit cette redirection, mais renvoie la requête en HTTP (mode Flexible). Le serveur redirige encore vers HTTPS, et ainsi de suite.

Diagnostic : vérifiez le mode SSL/TLS dans le dashboard Cloudflare. Si c'est "Flexible" et que votre serveur force HTTPS, vous avez trouvé la cause.

Correction : passez le mode SSL/TLS de Cloudflare en "Full" ou "Full (Strict)". Avec le mode Full, Cloudflare communique en HTTPS avec votre serveur, ce qui élimine le conflit. Assurez-vous que votre serveur possède un certificat TLS valide (Let's Encrypt suffit).

5. Cookies corrompus ou boucle d'authentification

Symptôme : ERR_TOO_MANY_REDIRECTS uniquement pour certains utilisateurs, ou uniquement en mode connecté.

Mécanisme : l'application redirige les utilisateurs non connectés vers la page de login. La page de login vérifie un cookie de session, détecte que l'utilisateur n'est pas connecté (cookie corrompu, expiré ou mal formaté), et redirige vers la page de login elle-même. Ou bien, après la connexion, l'application redirige vers une page protégée qui ne reconnaît pas le cookie et renvoie vers le login.

Diagnostic : testez le site en navigation privée (sans cookies). Si le problème disparaît, les cookies sont en cause. Demandez à l'utilisateur affecté de vider ses cookies pour le domaine.

Correction : si le problème est généralisé, vérifiez la configuration des cookies de session (domaine, chemin, attribut Secure, attribut SameSite). Un cookie avec Secure=true ne sera pas envoyé sur une connexion HTTP. Un cookie avec un mauvais domaine (.www.captaindns.com au lieu de .captaindns.com) ne sera pas lu sur la variante sans www.

6. Fichier .htaccess avec règles conflictuelles

Symptôme : ERR_TOO_MANY_REDIRECTS sur un serveur Apache, souvent après une modification manuelle du .htaccess.

Mécanisme : le fichier .htaccess contient plusieurs blocs RewriteRule qui se contredisent. Par exemple, une règle redirige /page vers /page/, et une autre redirige /page/ vers /page. Ou bien, une règle générique (catch-all) capture des URLs qui étaient censées être exclues par une règle précédente, mais l'ordre des règles est incorrect.

Diagnostic : examinez le fichier .htaccess à la racine du site et dans tous les sous-répertoires. Recherchez les blocs RewriteRule qui ciblent des patterns similaires.

Correction : simplifiez le .htaccess. Regroupez toutes les redirections dans un seul bloc, ordonnez de la plus spécifique à la plus générique, et ajoutez le flag [L] (last) aux règles terminales.

Exemple de .htaccess propre qui gère HTTP vers HTTPS et www vers non-www sans conflit :

RewriteEngine On
# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# Force non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

L'ordre est important : d'abord forcer HTTPS, puis gérer le www. Le flag [L] garantit que chaque règle est terminale : une fois déclenchée, Apache ne continue pas avec les règles suivantes.

7. CDN ou reverse proxy mal configuré

Symptôme : ERR_TOO_MANY_REDIRECTS après la mise en place d'un CDN (Cloudflare, Fastly, AWS CloudFront) ou d'un reverse proxy (Nginx, HAProxy).

Mécanisme : le CDN ou le reverse proxy modifie les en-têtes de la requête (protocole, host, chemin) avant de la transmettre au serveur d'origine. Le serveur d'origine prend une décision de redirection basée sur ces en-têtes modifiés, et renvoie une réponse qui déclenche une nouvelle redirection au niveau du CDN. Le cycle se répète.

Le cas classique : le CDN termine la connexion TLS et transmet la requête en HTTP au serveur d'origine. Le serveur voit HTTP et redirige vers HTTPS. Le CDN intercepte cette redirection, mais envoie à nouveau en HTTP.

Diagnostic : testez le site en contournant le CDN (accédez directement à l'IP du serveur). Si le site fonctionne sans CDN mais pas avec, le problème est dans la configuration du proxy.

Correction : configurez le serveur d'origine pour reconnaître les en-têtes de proxy (X-Forwarded-Proto). Sur Nginx, utilisez $http_x_forwarded_proto au lieu de $scheme. Sur Apache, vérifiez %{HTTP:X-Forwarded-Proto} dans les RewriteCond.

Exemple Nginx avec prise en charge du proxy :

server {
    listen 80;
    server_name captaindns.com;

    # Redirige vers HTTPS seulement si la requête n'arrive pas déjà via HTTPS au CDN
    if ($http_x_forwarded_proto != "https") {
        return 301 https://$server_name$request_uri;
    }
}

Comment diagnostiquer une boucle de redirection ?

Une fois que vous savez qu'une boucle existe (le navigateur affiche l'erreur), il faut la localiser précisément. Trois méthodes complémentaires permettent de reconstruire la chaîne de redirections et d'identifier le point de retour.

Méthode 1 : le Redirect Checker de CaptainDNS

La méthode la plus rapide. Entrez l'URL dans le Redirect Checker et lancez l'analyse. L'outil suit chaque redirection, enregistre le code HTTP, l'URL de destination, les en-têtes de réponse et le temps de réponse de chaque hop. Quand il détecte qu'une URL apparaît deux fois dans la chaîne, il signale la boucle et indique exactement à quel hop elle commence.

L'avantage : l'outil suit jusqu'à 30 hops (contre 20 pour les navigateurs), ce qui permet de détecter les boucles longues. Il affiche aussi les en-têtes HTTP complets, essentiels pour diagnostiquer les conflits de protocole et les problèmes de X-Forwarded-Proto.

Méthode 2 : curl en ligne de commande

Pour les administrateurs qui préfèrent le terminal, curl avec l'option -v (verbose) et -L (follow redirects) affiche chaque étape de la chaîne :

curl -v -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -E "^(< HTTP|< Location|> GET)"

Cette commande affiche le code HTTP et l'en-tête Location de chaque réponse, ainsi que la requête GET envoyée à chaque étape. Quand l'URL de la requête GET correspond à une URL déjà vue plus haut dans la sortie, vous avez trouvé la boucle.

L'option --max-redirs 25 augmente la limite par défaut de curl (50) à un niveau suffisant pour détecter la plupart des boucles sans générer une sortie trop longue.

Pour une sortie plus concise, limitez aux en-têtes uniquement :

curl -sI -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -iE "^(HTTP/|Location:)"

Méthode 3 : les DevTools du navigateur

Ouvrez les outils de développement (F12), allez dans l'onglet "Network" (Réseau), puis chargez l'URL problématique. Le navigateur affiche chaque requête HTTP dans l'ordre chronologique. Vous verrez une série de requêtes avec des codes 301 ou 302, chacune avec une URL différente, jusqu'à ce que le navigateur atteigne sa limite et affiche l'erreur.

L'avantage des DevTools : ils montrent les cookies envoyés et reçus à chaque requête, indispensable pour diagnostiquer les boucles d'authentification (cause 5). La limite : le navigateur n'affiche que les 20 premières requêtes (16 sur Safari).

Tableau comparatif des trois méthodes

Critère	Redirect Checker	curl	DevTools
Facilité d'utilisation	Haute (interface web)	Moyenne (terminal)	Moyenne (navigateur)
Nombre max de hops	30	Configurable	16 à 20
Détection automatique de boucle	Oui	Non (analyse manuelle)	Non (analyse manuelle)
Affichage des cookies	Non	Oui (avec -v)	Oui
Affichage des temps de réponse	Oui (par hop)	Oui (avec -w)	Oui
Requiert une installation	Non	Oui (présent sur Linux/macOS)	Non
Partage des résultats	Oui (URL de rapport)	Non	Non (screenshot)

Pour un diagnostic rapide, commencez par le Redirect Checker. Complétez avec les DevTools si le problème implique des cookies, ou avec curl pour l'automatisation en pipeline CI/CD.

Les chaînes de redirection : impact SEO et performance

Une chaîne de redirection est une séquence linéaire de redirections successives. Contrairement à la boucle, la chaîne aboutit à une page de contenu, mais elle passe par une ou plusieurs URLs intermédiaires avant d'y arriver. Le problème n'est pas l'inaccessibilité (la page finit par charger), mais la dégradation progressive du SEO et de la performance.

Combien de hops avant que cela devienne un problème ?

Un seul hop de redirection est parfaitement normal. C'est le cas standard d'un ancien lien qui redirige vers la nouvelle URL. Le problème commence quand les hops s'accumulent.

Nombre de hops	Évaluation	Impact
1	Normal	Aucun impact mesurable
2	Acceptable	Impact minimal, pas d'action requise
3	Avertissement	Latence perceptible, dilution SEO possible
4 à 5	Problème	400 à 2 500 ms de latence ajoutée, perte SEO probable
6 et plus	Critique	Google peut abandonner le suivi, page potentiellement non indexée

Google suit officiellement jusqu'à 10 redirections dans une chaîne. Cependant, John Mueller de l'équipe Google Search a précisé que le transfert de signal SEO peut se dégrader bien avant d'atteindre cette limite. La recommandation pratique est de ne jamais dépasser 2 hops entre l'URL source et la destination finale.

Impact SEO : dilution du PageRank et perte d'indexation

Chaque redirection intermédiaire dans une chaîne crée une opportunité de perte de signal SEO. Bien que Google affirme qu'une redirection 301 unique transfère 100 % du PageRank, le comportement avec des chaînes multiples est moins documenté et moins fiable.

Le problème concret : quand Googlebot rencontre une chaîne de 5 redirections, il effectue 6 requêtes HTTP. Chacune consomme du crawl budget. Pour les sites volumineux avec des milliers de chaînes, Google passe du temps à suivre des redirections au lieu de crawler du contenu nouveau.

De plus, si une redirection intermédiaire est une 302 au lieu d'une 301, le transfert de PageRank est interrompu à ce point. Une seule 302 dans une chaîne de 301 suffit à bloquer le transfert d'autorité.

Impact performance : la latence s'additionne

Chaque hop de redirection ajoute un aller-retour réseau complet entre le navigateur et le serveur. En pratique, cela représente 100 à 500 ms par hop, selon la latence réseau et la localisation géographique du visiteur.

Pour un visiteur en Europe accédant à un serveur en Amérique du Nord, chaque hop ajoute 150 à 200 ms. Une chaîne de 4 hops ajoute 600 à 800 ms avant que le contenu commence à charger.

Cet impact se concentre sur le LCP (Largest Contentful Paint), la métrique Core Web Vitals qui mesure le temps d'affichage du contenu principal. Un LCP supérieur à 2,5 secondes est classé "mauvais" par Google. Si votre page charge normalement en 1,8 secondes mais qu'une chaîne de 3 redirections ajoute 600 ms, vous passez dans la zone rouge.

Bonne nouvelle : les redirections 301 mises en cache par le navigateur n'ont plus d'impact après la première visite. C'est un argument supplémentaire pour préférer les 301 aux 302 dans les chaînes.

Comment les chaînes se forment : le cas de la migration en plusieurs étapes

Les chaînes de redirection sont rarement créées intentionnellement. Elles s'accumulent au fil du temps, à chaque migration, refonte ou changement de structure.

Scénario typique :

1. 2022 : le site est à http://captaindns.com. Passage à HTTPS. Redirection 301 de http:// vers https://.
2. 2023 : refonte du site. Changement de structure d'URL. Redirection 301 de /tools/dns-check vers /fr/tools/dns/test-propagation.
3. 2025 : consolidation du sous-domaine. Redirection 301 de https://outils.captaindns.com/dns-check vers https://captaindns.com/tools/dns-check.

Un backlink publié en 2022 qui pointe vers http://outils.captaindns.com/dns-check traverse désormais 3 redirections :

http://outils.captaindns.com/dns-check
→ 301 → https://outils.captaindns.com/dns-check
→ 301 → https://captaindns.com/tools/dns-check
→ 301 → https://captaindns.com/fr/tools/dns/test-propagation

Chaque migration individuelle était correcte. Mais l'accumulation crée une chaîne de 3 hops qui consomme du crawl budget et ajoute de la latence.

La solution : après chaque migration, mettez à jour les anciennes redirections pour pointer directement vers la destination finale. Dans cet exemple, la première redirection devrait être mise à jour vers https://captaindns.com/fr/tools/dns/test-propagation, éliminant les deux intermédiaires.

Comment détecter les chaînes sur votre site ?

La méthode la plus efficace est de tester vos URLs critiques (pages à fort trafic, pages avec le plus de backlinks) avec le Redirect Checker. L'outil indique le nombre de hops pour chaque URL et signale les chaînes de plus de 2 hops.

Pour un audit à grande échelle, exportez la liste de vos URLs depuis Google Search Console (rapport "Pages") et testez-les par lots. Priorisez les URLs avec le plus de trafic organique et le plus de backlinks.

Vous pouvez aussi utiliser le Page Crawl Checker pour analyser les chaînes de redirection dans le contexte d'un crawl complet de page, incluant les ressources chargées (CSS, JavaScript, images) qui peuvent elles aussi traverser des chaînes.

Liens raccourcis : où mènent-ils vraiment ?

Les services de raccourcissement d'URL (bit.ly, t.co, tinyurl.com, ow.ly, goo.gl) remplacent une URL longue par une URL courte qui redirige vers la destination. Cette opération est transparente pour l'utilisateur légitime : il clique, le service redirige, la page se charge. Mais cette transparence est aussi un vecteur d'attaque majeur.

Le problème de sécurité des liens raccourcis

Un lien raccourci masque complètement la destination. L'utilisateur ne peut pas savoir, avant de cliquer, si le lien mène vers un document Google légitime ou vers un site de phishing qui imite la page de connexion de sa banque.

Les attaquants exploitent cette opacité de façon systématique. Un email de phishing contenant https://bit.ly/3xYz123 est beaucoup plus difficile à détecter qu'un email contenant une URL suspecte en clair. Les filtres anti-phishing peinent à analyser les liens raccourcis, car le domaine visible (bit.ly) est légitime. C'est la destination finale qui est malveillante.

Selon les recherches de Palo Alto Networks (Unit 42), plus de 70 % des domaines malveillants sont enregistrés depuis moins de 32 jours (Newly Registered Domains). Les liens raccourcis sont le principal vecteur pour distribuer ces domaines récents.

Techniques d'obfuscation avancées

Les attaquants ne se contentent pas de raccourcir un lien malveillant. Ils combinent plusieurs techniques pour rendre la détection encore plus difficile.

Chaîne de raccourcisseurs : un lien bit.ly redirige vers tinyurl, qui redirige vers ow.ly, qui mène au site de phishing. Chaque couche ajoute une barrière pour les outils de détection. Le Redirect Checker suit la chaîne complète et révèle la destination finale.

Redirections conditionnelles : le service redirige vers un site différent selon le pays, le navigateur ou le moment de la journée. Les visiteurs ciblés voient la page de phishing, les autres sont redirigés vers un site légitime.

Domaines expirés réutilisés : l'attaquant rachète un domaine qui avait bonne réputation, y installe du contenu malveillant, puis distribue des liens raccourcis vers ce domaine. La réputation historique trompe les filtres de sécurité.

Comment le Redirect Checker démasque les liens raccourcis

Quand vous entrez un lien raccourci dans le Redirect Checker, l'outil suit chaque redirection jusqu'à la destination finale, enregistrant le code HTTP, l'URL de destination, les en-têtes et le temps de réponse de chaque hop. Il signale automatiquement plusieurs indicateurs de risque :

Domaines récemment enregistrés (NRD) : si la destination finale est un domaine enregistré depuis moins de 30 jours, l'outil émet un avertissement. Les domaines NRD sont statistiquement beaucoup plus susceptibles d'être malveillants que les domaines établis.

Nombre excessif de redirections : un lien légitime raccourci implique généralement 1 ou 2 redirections (le raccourcisseur vers la destination). Si la chaîne contient 4 redirections ou plus, c'est un signal d'alerte.

Changement de protocole suspect : si une redirection dans la chaîne passe de HTTPS à HTTP, c'est un indicateur de risque. Les sites légitimes utilisent HTTPS. Un retour vers HTTP en milieu de chaîne peut indiquer une tentative de downgrade pour intercepter le trafic.

Homographes IDN : quand le domaine ressemble à un autre

Les attaques par homographe IDN (Internationalized Domain Name) exploitent les caractères Unicode qui ressemblent visuellement à des lettres latines. Par exemple, le caractère cyrillique "a" (U+0430) est visuellement identique au "a" latin (U+0061), mais il s'agit d'un caractère différent.

Un attaquant peut enregistrer cаptaindns.com (avec un "a" cyrillique) qui ressemble exactement à captaindns.com dans la barre d'adresse. Derrière un lien raccourci, cette différence est totalement invisible.

Le Redirect Checker affiche l'URL de destination en ASCII Punycode quand elle contient des caractères IDN. L'URL cаptaindns.com apparaît alors sous sa forme technique xn--cptaindns-r6a.com, révélant immédiatement que ce n'est pas le domaine attendu.

Pour protéger votre marque, vérifiez régulièrement que les variantes homographes de votre domaine ne sont pas enregistrées par des tiers. Le Phishing URL Checker analyse spécifiquement les risques d'homographie et de typosquatting sur les URLs que vous lui soumettez.

Comment corriger les problèmes de redirection ?

Le diagnostic est fait, le problème est identifié. Voici les étapes de correction pour chaque type de problème.

Corriger une boucle de redirection

Étape 1 : identifier le point d'entrée et le point de retour. Utilisez le Redirect Checker pour reconstruire la chaîne complète. Notez à quel hop l'URL réapparaît.

Étape 2 : identifier le composant responsable du retour. C'est le serveur, le CDN, le CMS ou le plugin qui génère la redirection vers l'URL déjà vue. Consultez la section "Les 7 causes" ci-dessus pour identifier le pattern.

Étape 3 : casser le cycle. Modifiez la configuration du composant responsable pour qu'il ne génère plus la redirection circulaire. Dans la plupart des cas, cela signifie supprimer ou modifier une règle de redirection dans un des composants impliqués.

Étape 4 : tester immédiatement. Après la correction, videz le cache du navigateur (les 301 peuvent être mises en cache) et testez avec le Redirect Checker. Vérifiez que la chaîne se termine par un code 200 et non par un cycle.

Exemple concret : boucle entre Cloudflare (Flexible SSL) et un serveur Apache qui force HTTPS.

Avant correction :
https://captaindns.com → Cloudflare (HTTP vers serveur) → Apache (redirige vers HTTPS)
→ Cloudflare (HTTP vers serveur) → Apache (redirige vers HTTPS) → boucle

Correction : passer Cloudflare en mode "Full (Strict)"

Après correction :
https://captaindns.com → Cloudflare (HTTPS vers serveur) → Apache (pas de redirection, code 200)

Corriger une chaîne de redirection

Principe : raccourcir la chaîne à 1 seul hop. Chaque URL source doit pointer directement vers la destination finale, sans intermédiaire.

Étape 1 : lister toutes les redirections de la chaîne. Utilisez le Redirect Checker pour obtenir la séquence complète.

Étape 2 : identifier la destination finale. C'est la dernière URL de la chaîne, celle qui retourne un code 200.

Étape 3 : mettre à jour chaque redirection intermédiaire. Modifiez la configuration de chaque serveur ou service impliqué pour que les URLs intermédiaires redirigent directement vers la destination finale.

Exemple :

Avant correction :
http://captaindns.com/old-page
→ 301 → https://captaindns.com/old-page
→ 301 → https://captaindns.com/fr/old-page
→ 301 → https://captaindns.com/fr/tools/new-page

Après correction :
http://captaindns.com/old-page → 301 → https://captaindns.com/fr/tools/new-page
https://captaindns.com/old-page → 301 → https://captaindns.com/fr/tools/new-page
https://captaindns.com/fr/old-page → 301 → https://captaindns.com/fr/tools/new-page

Chaque URL source pointe désormais directement vers la destination finale en un seul hop. Le navigateur et Googlebot n'ont plus qu'une seule redirection à suivre.

Vérification post-correction

Après chaque correction, testez systématiquement avec le Redirect Checker :

1. Vérifiez que la chaîne se termine par un code 200.
2. Vérifiez que le nombre de hops est inférieur ou égal à 2.
3. Vérifiez que toutes les redirections intermédiaires utilisent le code 301 (sauf cas spécifique de redirection temporaire).
4. Vérifiez que le protocole final est HTTPS.
5. Testez les 4 variantes de l'URL : http://, https://, http://www., https://www..

Si vous avez corrigé plusieurs chaînes, attendez 48 à 72 heures, puis vérifiez dans Google Search Console que les erreurs de redirection ont disparu du rapport "Pages".

Bonnes pratiques pour éviter les problèmes futurs

Utiliser un seul point de contrôle pour les redirections. Ne configurez pas la même redirection à deux endroits différents (serveur web et CDN, CMS et .htaccess). Choisissez un seul composant pour gérer chaque type de redirection.

Toujours utiliser des 301 pour les redirections permanentes. Les 302 ne transfèrent pas le PageRank et ne sont pas mises en cache par le navigateur. Sauf cas spécifique (redirection conditionnelle, test A/B), la 301 est le choix par défaut.

Mettre à jour les anciennes redirections après chaque migration. Ne laissez pas les chaînes s'accumuler. Après chaque changement de structure d'URL, revenez sur les anciennes redirections et mettez-les à jour pour pointer directement vers la destination finale.

Documenter toutes les redirections en place. Maintenez un tableau récapitulatif de toutes les règles de redirection actives, avec la source, la destination, le code HTTP et la date de création. Ce tableau est indispensable pour éviter les conflits lors des futures modifications.

Tester avant de déployer. Avant de mettre en production une nouvelle règle de redirection, testez-la dans un environnement de staging ou avec curl -I. Vérifiez que la redirection fonctionne et qu'elle ne crée pas de conflit avec les règles existantes.

Plan d'action recommandé

Voici une checklist en 5 étapes pour auditer et corriger les problèmes de redirection sur votre site.

Étape 1 : scanner les URLs critiques

Identifiez vos 20 à 50 URLs les plus importantes : pages d'accueil, pages produit, articles de blog à fort trafic, pages de conversion. Testez chacune avec le Redirect Checker.

Pour chaque URL, notez :

• Le nombre de hops
• La présence éventuelle d'une boucle
• Le code HTTP de la destination finale (doit être 200)
• Le protocole de la destination finale (doit être HTTPS)

Étape 2 : identifier boucles et chaînes de plus de 3 hops

Parmi les URLs testées, isolez celles qui présentent un problème :

• Boucle détectée : priorité maximale, la page est inaccessible
• 5 hops ou plus : priorité haute, impact SEO et performance significatif
• 3 à 4 hops : priorité moyenne, à corriger dans le prochain cycle de maintenance
• 1 à 2 hops : pas d'action requise

Étape 3 : corriger les configurations serveur

Pour chaque problème identifié, appliquez la correction appropriée :

• Boucle : identifiez le composant responsable (voir les 7 causes) et cassez le cycle
• Chaîne : mettez à jour chaque redirection intermédiaire pour pointer vers la destination finale
• Conflit CDN/serveur : alignez la configuration SSL/TLS entre le CDN et le serveur d'origine
• Conflit .htaccess : simplifiez les règles, ajoutez les flags [L], ordonnez de la plus spécifique à la plus générique

Étape 4 : vérifier les liens raccourcis dans vos emails et newsletters

Passez en revue les liens raccourcis présents dans vos templates de newsletter, vos signatures email et vos campagnes marketing actives. Pour chaque lien raccourci :

• Testez la destination avec le Redirect Checker
• Vérifiez que la destination est bien votre site (et non un domaine tiers)
• Remplacez les liens raccourcis par des liens directs quand c'est possible
• Si le lien raccourci est nécessaire (tracking, QR code), vérifiez que la chaîne ne dépasse pas 2 hops

Étape 5 : re-tester après correction

Après chaque correction, revenez sur les URLs corrigées et vérifiez que :

• La boucle est résolue (code 200 en fin de chaîne)
• La chaîne est raccourcie (2 hops maximum)
• Les 4 variantes de l'URL (HTTP/HTTPS, www/non-www) fonctionnent correctement
• Aucun nouveau problème n'a été introduit

Planifiez un audit de suivi à 30 jours pour vérifier que les corrections tiennent et qu'aucune nouvelle chaîne ne s'est formée.

Cas pratiques : diagnostics courants et solutions

Cas 1 : site WordPress inaccessible après activation de Really Simple SSL

Symptôme : ERR_TOO_MANY_REDIRECTS immédiatement après activation du plugin.

Diagnostic avec le Redirect Checker :

Hop 1: https://captaindns.com → 301 → http://captaindns.com (plugin force HTTP ?)
Hop 2: http://captaindns.com → 301 → https://captaindns.com (serveur force HTTPS)
Hop 3: https://captaindns.com → 301 → http://captaindns.com
→ Boucle détectée au hop 3

Cause : le fichier wp-config.php contient define('FORCE_SSL_ADMIN', false) ou l'URL du site dans la base de données est en HTTP, ce qui entre en conflit avec le plugin qui tente de forcer HTTPS.

Solution : désactivez le plugin via FTP (renommez son dossier), mettez à jour les options siteurl et home dans wp_options pour utiliser HTTPS, ajoutez define('FORCE_SSL_ADMIN', true) dans wp-config.php, puis réactivez le plugin.

Cas 2 : lien raccourci dans un email qui mène vers un site de phishing

Symptôme : un employé reçoit un email avec un lien https://bit.ly/3Ab4Cd5 prétendant mener vers un document partagé.

Diagnostic avec le Redirect Checker :

Hop 1: https://bit.ly/3Ab4Cd5 → 301 → https://tinyurl.com/y7x8z9
Hop 2: https://tinyurl.com/y7x8z9 → 301 → https://docs-google-verification.com/login
→ Destination finale : https://docs-google-verification.com/login
→ ALERTE : domaine enregistré il y a 3 jours (NRD)
→ ALERTE : le domaine imite "docs.google.com" (homographie potentielle)

Indicateurs de risque : deux raccourcisseurs en chaîne (technique d'obfuscation), domaine de destination enregistré depuis 3 jours (NRD), nom de domaine qui imite un service légitime (Google Docs), URL contenant "/login" (tentative de vol d'identifiants).

Action : ne pas cliquer. Signaler l'email comme phishing. Avertir l'équipe de sécurité. Si le lien a été cliqué, changer immédiatement le mot de passe du service imité et activer l'authentification à deux facteurs.

Redirections et sécurité : les attaques basées sur les redirections

Les redirections ne sont pas seulement un problème de configuration. Elles sont aussi un vecteur d'attaque exploité activement par les cybercriminels.

Open redirect : quand votre propre site devient un vecteur d'attaque

Une vulnérabilité "open redirect" existe quand votre site accepte un paramètre d'URL qui contrôle la destination d'une redirection, sans valider ce paramètre. Exemple : https://captaindns.com/login?redirect=https://site-malveillant.com. Si votre application redirige aveuglément vers la valeur du paramètre redirect, un attaquant peut utiliser votre domaine légitime comme première étape d'une chaîne de phishing.

Protection : validez toujours les URLs de redirection côté serveur. N'acceptez que les redirections vers votre propre domaine ou vers une liste blanche de domaines autorisés.

Attaque par chaîne de redirections

Un attaquant peut exploiter des redirections légitimes pour construire des chaînes qui contournent les filtres de sécurité. La chaîne typique : un email contient un lien vers un raccourcisseur légitime (bit.ly), le raccourcisseur redirige vers un site réputé qui a une faille open redirect, l'open redirect envoie vers le site de phishing. Chaque étape passe les filtres individuellement. C'est la combinaison qui est malveillante. Seul un outil qui suit la chaîne complète jusqu'à la destination finale peut détecter l'attaque.

Bonnes pratiques de sécurité pour les redirections

1. Ne jamais cliquer sur un lien raccourci sans le vérifier. Utilisez le Redirect Checker pour révéler la destination avant de cliquer.
2. Auditer votre propre site pour les open redirects. Recherchez tous les endpoints qui acceptent un paramètre d'URL comme destination de redirection.
3. Vérifier les domaines NRD dans les emails. Un domaine de moins de 30 jours dans un lien email est un signal d'alerte fort.
4. Sensibiliser les équipes. Les liens raccourcis dans les emails internes devraient toujours être accompagnés de l'URL complète de destination en texte clair.

FAQ

Que signifie ERR_TOO_MANY_REDIRECTS ?

Ce message d'erreur signifie que le navigateur a atteint sa limite de redirections successives (20 pour Chrome et Firefox, 16 pour Safari) sans atteindre une page de contenu. La cause est soit une boucle de redirection (deux ou plusieurs URLs qui se redirigent mutuellement), soit une chaîne de redirection excessivement longue. Pour identifier la cause exacte, testez l'URL avec le Redirect Checker qui suit la chaîne complète et signale automatiquement les boucles.

Comment corriger une boucle de redirection sur WordPress ?

Les boucles WordPress sont généralement causées par un conflit entre un plugin (Really Simple SSL, Wordfence, W3 Total Cache) et la configuration serveur. La correction en 4 étapes : 1) désactivez les plugins un par un via FTP (renommez le dossier dans wp-content/plugins/) pour identifier le coupable ; 2) vérifiez que les URLs siteurl et home dans la table wp_options utilisent le bon protocole (HTTPS) ; 3) nettoyez le fichier .htaccess des règles de redirection en double ; 4) réactivez le plugin et ajustez ses paramètres pour ne pas dupliquer les redirections du serveur.

Combien de redirections Google peut-il suivre ?

Google suit officiellement jusqu'à 10 redirections dans une chaîne. Au-delà, Googlebot abandonne et la page finale n'est ni crawlée ni indexée. En pratique, John Mueller recommande de ne jamais dépasser 2 hops. Chaque redirection consomme du crawl budget et peut diluer le signal SEO, surtout si une 302 se glisse dans une chaîne de 301.

Les liens raccourcis sont-ils dangereux ?

Les liens raccourcis ne sont pas intrinsèquement dangereux, mais ils masquent la destination réelle, ce qui en fait un vecteur privilégié pour le phishing et la distribution de malware. Selon les recherches de Palo Alto Networks, plus de 70 % des domaines malveillants sont enregistrés depuis moins de 32 jours, et les liens raccourcis sont le principal moyen de distribuer ces domaines dans des emails. La bonne pratique est de toujours vérifier la destination d'un lien raccourci avant de cliquer, en utilisant un outil qui suit la chaîne de redirections jusqu'àu bout.

Comment savoir où mène un lien bit.ly ?

Plusieurs méthodes existent. La plus fiable est d'utiliser le Redirect Checker de CaptainDNS : entrez le lien bit.ly et l'outil suit toutes les redirections jusqu'à la destination finale, en affichant chaque hop intermédiaire. Vous pouvez aussi ajouter un "+" à la fin de l'URL bit.ly (par exemple https://bit.ly/3xYz123+) pour accéder à la page de statistiques de bit.ly qui affiche la destination, mais cette méthode ne fonctionne pas avec tous les raccourcisseurs et ne suit pas les redirections multiples.

Quelle différence entre une boucle et une chaîne de redirection ?

Une boucle est un cycle : l'URL A redirige vers B, qui redirige vers C, qui redirige de nouveau vers A. Le navigateur tourne en rond et n'atteint jamais une page de contenu. Le résultat est une erreur ERR_TOO_MANY_REDIRECTS. Une chaîne est une séquence linéaire : A redirige vers B, qui redirige vers C, qui retourne un code 200 (page de contenu). La chaîne aboutit, mais chaque hop intermédiaire ajoute de la latence et peut diluer le signal SEO. Les boucles sont bloquantes (la page est inaccessible), les chaînes sont dégradantes (la page charge, mais moins bien).

Le Redirect Checker fonctionne-t-il avec les liens raccourcis ?

Oui. Le Redirect Checker suit toutes les redirections HTTP, quel que soit le domaine source. Quand vous entrez un lien bit.ly, tinyurl.com, t.co ou tout autre raccourcisseur, l'outil suit la chaîne complète jusqu'à la destination finale. Il affiche chaque hop intermédiaire avec le code HTTP, l'URL de destination et le temps de réponse. Il signale aussi les domaines récemment enregistrés (NRD) et les chaînes anormalement longues qui peuvent indiquer une tentative d'obfuscation.

Comment détecter un lien de phishing masqué ?

Plusieurs indices permettent de détecter un lien de phishing derrière un raccourcisseur. Vérifiez la destination avec le Redirect Checker et recherchez ces signaux d'alerte : 1) le domaine de destination est enregistré depuis moins de 30 jours (NRD) ; 2) la chaîne contient plus de 2 redirections (technique d'obfuscation) ; 3) le domaine imite un service connu (homographe IDN ou typosquatting) ; 4) l'URL finale contient des mots comme "login", "verify", "secure" ou "update" ; 5) le protocole passe de HTTPS à HTTP en cours de chaîne. La présence de 2 ou plus de ces indicateurs suggère fortement un lien malveillant.

Les redirections meta refresh créent-elles des boucles ?

Oui, les redirections meta refresh peuvent créer des boucles exactement comme les redirections HTTP. La page A contient une balise <meta http-equiv="refresh"> qui redirige vers la page B, et la page B contient une balise similaire qui redirige vers A. La différence est que les meta refresh sont plus lentes (le navigateur doit télécharger et parser le HTML avant de rediriger) et plus difficiles à diagnostiquer car elles ne sont pas visibles dans les en-têtes HTTP. Les outils en ligne de commande comme curl ne les détectent pas sans option spécifique.

Comment éviter que les chaînes de redirection s'accumulent au fil du temps ?

La meilleure pratique est de mettre à jour les anciennes redirections après chaque migration. Quand vous ajoutez une nouvelle couche de redirection (changement de domaine, changement de structure d'URL, passage HTTPS), revenez sur les redirections précédentes et mettez-les à jour pour pointer directement vers la destination finale. Documentez toutes les redirections actives dans un tableau centralisé avec la source, la destination, le code HTTP et la date. Planifiez un audit trimestriel de vos URLs principales avec le Redirect Checker pour détecter les chaînes avant qu'elles ne deviennent problématiques.

Glossaire

• Boucle de redirection : cycle où deux ou plusieurs URLs se redirigent mutuellement. Le navigateur affiche ERR_TOO_MANY_REDIRECTS après 16 à 20 tentatives.
• Chaîne de redirection : séquence linéaire de redirections successives. La chaîne aboutit, mais elle dégrade le SEO et la performance.
• ERR_TOO_MANY_REDIRECTS : message d'erreur des navigateurs Chromium quand la limite de redirections est atteinte. Équivalent à "La page n'est pas redirigée correctement" sur Firefox.
• NRD (Newly Registered Domain) : domaine enregistré depuis moins de 32 jours. Statistiquement plus susceptible d'être malveillant.
• Homographe IDN : domaine internationalisé utilisant des caractères Unicode visuellement similaires à des lettres latines pour imiter un domaine légitime.
• Meta refresh : balise HTML <meta http-equiv="refresh"> qui déclenche une redirection côté client. Déconseillée par Google pour le SEO.
• Lien raccourci : URL courte (bit.ly, t.co, tinyurl.com) qui redirige vers une destination plus longue en masquant l'URL réelle.
• Open redirect : vulnérabilité où une application accepte un paramètre d'URL comme destination de redirection sans validation, permettant le phishing.

Sources

• RFC 7231, section 6.4 : HTTP Redirection : définition officielle des codes de redirection HTTP 301, 302, 303 et 307
• Google Search Central : URL redirections : documentation officielle Google sur le traitement des redirections par le moteur de recherche
• Palo Alto Networks Unit 42 : Newly Registered Domains : recherche sur l'utilisation malveillante des domaines récemment enregistrés