Écouter les autres, c'est bien. Tester soi-même, ce n'est pas plus mal.
Après avoir entendu pas mal de choses sur le fait que Google était arrivé à indexer des sites malgré un blocage avec le fichier .htaccess j'avoue avoir eu peur.
À ce jour, c'est la méthode la plus fiable que je connaisse pour empêcher Google d'indexer un site en préproduction.
L'enfer de la préproduction
Lorsque l'on est une agence, on est bien obligé de mettre des sites en ligne alors qu'il sont en cours de développement. D'une part pour faire nos propres tests (affichage multi navigateurs, multi OS, tests des fonctionnalités), mais aussi pour donner un accès au client pour lui permettre d'en vérifier l'avancement ou commencer à rentrer des données.
Le souci, c'est que si on ne fait rien de particulier, le site en préproduction sera indexé par Google. Le moteur a des tas de moyens pour cela ( visite avec le mouchard navigateur Google Chrome, visite avec une barre d'outils Google installée...).
Vous vous retrouvez alors avec des tas de contenus de test qui deviennent accessibles, des tas de pages indexées, qu'il faudra rediriger ou mettre en erreur 410 ensuite.
Si le contenu est définitif mais pas sur la bonne url, cela vous créer des problèmes de contenus dupliqués, bref, des tonnes de soucis pour votre référencement à venir.
Bien évidemment, on peut tenter le coup du disallow, nofollow and co, mais j'avoue ne pas avoir confiance. On a vu Google indexer des pages en disallow simplement parce qu'un lien pointait vers elles, ce qui me fait dire que ce n'est pas très fiable.
Vérifier l'efficacité du .htaccess
Un simple bout de code à placer dans votre fichier .htaccess permet de bloquer l'affichage d'une page en obligeant la saisie d'un login et d'un mot de passe, ce que ne fera pas le crawler d'un moteur.
Afin de revalider cette option, nous avons créé une page comportant du contenu, des mots-clés bizarres, une grosse image, et nous avons demandé à nos chers Cercles de Google Plus d'aller visiter cette page avec le navigateur Google Chrome.
Bien sûr, ils avaient le mot de passe (en fait, tout le détail est ici)
En prime, le lien vers la page était clairement affiché sur le post Google Plus qui a été "plussé" 41 fois et partagé 21 fois.
Le résultat.
OUF ! Google n'a rien indexé.
- La page est introuvable avec la commande "site :"
- Aucun des mots-clés ne permet d'accéder à la page dans Google.
- L'image contenue dans la page n'est pas indexée non plus.
Bref, la technique du filtrage par .htacess à parfaitement fonctionné, vous pouvez dormir sur vos deux oreilles si vous l'utilisez.
Petit conseil
Au sein de l'agence, nous sommes un peu paranos, alors quand c'est possible (quand notre client a une IP fixe), nous filtrons aussi sur les IP. Seules les IP du client et les nôtres sont autorisées à afficher la page, ceci en plus du login et mot de passe.
Exemples
Contrairement à ce que l'on pourrait croire, nombreux sont ceux qui laissent les sites en construction accessibles à Google...
Une belle piste pour les adeptes du NSEO
À lire : méthode pour bloquer les accès avec un .htaccess
Le fait de seulement filtrer les IPs n'est il pas suffisant ? J'ai bien aimé le clin d’œil NSEO de la fin, original venant de ta part ^^
salut sylvain,
Je confirme que les résultats de ton test. Dernièrement un client avait son site en prod accessible à tous. Le site était indexé par Google.
En ajoutant un htaccess, la home a été désindexée. par contre certaines pages profondes sont encore indexées quelques semaines après. Mais même en tapant l'intitulé entier du title de la page et un bout de texte dans la requête les pages ne remontent pas.
Salut Sylvain,
Heureusement le résultat était celui espéré, par contre j'avoue qu'une phrase de ton article m'a laissé sans voix : en ce qui concerne la page en noindex qui a été indexée dont tu parles, tu as l'URL sous la main ? Elle était en noindex dès le départ ou est-ce qu'elle a été d'abord indexée (sans consigne particulière) puis ensuite la directive noindex lui a été rajoutée ? Un lien a été vu mais la page a-t-elle été crawlée ?
Ça déborde un peu du cadre de ton test mais je suis perplexe, et j'aime pas ne pas savoir =)
Hello,
On peut aussi rajouter dans la liste site:test.* et site:temp* ça donne des résultats pas mal.
Personnellement, je n'ai jamais réussi à me faire indexer un site sur un hébergement de production qui se serait trouvé dans un dossier au nom aléatoire et qui ne comporte évidemment aucun lien vers lui, ni aucune référence.
Je n'ai jamais compris comment certains arrivaient même à faire indexer une partie de leur module d'administration !
Salut, Sylvain, quand j’ai fait le test suite à ton tweet, je pensais à autre chose en fait :
Pourquoi ne pas demander à Chrome de mémoriser le mot de passe, en principe pour la visite suivante, pour voir ce qu’il en fait après ?
Euh...
Je ne pige pas trop, c'était quoi le doute ?
Bien sûr que google ne peut pas lire le contenu d'un site protégé par mod_auth_basic... c'est techniquement impossible s'il n'a pas le login et le pass. Nul besoin de test.
Imaginez cinq minutes que ce soit à la portée de google... si Google peut le faire, n'importe qui pourrait le faire, et donc vos belles interfaces d'admin protégées par .htaccess deviennent hackables... (alors qu'elles sont la protection la plus sûre, bien plus qu'une page de log WordPress susceptible de failles.)
Paranoïa, quand tu nous tiens... Logiquement, un accès via htaccess/htpasswd ne peut être contourné par le bot de Google. Pour que Googlebot accède malgré tout à un contenu protégé, il faudrait qu'il capture les identifiants utilisés par un visiteur du site ou les pages affichées via Google Chrome et je ne crois pas que Google irait si loin.
Maintenant, pour dormir sur ses deux oreilles, il faut parfois se résoudre à effectuer ce genre de test, au cas où...
Heu, tu sais que je me suis fait désindexer de Google juste avec la case à cocher de WordPress "demander aux moteur de ne pas indexer ce site" ?!
En moins d'une semaine, j'ai vu mes positions disparaitre comme neige au soleil ! Elle est pas belle la boulette ? (:
J'ai eu un problème une fois sur un site en dev qui s'indexait, une belle frayeur, finalement le tir à été rectifié relativement vite mais tout de même... je ne sais toujours pas d'où Google avait réussi a connaitre l'url de dev... des pistes, mais rien de sur...
Test intéressant et conclusion rassurante. A faire tourner auprès de toutes les agences de dev, même les meilleures car il est malheureusement fréquent de tomber sur des sites dont certaines pages voir même parfois des sous-domaines de préprod se retrouvent indexer par négligence. Comme souvent, c'est pourtant beaucoup plus simple de traiter le problème à la racine en appliquant d’emblée les bonnes pratiques...
Merci pour cet intéressant article mais j'aimerai apporter aussi ma contribution sur l'utilisation du nofollow. J'ai fait un simple test dans le sens où j'ai pris un nom de domaine que je n'avais jamais exploité et sur lequel j'ai créé une page index vierge. Sur un de mes sites web déjà référencé, j'ai fait un lien en nofollow avec une ancre créée spécialement pour le test genre : yapayalle.
Résultat sur google... mon nom de domaine n'est pas ressorti... uniquement le site web qui avait fait le lien !
Même avis que @Alfred, techniquement c'est impossible pour un bot d'outrepasser ce genre de restriction (idem si on bloque au niveau de l'IP)
Pour avoir travaillé sur pas mal de sites en pre-prod -ou du moins pas accessibles par le public- et fouiner dans les logs Apache, je me suis rendu compte d'une chose : tant que les urls ne sont visitées que par moi, GoogleBot ne passe pas (normal on va dire) mais dès qu'on y accède de plusieurs IPs différentes, il se met à passer régulièrement pour essayer d'y acceder et au passage il cherche la présence du robots.txt sur le NDD restreind!
@ Simon
Oui, mais pas toujours possible avec les ip dynamiques
@ Sylvain F
La page était en noindex, mais dans l'extranet du client un lien vers la preprod était accessible dans la partie publique...
Du coup, le snipet était vide, mais la page indexée.
@ Christophe
Le simple fait de visiter la page avec Chrome suffit pour que le crawler aille voir.
@ Christian
Je l'ai fait, à priori ça ne change rien.
@ Alfred
Je pensais comme toi, mais plusieurs SEO ont dit voir des pages indexées, alors dans le doute, j'ai voulu tester en donn&ant toutes les chances à Google. On es donc rassurés 🙂
@4h18
Ca vaut bien le noindex oublié quand on passe en prod 🙂
@ François D
Une barre d'outil Google activée, une visite avec Chrome et il connait l'url.
Comme vous le disiez dans votre article, il est déjà arrivé que google indexe des pages web qu'il n'aurait pas dû !
C'est difficile avec google car il y a que très peu de réels échanges avec ce moteur.
Il communique des infos mais qui laissent supposer trop de choses.
C'est tout est son contraire.
Mais je pense qu'effectivement, le htaccess est imparable pour se protéger du crawl.
==> Le simple fait de visiter la page avec Chrome suffit pour que le crawler aille voir.
Je ne suis pas du tout certain de ça, je reste perplexe, dans tous les cas chez nous. Cependant, nous ne sommes jamais loggé à notre compte quand nous utilisons Chrome. Nous n'utilisons pas non plus la barre Google. Par contre en effet, si l'adresse est distribuée, on peut remarquer que le crawler tente de passer. Ça s'explique notamment par les urls qui traînent dans les e-mails que lit Google. Par ailleurs, contrairement à certains fureteurs, Google n'essaie pas de deviner les noms des dossiers qu'il serait susceptible de découvrir. Le robot de Google s'en tient aux liens, et uniquement aux liens.
Ca vaudrait la peine de faire une batterie de tests rien qu'avec Chrome.
PS : En effet, techniquement il est impossible à un bot de passer outre le fichier .htaccess mais pas pour les hackers ! Il existe des failles .htaccess, dont une qui sévit encore en 2013.
@Sylvain : C'est "marrant", la question que je me pose est en fait est-ce que Google a crawlé la page ? Si ce n'est pas le cas, ça voudrait dire qu'il n'a pas pu voir le noindex mais qu'il l'a quand même indexée, sans la crawler (comme par exemple avec les fichiers swf si je ne m'abuse ?)
@ Christophe
Ca par contre, j'avais fait le test. Plusieurs fois le même lien utilisé dans Gmail, et bien il n'est jamais passé voir la page (rien dans les logs et pas d'indexation).
En revanche, on retrouve bien des traces de passage du bot après des visites avec Google Chrome.
@ Sylvain F
Si tu parles de la page dont je parle dans mon commentaire n°13, oui, il l'a bien crawlé. D'ailleurs, je ne vois pas comment il l'aurait indexé sans la crawler 🙂
Tiens, tant qu'on y est, j'ai oublié de parler d'une erreur fréquente qui consiste à empêcher le crawl avec le robots.txt et à mettre un noindex dans la page.
Et bien bêtement, on empêche google de crawler, donc il ne sait pas que la page est en noindex... Mais du coup, si un lien pointe vers la page, il l'indexe, mais sans snippet. Dans celui-ci il indique que le robots.txt lui bloque l'affichage de ce snippet.
Hello,
Je me souviens d'une vidéo où Matt Cutts évoquait l'exemple du site de Metallica qui avait une règle de blocage dans son robots.txt mais qui était indexé quand même. A cela, Cutts avait rétorqué que Google avait la capacité d'indexer des sites sans aller dessus, notamment s'il y avait des liens qui pointaient vers ceux-ci
J'imagine que cela est également valable pour une preprod qui dispose d'un .htaccess. S'il y a sur le web pleins de liens vers cette preprod (ce qui est peu probable), Google l'indexera quand même.
Je fais un constat assez bizarre avec un site en production actuellement protégé par htaccess.
Il s'agit d'un forum, je peux donc savoir quels sont les utilisateurs actuellement connectés.
En toute logique, étant protégé, le forum ne devrait être accessible qu'à ceux disposant des identifiants afin de s'authentifier via apache.
Mais surprise, dans la liste des utilisateurs connectés, je vois un Google[Bot].
Le forum n'est pas indexé sur Google, mais la présence du bot pose tout de même un sacré problème non ?
@Sylvain : justement, l'indexer sans la crawler, c'est ce qu'il fait quand une page est bloquée par le robots.txt 🙂 Je me demande en fait si ça peut arriver : une page connue (grâce à un lien, une visite, etc.), non bloquée via le robots.txt, qui ne serait pas crawlée mais tout de même indexée ?
@ Sylvain F
Oui tu as raison, en fait il "crawle" l'url mais pas le contenu de la page.
Sinon, s'il n'y a pas de blocage, je ne vois pas de raison pour qu'il ne crawle pas la page.
Sylvain, décidément, c'est bon de te lire 😉
Merci pour avoir fait le test pour des mecs comme moi qui pensaient que parce qu'ils avaient lu que...
Le problème de l'indexation en préproduction s'est passé plusieurs fois dans mon expérience... via CMS, un simple plugin de "mise en maintenance", qui donc bloque l'index.php avec un mdp suffit en général... enfin je veux bien croire ce que je lis mais je n'en ai pas encore fait l'expérience.
Info intéressante car le blocage de certains répertoires dans le robots.txt parait pas toujours fiable
MErci pour le petit test Sylvain, ca va pas m'empecher d'etre parano quoi qu'il en soit et je vais donc continuer de casser les pieds de mes devs pour qu'ils combinent, HTaccess, robots.txt et balise meta - histoire d'etre bien sur.
L'article a le mérite de faire tomber un mythe en quelque sorte.