logo
GeekFormat

Vérificateur de chaîne de redirections

Vérification de la chaîne de redirections

Vérifie saut par saut 301/302/307/308, identifie les boucles, les redirections cross-domain et les problèmes de dégradation HTTPS.

Lorsque vous saisissez une adresse web dans votre navigateur, une série de redirections invisibles peuvent se produire en coulisse : HTTP→HTTPS, non www→www, ancien domaine→nouveau domaine, lien court→lien long… Chaque saut de redirection consomme du temps, affecte le classement SEO, et peut même secrètement dégrader HTTPS en HTTP. Le vérificateur de chaîne de redirections suit le chemin de redirection complet de l'URL saut par saut depuis la perspective du serveur, affiche le code d'état (301/302/303/307/308), l'en-tête Location et l'adresse cible de chaque saut, détecte automatiquement les boucles de redirection, les sauts inter-domaines, la dégradation HTTPS et la troncature de chaîne, vous aidant à découvrir les risques de redirection cachés lors des migrations de domaine, du déploiement HTTPS et de l'optimisation SEO.

Recommandations connexes

Cas d'utilisation

  • Validation de migration de domaine : après le passage d'un site de l'ancien domaine au nouveau, confirmez saut par saut si les anciennes URL sont correctement redirigées en 301 permanent vers la nouvelle adresse, évitez les pertes de trafic causées par des redirections en chaîne et des codes d'état erronés
  • Vérification du déploiement HTTPS : confirmez si la chaîne de redirection HTTP→HTTPS est un saut unique 301, vérifiez s'il existe une boucle de dégradation HTTP→HTTPS→HTTP, validez si la configuration HSTS est active
  • Détection de page de destination de lien court : suivez le chemin de redirection complet des liens courts (t.cn/bit.ly, etc.), des liens UTM marketing ou des liens de partage social, confirmez si la page de destination finale est l'adresse attendue, recherchez si des sauts intermédiaires insèrent des paramètres de suivi ou des redirections malveillantes
  • Normalisation www et non www : vérifiez si le domaine www et le domaine racine se redirigent correctement l'un vers l'autre en 301 vers la version normalisée, évitez les problèmes de contenu dupliqué causés par un fonctionnement double
  • Dépannage de boucle de redirection : lorsque le navigateur signale une erreur ERR_TOO_MANY_REDIRECTS, utilisez l'outil pour localiser précisément le nœud où la boucle se produit, distinguez s'il s'agit d'une erreur de configuration Nginx/Apache, d'un conflit de règles CDN ou d'une boucle causée par un plugin WordPress
  • Débogage CDN et proxy inverse : dépanner les conflits de redirection dans les architectures multicouches telles que Cloudflare, CDN Alibaba Cloud, proxy inverse Nginx, identifier les problèmes de redirection mutuelle entre les règles CDN et les règles du serveur d'origine
  • Audit de santé SEO : vérifiez régulièrement la longueur de la chaîne de redirection des pages principales du site, évaluez l'impact des redirections multiples sur l'efficacité du transfert de PageRank, optimisez les chaînes de redirection trop longues
  • Évaluation des risques de saut inter-domaine : détectez les scénarios impliquant des redirections inter-domaines tels que la redirection de connexion, le rappel OAuth, la redirection de paiement, confirmez si les Cookie et les Session sont correctement transmis lors du passage inter-domaine
  • Équilibrage de charge et validation multi-site : vérifiez la stratégie de redirection dans les scénarios de centres de données multi-sites, d'équilibrage de charge global GSLB, confirmez que les utilisateurs de différentes régions sont correctement redirigés vers le nœud disponible le plus proche
  • Débogage de cache de redirection : validez les paramètres des en-têtes Cache-Control et Expires des redirections permanentes 301 et temporaires 302, dépanner les accès anormaux causés par la mise en cache par le navigateur d'anciennes règles de redirection

Fonctionnalités

  • Suivi complet saut par saut : suit chaque saut de redirection depuis la perspective du serveur, affiche séquentiellement l'URL d'origine, le code d'état de chaque saut, le texte d'état, l'en-tête de réponse Location et le chemin de redirection complet, sans omettre aucun nœud intermédiaire
  • Prise en charge de tous les codes d'état : couvre les cinq codes d'état de redirection standard — 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect, et indique les différences sémantiques de chaque code
  • Détection de boucle de redirection : identifie automatiquement les modèles de saut en boucle tels que A→B→A, marque la position exacte du nœud où la boucle se produit et la longueur de la boucle, localise précisément la source de l'erreur ERR_TOO_MANY_REDIRECTS
  • Identification des sauts inter-domaines : détecte les changements de Host/Domaine à chaque saut, marque les nœuds de saut inter-domaine, signale le risque de perte de Cookie et les problèmes de pré-vérification CORS
  • Alerte de dégradation HTTPS : compte le nombre de nœuds HTTP (non HTTPS) dans la chaîne de redirection, marque les sauts de dégradation HTTPS→HTTP, signale les risques de sécurité et l'impact négatif sur le SEO
  • Protection contre troncature de chaîne : définit une limite de profondeur de saut maximale (20 sauts), tronque automatiquement et marque lorsque la chaîne est trop longue, évite les délais d'attente de requête causés par un suivi infini
  • Résumé statistique des redirections : fournit un aperçu des indicateurs clés — nombre total de sauts, URL de destination finale, détection de boucle, inter-domaine ou non, nombre de nœuds HTTP, chaîne tronquée ou non
  • Évaluation de l'impact SEO : évalue automatiquement le niveau d'impact sur le transfert de PageRank et les Core Web Vitals en fonction du nombre de sauts, du type de code d'état et de la couverture HTTPS
  • URL de test prédéfinies : inclut des adresses de test courantes telles que geekformat.com, github.com, httpbin.org/redirect, services de liens courts, remplissage en un clic pour une expérience rapide
  • Historique des requêtes récentes : enregistre automatiquement les 8 derniers enregistrements de requête (stockés localement dans le navigateur), prend en charge la répétition de la détection en un clic, pratique pour comparer l'effet avant et après correction
  • Carte de conseils de diagnostic : pour les problèmes détectés tels que boucle de redirection, saut inter-domaine, dégradation HTTP, chaîne trop longue, fournit des conseils de correction spécifiques et des guides de bonnes pratiques
  • Double vue détail et résumé : affiche par défaut la carte de résumé de la chaîne, en déroulant on peut voir l'URL de requête complète, l'état de réponse, la cible Location et le marquage HTTPS de chaque saut

Comment utiliser

  1. Saisissez l'URL à détecter dans la zone de saisie (doit inclure le préfixe de protocole http:// ou https://), ou cliquez sur le bouton d'URL prédéfinie (geekformat.com/github.com/httpbin.org/redirect, etc.) pour remplir rapidement une adresse de test
  2. Cliquez sur le bouton « Suivre la chaîne de redirections », l'outil enverra une requête depuis le côté serveur et suivra l'en-tête de réponse Location pour enregistrer les informations complètes de chaque saut
  3. Consultez la carte de résumé des redirections en haut : nombre total de sauts, URL de destination finale, détection de boucle ou non, présence de sauts inter-domaines, nombre de nœuds HTTP, chaîne tronquée ou non en raison d'un trop grand nombre de sauts
  4. Consultez les informations détaillées de chaque saut dans la zone de visualisation de la chaîne : numéro séquentiel, URL de requête, code d'état de réponse et texte descriptif, URL cible dans l'en-tête de réponse Location, marquage de sécurité HTTPS
  5. Faites attention aux cartes d'avertissement de diagnostic : si des boucles de redirection (rouge), une dégradation HTTPS (orange), des sauts inter-domaines (jaune) ou une chaîne trop longue (jaune) sont détectées, l'outil les mettra en évidence à l'emplacement correspondant et fournira une explication du problème
  6. Utilisez la zone d'évaluation de l'impact SEO pour consulter le niveau d'impact de la chaîne de redirection actuelle sur l'efficacité du transfert de PageRank, la vitesse de chargement des pages et les Core Web Vitals, ainsi que des suggestions d'optimisation
  7. Une fois la détection terminée, vous pouvez cliquer sur n'importe quel enregistrement dans l'historique des requêtes récentes pour répéter rapidement la détection et comparer les changements de la chaîne de redirection avant et après correction ; vous pouvez également capturer l'écran des résultats de détection ou copier le texte pour la communication d'équipe et l'enregistrement de tickets

FAQ

À partir de combien de sauts une chaîne de redirection est-elle considérée comme trop longue ? Quel est l'impact sur le SEO ?

Google recommande officiellement de maintenir la chaîne de redirection à un seul saut, au maximum 3 sauts. Selon la documentation de Google Search Central, Googlebot suit généralement jusqu'à 5 sauts de redirection avant d'arrêter le suivi, mais cela ne signifie pas que 5 sauts sont sûrs. Chaque saut de redirection augmente le délai de chargement de la page (100-300 ms/saut), gaspille le budget de crawl et peut entraîner une atténuation du transfert de PageRank. 1 saut n'a presque pas d'impact SEO ; 2 sauts sont acceptables mais recommandés d'être optimisés ; à partir de 3 sauts, cela commence à affecter le LCP et l'efficacité du crawl ; au-delà de 5 sauts, il y a un risque que la page ne soit pas indexée. Utilisez cet outil pour détecter la chaîne de saut de vos pages principales, assurez-vous que les URL clés (page d'accueil, pages produit principales, pages internes à fort trafic) sont toutes accessibles en un seul saut.

La redirection 301 nuit-elle au SEO ? Le PageRank peut-il être entièrement transféré ?

Une redirection permanente 301 utilisée correctement ne nuit pas au SEO. Gary Illyes et John Mueller de Google ont confirmé à plusieurs reprises que pour les redirections 301 de migration de domaine HTTP vers HTTPS et les migrations de page permanentes au sein d'un même domaine, le transfert de PageRank est de 100%, sans perte. Mais il faut noter : 1) Les redirections temporaires 302 ne transfèrent pas de PageRank (ou avec une efficacité très faible) ; 2) Si des noindex, des blocages robots.txt, des erreurs 4xx/5xx apparaissent dans la chaîne de redirection, le transfert de poids est interrompu ; 3) Après une migration 301 inter-domaine, il faut soumettre une notification de changement de domaine dans Google Search Console pour accélérer la migration de l'index ; 4) 301 est mis en cache à long terme par le navigateur, pendant la phase de test il est recommandé de d'abord valider avec 302 puis de passer à 301.

Pourquoi mon site redirige-t-il automatiquement vers HTTP au lieu de HTTPS ? Comment corriger ?

Les redirections de dégradation HTTPS→HTTP sont généralement causées par les raisons suivantes : 1) Le proxy inverse/CDN renvoie la source en HTTP, lorsque le serveur d'origine Nginx/Apache utilise la variable $scheme pour obtenir le protocole, il obtient http au lieu de https ; 2) Le code applicatif encode en dur des URL avec préfixe http:// ; 3) La Home URL ou la Site URL de CMS comme WordPress est définie sur http ; 4) Il reste d'anciennes règles HTTP dans .htaccess ; 5) Le paramétrage SSL/TLS du service tiers (CDN/WAF) est en mode « Flexible » au lieu de mode « Strict ». Étapes de correction : tout d'abord utilisez cet outil pour déterminer à quel saut se produit la dégradation ; configurez le SSL du CDN en mode « Full (strict) » ; dans Nginx, traitez correctement l'en-tête X-Forwarded-Proto ; dans WordPress, ajoutez $_SERVER['HTTPS']='on'; dans wp-config.php ; déployez l'en-tête de réponse HSTS pour empêcher la dégradation au niveau du navigateur ; vérifiez que toutes les règles de redirection ciblent bien https://.

Comment corriger une boucle de redirection dans Nginx (ERR_TOO_MANY_REDIRECTS) ?

Plus de 90 % des boucles de redirection Nginx sont causées par un traitement incorrect de l'en-tête X-Forwarded-Proto dans les scénarios de proxy inverse/CDN. Méthode de correction : 1) Assurez-vous que le CDN/équilibreur de charge envoie l'en-tête X-Forwarded-Proto au backend : proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx utilise X-Forwarded-Proto au lieu de $scheme pour décider de sauter vers HTTPS. Recommandé d'utiliser un bloc map : map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) Évitez d'écrire des règles rewrite dans le bloc server qui correspondent indéfiniment à elles-mêmes ; 4) La redirection www et non www ne doit être configurée que dans un seul bloc server en sens unique, ne pas configurer en bidirectionnel.

Comment corriger une boucle de redirection dans Apache .htaccess ?

Les boucles Apache .htaccess sont généralement causées par des conflits de règles RewriteRule. Étapes de correction : 1) Assurez-vous que RewriteEngine On n'apparaît qu'une seule fois ; 2) Placez la règle de redirection HTTP→HTTPS tout devant toutes les règles, utilisez : RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ; 3) Placez les règles www/non www après la redirection HTTPS, et ne faites qu'un saut unidirectionnel (non www→www ou inversement) ; 4) Notez que le drapeau [L] signifie « last » mais si la règle modifie l'URL, elle recommencera à correspondre depuis la première règle, ce qui peut entraîner une boucle, pour les règles complexes envisagez d'utiliser le drapeau [END] (Apache 2.3.9+) ; 5) Vérifiez s'il y a plusieurs fichiers .htaccess (le .htaccess dans les sous-répertoires prend également effet) ; 6) Changez temporairement R=301 en R=302 pour tester, évitez les interférences de cache du navigateur.

Comment corriger une boucle de redirection causée par Cloudflare ?

La cause la plus fréquente des boucles Cloudflare est un paramétrage erroné du mode de chiffrement SSL/TLS ou un conflit de règles de page : 1) Passez le mode SSL/TLS de Cloudflare de « Flexible » à « Full » ou « Full (strict) » — en mode Flexible, Cloudflare communique avec le serveur d'origine en HTTP, si le serveur d'origine a configuré une redirection forcée HTTPS, cela crée une boucle ; 2) Vérifiez si « Always Use HTTPS » dans « Edge Certificates » de Cloudflare est activé, ne configurez pas la redirection HTTPS à la fois sur le serveur d'origine et sur Cloudflare ; 3) Vérifiez s'il y a des règles de transfert en conflit dans les Page Rules ; 4) Si vous utilisez le plugin Cloudflare WordPress, ne configurez pas la redirection HTTPS à la fois dans le plugin et dans Cloudflare ; 5) Vérifiez si les règles Forwarding URL pointent vers une adresse qui est à nouveau redirigée par Cloudflare.

Quelle est la différence entre les redirections 301, 302, 307 et 308 ? Laquelle choisir ?

La différence fondamentale réside dans les deux dimensions « permanent ou non » et « conserve ou non la méthode de requête ». Guide de choix rapide : pour les requêtes GET de pages web classiques (utilisateur accédant à une page) — migration permanente utilisez 301 (migration de domaine, passage à HTTPS, modification permanente d'URL), redirection temporaire utilisez 302 (tests A/B, maintenance temporaire, redirection de connexion) ; pour les requêtes POST/PUT/DELETE (appels API, soumission de formulaire) — migration permanente utilisez 308, redirection temporaire utilisez 307, garantissant que la méthode et les données de requête ne sont pas perdues ; 303 est spécialement utilisé pour la redirection vers la page de résultat après soumission de formulaire POST (force GET, empêche la soumission répétée). Mémo simple : 301 = permanent sécurisé GET, 302 = temporaire sécurisé GET, 307 = temporaire toutes méthodes, 308 = permanent toutes méthodes, 303 = page de résultat après POST.

Le navigateur met-il en cache définitivement les redirections 301 ? Comment effacer le cache 301 ?

Les redirections permanentes 301 sont mises en cache par défaut par le navigateur, mais la durée de cache dépend des paramètres des en-têtes Cache-Control et Expires dans la réponse. Si aucun en-tête de cache n'est spécifié explicitement, le comportement de cache par défaut varie selon les navigateurs : Chrome met généralement en cache les redirections 301 pendant plusieurs semaines voire plusieurs mois (peut même rester en cache après le redémarrage du navigateur) ; Firefox met en cache 301 par défaut mais peut revérifier après le redémarrage du navigateur ; la stratégie de cache de Safari est relativement conservatrice. Méthodes pour effacer le cache 301 : 1) Chrome : Paramètres → Confidentialité et sécurité → Effacer les données de navigation → Plage de temps sélectionnez « Tout le temps » → cochez « Images et fichiers en cache » → Effacer les données ; 2) Lorsque les outils de développement (F12) sont ouverts, cochez « Disable cache » dans le panneau Network ; 3) Ajoutez un paramètre de requête dénué de sens après l'URL (?nocache=1) pour contourner le cache ; 4) Les développeurs Chrome peuvent Flush les sockets dans chrome://net-internals/#sockets, ou Clear le cache hôte dans chrome://net-internals/#dns ; 5) Pendant la phase de test, utilisez la redirection temporaire 302 au lieu de 301, puis passez à 301 après confirmation qu'elle est correcte.

Quelle est la différence entre Meta Refresh et la redirection HTTP ? Laquelle est meilleure ?

Meta Refresh est une redirection implémentée par la balise <meta> dans le document HTML (ex: <meta http-equiv="refresh" content="0;url=https://example.com/new">), elle exécute le saut après que le navigateur a analysé le HTML, tandis que la redirection HTTP est directement indiquée par le serveur au niveau du protocole HTTP via un code d'état 3xx. Comparaison des différences : 1) Vitesse : la redirection HTTP commence à sauter dès réception de l'en-tête de réponse, Meta Refresh doit attendre que le HTML soit téléchargé et analysé avant de sauter, plus lent ; 2) SEO : Google peut généralement reconnaître Meta Refresh et transférer le poids (si delay=0), mais la recommandation officielle est d'utiliser les redirections HTTP 301/302, car Meta Refresh est un saut côté client, le signal est moins clair que la redirection côté serveur ; 3) Délai : Meta Refresh peut définir un temps de délai (ex: content="5;url=..." signifie sauter après 5 secondes), mais la redirection HTTP n'a pas cette fonction ; 4) Accessibilité : W3C ne recommande pas d'utiliser Meta Refresh, car les technologies d'assistance telles que les lecteurs d'écran le traitent mal, et cela peut déconcerter l'utilisateur ; 5) Bouton retour : Meta Refresh peut altérer le comportement du bouton retour dans certains navigateurs. Conclusion : privilégiez toujours les redirections HTTP 301/302/307/308, évitez d'utiliser Meta Refresh, à moins que vous ne puissiez pas contrôler la configuration serveur (ex: hébergé sur une plateforme de pages statiques sans possibilité de configurer de règles côté serveur).

La redirection affecte-t-elle le LCP dans les Core Web Vitals ?

Oui, et l'impact est très important. La redirection se produit avant que le navigateur n'obtienne le document HTML, ce qui signifie que chaque saut de redirection retarde le début du téléchargement du document HTML. Le point de départ du calcul du LCP (Largest Contentful Paint) est le temps de début de navigation, et le navigateur doit obtenir le HTML final avant de pouvoir commencer à analyser le DOM, charger le CSS et rendre l'élément LCP. En supposant que chaque saut de redirection ajoute 150 ms de délai réseau (DNS+TCP+TLS+réponse requête), 3 sauts de redirection feront augmenter le LCP d'au moins 450 ms, ce qui suffit à faire passer le LCP de « bon » (≤ 2,5 s) à la plage « nécessite des améliorations » (2,5-4 s). La documentation des Core Web Vitals de Google cite explicitement « éviter les redirections multiples » comme l'une des recommandations clés pour optimiser le LCP. Bonne pratique : assurez-vous que les pages principales ont zéro redirection (lien direct vers l'URL finale), les redirections nécessaires telles que HTTP→HTTPS et la normalisation www sont contrôlées en un seul saut.

Comment vérifier vers où redirige finalement un lien court ?

Les liens courts (t.cn, bit.ly, dwz.cn, url.cn, etc.) atteignent généralement l'URL finale après 1 à 3 sauts de redirection, au milieu peuvent inclure des paramètres de suivi UTM, des sauts de détection d'appareil, des sauts géographiques, etc. Avec cet outil, vous pouvez : 1) Saisissez l'URL du lien court (incluant http:// ou https://) ; 2) Cliquez sur Suivre pour afficher le chemin complet de chaque saut ; 3) Consultez l'URL de destination finale, le nombre de sauts, le type de code d'état ; 4) Vérifiez s'il y a une dégradation HTTP ou un inter-domaine anormal dans les sauts intermédiaires. Remarque : certains liens courts renvoient différentes destinations finales en fonction du User-Agent ou de la région IP, cet outil utilise une adresse IP de serveur pour la requête, le résultat peut légèrement différer de ce que vous voyez en accédant directement via votre navigateur (en particulier pour les services de liens courts étrangers). Pour les liens courts url.cn de WeChat/QQ, il peut être nécessaire d'être dans l'environnement WeChat pour être correctement redirigé vers la page cible.

La redirection forcée HTTPS utilise-t-elle 301 ou 302 ? Faut-il ajouter HSTS ?

La redirection forcée HTTPS doit utiliser la redirection permanente 301, car le passage de HTTP à HTTPS est un changement permanent, pas une redirection temporaire. Après avoir configuré 301, il faut également déployer l'en-tête de réponse HSTS. Le schéma complet de forçage HTTPS se divise en trois phases : 1) Première phase (période de test) : configurez d'abord la redirection 301 HTTP→HTTPS, n'activez pas HSTS, observez pendant 1-2 semaines pour confirmer que toutes les ressources et sous-domaines fonctionnent normalement ; 2) Deuxième phase (période stable) : ajoutez l'en-tête de réponse Strict-Transport-Security, initialement max-age défini sur une durée plus courte (ex: max-age=300 soit 5 minutes), augmentez progressivement jusqu'à max-age=31536000 (1 an) ; 3) Troisième phase (Preload) : après confirmation que tous les sous-domaines prennent en charge HTTPS, ajoutez les directives includeSubDomains et preload, puis soumettez à la HSTS Preload List (hstspreload.org), faisant que le navigateur intègre la stratégie HSTS de votre domaine, éliminant la fenêtre HTTP du premier accès. Attention : une fois HSTS mis en cache par le navigateur, il ne peut pas être révoqué côté serveur avant l'expiration de max-age, donc testez soigneusement.

Quelle est la différence entre le saut window.location en JavaScript et la redirection HTTP ?

Le saut JS (ex: window.location.href='https://example.com') et la redirection HTTP 3xx ont une différence essentielle : 1) Niveau d'exécution : la redirection HTTP s'effectue au niveau du protocole avec un code d'état renvoyé par le serveur, le navigateur saute immédiatement après réception de l'en-tête de réponse ; le saut JS nécessite que le HTML soit téléchargé et que le JS soit analysé et exécuté avant de sauter, plus lent ; 2) SEO : les robots des moteurs de recherche peuvent correctement reconnaître et suivre les redirections HTTP 301/302 pour transférer le poids, mais l'effet SEO du saut JS dépend de l'exécution ou non du JS par le robot et du moment de l'exécution, le signal est faible et instable ; 3) Étape intermédiaire : avant le saut JS, la page a déjà commencé à se charger (peut apparaître un écran blanc ou un clignotement partiel du contenu), l'utilisateur de la redirection HTTP arrive directement à la page cible, expérience plus fluide ; 4) Fiabilité : le JS peut être bloqué par le navigateur, les extensions ou la Content Security Policy, la redirection HTTP est traitée par le cœur du navigateur, fiabilité maximale. Conclusion : lorsqu'il faut rediriger une URL de manière permanente/temporaire, utilisez toujours la redirection HTTP 301/302 côté serveur, le saut JS n'est utilisé que pour la navigation de page dans la logique interactive (ex: saut après validation de formulaire, saut au clic sur bouton, etc.).

La chaîne de redirection peut-elle fausser les résultats des tests A/B ?

Oui, la chaîne de redirection a des impacts multiples sur les tests A/B : 1) Si le test A/B est implémenté par redirection (50 % utilisateurs 302 vers version A, 50 % vers version B), le délai de redirection fera que les deux versions auront des vitesses de chargement de page différentes, la vitesse elle-même peut affecter le taux de conversion (la version plus rapide a naturellement un taux de conversion plus élevé), entraînant un biais de test ; 2) Les paramètres UTM ou les marques de source peuvent être perdus pendant le processus de redirection, entraînant des données d'attribution inexactes ; 3) Si la redirection 302 dure trop longtemps, Google peut juger par lui-même qu'il s'agit d'une redirection 301 et transférer le poids, affectant le référencement de la page de test ; 4) Si un saut dans une redirection à sauts multiples définit un Cookie, cela peut affecter la logique de groupage des utilisateurs. Il est recommandé d'utiliser le split de rendu côté serveur ou le split JS côté client (comme Google Optimize, Optimizely) pour les tests A/B, évitez d'utiliser le split par redirection. Si la redirection est indispensable (ex: tester des chemins d'URL complètement différents), utilisez 302 (pas 301) et assurez-vous d'un accès direct en un seul saut, supprimez la redirection rapidement après la fin du test.

Comment vérifier en masse la chaîne de redirection de l'ensemble du site ?

La vérification en masse des chaînes de redirection d'un site nécessite des outils de crawl : 1) Utilisez un outil de crawl comme Screaming Frog SEO Spider pour crawler l'ensemble du site, consultez toutes les URL de redirection et la longueur de la chaîne dans le rapport Redirect Chains ; 2) Utilisez les fonctionnalités d'audit de site des outils SEO tels que Ahrefs, Semrush ou Sitebulb, ils détectent automatiquement les chaînes et boucles de redirection ; 3) Pour une liste de pages principales, vous pouvez écrire un script appelant l'API backend de cet outil pour une détection en masse ; 4) Consultez les indications de « Erreur de redirection » et « Chaîne de redirection trop longue » dans le rapport « Index des pages » de Google Search Console ; 5) Utilisez l'audit Lighthouse de Chrome DevTools, la section Performance marquera les problèmes de redirection. Il est recommandé de vérifier en priorité : la page d'accueil, les pages de navigation principales, les pages d'atterrissage à fort trafic, les pages récemment migrées/refondues, toutes les URL HTTP après le passage à HTTPS, toutes les URL sous l'ancien domaine.

术语表

Redirection (Redirect)
Mécanisme par lequel le serveur renvoie un code d'état 3xx et un en-tête de réponse Location, indiquant au client d'accéder automatiquement à une autre URL. La redirection est généralement transparente pour l'utilisateur, le navigateur suit automatiquement le saut.
301 Moved Permanently
Code d'état de redirection permanente. Indique que la ressource a été définitivement déplacée vers un nouvel emplacement, les moteurs de recherche transfèrent le PageRank de l'ancienne URL vers la nouvelle, le navigateur met en cache cette redirection à long terme. Recommandé pour les scénarios de requête GET tels que la migration de domaine, le passage à HTTPS.
302 Found
Code d'état de redirection temporaire (anciennement appelé Moved Temporarily). Indique que la ressource se trouve temporairement à un autre emplacement, les moteurs de recherche ne transfèrent pas le poids, le navigateur ne met pas en cache à long terme. Remarque : après avoir reçu 302, la plupart des navigateurs transforment la requête POST en requête GET pour la redirection, le corps de requête peut être perdu.
303 See Other
Code d'état de voir autre emplacement. Généralement utilisé pour la redirection vers la page de résultat après la soumission d'un formulaire POST, demande explicitement au client de demander la nouvelle URL en méthode GET, empêche la soumission répétée du formulaire. La réponse 303 ne devrait pas être mise en cache.
307 Temporary Redirect
Code d'état de redirection temporaire (introduit dans HTTP/1.1). Même sémantique que 302, mais exige strictement de conserver la méthode et le corps de la requête — une requête POST recevant 307 doit toujours demander la nouvelle URL en mode POST, sans perdre les données du formulaire. Convient aux sauts temporaires pour les scénarios API et formulaire.
308 Permanent Redirect
Code d'état de redirection permanente (défini par RFC 7538). Même sémantique que 301, mais exige strictement de conserver la méthode et le corps de la requête — une requête POST recevant 308 est toujours redirigée en mode POST. Version « méthode sécurisée » de 301, entièrement prise en charge par les navigateurs modernes.
En-tête Location
Champ d'en-tête de réponse HTTP, utilisé pour spécifier l'URL cible dans les réponses de redirection 3xx. Peut être une URL absolue (recommandée) ou une URL relative, le client initie automatiquement une nouvelle requête vers cette URL après réception. Les caractères non ASCII dans l'en-tête Location doivent être encodés en URL.
Chaîne de redirection (Redirect Chain)
Série de redirections consécutives entre l'URL initiale et l'URL de destination finale. Par exemple, A→B→C→D forme une chaîne de redirection de 3 sauts. Une chaîne de redirection trop longue ralentit la vitesse de chargement et réduit le poids SEO, il est recommandé de la maintenir à un seul saut, au maximum 3 sauts.
Boucle de redirection (Redirect Loop)
Une URL apparaît à plusieurs reprises dans la chaîne de redirection, formant une boucle de saut infinie (ex: A→B→A). Le navigateur affiche une erreur ERR_TOO_MANY_REDIRECTS après avoir atteint le nombre maximum de sauts (généralement 20). Les causes courantes incluent le saut mutuel HTTP↔HTTPS, le saut mutuel www↔non www et la perte du protocole de proxy inverse.
Migration de domaine (Domain Migration)
Processus par lequel un site passe définitivement d'un domaine à un autre, comme lors d'un changement de nom de marque ou d'une fusion-acquisition. Lors de la migration, il faut rediriger toutes les URL de l'ancien domaine vers les pages correspondantes du nouveau domaine via une redirection permanente 301, et soumettre une notification de changement de domaine dans Google Search Console.
Normalisation d'URL (URL Canonicalization)
Processus d'unification de plusieurs variantes d'URL pour un même contenu (www/non www, avec/sans barre oblique de fin, HTTP/HTTPS, différence de casse) en une URL standard unique, généralement implémenté via une redirection 301. La normalisation évite les problèmes de contenu dupliqué et concentre le poids SEO.
Redirection forcée HTTPS
Configuration consistant à rediriger toutes les requêtes HTTP (port 80) vers HTTPS (port 443) via une redirection 301, étape nécessaire après le déploiement d'un certificat SSL/TLS. Généralement utilisée conjointement avec l'en-tête de réponse HSTS pour éliminer la fenêtre de premier accès HTTP en clair.
HSTS
HTTP Strict Transport Security, via l'en-tête de réponse Strict-Transport-Security indique au navigateur de ne pouvoir accéder au domaine que via HTTPS pendant un temps spécifié, le navigateur met automatiquement à niveau HTTP vers HTTPS en interne, sans nécessiter de redirection serveur. Défense efficace contre les attaques de dépeçage SSL.
Lien court (Short URL)
Service qui convertit une URL longue en URL courte (comme bit.ly, t.cn), lors de l'accès, redirige via 301/302 vers l'URL d'origine. Derrière les liens courts se cachent souvent des chaînes de redirection à sauts multiples, qui peuvent contenir des paramètres de suivi ou rediriger vers différentes cibles dans certaines conditions.
PageRank
Algorithme de classement de pages web inventé par les fondateurs de Google Larry Page et Sergey Brin, évaluant l'autorité de la page via les relations de liens. La redirection permanente 301 transfère le PageRank de l'ancienne URL vers la nouvelle, tandis que la redirection temporaire 302 ne transfère généralement pas ou très peu de poids.
Core Web Vitals
Indicateurs clés d'expérience web définis par Google, incluant LCP (Largest Contentful Paint, mesure des performances de chargement, bon ≤ 2,5s), FID/INP (réactivité interactive, bon ≤ 100ms/200ms) et CLS (stabilité visuelle, bon ≤ 0,1). La chaîne de redirection retarde le téléchargement HTML, dégrade directement l'indicateur LCP.
Redirection inter-domaine (Cross-origin Redirect)
L'URL cible de la redirection a un domaine différent de l'URL d'origine (y compris un domaine complètement différent ou un sous-domaine différent). La redirection inter-domaine est limitée par la politique de même origine, ce qui peut entraîner le non-envoi de Cookie, le blocage des Cookie tiers, l'échec de la pré-vérification CORS, etc.
Troncature de chaîne (Chain Truncation)
Lorsque le nombre de sauts de la chaîne de redirection dépasse la limite de profondeur maximale définie par l'outil ou le navigateur (20 sauts pour cet outil, 20 sauts pour Chrome), le traceur cesse de suivre les redirections suivantes et marque la chaîne comme tronquée. La troncature de chaîne suggère généralement l'existence d'une boucle infinie ou d'une configuration de redirection anormalement complexe.

Tableau de correspondance complet des codes d'état de redirection HTTP

301Moved PermanentlyOui (permanent)Peut changer (POST→GET)Migration de domaine, passage à HTTPS, normalisation www/non www, modification permanente d'URL
302FoundNon (temporaire)Peut changer (POST→GET)Page de maintenance temporaire, redirection de connexion, tests A/B, page de campagne à court terme
303See OtherNon (temporaire)Oui (force GET)Redirection vers la page de résultat après soumission de formulaire POST, empêche la soumission répétée
307Temporary RedirectNon (temporaire)Non (conserve strictement la méthode d'origine)Redirection temporaire d'API, sauts temporaires nécessitant de conserver les données POST
308Permanent RedirectOui (permanent)Non (conserve strictement la méthode d'origine)Migration permanente d'API RESTful, redirections permanentes nécessitant de conserver les méthodes PUT/DELETE

Tableau de comparaison de l'impact des chaînes de redirection sur le SEO

0 saut (accès direct)Aucun impact, état optimalAucun délai supplémentaireMaintenir l'état actuel, les liens internes pointent directement vers l'URL finale
1 sautTransfert normal de PageRank, impact SEO négligeableAjoute environ 100-300 ms de délai (un aller-retour)Acceptable, nombre de sauts courant pour HTTP→HTTPS et normalisation de domaine
2 sautsLéger affaiblissement possible du transfert de poids, le robot peut suivre normalementAjoute environ 200-600 ms de délaiRecommandé d'optimiser en un seul saut, vérifiez si les liens internes pointent vers une URL de redirection intermédiaire
3 sautsEfficacité du transfert de poids diminue, certains robots peuvent abandonner le suiviAjoute environ 300-900 ms de délai, LCP peut être affectéDoit être optimisé, fusionner les règles de redirection directement vers l'URL finale
4-5 sautsAtténuation marquée du PageRank, l'indexation peut être affectée, gaspillage du budget de crawlAjoute 500 ms-1,5 s de délai, LCP dépasse probablement la normeRéparation urgente, vérifiez la superposition de redirections multi-couches CDN/serveur d'origine/application
6 sauts et plusRisque grave, les moteurs de recherche peuvent cesser de suivre entraînant la désindexation de la pageDélai supérieur à 1 seconde, expérience utilisateur très médiocreEnquête immédiate sur la boucle ou l'erreur de configuration, refondre les règles de redirection
Boucle (ERR_TOO_MANY_REDIRECTS)Page complètement inaccessible, les moteurs de recherche la retirent de l'indexPage ne se charge pas, le navigateur affiche une erreurRéparation de la plus haute priorité, utilisez cet outil pour localiser le nœud de boucle

Erreurs de configuration de redirection courantes et solutions de correction

Erreur de boucle ERR_TOO_MANY_REDIRECTS, sauts répétés HTTP↔HTTPSCDN/équilibreur de charge renvoie la source en HTTP, le serveur d'origine ne traite pas correctement l'en-tête X-Forwarded-Proto, redirige toujours vers HTTPSAjouter dans la configuration Nginx : set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } ou utiliser la variable $scheme couplée à la configuration proxy_set_header X-Forwarded-Proto
www et non www se redirigent mutuellement formant une boucleLa couche CDN configure la redirection www→non www, le Nginx du serveur d'origine configure à son tour la redirection non www→www, conflit de règlesChoisissez une version normalisée (recommandé non www ou www, restez cohérent), configurez la redirection sur une seule couche (CDN ou serveur d'origine), supprimez les règles correspondantes des autres couches
La chaîne de redirection passe par 4-5 sauts avant d'atteindre la page finaleSaut HTTP→HTTPS → saut non www→www → saut ajout barre oblique de fin → saut ancien chemin vers nouveau chemin, superposition de règles multi-couchesFusionnez les règles de redirection, sautez directement de l'URL initiale à l'URL finale en une seule étape. Dans Nginx, utilisez la directive return pour sauter en une fois à l'adresse finale complète
Apparition d'un nœud HTTP dans la chaîne de redirection d'un site HTTPS (dégradation)La configuration serveur encode en dur la cible de redirection avec préfixe http://, ou l'application génère l'URL de redirection sans reconnaître que le protocole actuel est HTTPSConfigurez l'application pour faire confiance au proxy inverse, lisez correctement X-Forwarded-Proto ; dans Nginx, utilisez une URL absolue https:// ou la variable $scheme (à condition que le proxy ait correctement défini le scheme) ; déployez HSTS
Après modification de la redirection 301, le navigateur redirige toujours vers l'ancienne adresseLe navigateur met en cache à long terme la règle de redirection permanente 301, l'actualisation F5 est inefficacePendant la phase de test, utilisez la redirection temporaire 302 pour confirmer qu'elle est correcte puis passez à 301 ; effacez le cache du navigateur (Chrome : Paramètres → Confidentialité → Effacer les données de navigation → Images et fichiers en cache) ; utilisez l'option Disable cache des DevTools
Perte des données de formulaire après redirection de requête POSTUtilisation d'une redirection 301 ou 302, le navigateur transforme automatiquement POST en GET, le corps de requête est abandonnéPour les requêtes hors GET telles que POST/PUT/DELETE, utilisez plutôt la redirection 307 (temporaire) ou 308 (permanente), conservez strictement la méthode et le corps de la requête
Apparition de caractères doublement encodés tels que %2520 dans l'URL après redirectionLes paramètres URL ont déjà été encodés une fois, le serveur les encode une deuxième fois lors de la redirectionVérifiez la logique de redirection, assurez-vous que l'URL n'est encodée qu'une seule fois ; dans Nginx, utilisez $request_uri (URI d'origine, non décodée) plutôt que $uri (décodée)
Erreur CORS après redirection inter-domaine de requête AJAX/fetchLe serveur cible de la redirection inter-domaine n'a pas configuré les en-têtes de réponse CORS (Access-Control-Allow-Origin, etc.)Assurez-vous que chaque serveur de la chaîne de redirection a correctement configuré les en-têtes CORS ; ou évitez d'utiliser des redirections inter-domaines dans les requêtes AJAX, laissez plutôt le frontend obtenir l'URL cible puis faire la requête directement

Troubleshooting