Un site WordPress, c’est un programme, une base de données et un tas d’extensions, souvent sur un hébergement mutualisé. Quand l’un d’eux tombe en panne, le site tombe en panne à sa façon. La page peut devenir blanche, afficher un court message, ou se charger si lentement que les visiteurs partent.
La surveillance depuis l’extérieur ne voit rien de tout cela. Ce qu’elle peut faire, c’est demander à intervalles réguliers les mêmes adresses qu’un visiteur, et vous prévenir quand la réponse est mauvaise. Ce guide montre quelles adresses demander et quels signaux configurer.
Les pannes à repérer
La documentation de WordPress décrit les pannes que les propriétaires de sites rencontrent le plus souvent. Chacune se présente différemment vue de l’extérieur :
| Ce qui s’est passé | Ce que voit un visiteur | Ce qu’une vérification extérieure peut lire |
|---|---|---|
| Une extension ou un thème échoue avec une erreur PHP | Une page blanche (l’« écran blanc ») ou un message indiquant que le site a une erreur critique | En général une erreur serveur, 500. Parfois une page blanche qui répond quand même 200 |
| WordPress ne peut pas joindre sa base de données | « Error establishing a database connection » | Une erreur serveur, ou une page qui contient cette phrase |
| Une mise à jour est interrompue | Un court avis de maintenance qui ne disparaît pas | Une réponse 503 |
| L’hébergeur est surchargé | Une page qui se charge lentement, puis une erreur ou un délai d’attente dépassé | Des temps de réponse lents, puis un délai d’attente dépassé ou une réponse 5xx |
| Le certificat ou le domaine expire | Un avertissement de sécurité du navigateur, ou plus de site du tout | Une alerte SSL, domaine ou DNS |
Aucune n’est rare. La plupart commencent juste après une modification, elles ont donc tendance à apparaître quand personne ne regarde.
Quelles adresses surveiller
Chaque adresse exacte compte pour un site web, choisissez donc avec soin.
- La page d’accueil. La première adresse évidente. Une extension de cache peut la servir depuis une copie stockée, elle peut donc sembler saine un moment après que le reste du site est tombé.
- La page de connexion, wp-login.php. Elle est publique, répond sans mot de passe et n’est en général pas mise en cache. Elle doit être construite par PHP et la base de données à chaque requête, elle tend donc à échouer quand ils échouent.
- Une page importante pour l’activité. Une page de contact, une page de réservation, une liste de prix.
- Tout autre nom d’hôte. Une boutique ou un espace membres sur un sous-domaine, ou une copie de préproduction, est une adresse distincte avec ses propres pannes.
Ne surveillez pas l’espace d’administration. Une vérification ne se connecte pas, elle ne verrait donc qu’une redirection vers la page de connexion.
Repérer une page d’erreur qui répond 200
Une erreur serveur est facile : toute réponse finale hors de la plage 200 à 399 compte comme un échec, et la raison est enregistrée.
Le cas difficile est une page qui répond 200 mais qui est fausse. Un cache peut servir une page blanche ou cassée, ou un thème peut imprimer un message d’erreur dans une réponse par ailleurs normale. Deux alertes de texte couvrent ce cas :
- Échouer quand la page contient une phrase. Utilisez une phrase de la panne elle-même, comme « Error establishing a database connection ».
- Échouer quand la page ne contient pas une phrase. Utilisez une phrase toujours présente sur une page saine, comme une partie du texte du pied de page ou le nom d’un bouton.
Choisissez une phrase courte, exacte et que ni les rédacteurs ni les extensions de traduction ne modifient. Le texte doit correspondre exactement.
Bloqué en mode maintenance
Quand WordPress se met à jour lui-même, il affiche un court avis de maintenance et répond par un 503 un instant. Si la mise à jour est interrompue, l’avis peut rester des heures, et les visiteurs ne voient rien d’autre.
Un 503 est un échec pour une vérification extérieure, ce cas n’exige donc aucun réglage particulier. L’important est que quelqu’un soit prévenu. Comme une vérification échouée est répétée avant qu’un incident s’ouvre, une courte mise à jour normale ne déclenche pas d’alarme, et une mise à jour bloquée, si.
Lent avant d’être en panne
Un hébergeur surchargé passe rarement de sain à mort en une seule étape. Les pages mettent plus de temps, puis quelques-unes dépassent le délai d’attente. Une vérification attend jusqu’à 15 secondes avant de compter une réponse comme un échec, et elle enregistre le temps de réponse à chaque fois ; un graphique d’historique montre donc un site qui ralentit avant de s’arrêter.
Ce que la surveillance extérieure ne peut pas faire
- Elle ne sait pas quelles extensions ou quels thèmes sont installés, ni lesquels sont obsolètes.
- Elle ne trouve ni failles de sécurité, ni logiciels malveillants, ni page piratée qui répond encore normalement.
- Elle ne regarde pas derrière une connexion, un formulaire ou un paiement.
- Elle ne répare rien. Elle vous dit qu’il y a un problème, et quand il a commencé et fini.
Liste de contrôle
- La page d’accueil est-elle surveillée, et la page de connexion aussi ?
- Y a-t-il une alerte de texte sur une phrase d’une page saine ?
- Les alertes parviennent-elles à quelqu’un qui peut agir, par e-mail ou Telegram ?
- Les dates d’expiration du certificat SSL et du domaine sont-elles surveillées ?
- Si vous gérez des sites pour d’autres personnes, chacun est-il étiqueté avec son client ?