Une préproduction indexée par Google expose des travaux non publiés et crée du contenu dupliqué avec le site de production. La seule protection fiable est un mot de passe (authentification HTTP). L'en-tête X-Robots-Tag: noindex est un bon complément. Le fichier robots.txt seul ne suffit pas : il empêche l'exploration, pas l'indexation. Si votre préproduction est déjà dans Google, ajoutez d'abord le noindex, puis demandez la suppression dans la Search Console.
Pourquoi une préproduction finit dans Google
Une préproduction est une copie du site, sur une adresse séparée, qui sert à tester avant la mise en ligne. Elle n'est pas censée être publique. Pourtant, Google en trouve beaucoup. Trois raisons reviennent :
- Un lien qui traîne : un email transféré, un ticket public, un lien laissé dans le site de production par erreur.
- Un sitemap copié depuis la production, qui liste toutes les pages de la préproduction.
- Un nom public : chaque certificat HTTPS est publié dans les journaux Certificate Transparency, avec le nom du sous-domaine. Une préproduction en HTTPS laisse donc son nom dans un registre public.
Dans notre étude sur les 70 sites clients d'une agence web, une vingtaine de préproductions s'ouvraient sans mot de passe, et Google en avait indexé une partie.
Les risques
| Risque | Conséquence |
|---|
| Contenu dupliqué | Google voit deux versions du même site et peut choisir la mauvaise. |
| Page concurrente dans les résultats | Un visiteur arrive sur la préproduction, avec des prix ou des textes faux. |
| Fuite de travaux non publiés | Maquettes, nouvelle offre, tarifs à venir visibles par tous, concurrents compris. |
| Données de test | Faux clients, commandes de test, parfois une copie de la vraie base. |
| Accès administrateur | La page de connexion de la préproduction est exposée, souvent avec des mots de passe faibles. |
Le dernier point est souvent sous-estimé. Une préproduction est rarement mise à jour aussi vite que la production. Ses extensions sont parfois anciennes, ses comptes partagés entre plusieurs personnes.
Les protections, de la plus efficace à la moins efficace
1. Un mot de passe (authentification HTTP)
C'est la seule protection qui bloque à la fois Google et les visiteurs. Le serveur demande un identifiant avant d'afficher la moindre page. Google ne peut rien explorer ni indexer.
Avec Apache, dans le fichier .htaccess de la préproduction :
AuthType Basic
AuthName "Preproduction"
AuthUserFile /chemin/vers/.htpasswd
Require valid-user
Le fichier de mots de passe se crée avec htpasswd -c /chemin/vers/.htpasswd client. Placez-le en dehors du dossier public du site.
Avec Nginx, dans le bloc server de la préproduction :
auth_basic "Preproduction";
auth_basic_user_file /etc/nginx/.htpasswd;
Pensez aux exceptions utiles : un service de paiement qui doit joindre une URL de retour, ou un outil de test automatisé. Autorisez ces adresses précisément plutôt que de retirer le mot de passe.
2. L'en-tête X-Robots-Tag: noindex
Cet en-tête demande aux moteurs de ne pas indexer les pages, quel que soit leur type (HTML, PDF, images). Il s'ajoute au niveau du serveur, sans toucher au site :
# Apache
Header set X-Robots-Tag "noindex, nofollow"
# Nginx
add_header X-Robots-Tag "noindex, nofollow" always;
C'est un excellent complément au mot de passe, mais pas un remplacement : les visiteurs, eux, voient toujours le site. Vous pouvez vérifier les en-têtes envoyés avec notre outil d'analyse des en-têtes HTTP.
3. Le réglage WordPress « Demander aux moteurs de ne pas indexer ce site »
Dans Réglages, puis Lecture. WordPress ajoute alors une balise noindex dans les pages. C'est utile, mais fragile : le réglage est copié d'un environnement à l'autre lors des migrations. Il arrive qu'il parte en production, et le vrai site disparaît alors de Google. À l'inverse, il est souvent désactivé sur la préproduction après une copie depuis la production.
4. La restriction par adresse IP
Réserver l'accès aux adresses de l'agence et du client est efficace, mais contraignant : télétravail, connexion mobile, client qui change de réseau. À réserver aux environnements internes.
Pourquoi robots.txt ne suffit pas
Un Disallow: / dans robots.txt interdit à Google d'explorer les pages. Il ne lui interdit pas de les indexer. Si Google connaît une URL par un lien externe, il peut l'afficher dans les résultats, avec la mention « Aucune information n'est disponible pour cette page ».
Pire : une page bloquée par robots.txt ne peut pas être lue, donc Google ne voit jamais sa balise noindex. Les deux protections s'annulent.
Faire désindexer une préproduction déjà dans Google
- Ajoutez le noindex (en-tête
X-Robots-Tag ou balise), et laissez Google explorer les pages. Ne bloquez surtout pas par robots.txt à ce stade, sinon Google ne verra jamais le noindex.
- Déclarez la préproduction dans la Search Console comme une propriété, puis utilisez l'outil Suppressions pour masquer rapidement les URL des résultats.
- Attendez que les pages sortent de l'index. L'outil de suppression les masque environ six mois. Le noindex, lui, les retire durablement une fois les pages explorées à nouveau.
- Ajoutez ensuite le mot de passe, qui empêchera toute nouvelle indexation.
Vérifier vos préproductions
- Dans Google : tapez
site:preprod.exemple.fr, ou site:exemple.fr -www pour voir tous les sous-domaines indexés.
- Dans les journaux Certificate Transparency : le site crt.sh liste tous les certificats émis pour un domaine. Une recherche sur
%.exemple.fr montre les noms de vos préproductions tels que n'importe qui peut les voir.
- Depuis une navigation privée : ouvrez chaque préproduction. Si une page s'affiche sans demander de mot de passe, elle est publique.
Ces mêmes journaux servent aussi à repérer les sous-domaines abandonnés, qu'un tiers peut parfois récupérer. Voir notre article sur les sous-domaines oubliés.
Une règle simple pour les agences
Le plus sûr est de ne pas compter sur la vigilance de chacun, mais sur un réglage par défaut. Concrètement :
- Protégez le domaine de préproduction entier, pas chaque site. Un mot de passe et un en-tête
X-Robots-Tag posés au niveau du serveur couvrent automatiquement toute nouvelle préproduction.
- Utilisez un domaine dédié aux préproductions, distinct de celui de l'agence. Une erreur d'indexation ne touche alors pas votre propre site.
- Supprimez les préproductions une fois le site livré. Une préproduction oubliée vieillit sans mises à jour et devient une porte d'entrée.
- Ne copiez jamais la vraie base clients en préproduction sans l'anonymiser. Une fuite de préproduction devient alors une fuite de données personnelles.
- Vérifiez une fois par mois avec une requête
site: sur votre domaine de préproduction.
Ces réglages prennent une heure à mettre en place et évitent la question pour tous les projets suivants. Pour aller plus loin sur la gestion d'un parc de sites clients, voir comment surveiller les domaines de tous vos clients.
Questions fréquentes
Le noindex suffit-il à protéger une préproduction ?
Non. Il empêche l'indexation par les moteurs respectueux des consignes, mais la préproduction reste ouverte à tous ceux qui ont l'adresse. Seul un mot de passe la rend réellement privée.
Une préproduction protégée par mot de passe nuit-elle au SEO du site ?
Non. Google ne voit rien de la préproduction, donc aucun contenu dupliqué. C'est même la configuration la plus saine.
Combien de temps pour qu'une préproduction disparaisse de Google ?
Avec l'outil de suppression de la Search Console, les URL disparaissent des résultats en un jour environ. Leur sortie définitive de l'index dépend du passage de Google sur les pages avec le noindex, de quelques jours à quelques semaines.
Faut-il éviter le HTTPS sur une préproduction pour ne pas exposer son nom ?
Non. Le HTTPS reste indispensable, ne serait-ce que pour tester le site dans les mêmes conditions que la production. Partez du principe que le nom sera public, et protégez la préproduction par un mot de passe.