Aller au contenu principal

Site de préproduction : éviter que Google indexe vos essais

Préproduction privée, noindex, robots.txt : protégez votre site de test et vérifiez les bons réglages avant le lancement.

Publication
KADRI AI
Publié le
Sources vérifiées le
Lecture
6 min
Sommaire
  1. Décider ce qui peut réellement être public
  2. Comprendre le piège de robots.txt
  3. Réserver noindex aux contenus accessibles
  4. Tester avec une session sans accès
  5. Préparer une bascule avec deux contrôles
  6. Si la maquette apparaît déjà dans Google
  7. À retenir avant de partager une maquette

Votre nouveau site est presque prêt. L’équipe relit les pages sur une adresse provisoire, valide les photos et ajuste les offres. Cette version de travail, appelée préproduction, mérite une décision explicite : qui peut la consulter, et doit-elle apparaître dans Google ?

Pour une PME, le risque concret est simple : un prospect arrive sur une maquette, lit une offre encore en discussion ou utilise un formulaire de test. Voici une méthode pour encadrer cette version, puis ouvrir le bon site au moment du lancement.

1. Décider ce qui peut réellement être public

Commencez par classer le contenu de la préproduction. Contient-elle seulement des textes fictifs et des photos déjà publiques ? Ou présente-t-elle des tarifs non validés, des dossiers clients et des informations internes ?

Dans le second cas, protégez l’accès par authentification. Google recommande la protection par mot de passe pour les contenus privés ou confidentiels. Une consigne d’indexation laisse le contenu accessible à toute personne disposant du lien. Source : Google, contrôler les contenus partagés.

Pour votre projet, formalisez trois éléments : les personnes autorisées, le responsable des accès et la date de fermeture de l’environnement. Utilisez autant que possible des données fictives pendant les essais.

Demandez aussi la liste complète des adresses : sous-domaine de préproduction, adresse fournie par l’hébergeur, aperçus de déploiement et fichiers téléchargeables. La protection doit couvrir les chemins permettant d’atteindre les contenus, y compris les PDF ouverts directement.

2. Comprendre le piège de robots.txt

Le fichier robots.txt indique aux robots les URL qu’ils peuvent explorer. Google précise qu’une URL interdite à l’exploration peut malgré tout apparaître dans ses résultats si elle est connue par d’autres liens. Ce fichier ne constitue donc pas une méthode fiable pour retirer une page de Google. Source : introduction à robots.txt.

Exemple fictif : votre prestataire bloque l’exploration de la maquette, puis un partenaire publie son adresse dans une page accessible. Le blocage ne suffit pas à garantir l’absence de cette URL dans les résultats.

La question à poser à votre prestataire est précise : « Avons-nous limité l’exploration, empêché l’indexation, ou fermé l’accès ? » Ces trois objectifs nécessitent des vérifications différentes. Inscrivez la réponse dans votre liste de recette, à côté de l’adresse concernée.

3. Réserver noindex aux contenus accessibles

Si une page peut rester publique mais doit être exclue des résultats, la directive noindex permet de le demander à Google. Elle peut être placée dans une balise HTML ou dans l’en-tête HTTP X-Robots-Tag. L’en-tête convient aussi aux ressources non HTML, notamment aux PDF. Source : bloquer l’indexation avec noindex.

Point décisif : Google doit pouvoir explorer la ressource pour lire cette directive. Bloquer la même URL dans robots.txt peut l’empêcher de voir noindex. Google ne prend pas non plus en charge une directive noindex inscrite directement dans robots.txt. Même documentation Google.

Pour une préproduction privée, conservez l’authentification : inutile de rendre des documents confidentiels accessibles dans le seul but de laisser Google lire une balise. Pour une démonstration volontairement publique, vérifiez la directive sur chaque type de contenu concerné.

Évitez la réponse « l’option est cochée dans le CMS ». Demandez plutôt le résultat observable : que renvoie réellement la page ? Une capture du réglage aide à comprendre la configuration ; une vérification de la réponse permet de contrôler son application.

4. Tester avec une session sans accès

Voici une recette simple à confier à la personne qui valide le site. Elle complète le travail technique du prestataire.

  1. Ouvrez une fenêtre privée, sans session autorisée sur la préproduction.
  2. Essayez l’accueil, une page intérieure et une URL de document connue.
  3. Testez aussi l’adresse d’aperçu fournie par l’hébergeur, si elle existe.
  4. Vérifiez que les contenus privés restent inaccessibles avant connexion.
  5. Pour les contenus volontairement publics, faites contrôler la présence de noindex dans le HTML ou les en-têtes appropriés.
  6. Notez l’adresse exacte, la date, le résultat attendu et le résultat obtenu.

Une fenêtre privée sert ici à tester l’accès sans votre session habituelle. Pour savoir ce que Google connaît d’une URL, utilisez l’inspection d’URL dans une propriété Search Console qui couvre cette adresse. L’outil distingue les données de la version indexée et le test en direct. Un ancien état ne prouve donc pas que votre correction vient d’échouer. Source : inspection d’URL.

5. Préparer une bascule avec deux contrôles

Le jour du lancement, prévoyez deux lignes distinctes dans la recette : le site public doit être accessible ; la préproduction doit conserver sa protection.

Sur les pages publiques destinées au référencement, faites vérifier qu’aucune directive noindex de test n’a été conservée. Contrôlez également que robots.txt ne bloque pas par erreur leur exploration. Faites ces vérifications sur l’adresse finale, après le déploiement.

En parallèle, décidez du sort de la copie de travail : maintien sous accès restreint pour les prochains essais, ou fermeture lorsqu’elle devient inutile. N’enlevez pas sa protection simplement parce que le site principal est lancé.

Pour éviter les oublis, attribuez les rôles avant la bascule : une personne applique les réglages, une autre vérifie les URL finales et donne son accord. Conservez un petit échantillon représentatif : accueil, service, article et document téléchargeable. Ajoutez les modèles particuliers de votre site.

6. Si la maquette apparaît déjà dans Google

Commencez par sécuriser ou supprimer les contenus qui ne devraient pas être accessibles. Listez les URL concernées et leurs variantes : une correction limitée à l’accueil peut laisser des pages intérieures ouvertes.

Pour accélérer le masquage dans Google, le propriétaire du site peut utiliser l’outil de suppression de Search Console. Google indique que ces demandes sont temporaires, pour environ six mois. Une mesure durable doit les accompagner : suppression du contenu, protection par mot de passe ou noindex lorsque l’accès public reste acceptable. Source : retirer une page de Google.

Consignez ensuite les contrôles à refaire et leur responsable. Un résultat de recherche peut rester visible pendant le traitement ; cela justifie un suivi, sans rouvrir une page privée pour essayer d’accélérer sa disparition.

À retenir avant de partager une maquette

Écrivez une règle courte : qui peut ouvrir cette version, comment son accès est vérifié et ce qui changera au lancement. Le bon livrable est une liste d’URL testées avec leurs résultats attendus. Vous pourrez ainsi relire et présenter votre futur site sans laisser la version de travail devenir une seconde vitrine.

Références

Sources officielles

  1. Google — Contrôler les contenus partagésdevelopers.google.com
  2. Google — Introduction à robots.txtdevelopers.google.com
  3. Google — Bloquer l’indexation avec noindexdevelopers.google.com
  4. Google — Inspection d’URLsupport.google.com
  5. Google — Retirer une pagedevelopers.google.com

Sources consultées le . Les disponibilités et conditions peuvent évoluer.

Services et références

Pour aller plus loin

À propos de cette publication

KADRI AI

Veille et analyses KADRI AI : sources officielles datées, applications possibles pour les PME et limites explicites. Les annonces des éditeurs sont distinguées de notre analyse.

Partager

De la lecture au projet

Une idée à mettre à l’épreuve ?

Partons de votre processus, de vos outils et d’un résultat que votre équipe peut vérifier.