Redirect Checker

Trace une chaîne de redirections hop par hop, compare HTTP, HTTPS, www et non www, traite tes URL de migration en lot, puis lis le canonical final et les signaux robots.

Ce redirect checker te montre où une URL atterrit vraiment, pas où tu crois qu'elle atterrit. Colle une adresse et il suit la chaîne hop par hop, signale si chaque étape est un 301 ou 308 permanent ou un 302 ou 307 temporaire, puis échantillonne les variantes habituelles de protocole et de hostname pour que HTTP, HTTPS, www et non www soient comparés à ta politique d'hôte préférée en une seule passe. Ajoute un petit lot d'URL de migration et il les trace aussi. Quand la chaîne atteint un vrai document, il lit les signaux de la page finale, le canonical tag et la ligne robots, et te prévient quand ils contredisent la destination choisie. Il note l'audit, nomme les boucles et hops inutiles, et te donne un rapport copiable.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Audit de chaîne de redirections et flux canonical

Colle une URL, et regarde où elle atterrit vraiment. L'outil trace la chaîne de redirections, va titiller les variantes de protocole et de hostname, fait tourner un petit lot d'URL de migration qui t'intéressent, puis lit les signaux de la page finale. Et ces signaux, franchement, ils devraient coller avec l'endroit où tu veux envoyer tes visiteurs et les crawlers. Souvent, ils ne collent pas.

URL principale à tracer

URL personnalisées

URL de migration ou variantes à comparer (optionnel)

Les chaînes sont échantillonnées côté serveur avec des requêtes HEAD. Attention quand même : certaines applis répondent à une requête HEAD autrement qu'à un GET de navigateur, donc si un truc te paraît bizarre, va le revérifier sur la vraie stack.

Pourquoi un redirect checker a besoin de plus d'une seule URL

Une redirection, c'est souvent le bon réflexe. Elle accompagne le visiteur d'une ancienne adresse vers une nouvelle. Elle garde les vieux favoris en vie après une migration, pousse le trafic vers HTTPS, et permet à un site de choisir un seul hostname canonical pour ne pas disperser ses signaux sur une poignée de variantes publiques. Les ennuis commencent quand le chemin devient flou. Une vieille règle pointe vers une autre vieille règle. HTTP fait sa vie pendant que HTTPS fait autre chose. Le www atterrit ailleurs. Ou, le pire de tout, la page finale déclare une URL canonical qui contredit carrément l'endroit où la chaîne t'a déposé.

Du coup, ce checker ne s'arrête pas à l'URL principale. Il trace la chaîne que tu lui as donnée, va tester les variantes habituelles de protocole et de hostname, avale un petit lot d'URL de migration, et lit les signaux de la page finale dès qu'il y a un vrai document accessible au bout. Honnêtement, c'est assez proche de ce à quoi ressemble le boulot dans la vraie vie : le changement de permalink WordPress, le déménagement de domaine, le nettoyage HTTPS, l'audit à 23h juste avant un lancement.

Comment lire une chaîne de redirections

Lis-la ligne par ligne. Chaque ligne, c'est une réponse échantillonnée. Une redirection permanente (301 ou 308) dit normalement « ce déplacement est définitif ». Une redirection temporaire (302 ou 307) peut être parfaitement OK pour du routage de courte durée, une session, un rebond de login. Mais elle mérite un œil méfiant quand une vieille URL publique a clairement déménagé pour de bon et que quelqu'un l'a laissée sur un code temporaire quand même. La dernière ligne ? C'est là que ça compte. Ça devrait être soit le vrai document de destination, soit une erreur que tu voulais vraiment servir.

Pars sur le chemin le plus court qui fait quand même ce que tu voulais.
Fais atterrir chaque destination finale sur le protocole et le hostname canonical que tu as choisis, sans exception.
Corrige les liens internes, les URL du sitemap, les liens marketing. Ne t'appuie pas sur les redirections à vie, c'est une béquille.
Traque les boucles et les hops répétés. Et ces redirections temporaires qui font discrètement un boulot permanent. Et tout ce qui finit en 4xx ou 5xx.
Reteste les règles importantes dès que tu touches au CDN, au cache, à un plugin de sécurité, à la config du serveur web.

Redirections, canonical tags et signaux de recherche

Ces deux là, on les confond tout le temps. Une redirection dit où la requête part maintenant. Un canonical tag indique aux moteurs de recherche sous quelle URL la page préférerait être vue quand des doublons ou des variantes traînent. Deux jobs différents. Un site en bonne santé, lui, les fait simplement s'accorder. Imagine qu'une vieille page redirige vers une nouvelle URL, et qu'ensuite cette nouvelle page se canonicalise vers un endroit totalement différent. Là, tu viens de servir une contradiction à Google, et ça mérite un coup d'œil. Même histoire pour les entrées de sitemap ou les liens internes qui visent encore des URL rebondissant via une redirection à chaque crawl.

Pour le SEO, tu veux que tes redirections soient ennuyeuses. L'ennui, c'est le but ici. La destination doit être claire, vivante, indexable si elle est censée ranker, liée directement depuis le site quand c'est possible. Et des redirections propres ne masquent pas un contenu pauvre, ça n'a jamais marché comme ça. Elles enlèvent juste la friction pour que les gens et les crawlers atteignent les trucs que tu as déjà sués à produire.

Une checklist de migration concrète

Prends un échantillon d'anciennes URL pour chaque template ou type de contenu qui compte.
Assure-toi que les plus importantes atterrissent sur leur nouveau foyer utile le plus proche.
Compare le comportement de HTTP, HTTPS, www et non www face à ta politique d'hôte préférée.
Vérifie le canonical tag et le signal robots sur la page où tu atterris réellement.
Mets à jour les liens internes et les sitemaps, mais seulement une fois que les règles de redirection ont arrêté de bouger.

Les erreurs de redirection classiques

La plus grosse ? Ne pas rediriger du tout alors qu'une URL ramène encore du vrai trafic. Les gens suppriment juste la page et passent à autre chose. Juste derrière : tout balancer vers la homepage (fainéant, et Google le remarque), laisser les règles historiques s'empiler sur trois migrations jusqu'à ce que plus personne ne se souvienne de leur raison d'être, coller un code temporaire sur un déplacement permanent sans qu'aucune raison n'ait jamais été écrite. Et on oublie que les query strings, un trailing slash ou un hôte alternatif peuvent discrètement emprunter un chemin totalement différent. Un petit lot de vérification attrape beaucoup de ça avant que ça ne devienne le truc que tu expliques dans un postmortem.

Questions fréquentes

Une redirection en deux étapes est-elle toujours mauvaise ?

Non, pas toujours. Parfois une règle de edge, un changement de protocole ou un truc dans l'appli rend ça inévitable pendant un moment. N'empêche, tu veux savoir que c'est là. Surtout sur tes URL à fort trafic et sur n'importe quel chemin de migration que tu pourrais vraiment aplatir en t'y posant dix minutes.

Est-ce que chaque 404 doit rediriger quelque part ?

Non. S'il n'y a pas de remplacement proche, un 404 honnête (ou un 410) vaut mieux que de pousser quelqu'un vers une page qui n'a rien à voir avec ce qu'il cherchait. Redirige quand le nouvel endroit répond vraiment à l'intention de départ. Sinon, laisse le 404 faire son job et passe à autre chose.

Pourquoi vérifier le canonical après les redirections ?

Parce que la page où tu finis par atterrir peut quand même nommer une URL préférée qui se bat avec l'endroit où la redirection t'a envoyé. Quand tu es à fond dans le SEO technique, tu veux que les deux signaux racontent la même histoire, pas qu'ils se disputent.

Dois-je utiliser une redirection 301 ou 302 ?

Utilise un 301 pour les déplacements permanents. C'est celui qui dit aux moteurs de recherche de transmettre le ranking à la nouvelle URL. Garde le 302 pour ce qui est vraiment temporaire, quand tu veux que l'originale conserve sa valeur parce qu'elle va revenir.