Vérifier une redirection 301 : suivez chaque chaîne de redirections

Un vérificateur de redirection montre ce qui se passe vraiment entre le clic sur un lien et l’arrivée sur une page. Chaque URL saisie est demandée depuis le serveur de Marqly avec les redirections automatiques désactivées : chaque réponse est donc enregistrée séparément, avec son code d’état, l’en-tête Location vers lequel elle pointe, son temps de réponse et les en-têtes qui comptent pour le SEO. L’outil suit ensuite cette Location et recommence, jusqu’à 10 redirections, la même limite que celle appliquée par défaut par les robots de Google. Vous obtenez la chaîne de redirections complète, l’URL et le statut finaux, et des alertes en langage clair sur les boucles, les redirections temporaires, les étapes lentes, les paramètres de suivi perdus et les chaînes à raccourcir.

Comment vérifier une redirection

1. Collez une URL dans le champ. Pour une vérification en lot, collez jusqu’à 10 URL, une par ligne.
2. Choisissez un user-agent si besoin. Par défaut, l’outil s’identifie comme vérificateur Marqly ; vous pouvez aussi envoyer le user-agent de Chrome, de Safari sur iPhone, de Googlebot smartphone ou de Googlebot ordinateur pour repérer les règles qui traitent différemment navigateurs, téléphones et robots.
3. Cochez Vérifier aussi les versions http/https et avec/sans www pour tester d’un coup les quatre formes d’une même adresse. C’est le moyen le plus rapide de confirmer qu’un site a un seul nom d’hôte canonique et que chaque variante l’atteint en une seule étape.
4. Cliquez sur Vérifier les redirections. Chaque URL obtient sa propre fiche avec le verdict, les conseils et la chaîne étape par étape.
5. Utilisez Copier les résultats pour un rapport texte, Télécharger le CSV pour un tableur avec une ligne par étape, ou Copier le lien de partage pour envoyer un lien qui relance la même vérification.

Comment lire les résultats

Chaque fiche commence par le code d’état final, l’URL saisie, le nombre de redirections, le temps total et l’URL finale. En dessous, des conseils signalent ce qui mérite votre attention : des erreurs (boucles, chaînes au-delà de la limite, chaîne qui se termine sur une 404), des avertissements (redirections temporaires, meta refresh, passage de HTTPS à HTTP, paramètres de requête perdus, X-Robots-Tag: noindex sur la page finale) et des remarques neutres (ajout ou retrait de la barre oblique finale ou du www, changement de domaine, étapes lentes).

Le tableau de la chaîne liste chaque requête dans l’ordre. Statut est le code d’état HTTP renvoyé par le serveur. URL est l’adresse demandée et, en dessous, la destination vers laquelle cette étape envoie le client, déjà convertie en adresse absolue quand le serveur a envoyé une Locationrelative. Temps est la durée nécessaire au serveur pour renvoyer les en-têtes de cette étape. Ouvrez En-têtes sur n’importe quelle ligne pour voir Location,Cache-Control, Content-Type, X-Robots-Tag, Link (où une URL canonique peut être déclarée), Strict-Transport-Security, X-Redirect-By (WordPress et certaines extensions s’y nomment) et Server. Les valeurs des cookies ne sont jamais affichées, seulement leur nombre.

301, 302, 307 ou 308 : que signifie chaque code de redirection ?

HTTP définit les codes d’état de redirection dans la RFC 9110, section 15.4. Deux questions les distinguent : le déplacement est-il permanent, et le client peut-il changer de méthode (par exemple transformer l’envoi d’un formulaire en POST en requête GET) en suivant la redirection ? Ladocumentation de Google sur les codes d’état HTTPexplique comment ses robots et son indexation traitent chacun d’eux.

Pour des pages ordinaires, utilisez une 301 quand le contenu a déménagé pour de bon : slug renommé, articles fusionnés, migration de domaine, passage au HTTPS. Utilisez une 302 ou une307 quand l’URL d’origine reviendra : page de maintenance, campagne courte ou test. Choisissez une308 quand la méthode compte, par exemple pour un point d’accès d’API ou un formulaire qui reçoit des requêtes POST : la RFC 9110 autorise les clients à transformer un POST redirigé en GET avec une 301 ou une 302, mais l’interdit avec une 307 ou une 308.

Meta refresh et redirections JavaScript

Le guide de Google sur les redirectionsrecommande une redirection permanente côté serveur chaque fois que c’est possible. Il traite un meta refresh instantané comme une redirection permanente et un meta refresh différé comme une redirection temporaire, et ne conseille les redirections JavaScript que si ni les redirections côté serveur ni le meta refresh ne sont possibles, car le rendu peut échouer. Ce vérificateur suit les balises meta refresh et l’en-têteRefresh et les signale, mais il n’exécute pas JavaScript.

Qu’est-ce qu’une chaîne de redirections, et pourquoi pose-t-elle problème ?

Une chaîne de redirections est un parcours qui compte plus d’une étape : http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/. Les chaînes naissent rarement exprès. Elles s’accumulent quand un site passe au HTTPS, choisit une préférence www, change de CMS, renomme des rubriques et redirige d’anciennes redirections au lieu de les réécrire. Chaque couche fonctionne seule ; ensemble, elles s’additionnent.

• Vitesse. Chaque étape est une requête complète de plus avant que la page ne commence à se charger, et une étape vers un nouveau nom d’hôte ajoute une résolution DNS et une négociation TLS. La colonne du temps montre ce que coûte chaque étape.
• Exploration. Google indique que ses robots suivent par défaut jusqu’à 10 redirections, et son rapport d’indexation des pages classe une chaîne de redirections trop longue, une boucle de redirection et une URL incorrecte ou vide dans la chaîne parmi les erreurs de redirection. Le guide de Google sur le déplacement de siteconseille de rediriger directement vers la destination finale, en précisant qu’enchaîner les redirections augmente la latence et que tous les user-agents et navigateurs ne prennent pas en charge les longues chaînes.
• Autres clients. La RFC 9110 rappelle qu’une ancienne spécification HTTP recommandait un maximum de cinq redirections et que certains clients appliquent peut-être encore une limite fixe de ce type : une chaîne que Googlebot tolère peut donc échouer avec d’autres logiciels.
• Fragilité et perte de données. Chaque étape est une règle de plus qui peut être modifiée, supprimée ou masquée par une autre. Une étape qui reconstruit l’URL peut perdre silencieusement la chaîne de requête : c’est ainsi que des balises UTM disparaissent avant même que l’outil d’analyse ne les voie. Le vérificateur vous avertit quand un paramètre de l’URL d’origine manque dans l’URL finale.

Comment corriger une chaîne de redirections

1. Trouvez l’URL finale. Passez l’ancienne URL dans le vérificateur et copiez la dernière URL de la chaîne.
2. Faites pointer la première redirection vers l’URL finale. Si A redirige vers B et B vers C, modifiez la règle de A pour qu’elle aille directement vers C, et conservez B → C pour ceux qui ont encore B. Dans une table de redirections ou une extension, cherchez les règles dont la cible est elle-même la source d’une autre règle.
3. Combinez les règles de protocole et de nom d’hôte. La chaîne la plus courante est http → https suivie de sans www → www. Écrivez une seule règle qui envoie chaque variante vers la forme canonique en une étape, comme dans cet exemple nginx :

# Une seule étape depuis chaque variante vers https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # lignes ssl_certificate omises
    return 301 https://www.example.com$request_uri;
}

4. Mettez à jour les liens à la source. Faites pointer les liens internes, les balises canoniques, les annotations hreflang et les sitemaps XML vers les URL finales ; le guide de Google sur le déplacement de site demande lui aussi de mettre à jour les liens internes vers les nouvelles URL. Les redirections doivent rattraper les anciens liens venus d’ailleurs, pas porter votre propre navigation.
5. Conservez les redirections. Google conseille de garder les redirections aussi longtemps que possible, en général au moins un an. Raccourcir une chaîne, c’est changer sa cible, pas supprimer les anciennes règles.
6. Testez à nouveau. Relancez les mêmes URL, idéalement avec l’option des variantes cochée, et vérifiez que chacune atteint une page 200 en une seule étape.

Corriger une boucle de redirection

Une boucle est une chaîne qui revient vers une URL déjà visitée et ne se termine donc jamais ; les navigateurs affichent alors une erreur de redirections trop nombreuses. Les causes habituelles sont deux couches qui ne sont pas d’accord : un CDN qui parle au serveur d’origine en HTTP alors que l’origine impose HTTPS, une règle de barre oblique finale dans le serveur web qui s’oppose à la règle inverse dans l’application, ou des règles www définies à la fois dans une redirection au niveau DNS et sur le site. Regardez l’étape où l’URL revient en arrière : ses en-têtes Server et X-Redirect-By indiquent souvent quelle couche l’a envoyée. Certaines boucles ne se produisent que sans cookies (redirections de consentement ou de connexion) et ne touchent pas les visiteurs qui les ont déjà ; le vérificateur n’envoie aucun cookie, il fait donc aussi apparaître ces cas.

Vérifier des redirections en lot

Collez jusqu’à 10 URL, une par ligne, pour les vérifier en une seule fois ; les doublons sont supprimés et chaque URL obtient son propre résultat. L’export CSV contient une ligne par étape, avec l’URL saisie répétée : vous pouvez filtrer par statut, trier par nombre d’étapes ou transmettre le fichier à la personne qui gère les règles de redirection. Pour une liste d’anciens favoris, exportez-les d’abord depuis votre navigateur ; notre guide pourexporter ses favoris Chrome explique comment faire. Pour un site entier, utilisez un robot d’exploration ou vos journaux serveur pour trouver les URL redirigées, puis contrôlez ici les plus importantes avec le user-agent Googlebot.

HTTPS, www et barre oblique finale

La plupart des sites devraient répondre sur une seule combinaison de protocole et de nom d’hôte, toutes les autres formes redirigeant vers elle de façon permanente et en une étape. L’option des variantes vérifiehttp://example.com, https://example.com, http://www.example.com ethttps://www.example.com avec le même chemin, et indique si les quatre aboutissent à la même URL et combien d’étapes chacune nécessite. Les conseils signalent un passage au HTTPS qui arrive tard dans la chaîne, une chaîne qui alterne plus d’une fois entre www et sans www, et les étapes qui ne font qu’ajouter ou retirer une barre oblique finale ou changer la casse, faciles à intégrer à la première redirection.

Pourquoi les résultats peuvent différer de votre navigateur

Si votre navigateur arrive ailleurs, c’est généralement qu’il se souvient de quelque chose. La RFC 9110 autorise la mise en cache d’une 301 : un navigateur peut donc sauter une ancienne redirection, ou continuer à suivre une redirection que vous avez déjà supprimée. Dès qu’un navigateur a vu l’en-tête HSTS d’un site (ou si le site figure sur la liste de préchargement HSTS), il transforme http:// en https:// en interne avant qu’une requête ne quitte votre machine. Les cookies, votre langue et votre localisation peuvent aussi déclencher leurs propres redirections. Le vérificateur repart de zéro à chaque fois et rapporte ce que le serveur envoie : c’est la vue qui compte pour les robots d’exploration et les nouveaux visiteurs.

Comment fonctionne le vérificateur

Chaque étape est une requête GET envoyée depuis le serveur de Marqly sur Cloudflare avec les redirections en mode manuel : rien n’est suivi avant que le vérificateur ne l’ait enregistré. Chaque nom d’hôte est résolu et doit pointer vers une adresse publique ; les réseaux privés, localhost et les adresses de métadonnées cloud sont refusés, y compris quand une redirection pointe vers l’un d’eux en cours de chaîne. Chaque étape a un délai maximal de 6 secondes, une chaîne entière s’arrête après 20 secondes ou 10 redirections, et le contenu des pages est ignoré, sauf les 64 premiers Ko d’une page HTML finale, analysés à la recherche d’un meta refresh. Rien n’est conservé : les résultats n’existent que dans l’onglet de votre navigateur.

Si vous créez des liens de campagne, notre générateur UTM les construit et ce vérificateur confirme que les paramètres survivent à chaque étape. Si vous travaillez dans le marketing avec beaucoup de liens, la page Marqly pour le marketing montre comment réunir pages de destination, éléments de campagne et lectures de référence au même endroit. Et pour les développeurs qui veulent garder documentation, tickets et références sous la main, il y aMarqly pour les développeurs.