Cela arrive trop rarement: des sites de pré-production ou en cours de développement qui sont indexés par GoogleBot, c’est bien souvent la porte ouverte à des tonnes de contenu dupliqué. Il suffit de faire une requête comme celle ci par exemple pour voir l’étendu des dégâts…
Il existe pourtant plusieurs manières pour éviter que cela vous arrive (ou arrive aux site de vos clients), c’est simple à mettre en place et ça vous évitera bien des tracas ! J’ai encore vu le cas récemment, en 2013… (non je ne suis pas énervé ^_^) un petit rappel ne fait jamais de mal.
La fausse bonne idée: le robots.txt
La méthode la plus rapide à mettre en place consisterait mettre en place un robots.txt à la racine du site de dev avec les éléments suivants.
User-agent: * Disallow: /
C’est bien, mais insuffisant: tout le monde connait l’efficacité d’un fichier robots.txt, on en va pas en débattre ici mais en gros, oublier tout de suite cette méthode si c’est la seule protection que vous songez à utiliser. C’est un plus, mais de loin efficace à 100%…
Les bonnes méthodes
La restriction par IP
Cette méthode consiste à autoriser l’accès à votre site de préprod uniquement pour quelques adresses IP (celles de votre proxy ou connexion internet sortante) via le module mod_access d’Apache.
Il vous suffit de placer les éléments suivants dans votre fichier .htaccess ou dans la configuration de l’hôte virtuelle de votre site de dev.
Order Deny,Allow Deny from all Allow from 64.229.13.25 Allow from 64.229.13.26
Cela implique d’avoir des IP fixes bien évidemment. Si ça n’est pas le cas, la méthode suivante sera peut être plus adaptée.
La restriction par mot de passe
Un peu plus longue à mettre en place, cette technique consiste à protéger l’accès à un répertoire de votre serveur avec un nom d’utilisateur et un mot de passe. Nous allons utiliser ici le module mod_authz_user d’Apache.
Voici tout d’abord les éléments à placer dans votre fichier .htaccess
AuthUserFile /var/www/sitepreprod/.htpasswd AuthGroupFile /dev/null AuthName "Accès interdit - site top secret" AuthType Basic require valid-user
Il faut ensuite renseigner le fichier .htpasswd avec une combinaison username/password en créant un nouvel utilisateur. On utilisera la commande htpasswd:
htpasswd -c /var/www/sitepreprod/.htpasswd aymericdev
c’est à dire #htpasswd -c chemindufichierhtpasswd nomutilisateur
Les personnes en chargent du projet n’auront plus qu’à renseigner leurs identifiants avant d’afficher le site.
Restriction avec mot de passe dans le User-Agent
C’est une idée un peu tordu qui m’est venue dans le cas où vous voulez éviter d’avoir à taper un nom d’utilisateur et un mot de passe et que plusieurs personnes travaillant sur le projet on des IP différentes ou dynamiques (ex: freelances en télétravail), ou que vous souhaitez plus simplement simuler le passage d’un robot avec un crawler pour remonter rapidement tous les title/h1/meta etc.
Le principe: Laissez votre site de dev accessible uniquement pour un User-Agent dont vous seul avez le secret (Ex- User-Agent: »Aymeric-Crawler-4568ezrezesdf »).
Nous allons donc modifier le .htaccess pour que le site de préprod ne soit accessible que pour un User-Agent spécifique:
RewriteCond %{HTTP_USER_AGENT} !^Aymeric-Crawler-4568ezrezesdf$
RewriteRule .* - [F]
Il ne vous reste plus qu’à utiliser l’addon User-Agent Switcher de Firefox pour paramétrer votre User-Agent qui fait office de mot de passe: « Aymeric-Crawler-4568ezrezesdf ».
Comme Screaming Frog SEO permet de modifier le User-Agent, il pourra effectuer le crawl sans soucis!
Bloquer l’indexation via les en-têtes HTTP
Plutôt que de bloquer l’accès à GoogleBot et à n’importe quel utilisateur, cette méthode permet d’empêcher l’indexation de votre site de Dev via l’en-tête HTTP X-Robot-Tag, le mod_headers d’Apache doit être activé. On va ajouter à tous les éléments d’un répertoire une en-tête HTTP indiquant à GoogleBot qu’il ne doit pas indexer ces contenus.
Header set X-Robots-Tag "noindex, nofollow"
L’inconvénient est qu’une personne connaissant l’URL pourra accéder aux contenus malgré tout.
Bref
Il existe d’autres méthodes, le but n’est pas de tout lister ici mais surtout de vous alerter en vous donnant le moyen d’éviter l’indexation de vos sites en Version Beta.
Il est également peut souhaitable que n’importe quel internaute tombe sur une version de préproduction d’un site, avec parfois des informations confidentielles…
Quand cela est possible, on préférera tout simplement travailler en local avec une modification du fichier hosts
Cela arrive TROP souvent! Mieux vaut prévenir que guérir 😉
PS: dédicace à @Diije, il saura pourquoi 🙂
Quoi c’est pas bien de filer un accès Beta à Google qu’il voit les futures modifications ? 😀
Il y a longtemps que j’ai opté pour la protection par mot de passe au dossier. Je n’avais pas pensé à le faire par l’IP et cela me semble intéressant.
Bon rappel pour ceux qui veulent éviter l’indexation d’un site en développement. Si certains le font encore par le robots.txt, tant pis.
Sacré scrapeur ce Google 😉
Très bonne piqure de rappel.
Je privilégie aujourd’hui la méthode avec mot de passe.
Une autre solution que j’utilise en tant que développeur est d’avoir recours au fichier hosts. Ca permet de ne pas avoir de mot de passe à taper, de pouvoir bosser à partir de plusieurs postes de travail sans se soucier de l’IP à utiliser et enfin, Google et les regards indiscrets n’ont pas accès aux sites beta.
Le soucis est que ce n’est valable que pour des projets qui n’impliquent pas de validation de clients.
Le truc le plus chiant par la suite, c’est de supprimer les urls de la pre-prod qui ont été indexé. Car lorsque qu’on externalise la production il arrive parfois que le presta ne soit pas du tout au courant qu’une preprod peut s’indexer …
Et comme tu le dis si bien « Cela arrive TROP souvent ! »
Merci pour ce rappel des points 😉
Bonjour Aymeric,
Bon article.
Pour ma part je n’utilise qu’une seule méthode : la méthode de restriction par IP mais au lieu de renvoyer une 403 comme toi je fais une redirection 301 vers la prod pour les IP non autorisées. Ca pose moins de soucis, surtout si des scripts externes sont appelés, ça permet de ne pas les briser. De plus si un lien est fait par inadvertance vers la preprod (peu fréquent); ça envoie le BL vers la prod. Pour cela il faut faire des RewriteCond.
Concernant le robots.txt, en quoi penses tu qu’il n’est pas efficace ?
Dans ce pour quoi il existe (la gestion du crawl), et quand il est correct, il fonctionne à la perfection avec Google. Si bien sur des pages ont été indexées avant sa prise en compte en disallow: / ou si des BL pointent vers les pages disalowées cas ça ne fera qu’afficher un snippet bien connu : « Cette page a été bloquée blabla ».
De toutes façons puisque ça ne bloque pas les visiteurs ce n’est pas une solution.
Enfin attention à X-Robots-Tag : ça n’empêche pas le crawl.
François-Olivier
Pas bête la restriction par IP suivie de la 301! mais par principe, je n’aime pas faire perdre son temps à Googlebot avec des 301 pas forcément pertinentes pour la suite.
Pour le robots.txt, j’ai assez peu confiance en ce fichier, on en des mauvaises expériences avec Sylvain d’Axenet (regarde nos robots;txt pour mieux comprendre ^_^), et je n’ai pas non plus envie de voir « cette page a été bloqué blablabla » dans l’index de Google. Qi’il se mêle de ce qui le regarde ce GoogleBot.
Enfin, dans le X-Robot-Tag il y a un nofollow: le petit robot n’est il pas censé ne pas suivre les liens et donc ne pas crawler la suite ? 😉
PS : si je peux me permettre un lien, j’ai écrit un article complémentaire au tiens ici http://www.nicemedia.fr/blog/articles-referencement/trouvez-desindexez-facilement-les-domaines-100-dupliques-de-votre-site : comment trouver ces fameux domaines parasites indexés : preprod mais aussi IP, staging, mirroirs, etc.
of course tu peux te permettre
Hello,
J’utilise aussi la restriction par Ip.
Après si le site est sous WordPress, je crois que depuis la dernière mise à jour, il y a un champ à remplir pour ne pas être indexé.
Merci Aymeric pour cette piqûre de rappel ! Le truc c’est que très souvent, le site préprod n’est pas considérer psychologiquement comme le site définitif et que le dev qui s’en occupe doit penser que Google crawl uniquement les sites lancés 😉 Ouups la boulette. Dans le même esprit que ta requête, tu as aussi la version Bet 🙂 site:beta.*
Il y a aussi de belles perles :p
J’ai aussi vu des hébergeurs oublier d’enlever les restrictions par en-têtes HTTP. C’est très dangereux cette méthode, car invisible ( tout le monde n’a pas un seo qui veille ).
Le filtre par ip et htpassword c’est top.
j’ai eu une expérience amusante. En 2009, j’ai développé pour un gros client une bourse de devis déménagement qui utilisait toutes les techniques possibles à ma disposition pour passer en premières pages sur toutes les localités de France. Pour les référenceurs qui liront ces lignes, je précise qu’aujourd’hui … c’est mort. Bref, je met une version béta à valider sur un sous-domaine créé pour l’occasion ; sous-domaine d’un site existant et lui, plutôt bien référencé mais rien à voir avec le déménagement! Quelle ne fut pas ma stupeur de voir 15j après le sous-domaine en 1ère page de Google sur le mot « devis déménagement » alors qu’il n’existait aucun lien sur le web en direction de la version béta. Puis avons mis le site en ligne sur ses domaines officiels (et oui 400 en vérité… je vous avez prévenu, avec Penguin/Panda c’est mort….). Et bien sûr j’ai oublié de retirer la version béta trop occupé que j’étais à corrigé les derniers bug dus à l’utilisation réelle du site (10000 visiteurs en quelques jours, ça vous teste les failles d’un site comme jamais vous n’avez imaginé… même les trucs les plus débiles ils vous les font!). Et bien devinez qui sortait toujours en premier sur « devis déménageur » ??? Dans le mile ! Le client a fini par me demander de retirer la version démo qui lui faisait de l’ombre 😀
PS : toujours à destination des référenceurs curieux : Penguin a démoli complétement le système et les 400 sites sont aujourd’hui black listés. Bref.
Sympa ton anecdote 🙂 Merci pour ton retour d’expérience, j’aime ce type de commentaires, ça avait l’air d’être assez épique cette mise en prod…!
C’est pas comme si ça arrivait jamais :
Une bible de la duplication de pre-prod……
site:http://nbs-test.com/
Et pis pas que des petits…..
Es-ce un scandale des agences de dév ? La question se pose…..
A bon entendeur salut !
C’est sympa aussi de faire une redirection vers le site en ligne si jamais Google a commencé à indexer les pages. (en mode 301 bien sur)
Hello Aymeric,
je connaissais le X-Robots-tag, en revanche à quoi sert le « env=headernoindex » en fin de ligne ?
@Thomas : je ne connaissais pas le principe du fichier hosts, ça m’intéresse.
Tu parles bien du fichier hosts en local sur le client ?
Si tu as qq infos à partager sur le sujet, ça m’intéresse merci 🙂
je l’ai enlevé, c’est parce que dans le bout de code que j’utilise, j’avais une RewriteCond juste avant qui faisait appel à une variable d’environnement.
Pour le fichier hosts, en gros tu as le site qui tourne sur le réseau local et tu ajoutes une entrée dans le fichier C:\Windows\system32\drivers\etc\hosts avec le nom de domaine de ton site et l’adresse IP de ton serveur local, comme ça c’est ton poste qui fait directement la résolution DNS.
Vrai qu’il faut toujours éviter le duplicate content, et que ce faire indexer un site de production peut créer une grosse pénalité.
Les astuces que tu donnes sont de bon rappels. Personnellement j’aime bien utiliser login plus mot de passe. Ce qui permet au client de ce connecter. Il y a toujours moyen d’inverser la vapeur mais c’est beaucoup de temps perdu pas grand chose.
mieux vaut penser à verrouiller les site de préprod pour stopper le duplicate content.
Le seul truc qui fonctionne vraiment, c’est les headers noindex.
Parce que même avec un disallow / et un login / mdp, votre url principale se fera indexer.
Par ailleurs, n’imaginez pas que « l’attaque » viendra toujours de l’url principale, car il y a bien des cas dans lesquels des urls profondes se feront indexer.
Pensez à ajouter au cas où un link rel canonical vers l’url de front. Ainsi, si un étourdit partage l’url de backoffice ou de préprod, c’est le front qui prendra le jus.
Faites également très attention aux modules qui cachent des pages en back office / préproduction et qui vous les ressortent en front : je pense aux modules de partage (Facebook, Twitter) ou aux modules de commentaires centralisés (Disqus) avec la même clé API utilisée sur tous les environnements.
Vous devez dans ce cas impérativement forcer l’url de prod en tant qu’url de partage, afin que vous ou vos collègues ne puissiez partager par mégarde un lien indésirable. En effet, un lien partagé, c’est des milliers de liens trois mois plus tard, sur des domaines qui ne sont pas les vôtres, donc sur lesquels vous n’avez pas la main… Et là, bonjour la rigolade pour faire des redirections et récupérer le jus de liens.
En conclusion… Mieux vaut prévenir que guérir !
Quand on dit qu’il faut un seo dans le loop dès le début d’un projet 🙂
ps : Aymeric, mervi pour la mention
ps 2 : mon délire de robots.txt n’est appliqué que sur le blog
Je connais très très bien ce problème qui arrive à beaucoup de système de CMS propriétaires, c’est à dire « hebergés »… A une époque, je tirais avantage de l’usine à gaz pour tester mes préprods… Google se cassait toujours les dents sur mes jeux de cadres et n’indexait jamais rien.
Mais ça, c’était avant… Aujourd’hui je serais plus méfiant s’il fallait le refaire, d’ailleurs je préfère passer par htpasswd 😉
Apparemment le fichier robot.txt n’est pas 100% fiable, mais est-ce que les balises mises sur chaque sont plus efficaces ou cela revient-il au même?
est-ce que les balises « Meta robot noindex » mises sur chaque pages, sont plus efficaces qu’une interdiction dans le fichier robot.txt ?
La Noindex évitera l’indexation mais pas le crawl. Le robots.txt évitera le crawl, à priori.
Pour avoir eu le problème récemment, j’en suis arrivé à mettre en place un système automatique pour que les sites de dev aient systématiquement noindex,nofollow et d’autres trucs pour avoir la paix.
Je ne connaissais pas le header PHP, je vais l’ajouter, merci 🙂
« La Noindex évitera l’indexation mais pas le crawl ».
Ok mais dans l’absolu cela gène en quoi le crawl seul ? A part servir des pages « inutilement »…
Temps perdu par Googlebot qui ne sera pas utilisé ailleurs!
Merci pour le rappel, j’utilise surtout la protection par mot de passe, un pour les dev et u autre pour le client qui veut avoir un aperçue du travail. C’est assez pratique et aussi sécurisé, pas de risque qu’un petit malin découvre l’url de développement.
Au plaisir.
Le soucis avec la restriction via Mot de Passe est que le crawl est super difficile à faire lorsque l’on veut récupérer les URLs (pour le plan de redirection par exemple) à moins d’avoir certains outils pas accessibles à tous. De la même manière, j’ai pu rencontrer pas mal de dev (enfin soit disant dev) qui ne savent pas mettre en place le système par IP.
Donc en effet pas de recette miracle, même si je pense que la méthode la plus efficace pour protéger son site de dev des robots & internautes est la protection par mot de passe.
Pour le crawl, tu peux toujours faire http://username:password@www.monsite.com/ ce qui sous entend que les liens doivent être en <a href= »/lien »>
J’aurais quand même quelques contre exemples. Si vous faites un blocage par ip, le jour ou vous ou le client changez de FAI, ou passez en répartition de charges , il faudra mettre a jour le htaccess (un peu chiant).
Sur un site ecommerce type Magento, si vous avez fait un blocage par password, il me semble que cela va bloquer lorsque le site qui valide le paiement essaiera de contactez le votre.
A mon sens, il faut donc quand même conserver le robots.txt, car lorsque vous leverez les restrictions pour une raison ou pour une autre vous risque d’avoir des pb.
Donc pour moi, ca sera robots.txt + restriction password (sauf quand test du module de paiement).
C’est vrai qu’on a parfois tendance, à tort, à trop faire confiance au robtos.txt. Dans le cas d’un site en preprod les conséquences peuvent être catastrophiques, non seulement en SEO mais aussi en termes de sécurité.
Pour ma part j’utilise souvent la méthode du htpasswd.
En effet le rappel ne fait pas de mal. cela arrive trop souvent. Le robots.txt ? Cela fait un moment que que Google et les autres moteurs en font à leur sauce. Par contre je trouve que vous allez un peu loin avec toutes ces protections : htpasswd + filtre par IP + Noindex +++ ;). Le noindex et un bon htpasswd suffisent non ?
Salut,
Naïf comme jetait juste la première manip était suffisante, maintenant je sais que non et en plus je sais comment faire plus.
Merci et à bientôt.