Le Bulk HTTP Status Checker de Screpy vérifie une liste de 50 URL maximum et affiche la première réponse, la réponse finale et les redirections observées. Utilisez-le après une migration, pour examiner des pages inaccessibles ou préparer des corrections. Le résultat décrit une requête GET publique à l’heure indiquée, pas une disponibilité continue, une vitesse de chargement dans le navigateur ou une indexation confirmée.
Choisissez une liste d’URL avec un objectif précis
Collez une adresse HTTP ou HTTPS publique complète par ligne. Commencez par une question : les anciens liens de campagne atteignent-ils leurs remplaçants, ou les liens de navigation renvoient-ils encore des erreurs ? Pour les redirections, indiquez les adresses d’origine. Tester uniquement les destinations finales ne montre pas le comportement des anciens liens.
La limite porte sur 50 lignes non vides envoyées. Les lignes vides sont ignorées et les URL répétées après normalisation ne sont vérifiées qu’une fois. Supprimez les doublons avant l’envoi s’ils font dépasser la limite. Corrigez les lignes invalides. L’outil ne découvre pas les pages du site et n’importe pas automatiquement un sitemap.
Un échantillon utile comprend une page inchangée, une page déplacée et un contenu volontairement supprimé. Notez le résultat attendu pour chacune avant le contrôle. Un 404 peut être correct pour une suppression, mais doit être étudié sur une page de paiement active. Utilisez de vrais chemins publics, pas des tableaux de bord privés ou des URL contenant des identifiants.
Lisez la première réponse et la destination finale
Le premier code appartient à l’adresse saisie. Le dernier correspond à la destination atteinte après les redirections suivies. Les URL finales figurent dans le tableau ; les chaînes de redirection observées sont regroupées dans les détails du rapport. Une destination correcte ne signifie pas que l’adresse initiale renvoie directement 200.
Ces exemples fictifs expliquent des vérifications terminées ; ils ne proviennent pas d’un site particulier.
| Première → dernière réponse | Signification | Point à examiner |
|---|---|---|
| 200 → 200 | Réponse réussie directe | Est-ce la page prévue, avec un contenu utile ? |
| 301 → 200 | Redirection permanente vers une réponse réussie | L’URL finale est-elle le remplacement attendu ? |
| 302 → 200 | Redirection temporaire vers une réponse réussie | Le déplacement est-il vraiment temporaire ? |
| 301 → 404 | Redirection vers une ressource introuvable | Corriger la destination ou la correspondance si la page doit exister |
| 403 → 403 | Requête refusée | Examiner les règles d’accès, sans supposer que tous sont bloqués |
La référence HTTP de MDN explique les codes. Un 404 signifie introuvable ; un 410 indique une ressource supprimée. Les deux peuvent être voulus. Un 429 signale trop de requêtes et les 5xx des erreurs serveur. Le code identifie une catégorie, pas toute la cause.
Les compteurs se recoupent : une URL redirigée peut aussi finir en réussite ou en erreur HTTP. Ne les additionnez pas en attendant le nombre d’URL uniques.
Séparez les contrôles indisponibles des erreurs HTTP
Une erreur HTTP, comme 404 ou 503, reste une réponse. Un résultat indisponible signifie que l’observation n’a pas pu aboutir. Résolution DNS, connexion sécurisée ou délai dépassé peuvent empêcher la réponse finale. Lisez la raison au lieu d’assimiler une cellule vide à un 404.
Chaque URL dispose de huit secondes et le lot de 30 secondes. L’outil suit jusqu’à cinq redirections HTTP. Boucle, destination manquante ou chaîne plus longue peuvent laisser le contrôle incomplet. Ce sont les limites de l’outil, pas celles de l’exploration Google. Les étapes déjà observées restent visibles : un 301 peut apparaître sans code final si la connexion sécurisée suivante échoue.
Le passage de HTTPS à HTTP est signalé. L’outil suit les redirections des réponses HTTP ; il n’exécute pas JavaScript et ne suit pas les instructions meta-refresh de la page. Un navigateur peut donc agir autrement.
La durée décrit ce contrôle et son parcours de requêtes. Elle ne mesure ni chargement des images, ni exécution JavaScript, ni moment où le visiteur peut interagir. Utilisez-la pour examiner cette observation, pas comme score de vitesse.
Exportez les corrections et revérifiez les mêmes URL
Priorisez les erreurs sur les pages qui doivent rester accessibles, les mauvaises destinations et les liens cassés encore présents sur des pages importantes. Ne redirigez pas chaque suppression vers l’accueil pour obtenir du vert. Si le contenu a déménagé, choisissez un remplacement pertinent ; s’il a disparu, examinez la réponse voulue et nettoyez les anciens liens.
Filtrez erreurs HTTP, redirections ou contrôles indisponibles, puis recherchez des URL. Le CSV contient seulement les lignes filtrées : premiers/derniers codes, destination, durée, raison, heure et chaîne observée. Conservez ce relevé avec le résultat attendu, corrigez puis relancez les mêmes adresses d’origine.
Examinez le contenu douteux séparément. Les consignes HTTP de Google confirment qu’un 2xx ne garantit pas l’indexation ; une page d’erreur peut même renvoyer 200. Cet outil n’analyse pas le corps pour détecter les soft 404. Utilisez le Noindex Checker pour les directives d’indexation ou le Redirect Checker pour les redirections. Un statut corrigé est une condition vérifiée, pas un audit SEO complet.
Pour examiner une liste d’URL préférées déclarées, utilisez le vérificateur canonique en lot. Il vérifie les déclarations HTML et HTTP et une cible immédiate par page, sans indiquer la canonique choisie par Google.