Un site de staging n’est pas un petit site de production. Il est là pour essayer une mise à jour, il est souvent protégé par une authentification HTTP (réponse 401 sans identifiants), et il ne doit pas être indexé. Le surveiller comme l’accueil public — même destinataire, même seuil, même mot dans le HTML — fabrique de fausses alertes et, pire, peut faire envoyer au client un message sur une URL qu’il ne doit pas voir. La question n’est donc pas oui ou non dans l’absolu. C’est : quel contrôle, dans quel projet, vers qui.
À quoi le staging doit répondre
Depuis l’extérieur, sans mot de passe, la réponse saine est un 401 (ou un 403 si vous filtrez par adresse IP). Ce n’est pas un 200. Un 200 public sur staging.example.com veut dire que la copie est ouverte. Regardez alors trois points, le jour même :
- Le robots.txt. Un
Disallow: /limite les robots qui le respectent. Il ne retire pas une URL déjà indexée. - La balise meta robots
noindexsur les modèles, ou l’en-têteX-Robots-Tag: noindex. - Search Console : si une propriété existe pour cet hôte, regardez si des URL sont indexées. Sinon, une recherche
site:sur l’hôte de préproduction donne un indice, pas une preuve exhaustive.
Les pièges du robots.txt, y compris un fichier de préproduction recopié en production, sont dans robots.txt : configuration et pièges.
Ce qui mérite un contrôle, et ce qui n’en mérite pas
| Contrôle | Utile sur le staging | Destinataire |
|---|---|---|
| Code 401 sans identifiant | Oui, pour voir si la porte s’ouvre toute seule | Interne agence, e-mail du matin |
| Code 500 | Oui, la copie est cassée avant un essai de mise à jour | Interne, pas le client |
| Mot de passe dans l’URL de contrôle | Non | Fuite dans les journaux |
| Mêmes alertes SMS que la production | Non | Réveil inutile |
| Certificat au nom du mauvais hôte | Oui, une fois | Interne |
| Indexation | Oui, une fois par mois | La personne qui met en ligne |
SiteGarde peut suivre une URL de staging comme une URL de production : même type de contrôle HTTP. La différence est dans votre réglage, pas dans le protocole. Mettez ces URL dans un projet ou un nommage à part, avec un e-mail interne. Ne les mélangez pas au projet dont les alertes partent vers le client.
Le jour où la préproduction est dans l’index
Retirer le Disallow ne suffit pas, et l’ajouter non plus si Google a déjà la page. Il faut un noindex effectif (la page doit être explorée pour que Google voie le noindex : un robots.txt qui bloque tout peut empêcher de voir la balise). Puis Inspection de l’URL, et demande de suppression si des résultats sont encore visibles. Ensuite seulement vous refermez l’authentification. Documentez l’hôte dans la fiche projet : ne pas soumettre ce sitemap dans la propriété de production. Un sitemap de staging envoyé par erreur est une cause classique de mélange des deux environnements.
Pendant une recette, vous pouvez ouvrir temporairement une IP. Notez la date de réouverture du 401 dans le ticket de mise en ligne. Une recette encore ouverte lundi est un 200 public oublié. Le contrôle du matin le voit, à condition qu’il attende un 401 et non un 200.
La règle dans la fiche projet
Écrivez trois lignes : l’URL de staging, le code attendu depuis l’extérieur (401), le fait que le client n’est pas destinataire. Ajoutez qui a les identifiants, dans le coffre, pas dans la fiche. Le livrable est cette règle, relue à chaque ouverture de compte.
La production, elle, reste sur sa propre fiche, avec ses destinataires. Organiser les deux sans les croiser est le même travail que le monitoring de plusieurs clients : des projets séparés, des seuils séparés. Le staging n’a pas besoin d’une astreinte. Il a besoin de ne pas fuir, et de répondre encore le jour où vous voulez y tester une mise à jour.