« Vous pouvez m'envoyer le lien, que je voie où ça en est ? » La demande est légitime, et pourtant la bonne réponse n'est pas de donner l'adresse du futur site public. Pendant qu'on le fabrique, un site sérieux ne vit pas sur son adresse définitive. Il vit ailleurs, sur une adresse de préproduction, le temps d'être terminé, vérifié, validé. Ce n'est pas un détail d'organisation : c'est une décision de conduite de projet, et elle évite deux ennuis bien concrets.
Pourquoi on ne construit pas sur l'adresse définitive
La première raison est évidente une fois dite : tant qu'un site n'est pas fini, personne ne devrait tomber dessus par hasard. Un visiteur, un client, un partenaire qui arrive sur une page à moitié montée, avec du faux texte et des images manquantes, en garde une impression durable. Une refonte aggrave le cas : pendant qu'on reconstruit, l'ancien site doit continuer de tourner et de recevoir ses visiteurs. Il ne peut pas être remplacé en direct sous leurs yeux.
La seconde raison est moins visible et bien plus coûteuse, et c'est le cœur de cet article. Un site en construction, laissé accessible quelque part sur le web, finit par être trouvé par Google.
Une préproduction, c'est donc une adresse séparée, souvent un sous-domaine de travail ou une adresse fournie par l'hébergeur, où le site se fabrique, se montre et se valide. Le jour venu, on le bascule vers l'adresse publique définitive.
Le piège : Google peut indexer votre site de test
Le web n'a pas de registre central : pour connaître une page, Google doit d'abord la trouver, en général en suivant un lien. C'est le trajet que j'ai détaillé à propos du chemin d'une page avant d'apparaître dans Google. Un site de préproduction qu'on croit « privé » parce qu'on n'a communiqué l'adresse à personne ne l'est pas vraiment : il suffit d'un lien posé quelque part, d'un outil qui visite l'adresse, et le robot finit par passer.
Les conséquences ne sont pas théoriques. Google peut indexer les pages de test, et vous retrouvez dans ses résultats l'adresse de préproduction au lieu de l'adresse définitive. Pire, le jour de la mise en ligne, les deux versions coexistent un temps, le même contenu à deux adresses, ce qui brouille le choix de l'adresse de référence. On a alors fabriqué soi-même le problème qu'on voulait éviter.
Beaucoup croient régler la question avec une ligne dans le fichier robots.txt qui demande à Google de ne pas explorer le site. C'est une erreur de raisonnement, et elle est vérifiable sur la documentation de Google : le fichier robots.txt gère l'exploration, pas l'indexation. Une adresse bloquée à l'exploration mais pointée par un lien ailleurs peut rester indexée, affichée sans description. Et comme Google ne lit plus la page, il ne voit pas non plus une éventuelle instruction « noindex » posée dessus : bloquer l'exploration empêche justement l'instruction qui retirerait la page.
Les trois façons de protéger une préproduction
Il y a une bonne méthode, une méthode acceptable, et une fausse bonne idée. Dans l'ordre de sûreté.
- Le mot de passe, la plus sûre. Un serveur qui exige une authentification répond au robot « accès refusé » : celui-ci n'atteint jamais la page, donc ne peut ni l'explorer ni l'indexer. C'est la méthode recommandée pour un contenu qui doit rester privé, et celle à privilégier pour une préproduction.
- La balise « noindex » lisible. Si le site de test doit rester ouvert, chaque page porte une instruction noindex, dans une balise meta ou un en-tête HTTP, et Google doit pouvoir explorer la page pour la lire. Donc on ne bloque surtout pas l'exploration par robots.txt en même temps, sinon l'instruction ne sera jamais vue.
- La fausse bonne idée : compter sur un simple « Disallow » dans robots.txt pour empêcher l'indexation. Il empêche l'exploration, pas l'apparition dans les résultats. Seul, il ne protège rien.
Le jour de la bascule
Le passage en ligne n'est pas qu'un changement d'adresse. C'est le moment où l'on retire les protections de la préproduction : on enlève le mot de passe et les instructions noindex, pour que le site public, lui, soit bien explorable et indexable.
L'erreur miroir existe, et elle est redoutable : un site mis en ligne en gardant par mégarde le « noindex » de sa préproduction reste invisible dans Google, parfois pendant des semaines, sans que rien ne le signale. C'est l'une des premières choses à contrôler après une mise en ligne, et l'inspection d'URL de la Search Console le dit en un coup d'œil.
La bascule, c'est aussi le moment de la recette. La préproduction est précisément l'endroit où l'on déroule ce contrôle poste par poste avant d'ouvrir les portes, sur un site complet mais encore à l'abri des regards.
Ce que la méthode ne garantit pas
Une préproduction n'est pas la production. L'adresse change, parfois l'hébergement et les réglages aussi, et certains comportements ne se révèlent qu'une fois le vrai site en ligne, sur le vrai nom de domaine, avec les vrais e-mails et les vrais paiements. Valider en préproduction réduit les mauvaises surprises, il ne les supprime pas, d'où l'intérêt d'une courte surveillance après la bascule.
Et aucune protection n'est absolue : un lien de préproduction partagé largement, un outil qui recopie le contenu, et une partie peut fuiter malgré tout. La règle reste la même : moins le site de test est accessible, moins il y aura à rattraper.
Au fond
Demander « où ça en est » est normal, et un bon prestataire doit pouvoir montrer l'avancement. La bonne réponse n'est pas un lien public jeté à la va-vite, mais une adresse protégée, faite pour être vue par les bonnes personnes et par personne d'autre. Ce qui se joue là n'est pas de la technique pour la technique : c'est la différence entre un site qu'on découvre fini et un chantier qu'on a laissé traîner sous les yeux de tout le monde, moteurs de recherche compris. Si vous préparez une refonte ou une première mise en ligne, c'est l'une des premières questions à poser, et nous pouvons en parler.
Sources
- Google Search Central, « Block Search indexing with noindex » (source primaire, documentation officielle) : l'instruction noindex se pose dans une balise meta ou un en-tête HTTP et n'est pas prise en charge dans le fichier robots.txt ; Googlebot doit pouvoir explorer la page pour voir le noindex, donc une page bloquée par robots.txt ne peut pas être retirée de l'index par cette instruction, consulté le 2026-10-28.
- Google Search Console, aide « Supprimer une page » (source primaire) : pour retirer durablement une page, il faut aussi retirer la règle robots.txt qui la bloque, car Google doit pouvoir lire la page pour constater qu'elle ne doit plus être indexée, consulté le 2026-10-28.
- Search Engine Journal, « How to block Google from indexing a staging site » (presse spécialisée, relayant John Mueller de Google) : pour une préproduction, la protection par mot de passe est la méthode privilégiée, sans toucher aux réglages robots.txt ni noindex du site, consulté le 2026-10-28.
Questions fréquentes
Qu'est-ce qu'une adresse de préproduction ?
Une adresse séparée, souvent un sous-domaine de travail ou une adresse fournie par l'hébergeur, où un site se fabrique, se montre et se valide avant d'être basculé vers son adresse publique définitive. Elle évite qu'un visiteur tombe sur un site inachevé et que Google indexe la mauvaise adresse.
Une ligne dans le robots.txt empêche-t-elle Google d'indexer mon site de test ?
Non. Le fichier robots.txt gère l'exploration, pas l'indexation : une adresse bloquée mais pointée par un lien peut rester indexée, affichée sans description. Pire, comme Google ne lit plus la page, il ne voit pas une balise noindex posée dessus. C'est vérifiable dans la documentation de Google.
Comment protéger efficacement une préproduction ?
Par ordre de sûreté : un mot de passe, car le robot n'atteint jamais la page ; ou une balise noindex que Google peut lire, à condition de ne pas bloquer l'exploration en même temps. Et le jour de la mise en ligne, on retire ces protections, sinon le site public reste invisible dans Google.