# Renvoyer 200 pour une page en réalité en erreur de base de données : le piège

> Une page de cache statique continue de répondre 200 pendant que la base de données est indisponible, et transmet aux robots un contenu d'erreur comme s'il était valide.

- Auteur : WordPress Développement
- Publié le : 2022-11-04
- Mis à jour le : 2022-11-04
- Catégorie : SEO & GEO
- URL : https://www.wpmoderne.fr/seo/cache-masque-erreur-bdd-code-200/

## L’essentiel

- Le cache de page peut servir un contenu d'erreur sans jamais le signaler
- Un code 200 sur une page d'erreur trompe durablement l'indexation
- Le contrôle du code retour doit se faire après la génération, pas avant

On observe ici un antipatron précis : une extension de cache configurée pour servir une version statique de chaque page en cas d'indisponibilité du serveur de base de données, dans l'idée louable d'éviter un écran blanc au visiteur. Le problème survient quand cette version statique correspond en réalité à la page d'erreur générique de WordPress — celle qui affiche « Erreur d'établissement de la connexion à la base de données » — et que ce contenu se retrouve mis en cache et servi avec un code 200 pendant des heures, y compris aux robots d'indexation.

Pourquoi c'est un problème : un code 200 signale sans ambiguïté à Google, aux navigateurs et aux outils tiers qu'une ressource est disponible et valide. Un robot qui explore une page pendant cette fenêtre d'indisponibilité voit un contenu d'erreur qu'il traite comme un contenu légitime, susceptible de remplacer en index la version normale de la page si l'incident se prolonge suffisamment.

## Comment l'incident se met en place

La configuration en cause reposait sur une page de secours statique, générée une seule fois puis stockée sur le disque, appelée automatiquement par le plugin de cache lorsque la connexion MySQL échoue. Cette page de secours, pensée à l'origine comme un message d'attente convivial pour l'utilisateur, n'a jamais été associée à l'en-tête `Retry-After` ni au code `503 Service Unavailable` que WordPress renvoie pourtant nativement dans ce cas de figure, via la fonction `wp_die()` appelée en interne par `wpdb::bail()`.

Le module de cache, positionné en amont du cœur de WordPress au niveau du serveur web, interceptait la requête avant même que ce code natif ne s'exécute, et renvoyait sa propre page statique avec un code 200 forcé.

## Pourquoi le soft 404 ne s'applique pas ici

> L'essentiel à retenir : Le cache de page peut servir un contenu d'erreur sans jamais le signaler ; Un code 200 sur une page d'erreur trompe durablement l'indexation ; Le contrôle du code retour doit se faire après la génération, pas avant

Ce cas se distingue d'un soft 404 classique. Un soft 404 concerne une page qui existe, répond 200, mais dont le contenu réel indique une absence de résultat — une fiche produit retirée du catalogue, par exemple. Ici, la page existe normalement en temps ordinaire : c'est l'incident technique lui-même qui est maquillé en réponse valide, un problème d'infrastructure déguisé en contenu normal plutôt qu'un problème de contenu déguisé en réponse normale.

## Corriger la configuration du cache

La correction repose sur trois ajustements distincts, chacun indépendant des autres :

- Configurer la page de secours du plugin de cache pour qu'elle renvoie explicitement un code `503`, via l'en-tête HTTP envoyé par le serveur web (Apache ou Nginx) avant que le contenu ne soit servi.
- Ajouter un en-tête `Retry-After: 300` indiquant aux robots un délai raisonnable avant nouvelle tentative, plutôt que de les laisser deviner.
- Exclure explicitement cette page de secours de toute mise en cache disque, pour qu'elle ne survive jamais à la résolution de l'incident.

## Vérifier après coup dans les logs

Un simple `grep` sur les logs d'accès du serveur, filtré sur la plage horaire de l'incident, révèle immédiatement l'ampleur du problème :

```
grep '04/Nov/2022:0[2-6]' access.log | awk '{print $9}' | sort | uniq -c
```

Si la colonne des codes retour n'affiche que des `200` pendant une coupure de base de données confirmée par ailleurs dans les logs applicatifs, la configuration du cache est bien en cause.

> Un code 200 est une promesse faite au robot. La tenir alors que le site est réellement en panne coûte plus cher, à terme, que l'écran blanc qu'on cherchait à éviter.

## Prévenir : surveiller le couple code retour et disponibilité réelle

Corriger la configuration ne suffit pas à garantir qu'un incident futur, sur un mécanisme de secours différent ou une nouvelle extension de cache, ne reproduise pas le même antipatron. Une supervision externe, qui interroge le site depuis un serveur tiers toutes les quelques minutes, doit vérifier non seulement que le code retour vaut 200, mais aussi que le contenu de la page correspond à un gabarit attendu, par exemple la présence d'un identifiant HTML stable habituellement généré par le thème.

- Une sonde de supervision qui ne vérifie que le code retour ne détecte jamais ce type d'incident, puisque le code reste 200 de bout en bout.
- Chercher une chaîne de contenu précise, absente de la page d'erreur générique, distingue une réponse normale d'une réponse de secours maquillée.
- Une alerte déclenchée sur cette absence de contenu attendu prévient l'équipe avant que les robots n'aient eu le temps d'explorer massivement la version dégradée.

Sur le projet concerné, cette vérification de contenu a été ajoutée à la supervision existante après l'incident, ciblant la présence du pied de page habituel plutôt que la seule disponibilité brute du serveur : une différence qui aurait permis de détecter l'incident dans les minutes suivant son déclenchement, plutôt que plusieurs heures plus tard.

## Ce qu'on retient

Un mécanisme de secours pensé pour l'expérience humaine peut, sans supervision technique, se transformer en source de confusion pour les robots d'indexation. Le code retour HTTP doit toujours refléter l'état réel du système, y compris — surtout — pendant un incident, faute de quoi le remède devient plus coûteux que le mal qu'il prétendait soigner.