Utilisez le Vérificateur de Redirections pour suivre une URL publique à travers ses redirections HTTP et examiner la réponse obtenue à la fin. Le rapport présente les adresses observées, les codes de statut et les destinations de redirection. Comparez ces éléments à la destination prévue du lien : une chaîne terminée peut aboutir à la mauvaise page, tandis qu'une vérification incomplète ne confirme aucune destination finale.
Saisissez l'URL à vérifier
Commencez par l'adresse réellement utilisée, avec son chemin et les paramètres de requête pertinents. Vérifier uniquement la page d'accueil ne révèle pas ce qui arrive à un ancien lien produit. Par exemple, http://example.com/products/old-mug/ illustre une adresse de départ ; remplacez-la par l'URL publique à examiner.
Avant de lancer la vérification, définissez la destination attendue et le caractère permanent ou temporaire du déplacement. Après un changement d'URL produit, il peut s'agir du même produit à sa nouvelle adresse. Pendant une interruption temporaire du service, l'adresse d'origine peut devoir rester le point d'entrée à long terme.
Saisissez une URL HTTP ou HTTPS complète et lancez la vérification. Screpy effectue une requête GET et suit les redirections HTTP prises en charge. Il ne découvre pas toutes les variantes de votre domaine, n'utilise pas votre session de navigateur connectée et n'exécute aucun script. Pour comparer différents chemins, protocoles ou noms d'hôte, soumettez chaque URL de départ séparément.
Lisez la chaîne de redirections et la réponse finale
Lisez les lignes de réponse dans l'ordre. Chaque ligne indique l'URL demandée, son statut HTTP et une destination Location lorsqu'une redirection prise en charge en fournit une. Les valeurs Location sont affichées sous forme d'adresses résolues. Si une réponse indique /products/new-mug/, le rapport résout ce chemin à partir de l'URL qui l'a envoyé ; l'adresse affichée peut donc différer du texte littéral de l'en-tête.
Cette chaîne illustrative comporte trois réponses et deux redirections. Il s'agit d'un exemple, pas de l'analyse d'un site réel :
http://example.com/products/old-mug/ 301 → https://example.com/products/old-mug/
https://example.com/products/old-mug/ 301 → https://example.com/products/new-mug/
https://example.com/products/new-mug/ 200
Le premier statut est ici 301, le statut final 200 et l'URL finale la nouvelle adresse du produit. La dernière ligne 200 est une réponse, pas une redirection supplémentaire. Lors d'une vérification terminée, le nombre de redirections décrit les transitions entre les réponses observées. Si la vérification s'arrête avant la fin, interprétez ce nombre avec les lignes conservées, et non comme la longueur totale de la chaîne.
Interprétez la couleur du résultat avec ces détails :
- Vert : une réponse réussie directe, sans redirection suivie. C'est utile lorsque l'URL doit déjà être la destination.
- Jaune : une redirection, même si elle se termine par une réponse réussie, ou une autre réponse à examiner. Une redirection jaune n'est pas automatiquement un lien cassé.
- Rouge : une erreur HTTP finale, telle que 404 ou 500. Lisez la destination et le code avant de choisir une correction.
- Gris : la vérification n'a pas pu établir de réponse finale. Les lignes conservées constituent des éléments partiels.
Ces couleurs décrivent des catégories de réponse. Elles ne notent pas le contenu, ne prouvent pas l'indexation et ne déterminent pas si une redirection correspond à votre intention.
Comprenez les codes 301, 302, 303, 307 et 308
Définissez le comportement attendu avant de choisir le statut. Voici les cinq codes de redirection suivis par cet outil :
| Code | Signification HTTP | Point à examiner |
|---|---|---|
| 301 | Déplacement permanent | Les futurs liens doivent-ils utiliser la nouvelle adresse ? |
| 302 | Déplacement temporaire | L'adresse d'origine doit-elle rester utilisée ? |
| 303 | Consulter une autre ressource pour obtenir la réponse | Est-ce une ressource de suivi délibérée plutôt qu'un remplacement permanent ? |
| 307 | Redirection temporaire conservant la méthode de requête | Une redirection temporaire sans changement de méthode est-elle voulue ? |
| 308 | Redirection permanente conservant la méthode de requête | Un déplacement permanent sans changement de méthode est-il voulu ? |
Ces distinctions suivent la sémantique des redirections HTTP du RFC 9110. Une vérification limitée à GET ne confirme pas ce qui arrive à une requête POST envoyée ou à son corps. Voir ici 307 ou 308 ne teste pas un parcours d'envoi de formulaire.
Les consignes de Google sur les redirections recommandent des redirections permanentes côté serveur pour les changements permanents d'URL. Google les utilise comme signal favorisant la destination comme URL canonique ; les redirections temporaires ont un autre objectif. Cela ne fait pas de chaque 302 une erreur SEO et ne garantit pas qu'un 301 modifie immédiatement les résultats de recherche.
Si un déplacement permanent renvoie de façon inattendue un code temporaire, examinez la règle responsable. Pour un détour temporaire volontaire, ne changez pas le statut uniquement pour obtenir un résultat d'apparence plus favorable.
Vérifiez que la destination est la bonne page
Une chaîne terminée indique où cette requête a abouti. Elle ne prouve pas que la page soit un remplacement approprié. L'outil lit les statuts de réponse et les destinations de redirection sans examiner le contenu de la page finale.
Comparez l'URL finale à la destination définie avant la vérification. Examinez le nom d'hôte, le chemin et les paramètres pertinents. Un ancien lien produit qui termine sur la page d'accueil avec 200 peut toujours manquer l'objectif du visiteur. Ouvrez la destination et déterminez si elle contient le produit, l'article ou un autre remplacement pertinent. S'il n'existe aucun remplacement adapté, n'en inventez pas uniquement pour retirer une erreur du rapport.
Examinez aussi une alerte de passage de HTTPS à HTTP. Déterminez si la règle pointe vers l'adresse sécurisée prévue et corrigez un passage involontaire. L'alerte décrit cette transition ; elle ne constitue pas un audit de sécurité de la destination.
Pour une page destinée à apparaître dans les recherches, utilisez séparément le Vérificateur de Balises Canonical pour examiner l'URL préférée déclarée. Une redirection réussie ne confirme ni cette déclaration, ni l'absence de noindex, ni la décision d'indexation de Google. Une chaîne HTTP correcte et une déclaration correcte sur la page sont deux observations différentes.
Diagnostiquez une chaîne incomplète
Lorsque l'URL ou le statut final est indisponible, commencez par la dernière réponse réellement enregistrée. Une valeur Location indique où cette réponse voulait envoyer la requête. Elle ne prouve pas que l'adresse suivante ait été atteinte ou ait répondu avec succès. Un résultat indisponible diffère également d'une erreur HTTP observée : un délai dépassé n'a pas de code final confirmé, alors qu'une réponse reçue peut explicitement renvoyer 404 ou 403.
Utilisez les lignes conservées pour cibler l'enquête :
- Adresses répétées : la séquence illustrative
A → B → Aest une boucle. Examinez les règles renvoyant vers une URL déjà visitée, comme des règles de nom d'hôte ou de chemin contradictoires. - Longue séquence sans répétition : l'outil suit au maximum cinq redirections. Atteindre ce plafond ne prouve pas une boucle et ne révèle pas la suite de la chaîne. Examinez séparément la dernière destination enregistrée.
- Statut de redirection sans destination utilisable : vérifiez que la réponse fournit un Location valide. Une cible absente ou invalide ne peut pas être considérée comme un déplacement terminé.
- Absence de réponse suivante : des problèmes d'accès public, de résolution de nom, de connexion ou de connexion sécurisée peuvent empêcher la vérification. Toute la chaîne dispose de huit secondes, et non chaque étape. Les limites des en-têtes de réponse ainsi que les cibles privées ou non prises en charge peuvent aussi arrêter la vérification.
Si la destination renvoie une restriction d'accès ou une limite de requêtes, examinez cette condition avant de supposer que le contenu a été supprimé. Cette requête peut recevoir une réponse différente de celle de votre navigateur connecté. Les redirections JavaScript, meta refresh et le comportement du navigateur sont hors périmètre ; le résultat HTTP ne peut donc pas expliquer toutes les navigations visibles à l'écran.
Corrigez la cause et revérifiez la même URL
Téléchargez le rapport JSON avant de modifier une règle. Conservez avec lui l'URL soumise et la destination attendue pour que la personne chargée de la correction distingue le comportement observé du comportement souhaité. Cet outil exporte le rapport en JSON ; il ne fournit pas de CSV filtré et ne modifie pas les redirections à votre place.
- Repérez la réponse où l'adresse ou le statut s'écarte pour la première fois de votre intention. Trouvez le réglage qui produit cette réponse plutôt que de modifier des métadonnées sans rapport.
- Corrigez une destination, un statut, une boucle ou un passage à HTTP involontaire. Supprimez les étapes intermédiaires inutiles lorsque vous maîtrisez les règles, tout en conservant le routage ou le suivi ayant un objectif délibéré. Faites pointer les liens internes directement vers la destination prévue lorsque cela répond au besoin du visiteur.
- Relancez exactement la même URL de départ dès que la réponse publique corrigée est disponible. Comparez la séquence, les codes initial et final, l'adresse finale et les éléments toujours indisponibles au rapport enregistré.
- Vérifiez séparément les variantes pertinentes, par exemple un ancien chemin ou un autre nom d'hôte. Une adresse réparée ne confirme pas toutes les correspondances d'une migration.
Utilisez le Vérificateur HTTP par Lots pour examiner une liste. Il accepte jusqu'à 50 URL et permet l'export CSV filtré. Gardez cet outil pour lire une seule chaîne en détail. Une revérification réussie confirme la réponse observée maintenant, pas un comportement identique pour un futur visiteur, navigateur ou robot de recherche.