Comment auditer les redirections après la migration d'un site web
Après une migration, chaque ancienne URL doit atteindre sa nouvelle page en une seule redirection permanente, et cette page doit répondre 200. Collez vos anciennes URL dans le vérificateur de redirections en masse : chaque ligne liste chaque saut avec son code de statut et l'URL finale, et signale les boucles, les longues chaînes, les retours de HTTPS vers HTTP et les pages qui se terminent sur une erreur.
Vérifier où redirige une liste d'URL →
Les vérifier en masse
- Exportez les anciennes URL : depuis votre ancien sitemap, les principales pages d'entrée de vos statistiques, ou les liens des emails et des publicités que vous avez déjà envoyés.
- Ouvrez le vérificateur de redirections en masse et collez-les, une par ligne : jusqu'à 100 par passage, ou 500 après une connexion Google gratuite.
- Cliquez sur Check redirects (vérifier les redirections). Chaque URL est demandée une fois et ses redirections sont suivies, jusqu'à dix sauts.
- Lisez chaque ligne : OK, Redirects, Broken (la page finale répond 4xx ou 5xx), Loop, Too many hops ou No answer.
- Filtrez sur Broken et les longues chaînes, et téléchargez le CSV.
Le faire à la main
Une ligne par URL : sauts, statut final et point d'arrivée.
printf "http://stripe.com/docs\nhttps://docs.github.com/en/github\nhttp://python.org\nhttps://github.com/nope-1109-zz\n" > old-urls.txt
while read -r u; do
curl -s -o /dev/null -m 10 -L -w "$u,%{num_redirects},%{http_code},%{url_effective}\n" "$u"
done < old-urls.txt
# http://stripe.com/docs,2,200,https://docs.stripe.com/
# https://docs.github.com/en/github,1,200,https://docs.github.com/en
# http://python.org,1,200,https://www.python.org/
# https://github.com/nope-1109-zz,0,404,https://github.com/nope-1109-zz
Chaque saut d'une URL, avec son code de statut :
curl -sL -m 15 -o /dev/null -D - http://stripe.com/docs | grep -iE '^(HTTP|location)'
# HTTP/1.1 301 Moved Permanently
# Location: https://stripe.com/docs
# HTTP/2 301
# location: https://docs.stripe.com
# HTTP/2 200
Nous avons lancé ces commandes le 9 novembre 2026. L'ancienne URL de la documentation de Stripe fait deux sauts permanents : de http à https, puis le déplacement vers son sous-domaine de documentation. C'est acceptable pour une URL ; si votre propre migration ajoute un saut en plus d'une redirection http vers https existante, faites plutôt pointer l'ancienne URL directement vers la page finale.
Utilisez GET, comme ci-dessus, plutôt que curl -I. Le même jour, curl -sIL https://aka.ms/admin (requêtes HEAD) s'est terminé sur un 500, alors que la même chaîne en GET s'est terminée sur un 200. Certains serveurs répondent différemment à HEAD.
Ce qu'il faut corriger
- Un 404 à l'arrivée. L'ancienne URL n'a pas de correspondance. Ajoutez une redirection vers la nouvelle page la plus proche, pas une redirection globale vers la page d'accueil.
- Un 302 ou un 307 là où vous vouliez du permanent. La RFC 9110, section 15.4 définit 301 et 308 comme permanents et 302 et 307 comme temporaires, cas où "the client ought to continue using the original target URI for future requests." (le client devrait continuer à utiliser l'URI cible d'origine pour les requêtes futures). Utilisez 301, ou 308 si la méthode de la requête ne doit pas changer.
- Les chaînes. Les anciennes redirections des migrations précédentes s'accumulent. Faites pointer chaque ancienne URL directement vers sa destination finale.
- Les boucles. Une règle qui renvoie une URL vers une autre déjà visitée. Les navigateurs abandonnent avec une erreur.
- De HTTPS vers HTTP. Un saut qui redescend en http simple, en général une règle codée en dur de l'ancien site.
Pour les seules pages d'accueil de nombreux domaines, utilisez le vérificateur de statut de sites en masse ; pour les versions http, https, www et sans www d'un domaine, le vérificateur de redirection WWW.
Étape suivante : vérifier la liste à laquelle vous annoncerez le nouveau site
Une annonce de migration part à toute votre liste, y compris aux adresses mortes depuis le dernier gros envoi. Importez-la sur /verify pour vérifier chaque boîte sans rien envoyer. Les 100 premières vérifications sont gratuites avec une connexion Google, sans carte.
Pro, 39 $ par mois : vérification d'emails illimitée.* Jamais décomptée, jamais coupée. Voir les tarifs.
*Usage raisonnable : les 100 000 premières vérifications du mois à pleine vitesse, puis plus lentement, jamais coupées.
À lire aussi : vérifier si une liste de sites web est en ligne, les raccourcisseurs d'URL nuisent-ils à la délivrabilité des emails ?
Questions fréquentes
Comment vérifier les redirections d'une liste d'URL ?
Collez les URL dans le vérificateur de redirections en masse, une par ligne. Il suit les redirections de chacune jusqu'à dix sauts et affiche chaque code de statut, l'URL finale et si elle s'est terminée sur une erreur, avec un CSV.
Une migration doit-elle utiliser des redirections 301 ou 302 ?
Des redirections permanentes : 301, ou 308 si la méthode de la requête ne doit pas changer. La RFC 9110 définit 302 et 307 comme temporaires, ce qui signifie que le client devrait continuer à utiliser l'URL d'origine.
Pourquoi curl affiche-t-il un résultat différent de mon navigateur ?
Les sites peuvent répondre différemment selon le pays, l'appareil, les cookies ou la protection anti-bots, et certains redirigent en JavaScript ou par meta refresh, ce que curl et le vérificateur de redirections ne suivent pas. Ouvrez l'URL dans un navigateur pour confirmer.
Combien de sauts de redirection, c'est trop ?
Le vérificateur de redirections en masse signale comme longues les chaînes de plus de trois sauts et s'arrête à dix. Après une migration, chaque ancienne URL ne devrait en nécessiter qu'un.
Vérifiez vos e-mails pour 39,00 USD/mois, sans coupure
Vérification SMTP réelle de la boîte aux lettres. Sans crédits ni frais par e-mail.
Commencer