Audit de l'intégrité des codes de statut

Les frameworks modernes renvoient un 200 pour à peu près tout, si bien qu'un produit supprimé, un filtre sans résultat et un appel tiers en échec ressemblent tous à des pages saines aux yeux d'un robot. Google doit alors deviner, via sa détection des soft 404, ce qui est lent et peu fiable. Le réflexe d'ajouter un noindex est inadapté à la plupart de ces états, car il maintient l'URL dans la file de crawl indéfiniment au lieu de l'en sortir.

Le fichier de compétence

---
name: status-code-integrity-audit
description: À utiliser lorsque des pages supprimées, vides ou en erreur renvoient un 200 OK, lorsque des soft 404 apparaissent dans la Search Console, ou avant de retirer un lot d'URL d'un site.
---

# Audit de l'intégrité des codes de statut

Les frameworks modernes renvoient un 200 pour à peu près tout, si bien qu'un produit supprimé, un filtre sans résultat et un appel tiers en échec ressemblent tous à des pages saines aux yeux d'un robot. Google doit alors deviner, via sa détection des soft 404, ce qui est lent et peu fiable. Le réflexe d'ajouter un noindex est inadapté à la plupart de ces états, car il maintient l'URL dans la file de crawl indéfiniment au lieu de l'en sortir.

## Ce qu’il vous faut d’abord

- Un export de crawl avec les codes de statut, plus la liste des soft 404 de la Search Console
- La liste de tous les états dans lesquels l'application ne produit aucun contenu utile, obtenue à partir du code ou auprès des développeurs plutôt que d'un crawl
- Un accès en ligne de commande pour interroger les URL et lire les en-têtes de réponse bruts
- La capacité de modifier les codes de statut dans l'application et de voir ce que le CDN en fait

## Méthode

1. Recensez les états d'échec dans le code avec les développeurs : élément supprimé, recherche ou filtre sans résultat, annonce expirée, rupture de stock définitive, page réservée aux connectés, dépendance API en échec. Un crawl ne trouve que les états déjà liés, qui sont minoritaires.
2. Interrogez une URL par état depuis la ligne de commande et relevez le statut de l'en-tête, pas ce que raconte le corps de la page. Une page qui affiche « introuvable » tout en renvoyant un 200 est la trouvaille la plus fréquente de cet audit, et elle est invisible dans un navigateur.
3. Attribuez le bon code à chaque état : 404 quand la chose a disparu sans équivalent, 410 quand vous en êtes certain et voulez un retrait plus rapide, 301 quand il existe un vrai remplacement un pour un, 200 avec du contenu réel quand la page sert encore à quelque chose, et 503 avec Retry-After pour une indisponibilité planifiée.
4. Vérifiez ce qui se passe sous charge et pendant les pannes de dépendances. Un serveur qui répond 200 avec une page d'erreur cache l'incident à la supervision comme à Google, alors qu'un 503 correct fait ralentir puis reprendre le crawl sans perte d'index.
5. Confrontez la liste au rapport des soft 404. Chaque entrée est une déclaration de Google disant qu'il n'est pas d'accord avec votre 200, et c'est la confirmation la moins coûteuse qu'un état est mal classé.
6. Vérifiez au niveau des en-têtes après le déploiement, car un worker en périphérie, une règle de cache ou une page d'erreur personnalisée peut réécrire un statut que l'application avait pourtant bien positionné, et les logs applicatifs afficheront le bon.
7. Surveillez les statistiques d'exploration pendant deux semaines. Un gros lot de nouveaux 404 ou 410 produit une courbe alarmante mais attendue, qui se corrige d'elle-même ; une hausse des 5xx sur la même période, non, et elle doit être arrêtée.

## Ce que ça produit

Une carte des codes de réponse état par état, avec le code actuel et le code correct pour chacun, et une vérification au niveau des en-têtes confirmant ce que la production envoie réellement.

## Là où ça dérape

- Rediriger toutes les pages supprimées vers la page d'accueil, ce que Google traite de toute façon comme une soft 404 tout en détruisant le signal indiquant que la page a disparu
- Servir un 200 avec un noindex sur un état vide, si bien que l'URL reste indéfiniment dans la file de crawl sans jamais en sortir
- Tester dans un navigateur, où un routeur côté client ou un service worker peut afficher une page 404 livrée avec un en-tête 200
- Répondre 404 pendant une fenêtre de maintenance au lieu de 503, ce qui fait sortir de l'index des pages parfaitement fonctionnelles pour une heure d'interruption

---

Extrait de la bibliothèque de compétences QuQi - https://www.quqi.io/fr/skills/status-code-integrity-audit

Ce qu’il vous faut d’abord

• Un export de crawl avec les codes de statut, plus la liste des soft 404 de la Search Console
• La liste de tous les états dans lesquels l'application ne produit aucun contenu utile, obtenue à partir du code ou auprès des développeurs plutôt que d'un crawl
• Un accès en ligne de commande pour interroger les URL et lire les en-têtes de réponse bruts
• La capacité de modifier les codes de statut dans l'application et de voir ce que le CDN en fait

Méthode

1. 01 Recensez les états d'échec dans le code avec les développeurs : élément supprimé, recherche ou filtre sans résultat, annonce expirée, rupture de stock définitive, page réservée aux connectés, dépendance API en échec. Un crawl ne trouve que les états déjà liés, qui sont minoritaires.
2. 02 Interrogez une URL par état depuis la ligne de commande et relevez le statut de l'en-tête, pas ce que raconte le corps de la page. Une page qui affiche « introuvable » tout en renvoyant un 200 est la trouvaille la plus fréquente de cet audit, et elle est invisible dans un navigateur.
3. 03 Attribuez le bon code à chaque état : 404 quand la chose a disparu sans équivalent, 410 quand vous en êtes certain et voulez un retrait plus rapide, 301 quand il existe un vrai remplacement un pour un, 200 avec du contenu réel quand la page sert encore à quelque chose, et 503 avec Retry-After pour une indisponibilité planifiée.
4. 04 Vérifiez ce qui se passe sous charge et pendant les pannes de dépendances. Un serveur qui répond 200 avec une page d'erreur cache l'incident à la supervision comme à Google, alors qu'un 503 correct fait ralentir puis reprendre le crawl sans perte d'index.
5. 05 Confrontez la liste au rapport des soft 404. Chaque entrée est une déclaration de Google disant qu'il n'est pas d'accord avec votre 200, et c'est la confirmation la moins coûteuse qu'un état est mal classé.
6. 06 Vérifiez au niveau des en-têtes après le déploiement, car un worker en périphérie, une règle de cache ou une page d'erreur personnalisée peut réécrire un statut que l'application avait pourtant bien positionné, et les logs applicatifs afficheront le bon.
7. 07 Surveillez les statistiques d'exploration pendant deux semaines. Un gros lot de nouveaux 404 ou 410 produit une courbe alarmante mais attendue, qui se corrige d'elle-même ; une hausse des 5xx sur la même période, non, et elle doit être arrêtée.

Ce que ça produit

Une carte des codes de réponse état par état, avec le code actuel et le code correct pour chacun, et une vérification au niveau des en-têtes confirmant ce que la production envoie réellement.

Là où ça dérape

• Rediriger toutes les pages supprimées vers la page d'accueil, ce que Google traite de toute façon comme une soft 404 tout en détruisant le signal indiquant que la page a disparu
• Servir un 200 avec un noindex sur un état vide, si bien que l'URL reste indéfiniment dans la file de crawl sans jamais en sortir
• Tester dans un navigateur, où un routeur côté client ou un service worker peut afficher une page 404 livrée avec un en-tête 200
• Répondre 404 pendant une fenêtre de maintenance au lieu de 503, ce qui fait sortir de l'index des pages parfaitement fonctionnelles pour une heure d'interruption

Utiliser cette compétence dans votre propre IA

Le fichier téléchargé est un simple markdown dont l'en-tête porte le nom et le déclencheur. Quand un assistant sait charger des compétences tout seul, c'est cet en-tête qu'il lit pour décider que celle-ci s'applique.

Plus dans SEO technique