Votre site peut répondre alors qu’une page importante affiche une erreur, qu’un lien conduit ailleurs ou que les demandes n’arrivent plus. Surveiller le site consiste à choisir ce qu’on observe, reconnaître un écart et savoir qui le traite. Une alerte ne répare rien à elle seule et ne prouve pas que tous les visiteurs rencontrent le même problème.
Ce guide aide à préparer une surveillance limitée aux fonctions utiles à votre activité. Il ne définit ni forfait, ni astreinte, ni disponibilité garantie. La surveillance, l’intervention et la communication aux clients sont trois responsabilités à convenir séparément.
Choisir les pages et les résultats attendus
Commencez par les actions qui comptent : lire votre offre, consulter un produit, trouver un moyen de contact ou accéder à un espace prévu. Identifiez quelques adresses représentatives, leur destination finale et le contenu qui doit être présent. Une page d’accueil accessible ne suffit pas à recevoir le formulaire ou la boutique.
Préparez une fiche pour chaque contrôle : adresse, méthode autorisée, résultat attendu, conditions d’accès, responsable et effet éventuel. Ne transmettez pas de mot de passe ou de lien privé à un service externe sans avoir défini les accès et la confidentialité. Ne supposez pas qu’une adresse peut être appelée sans conséquence simplement parce qu’elle ressemble à une page.
Exemple illustratif : la fiche d’un service doit aboutir à son adresse habituelle et afficher le nom de l’offre ainsi que le lien de contact. Le contrôle signale une disparition de ces éléments ; il ne confirme pas la réception d’une demande. Cette distinction évite de déclarer tout le parcours opérationnel à partir d’un seul écran.
Distinguer disponibilité, contenu et parcours métier
Le statut HTTP décrit la réponse à une requête. Une réponse 200 indique un succès HTTP, pas l’exactitude commerciale de la page. Une redirection doit être examinée jusqu’à sa destination attendue. Une erreur 404 concerne la ressource demandée ; une erreur 500 signale un problème serveur sans en donner la cause précise. La référence MDN des statuts HTTP permet d’interpréter le code observé.
Ajoutez, si nécessaire, une vérification de contenu : titre, texte stable ou présence d’un élément utile. Un écran d’erreur peut être servi avec un statut 200. Le contrôle ne doit pas dépendre d’une formule qui change légitimement, comme un prix promotionnel ou une disponibilité de stock, sans intégrer cette variation.
La vitesse est un autre sujet : un serveur joignable peut répondre lentement, et un chargement rapide peut afficher la mauvaise page. Pour diagnostiquer un retard, utilisez le guide de mesure des lenteurs WordPress, avec ses conditions de test. Ne confondez pas temps de réponse réseau, affichage dans le navigateur et réception d’une commande.
Un parcours métier demande une recette distincte. Les sondes ne doivent envoyer aucun message réel ni engager de paiement réel. Préparez un environnement adapté, des destinataires autorisés et des données de test identifiables avant un essai de formulaire ou de commande. Consulter la page Contact ne prouve pas qu’un message a été reçu.
Définir les observations et les limites du relevé
Choisissez la fréquence selon les fonctions suivies, les contraintes de l’hébergement et votre capacité à agir. Il n’existe pas d’intervalle universel valable pour tous les sites. Des contrôles trop fréquents peuvent ajouter de la charge sans améliorer la réponse si personne ne traite les alertes.
Consignez l’heure, l’adresse, le statut, la destination, le résultat du contrôle de contenu et le point d’observation. Si une mesure manque, notez-la comme manquante. Une sonde distante ne reproduit pas exactement le réseau, le téléphone ou les droits d’un client. Une vérification depuis un autre emplacement peut aider à confirmer un écart, sans représenter tous les visiteurs.
Présentez honnêtement un taux de disponibilité : période observée, fréquence, contrôles réussis, échecs et exclusions éventuelles. Un relevé par intervalles peut manquer une interruption entre deux observations. Il ne permet pas de promettre une disponibilité continue ni de calculer des ventes perdues sans données commerciales adaptées.
Vérifiez aussi la résolution du domaine et la validité du certificat lorsque cela fait partie du périmètre retenu. Un refus d’accès ou une protection anti-abus n’autorise pas à contourner la sécurité. Examinez la règle avec le responsable du site et le fournisseur concerné avant de modifier les contrôles.
Faire parvenir une alerte à une personne responsable
Définissez ce qui déclenche une alerte et ce qui confirme l’anomalie. Un second relevé ou une observation indépendante peut éviter de confondre un incident du site avec celui de la sonde. Le nombre d’essais et le délai doivent rester compatibles avec l’importance du parcours : ne masquez pas un incident confirmé derrière une attente indéfinie.
L’alerte utile indique la fonction touchée, l’adresse, l’heure, le résultat attendu, le résultat obtenu et les vérifications déjà faites. Elle ne contient pas de secrets ni de données de clients. Regroupez les observations qui décrivent le même incident pour éviter une succession de notifications sans information nouvelle.
Convenez du canal, du destinataire, des horaires réellement couverts et du relais en cas d’absence. Vérifiez les dépendances : une notification qui passe par le service indisponible peut ne pas arriver. Recevoir un e-mail ne signifie pas qu’une personne l’a lu ; un acquittement et un responsable identifié peuvent être nécessaires.
Testez la chaîne d’alerte dans des conditions autorisées, avec un événement explicitement identifié comme essai. Il n’est pas nécessaire de rendre le site public indisponible pour vérifier les destinataires. Une promesse d’intervention ne doit jamais être déduite des seules capacités du logiciel choisi.
Examiner l’incident avant de changer le serveur
Conservez les premiers constats, puis recherchez le périmètre touché et les changements récents. Comparez les observations publiques aux journaux et aux informations disponibles chez les prestataires, avec les accès prévus. Distinguez fait observé, cause supposée et cause confirmée. Un code d’erreur seul ne justifie pas un redémarrage automatique.
Ne lancez pas une restauration, une purge de données ou un changement DNS à l’aveugle. Identifiez les conséquences, la personne habilitée à intervenir et le retour arrière. En cas de suspicion de compromission, préservez les éléments utiles au diagnostic et faites qualifier la situation avant une correction qui pourrait les effacer.
Une copie déclenchée après une anomalie n’est pas forcément saine. Pour WordPress, une restauration complète classique exige fichiers et base de données, comme le rappelle la documentation des sauvegardes. Vérifiez la date de la copie et les changements intervenus depuis, notamment les commandes, avant de choisir quoi restaurer. Posséder une sauvegarde ne prouve pas qu’elle a été essayée.
Si une communication est nécessaire, annoncez le problème confirmé, les fonctions concernées et le prochain point d’information convenu. Ne donnez pas une heure de remise en service sans fondement. Une page de statut n’est utile que si sa mise à jour et son accès pendant l’incident sont organisés.
Vérifier le rétablissement et revoir le dispositif
Refaites les contrôles de disponibilité, de contenu et les recettes autorisées du parcours touché. Un écran revenu ne prouve pas que les demandes en attente ou les commandes ont été traitées. Vérifiez ces états séparément avec les personnes responsables, sans relancer automatiquement des messages ou des paiements.
Gardez un bilan court : début observé, périmètre, cause établie ou encore inconnue, intervention, contrôles de retour et action préventive retenue. Ajustez les sondes qui n’ont pas détecté l’écart ou qui ont alerté à tort. Le suivi doit évoluer avec les pages et les connexions du site, pas rester attaché à des adresses abandonnées.
Pour le référencement, Google explique que les erreurs serveur peuvent réduire temporairement l’exploration et qu’un statut 200 ne garantit pas l’indexation. Consultez sa documentation sur les statuts HTTP plutôt que de déduire une perte de positions d’une seule panne. Distinguez l’incident technique des observations faites dans Search Console.
La maintenance du site peut intégrer des contrôles convenus, mais la fréquence, les horaires et les interventions incluses doivent être précisés. Pour préparer votre demande, partagez l’adresse publique, la fonction importante et l’anomalie rencontrée via le formulaire de contact, sans identifiants ni données privées. Nous pourrons délimiter le travail à réaliser et les vérifications à livrer.
