Un site peut être « en ligne » et pourtant cassé : le serveur répond HTTP 200, mais la page affiche une erreur de base de données, une liste de produits vide ou la page par défaut d’un hébergeur. Une vérification qui ne regarde que le code de statut les laisse toutes passer. La surveillance par mot-clé comble cette lacune en vérifiant aussi le contenu : un texte qui doit figurer sur la page, comme « Add to cart », ou un texte qui ne doit pas y figurer, comme « Fatal error ». Si la condition n’est pas remplie, la page est considérée comme hors ligne et vous recevez une alerte.
Comment un site peut être en ligne mais cassé
Le code de statut est fixé par ce qui répond à la requête, et ce n’est pas toujours la partie de la stack qui a planté. Tous ces cas se produisent avec un 200, ou avec un code que votre outil de surveillance accepte :
Une page d’erreur applicative. Certains frameworks, thèmes et pages d’erreur personnalisées affichent les erreurs avec un 200 au lieu d’un code 5xx.
Une page vide. Une erreur fatale PHP avec l’affichage des erreurs désactivé peut produire un corps vide, ou un cache peut stocker et servir une page vide.
Des données manquantes. La boutique se charge, mais l’API produits derrière elle a échoué, si bien que chaque catégorie affiche « Aucun produit trouvé ».
Le mauvais site. Après un changement d’hébergement ou de DNS, le domaine tombe sur une page par défaut comme « Welcome to nginx! » ou une page de parking.
Une page de maintenance oubliée. Un plugin de mode maintenance qui répond 200 au lieu de 503 ressemble à un site qui fonctionne pour une vérification de statut.
Une page défigurée ou injectée. Un attaquant remplace le contenu ou ajoute des liens de spam, et le serveur répond toujours normalement.
Google appelle soft 404 une page qui indique « introuvable » ou n’affiche rien tout en répondant 200, et ces pages peuvent disparaître des résultats de recherche. Les utilisateurs, eux, voient simplement un site cassé.
Comment fonctionne la surveillance par mot-clé
À chaque vérification, l’outil de surveillance demande la page, lit le HTML renvoyé par le serveur et y cherche votre texte. Il existe deux modes :
Doit contenir : la vérification échoue quand le texte est absent. À utiliser comme preuve que la page fonctionne, par exemple le libellé d’un bouton ou un nom de produit.
Ne doit pas contenir : la vérification échoue quand le texte apparaît. À utiliser pour les messages d’erreur connus.
Deux détails comptent. La vérification lit le code source HTML, pas la page que vous voyez dans un navigateur : un texte ajouté ensuite par JavaScript n’y figure donc pas. Et la correspondance est généralement exacte, majuscules et minuscules comprises. L’entrée du glossaire sur la surveillance par mot-clé en donne la définition courte.
Comment choisir un bon mot-clé
Un bon mot-clé « doit contenir » n’apparaît que lorsque la page fonctionne, et reste identique d’un jour à l’autre. Cela exclut les prix, les dates, les niveaux de stock, les compteurs et tout ce qui fait l’objet d’un test A/B. Préférez un texte que l’application génère à partir de ses données ou de ses templates, qui disparaît donc quand l’application tombe, plutôt qu’un texte dans un en-tête statique qu’un cache pourrait encore servir.
PageDoit contenirPourquoi ça marchePage produitAdd to cartAffiché uniquement quand le produit et le panier fonctionnentPage catégorieUn nom de produit toujours en stockAbsent quand les données produits ne se chargent pasPage de connexionMot de passe oublié ?Fait partie du vrai formulaire de connexion, pas d’une page d’erreurPage de blog ou d’actualitésUne ligne du pied de page généré par le CMSDisparaît quand le CMS n’arrive pas à joindre sa base de donnéesEndpoint de santé »status »: »ok »Écrit par l’application après avoir vérifié ses dépendances
Pour une API ou un endpoint de health check, une vérification JSON comme $.status égal à ok est plus précise qu’un mot-clé, car elle ne dépend ni des espaces ni de l’ordre des champs.
Des vérifications « ne doit pas contenir » pour les messages d’erreur
Une vérification négative détecte les pannes que vous pouvez nommer à l’avance. Quelques chaînes utiles, selon votre stack :
Error establishing a database connection sur WordPress. Le cœur l’envoie avec un 500, mais une page db-error.php personnalisée ne le fait pas forcément.
Fatal error ou Parse error sur les sites PHP qui affichent les erreurs.
Welcome to nginx! ou le titre de la page par défaut de votre hébergeur, pour repérer un domaine qui pointe vers le mauvais serveur.
Des mots de spam qui n’ont rien à faire sur votre site, comme alarme de base contre le contenu injecté.
Méfiez-vous des pages où la chaîne peut apparaître légitimement. Un article de blog sur les erreurs de base de données, ou un article d’aide qui cite un message d’erreur, ferait échouer une vérification « ne doit pas contenir » à chaque fois. Dans le doute, une vérification positive sur un texte qui prouve que la page fonctionne est le choix le plus sûr, car elle détecte aussi les pannes auxquelles vous n’aviez pas pensé.
Testez le mot-clé avant de vous y fier
Vérifiez ce que le serveur envoie réellement, pas ce qu’affiche le navigateur. Depuis un terminal :
curl -s –compressed https://example.com/product/blue-mug | grep -c « Add to cart »
Un résultat de 0 signifie que l’outil de surveillance ne le trouvera pas non plus. Les raisons habituelles :
Le texte est généré par JavaScript. Affichez le code source de la page (pas l’inspecteur) pour voir le HTML renvoyé par le serveur, et choisissez un texte qui s’y trouve.
Les entités HTML. « Terms & Conditions » à l’écran devient souvent Terms & Conditions dans le code source, et les guillemets typographiques peuvent aussi être encodés. Choisissez un texte sans caractères spéciaux, ou copiez-le depuis le code source.
La casse et les espaces. Un bouton mis en majuscules avec du CSS reste « Add to cart » dans le HTML. Les retours à la ligne à l’intérieur du texte empêchent aussi une correspondance exacte.
L’outil de surveillance voit une autre page. Les sites qui choisissent la langue ou la devise selon la localisation, ou qui affichent un défi anti-bot aux clients inconnus, peuvent envoyer à un outil de surveillance un autre HTML que celui que vous obtenez à votre bureau.
Quand un mot-clé ne suffit pas
Le contenu dépend de JavaScript. Les applications monopages envoient peu de HTML. Vérifiez-les avec un parcours dans un vrai navigateur, qui exécute le JavaScript avant de chercher le texte.
La panne survient quelques étapes plus loin. La page produit fonctionne, mais l’ajout au panier non. Une vérification synthétique en plusieurs étapes parcourt le chemin de l’utilisateur et vérifie chaque étape.
La page est très volumineuse. Les outils de surveillance ne lisent généralement que le début d’une réponse. Cherchez un texte situé en haut de page, ou vérifiez un endpoint plus léger.
La page est lente, pas cassée. C’est une question de temps de réponse : définissez plutôt une limite de réponse lente.
La checklist de ce qu’il faut surveiller sur votre site web indique quelles pages méritent une vérification du contenu, et comment réduire les fausses alertes couvre le reste des réglages.
Les vérifications par mot-clé dans Uptimecheck
Chaque moniteur HTTP(S) de la surveillance de disponibilité d’Uptimecheck peut intégrer une vérification par mot-clé en plus des codes de statut attendus :
Contient ou ne contient pas : un mot-clé par moniteur, recherché à l’identique, casse comprise, dans les 2 premiers Mo de la réponse. Besoin d’une vérification positive et d’une négative sur la même page ? Ajoutez un second moniteur.
Vérifications JSON et d’en-têtes : jusqu’à 10 par moniteur, par exemple $.status égal à ok ou un en-tête Content-Type qui contient json, pour les API et les endpoints de santé.
Requête de test : voyez la réponse et si les vérifications passent avant d’enregistrer le moniteur.
Confirmé et expliqué : une vérification échouée est relancée avant l’ouverture d’un incident, et l’incident indique ce qui n’allait pas, par exemple que le texte attendu ne figurait pas sur la page ou que la page est revenue vide, avec le début de la réponse.
JavaScript et parcours : les parcours vérifient le texte à chaque étape, et les parcours dans un vrai navigateur voient le texte généré par JavaScript, avec une capture d’écran de l’étape qui a échoué.
Les vérifications tournent jusqu’à chaque minute depuis Stockholm, Londres et New York : un site qui change de langue selon la localisation montre donc à Uptimecheck la version qu’il sert à la Suède, au Royaume-Uni ou aux États-Unis. Choisissez un mot-clé identique dans toutes les versions, ou envoyez les en-têtes qui déterminent la langue. Pour en configurer un, consultez comment ajouter votre premier moniteur, et si un moniteur signale une panne alors que le site fonctionne chez vous, pourquoi un moniteur peut être en panne alors que le site fonctionne.
Faites en sorte que « en ligne » veuille dire « fonctionne ». Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.