Documentation

Repérer une page cassée qui se charge pourtant

La surveillance de disponibilité pose généralement une seule question : la page a-t-elle répondu ? Or bien des problèmes qui font perdre visiteurs et commandes à un site ne changent rien à cette réponse. La grille de produits de la boutique s’affiche vide. Le CMS montre son message d’erreur dans la mise en page habituelle. Un bandeau de maintenance reste en place après la maintenance. Une mise en production embarque la configuration de préproduction, et avec elle <meta name="robots" content="noindex"> : le site disparaît des résultats de recherche dans les semaines qui suivent.

Pingsured lit le HTML et vérifie les éléments que vous désignez — avec les sélecteurs CSS que vous utilisez déjà dans les outils de développement de votre navigateur.

Que vérifier ?

Une vérification peut aussi lire un attribut plutôt que le texte : link[rel=canonical] avec l’attribut href égal à l’adresse de la page elle-même repère une balise canonique qui pointe ailleurs. Lorsqu’une page indique sa date de mise à jour, par exemple dans time[datetime] ou une balise meta article:modified_time, les opérateurs d’âge vous signalent quand elle est plus ancienne que prévu.

Le texte est comparé après normalisation des espaces : un retour à la ligne ou une indentation modifiée dans le gabarit ne déclenche pas d’alerte. Si vous préférez XPath à CSS, chaque vérification peut utiliser l’un ou l’autre.

Pourquoi surveiller vos pages avec Pingsured

• Ce que voient vraiment vos visiteurs. Pas seulement « le serveur a répondu », mais « la page a ses produits, ses prix et aucun message d’erreur ».
• Les problèmes de référencement à la prochaine vérification, pas au prochain passage du robot. Un noindex ou une balise canonique erronée est repéré dans l’intervalle de vérification — quelques minutes, et non les semaines qu’il faut pour qu’il se traduise par une perte de trafic.
• Des sélecteurs que vous connaissez déjà, librement combinés avec le code de statut, une recherche de texte et des vérifications d’en-têtes ; le ping ne réussit que si toutes réussissent.
• Chaque emplacement séparément. Une page qu’un nœud de CDN sert périmée, ou qu’une règle de pare-feu bloque dans une région, échoue depuis cet emplacement sans être masquée par les autres.
• Facile à exclure de vos statistiques. Chaque requête porte le User-Agent Pingsured/1.0, et nos vérifications partent d’adresses publiées.

Limites à connaître

• Les vérifications lisent le HTML envoyé par votre serveur ; elles n’exécutent pas de JavaScript. Le contenu qu’une application monopage affiche dans le navigateur n’y figure pas — vérifiez plutôt l’API qui lui fournit ses données.
• La page est lue jusqu’à 1 Mo. Un HTML plus long est vérifié jusqu’à cette limite : un élément proche de la fin d’une très grande page peut ne pas être trouvé.
• Les vérifications envoient des requêtes GET ou HEAD et peuvent ajouter des en-têtes de requête et une authentification HTTP basique. Les pages derrière un formulaire de connexion ne peuvent pas être vérifiées.