L’onboarding monitoring se termine quand une fiche est remplie et qu’un e-mail de test est arrivé dans la bonne boîte. Pas quand l’URL est collée dans l’outil. SiteGarde enverra un message au changement d’état : encore faut-il que l’URL soit la production, que le code attendu soit le bon, et que le destinataire lise cette boîte. La checklist ci-dessous est le livrable, cochée dans le dossier du client.
Avant d’ajouter la première URL
Récupérez, par écrit, cinq éléments. S’il en manque un, vous n’activez pas les alertes. Vous notez le manque.
- L’URL canonique de production, celle qui doit répondre 200, avec le bon hôte (www ou non, https).
- Deux URL stables de plus au plus : la page de demande (contact, devis, paiement) et, seulement si le contrat le couvre, l’administration.
- Un mot présent dans le HTML de l’accueil, qui survit à un changement de une. Le nom du site convient.
- Le destinataire : adresse de l’agence. L’adresse du client seulement si elle est prévue, et jamais en seul destinataire tant que le test n’est pas confirmé.
- L’URL de staging, pour l’exclure. Elle ne se découvre pas toute seule. Demandez-la. Si elle répond 200 sans authentification, ce n’est pas encore un sujet d’alerte client : c’est un sujet d’indexation à traiter à part.
Vérifiez chaque URL comme dans tester la disponibilité. Notez le code réel. Si l’accueil répond 301, l’attendu n’est pas 200 sur cette variante : soit vous suivez la cible du 301, soit vous surveillez le 301 lui-même. Surveiller un 301 en exigeant un 200 produit une alerte permanente.
L’ordre de mise en place
- Créez le projet au nom du client, pas au nom de l’URL seule. Vous aurez d’autres URL.
- Ajoutez l’accueil avec le code et le mot. Lancez un contrôle immédiat. Le premier résultat doit être conforme. S’il est déjà en échec, corrigez l’attendu ou le site avant d’inviter qui que ce soit à surveiller.
- Ajoutez la deuxième URL. Pas le sitemap entier.
- Réglez le destinataire sur la boîte d’agence. Désactivez un envoi vers le client tant que le modèle de message n’est pas décidé.
- Envoyez un essai (changement d’état de test, ou coupure volontaire courte sur une URL non publique si vous avez ce moyen). La personne nommée répond qu’elle a vu l’e-mail, et depuis quelle boîte.
- Écrivez la fréquence. Elle découle du délai du contrat, pas du réglage le plus court disponible.
- Notez ce qui est exclu : staging, blog, fichiers statiques.
- Rangez la checklist cochée, avec la date et le nom de la personne côté client qui a confirmé le test.
Sans l’étape 5, vous avez un projet. Vous n’avez pas un onboarding. Le premier vrai incident partira vers une adresse que personne n’a ouverte.
Les accès dont vous n’avez pas besoin pour cette checklist
Surveiller une URL publique ne demande pas le mot de passe WordPress ni le panneau d’hébergement. Les demander pour le monitoring mélange deux sujets. Les accès d’intervention se traitent dans le registre des comptes, et Search Console par invitation, comme dans partager l’accès Search Console. Ne bloquez pas l’onboarding monitoring sur un accès administrateur. Ne profitez pas non plus de l’onboarding pour collectionner des accès dont la fiche ne parle pas.
Ce que vous remettez au client
Une page : URL surveillées, code attendu, mot, fréquence, qui est prévenu en premier, ce qui n’est pas surveillé, heure du test d’alerte. Le client signe ou répond par e-mail. Cette page évite, trois mois plus tard, la phrase je croyais que vous voyiez aussi les formulaires. Les formulaires ne sont pas dans cette checklist. Les ajouter plus tard est une autre fiche.
Quand plusieurs comptes s’ouvrent le même mois, la même checklist évite les projets copiés avec l’URL du client précédent. Le cadre multi-clients est dans monitoring pour agences. L’onboarding, lui, se juge à la checklist rangée, pas au nombre d’URL ajoutées.