Arrêtez d’indexer les environnements de préprod

S’il y a bien une erreur stupide mais qui est constamment répétée sur la plupart de mes sites clients, c’est l’indexation des environnements de préprod. Vous savez, les fameux staging.monsite.com ou encore prd.monsite.com, sans compter le célèbre preprod.monsite.com.

Comme moi, malgré de précieuses recommandations auprès des équipes techniques/gestion de projet, vous avez vécu ce problème lorsque le chef de projet vous dit que l’environnement de préprod est accessible sans mot de passe et depuis l’IP de l’entreprise.

Et comme moi, vous vous êtes aperçu qu’il ne savait pas vraiment de quoi il parlait puisque l’URL était accessible de partout… Bref !

Il existe 3 façons efficaces de ne pas indexer votre environnement de préprod.

1) Restriction par user/mot de passe

Le plus efficace, contre tout type d’accès. Faites en sorte que l’accès à la préprod nécessite de remplir un champ avec un nom d’utilisateur et un mot de passe. Dès que c’est entré, le site s’affiche. De cette façon, aucun risque que Google crawle et indexe la duplication.

2) Restriction de l’adresse IP

Autre moyen possible, restreindre l’accès par adresse IP. En mettant uniquement l’IP de votre entreprise, le site sera accessible seulement depuis les machines qui ont cette ip. Pas de risque à ce que Google vous indexe également, mais pensez à vérifier que la restriction est bien appliquée à une seule IP… J’ai déjà vu des surprises.

3) Ajout d’une meta robot

Vous vous fichez que n’importe qui puisse voir la préprod et que les moteurs passent dessus ? Soit, mais pensez à mettre au moins des balises pour restreindre l’accès aux robots :

<meta name=”robots” content=”noindex, nofollow”>

De cette façon, on interdit aux moteurs de suivre et indexer la page dans les résultats de recherche. La meta tag permet de le faire efficacement. Truc pratique, ça vous permettra de vérifier quelques points directement en ligne, comme par exemple la validation de l’implantation de microdata à grande échelle.

Le truc qui ne fonctionne pas : le fichier robots.txt

En revanche, ne comptez pas sur votre fichier robots.txt pour interdire l’accès de votre préprod aux moteurs.

User-agent:*
Disallow: /

Google va quand même indexer vos pages et ça va être… Sale. Bref, laissez tomber le fichier robots.txt si c’est pour éradiquer la préprod des résultats des moteurs.

Si vous me lisez régulièrement, n’hésitez pas  replonger la tête dans les contenus du blog relatifs au fichier robots.txt. Vous connaissez l’efficacité de ce fichier, non ? Bref, ce rappel, bien qu’un peu “SEO beginner” m’a paru nécessaire car j’ai encore vécu récemment ce genre de souci pour l’un de mes clients.

Pourquoi je vous dis tout ça ?

A votre avis, qui se charge de lister les URL indexées de la préprod pour les faire rediriger par la suite en 301… ? C’est bibi ! Mais plus sérieusement, c’est surtout du temps et de l’argent perdus inutilement pour vous, comme pour le client. Pensez à mettre votre spécialiste SEO au tout début du projet.

16 réflexions au sujet de “Arrêtez d’indexer les environnements de préprod”

  1. “Coup de gueule” justifié !
    Cette erreur est tellement répandue et pourtant comme tu l’indiques , des solutions existent.
    Une autre solution pratique est l’entête HTTP X-Robots-TAG à mettre coté serveur (en général les serveurs sont séparés donc ça évite de se retrouver avec ça en prod ^^)

  2. Effectivement, ça n’est pas du propre !
    Par contre, modifier les entêtes HTML ou même le robots.txt, ça peut être difficile étant donné que la préprod est censé être identique (ou prochainement) à la prod, donc gérer les différences à ce niveau, bof…
    Et puis l’authent ou le filtrage IP ça n’est malheureusement pas toujours possible (déterminable ou techniquement faisable).
    Par contre l’entête HTTP je regarderai ça, ç’a l’air effectivement de répondre à mes besoins (si les crawlers le supportent bien -_-‘), pratique ! Ne serait-ce qu’entre vhosts différents.

  3. Hello Arnaud,

    Je suis d’accord avec toi sur l’objectif et en grande partie sur les moyens.
    Le robots.txt fonctionne, mais n’est pas suffisant. Les pages ne sont pas indexées mais connues (Le crawler identifie les liens, mais ne les suit pas). C’est pour cela que le snippet devient : “La description de ce résultat n’est pas accessible à cause du fichier robots.txt de ce site”
    Attention au changement de code. En effet, un environnement de préprod idéal est 100% identique à celui qui sera mis en prod. Le risque du rajout d’un meta robot est de le retrouver en prod (déjà vu)
    La restriction par ip ou Login / password est selon moi la solution la plus efficace.

  4. Pour avoir déjà eu le problème chez un client, j’avais simplement fait une redirection en 301 de toutes les URL de la preprod vers la prod si on ne venait pas visiter le site avec l’IP de la boîte. Simple et efficace :)

  5. Effectivement, coup de gueule justifié. Et je confirme le fait que ce problème est bien plus répandu qu’on ne le croit, et que le robots.txt ne sert effectivement à rien.

    Le mieux d’ailleurs, c’est sans doute de travailler en local en configurant son serveur local comme celui de production. ;)

  6. merci pour l’info. C’est dingue quand même, les solutions ont l’air si simple alors que vous dites que l’erreur se produit presque systématiquement

  7. Merci pour cette mise au point.
    Mais je pense qu’il faut utiliser plusieurs de ces méthodes.
    La première (MDP) pour empêcher les robot de visiter le site et la meta robot pour empêcher les robots d’indexer la page d’accueil (avec MDP).

  8. Un moyen simplissime d’appliquer la solution #1 (username et mot de passe), que j’emploie, est d’utiliser le .htaccess pour restreindre l’accès au sous-domaine en développement.

    Une chose que j’ai appris, c’est qu’un sous-domaine de développement “secret” ne restera jamais secrèt pour Google. Il suffit de citer le lien dans un courriel passant par Gmail pour que le moteur de recherche indexe l’URL!

  9. Je confirme que cette pratique est plus répandu qu’on ne le pense.
    En complément j’ajouterais qu’il est aussi indispensable d’enlever ces verrous une fois le site réellement en prod.
    Ne pas faire référencer le site de pré-prod c’est bien. Faire référencer le site de prod, c’est mieux ;-)

  10. Pour ma part, je déconseille fortement de travailler en local. Il y a toujours des écarts et nouveaux bugs lorsque l’on fait la transition entre le local et la prod. Autant travailler directement sur le vrai environnement de travail, ça évitera les mauvaises surprises ;)

  11. Non c’est sûr, même avec un mot de passe, la première page peut se retrouver au fond de l’index. Mais au moins ça évite de créer de la pollution sur le web et d’avoir du trafic qui se perd dans la préprod :).

  12. Il y a un truc à vérifier quand même : que le site reste accessible à VOTRE crawler, celui qui est utilisé pour vérifier son bon fonctionnement avant la mise en prod.
    Sinon, c’est vrai que le robots.txt n’est pas 100% bulletproof, même sur un site en cours de lancement et donc avec 0 lien.

  13. C’est vrai c’est important à verifier, et ce même si aucun lien ne pointe vers le site (par rapport au commentaire precedent, vu que google explore aussi quelques mails :p ).
    Sinon dans le même genre mais pas lié au SEO, j’ai déja vu le cas ou tu pouvais passer du site de prod à celui de preprod sur quelques liens spécifiques du site, mal foutu. C’est en general transparent pour les utilisateurs qui ne regardent pas l’url, mais ca la fout tout de même mal ….

  14. Merci du rappel… mis sur ke fait accompli, je viens justement de hurler en voyant que presque tout le site d’un client a été dupliqué à cause d’une i-frame sur des sites tiers (pour présenter les produits en marque blanche), générant un sous-domaine avec les mêmes pages… google s’est engouffré dans la brèche, a quasiment tout indexé, et remplacé les pages d’origine dans les SERPs par le contenu des i-frame, avec bien entendu une dégringolade dans le classement…

Les commentaires sont fermés.