HTTP Status Checker

Un code de statut HTTP est un nombre à trois chiffres qu'un serveur retourne avec chaque réponse pour dire au client ce qui s'est passé avec la requête. 200 signifie que la page s'est chargée correctement. 301 signifie que la page a bougé de façon permanente. 404 signifie que la page n'a pas été trouvée. 500 signifie que le serveur s'est écrasé. Les codes font partie de la spécification HTTP (RFC 9110) et chaque navigateur, crawler et client API les utilise pour décider de la marche à suivre. Il existe 63 codes de statut définis répartis dans cinq classes, mais dans le travail SEO réel, vous voyez approximativement dix codes régulièrement : 200, 301, 302, 307, 308, 403, 404, 410, 500 et 503. Cet outil de vérification des codes de statut HTTP rapporte le code exact retourné pour chaque URL que vous soumettez afin que vous puissiez corriger celles qui ne devraient pas y être.

Les cinq classes sont 1xx, 2xx, 3xx, 4xx et 5xx. Les codes 1xx (100-103) sont informatifs et indiquent au client que la requête a été reçue et que le traitement se poursuit. Vous ne les voyez presque jamais dans les contextes du navigateur ou du SEO. Les codes 2xx (200-226) signifient succès. 200 est le standard OK et le seul que la plupart des sites utilisent. Les codes 3xx (300-308) signifient redirection, indiquant au client de récupérer une URL différente. 301 est permanent, 302 est temporaire, 307 préserve la méthode de requête lors d'une redirection temporaire, et 308 la préserve lors d'une redirection permanente. Les codes 4xx (400-451) signifient que le client a fait une mauvaise requête, avec 404 (non trouvé), 403 (interdit) et 410 (disparu) comme codes les plus courants. Les codes 5xx (500-511) signifient que le serveur a échoué, avec 500 (erreur interne) et 503 (indisponible) comme codes que les SEOs rencontrent le plus souvent.

Un 301 est une redirection permanente qui indique aux moteurs de recherche de mettre à jour leur index et de passer l'équité de lien complète vers la nouvelle URL. Un 302 est une redirection temporaire qui indique aux moteurs de recherche de garder l'ancienne URL indexée car le déplacement n'est pas permanent. Pour le SEO, presque chaque redirection devrait être un 301. Utilisez 302 uniquement pour les cas véritablement temporaires, comme les géo-redirections lors d'un déploiement régional ou les répartitions de trafic des tests A/B. Google a confirmé que les 302 de longue durée sont finalement traités comme des 301, mais la transition peut prendre des semaines, pendant lesquelles les classements peuvent baisser. Si vous avez exécuté une migration et que vos anciennes URLs retournent 302, changez-les en 301 dès maintenant. Cet outil de vérification des redirections affiche le code exact retourné, donc une exécution rapide en masse sur votre liste d'anciennes URLs confirme si votre carte de redirection utilise le bon type.

Un 307 est une redirection temporaire qui préserve la méthode HTTP originale, ce qui signifie qu'une POST reste une POST quand le client suit la redirection. Un 302 permettait historiquement aux clients de changer une POST en GET, ce qui cassait les soumissions de formulaires. 307 a corrigé cela. À des fins de SEO, 307 se comporte comme 302 : temporaire, ne passe pas l'équité de lien complète, conserve l'ancienne URL indexée. Vous verrez des 307 sur les sites qui utilisent des frameworks côté serveur (Next.js, Nuxt, Django) pour les redirections, puisque ces frameworks utilisent par défaut 307 pour des raisons de sécurité. Si un 307 est censé être permanent, changez-le en 308 (l'équivalent permanent) ou en 301. L'outil de vérification des codes de statut des URLs capture le code exact afin que vous puissiez identifier les 307 qui devraient être 308 ou 301 à la place.

Un 404 signifie que le serveur ne peut pas trouver la page en ce moment et que le client ne doit pas supposer quoi que ce soit sur le futur. Un 410 signifie que la page a disparu de façon permanente et ne reviendra jamais. Pour le SEO, 410 est un signal plus fort à Google pour supprimer l'URL de l'index rapidement. Si vous avez intentionnellement supprimé une page (produit discontinué, article de blog supprimé, fonctionnalité retirée) et que vous n'avez aucun remplacement, retournez 410 au lieu de 404. Google désindexe les URLs 410 environ 2 fois plus rapidement que les URLs 404 selon plusieurs recommandations du Search Central. Si la page est véritablement manquante par accident ou temporairement indisponible, 404 est le code correct. Cet outil de vérification des codes 200, 301, 404 rapporte les deux afin que vous puissiez basculer les suppressions intentionnelles de 404 à 410 et nettoyer votre index plus rapidement.

Un code de statut 500 signifie que le serveur a rencontré une erreur interne qu'il n'a pas pu gérer. Les causes courantes incluent un processus d'application écrasé, une défaillance de la connexion à la base de données, une exception non gérée dans le code ou un serveur mal configuré. 500 est générique, ce qui signifie que le corps de la réponse n'a généralement aucune information de diagnostic utile. Pour déboguer, vous devez accéder aux logs du serveur. Pour le SEO, les 500 sont du gaspillage de crawl et un signal de qualité qui nuit aux classements s'ils persistent. Google réessaye les 500 pendant un certain temps, puis supprime l'URL de l'index si l'erreur persiste. Si votre exécution en masse de l'outil de vérification affiche des 500 sur des URLs qui devraient fonctionner, vérifiez vos logs du serveur immédiatement. Un 500 sur une page à fort trafic coûte des revenus et des classements à chaque minute où il reste cassé. Exécutez l'outil de vérification des codes de statut HTTP après chaque déploiement pour attraper les 500 introduits par les changements de code.

Un 503 signifie que le serveur est temporairement indisponible, généralement en raison d'une surcharge, d'une maintenance ou d'une dégradation de service. Contrairement à un 500, qui signale une véritable erreur, un 503 dit « reviens plus tard ». Les 503 correctement configurés incluent un en-tête Retry-After qui indique aux crawlers quand réessayer. Google respecte Retry-After et met en pause le crawling sans supprimer l'URL de l'index, tant que le 503 est résolu en quelques heures. Si les 503 persistent pendant plus de 48 heures, Google commence à les traiter comme des 500 et supprime les URLs. Pour la maintenance programmée, retournez un 503 avec un en-tête Retry-After défini sur le temps d'arrêt prévu. Pour les 503 inattendus trouvés par cet outil de vérification, enquêtez sur la capacité du serveur, la configuration du CDN ou la santé du service en amont.

Collez jusqu'à 50 URLs dans la zone de texte de cet outil de vérification des codes de statut HTTP, une par ligne, avec le protocole complet (https:// ou http://). Choisissez s'il faut suivre les redirections, puis cliquez sur Vérifier les statuts. L'outil récupère chaque URL en parallèle et retourne un tableau avec le code de statut, la chaîne de redirection le cas échéant, l'URL finale après les redirections et le temps de réponse en millisecondes. Pour les listes plus grandes que 50, divisez-les en lots. L'approche en masse est environ 30 fois plus rapide que la vérification de chaque URL une par une dans un navigateur, et elle met en évidence les motifs (chaque URL dans un dossier retournant 404, chaque page de produit chaînant par le biais de deux redirections) que les vérifications d'URL unique manquent. Associez la sortie au sitemap-checker pour confirmer que votre sitemap ne liste que des 200.

Extrayez une liste de chaque URL sur votre site à partir de votre sitemap, votre CMS ou un crawler comme Screaming Frog. Divisez la liste en lots de 50 et exécutez chaque lot dans cet outil de vérification en masse des codes de statut HTTP. Groupez les résultats par classe de codes de statut. Tout 4xx est une page cassée qui a besoin d'une correction ou d'une redirection. Tout 5xx est un problème de serveur qui a besoin d'une enquête. Tout 3xx est soit une redirection fonctionnelle, soit une chaîne qui doit être aplatie. Pour les sites avec moins de 1 000 pages, l'audit complet prend moins d'une heure. Pour les sites plus importants, priorisez les URLs avec des liens externes entrants et les pages qui reçoivent du trafic organique, car ce sont celles qui coûtent une véritable visibilité quand elles sont cassées. Réexécutez mensuellement pour attraper les nouveaux breaks avant qu'ils s'accumulent.

Une chaîne de redirection est une séquence de deux ou plusieurs redirections entre l'URL originale et la destination finale. L'URL A redirige vers l'URL B, qui redirige vers l'URL C, qui retourne finalement 200 à l'URL D. Chaque saut ajoute de la latence (généralement 100-500 ms par redirection) et dilue l'équité de lien. Google a confirmé qu'il suit jusqu'à 10 sauts avant d'abandonner, mais traite chaque saut comme une friction. Les chaînes longues ralentissent à la fois les utilisateurs et les crawlers. Corrigez les chaînes en mettant à jour l'URL originale (URL A) pour pointer directement vers la destination finale (URL D). Cet outil de vérification des redirections affiche la chaîne complète quand Suivre les redirections est défini sur Oui, afin que vous puissiez voir exactement combien de sauts chaque URL traverse et aplati les chaînes plus longues que deux.

Une redirection saine va d'un seul saut, retourne 301 (ou 308 pour les requêtes non-GET), préserve la structure du chemin autant que possible, et pointe vers une page vivante pertinente. La destination devrait retourner 200 et se canonicaliser sur elle-même. La chaîne ne devrait pas inclure de 4xx, 5xx ou de protocoles mixtes. Pour une migration, la carte de redirection devrait couvrir 100 % des anciennes URLs qui ont reçu des liens externes ou du trafic organique au cours des 12 derniers mois. Les URLs qui n'ont jamais eu de liens peuvent être autorisées à retourner 404. Une étude de 2023 de SEMrush sur 200 migrations de sites a constaté que les sites avec des 301 d'un seul saut et zéro redirections cassées ont conservé 89 % du trafic organique après le lancement, tandis que les sites avec des chaînes plus longues que trois sauts ou des 404 non mappés ont conservé seulement 51 %.

Pour le SEO, le temps de réponse du serveur (aussi appelé Time to First Byte ou TTFB) devrait être inférieur à 800 ms pour une bonne expérience utilisateur et inférieur à 200 ms pour une excellente. Les données de Core Web Vitals de Google montrent que les pages avec un TTFB supérieur à 1 500 ms se classent mesurément plus bas dans les requêtes compétitives. Cet outil de vérification des codes de statut HTTP rapporte le temps de réponse par URL afin que vous puissiez marquer les lentes. Un 200 qui prend 3 000 ms pour répondre est techniquement actif mais fonctionnellement cassé. Les causes courantes incluent les requêtes à base de données non optimisées, l'absence de CDN, le HTML rendu côté serveur surdimensionné ou la distance géographique entre le serveur et le crawler. Corrigez d'abord les 10 % de pages les plus lentes car elles partagent généralement une cause sous-jacente. Associez cet outil au google-crawler-simulator pour confirmer que Googlebot voit le même temps de réponse que vous.

curl est un outil en ligne de commande qui peut récupérer n'importe quelle URL et afficher le code de statut avec les bons drapeaux (curl -I -L https://example.com). C'est puissant, gratuit et fonctionne pour une URL à la fois. Un outil de vérification en masse des codes de statut HTTP comme celui-ci exécute la même récupération sur 50 URLs en parallèle, capture la chaîne de redirection dans un tableau lisible, calcule la réponse et affiche le résultat dans un navigateur sans taper de drapeaux. Pour un développeur à l'aise avec la ligne de commande, curl est bien pour les vérifications ponctuelles. Pour les audits SEO sur des centaines d'URLs, un outil en masse est environ 30 fois plus rapide et bien plus facile à partager avec les collègues non techniques. Les deux outils retournent les mêmes codes de statut puisque les deux parlent HTTP.

Oui. Ouvrez l'onglet Réseau dans les devtools de Chrome ou Firefox, chargez l'URL et regardez la requête du document. Chaque redirection apparaît comme une ligne séparée avec le code de statut (301, 302, 307) et l'en-tête Location pointant vers l'URL suivante. La dernière ligne est la page qui retourne 200. Les devtools sont excellents pour déboguer une URL à la fois et voir les en-têtes de requête et de réponse exacts. C'est impratique de vérifier 50 URLs car vous devez recharger chacune et lire le log du réseau manuellement. Pour les audits en masse, utilisez cet outil de vérification des redirections, qui affiche les mêmes données de chaîne dans un tableau que vous pouvez scanner en secondes. Utilisez les devtools quand vous avez besoin de détails complets sur les en-têtes et l'outil de vérification en masse quand vous avez besoin d'échelle.

Les migrations cassent les liens. Même les cartes de redirection soignées manquent des cas limites : les barres obliques finales, la sensibilité à la casse, les chaînes de requête, les caractères encodés, les fichiers dans les sous-dossiers que le nouveau serveur a oublié de copier. Un outil de vérification en masse des codes de statut des URLs exécuté le jour du lancement détecte la première vague de casse. Une deuxième exécution deux semaines plus tard détecte les URLs que les motifs de trafic révèlent. Les sites qui ignorent les audits post-migration perdent généralement 20-40 % de leur trafic organique le premier mois et mettent 3-6 mois à se rétablir. Les sites qui auditent immédiatement et corrigent en 48 heures conservent généralement 85 %+ du trafic. Exécutez cet outil de vérification des codes de statut HTTP sur votre sitemap, vos 100 pages d'arrivée organiques les plus importantes et toutes les URLs avec des backlinks externes. Utilisez le sitemap-checker pour confirmer que le nouveau sitemap ne contient que des 200.

Oui. Cet outil de vérification des codes de statut HTTP est gratuit, ne nécessite aucune inscription et n'a pas de limite quotidienne sur le nombre de lots que vous exécutez. La seule contrainte est 50 URLs par exécution, ce qui maintient la réponse rapide et prévient les abus. Pour les lots plus importants, divisez les URLs en groupes de 50 et collez chacun à tour de rôle. L'outil s'exécute côté serveur, ce qui signifie qu'il voit les codes de statut de la manière que Googlebot les voit, pas de la manière que votre navigateur les voit après la mise en cache. Utilisez-le aussi souvent que vous le besoin : hebdomadairement pour les sites actifs, quotidiennement lors des migrations et après chaque déploiement pour attraper les régressions. Associez-le au canonical-checker, sitemap-checker et google-crawler-simulator pour un flux de travail d'audit complet au niveau des URLs.