Skip to content

Maîtriser le repassage des moteurs de recherche sur son catalogue (et éviter les faux-plis) (1/2)

27/03/2012

Biblibre (prestataire proposant ses services aux bibliothèques qui souhaitent installer Koha chez eux [la définition est peut-être réductrice, qu’ils m’en excusent : j’ai nulle malveillance à leur égard ! je resitue rapidement les choses pour la suite du propos]) a publié récemment un billet très intéressant sur leur site.

En substance : les moteurs de recherche viennent indexer les notices, et ils passent et repassent si souvent que ça finit par utiliser beaucoup de bande passante, donc ralentit le temps de réponse des serveurs et diminue le taux de satisfaction des usagers.

La proposition pour empêcher ce ralentissement : indiquer aux moteurs qu’on ne veut pas qu’ils viennent moissonner nos données.

Pour cela, il existe une très simple technique : à la racine du serveur, on rajoute un fichier appelé robots.txt qui va dire aux moteurs de ne pas entrer dans le « répertoire » contenant les notices (donc pour une URL http://www.monsite.fr, l’URL du fichier sera http://www.monsite.fr/robots.txt).

Précision technique : c’est une convention, mais pas une manière de rendre inaccessible des dossiers. Un moteur peut décider d’enfreindre ces consignes sans difficulté technique (Technorati était pointé du doigt à ce sujet, à une époque — voyez ce qu’il est devenu…)

Ils expliquent quel doit être le contenu du fichier dans leur billet.

Au passage : les cahiers des charges dans le cadre de réinformatisation précisent généralement les temps de réponse attendus aux différents types d’actions sur le SIGB (que ce soit en consultation publique, simple, comme en gestion/administration côté professionnel). Donc Biblibre s’est engagé sur des temps de réponse, a dimensionné dans ses offres des serveurs en conséquence — et se voit contredite par ces robots qui ralentissent toute la machine. Il est donc parfaitement logique qu’ils cherchent une solution pour résoudre ce problème.

Ce qui me chagrine, c’est qu’on (enfin, moi en tout cas — mais pas que) a voulu que les opac soient moissonnables, parce que si à 50 ans t’es pas indexé par Google, c’est que tu as raté ta vie. Et voilà qu’on cherche à interdire à Google d’entrer pour permettre aux lecteurs d’avoir accès à une interface réactive.

Alors quoi ?

Avant-propos : comment un moteur de recherche web peut-il entrer dans une base de données ?

Avant d’aller plus loin dans les explications concernant les manières de bloquer ou contrôler ces moteurs de recherche, je profite de l’occasion pour donner quelques explications succinctes sur les formulaires de recherche.

Quand vous voyez un formulaire comme ceci :

cet affichage est généré (en simplifiant) par le code suivant :

<form action="http://www.google.fr/search">
<input type="text" name="q" value=""/>
<input type="submit" value="Recherche Google"/>
</form>

  • La balise <form> pointe vers la base de données
  • Le champ de saisie est appelé par la balise <input> de type "text"
  • Le bouton de validation est l’input de type "submit"

Et quand on écrit un mot dans le champ de recherche, le navigateur transforme cela en URL qui concatène (fusionne et met bout à bout) les différentes informations du formulaire, et le mot recherché.

Par exemple si j’écris

je génère l’URL : http://www.google.fr/search?q=ACTA

Quand il arrive sur une page contenant un formulaire, le robot Google (googlebot) va, essayer de générer des URL sur la base des paramètres fournis dans le formulaire, en fonction notamment :

  • de la langue de la page
  • du contexte (mots déjà présents dans la page)

Cela permet au bot de choisir des mots qui généreront de nombreuses pages de résultats, donc d’explorer autant que possible la base de données — évidemment pas de manière satisfaisante, en tout cas pas exhaustive : ne sortiront que les notices indexées aux termes utilisés par les moteurs. En tout cas le bot peut ainsi aller de rebond en rebond et naviguer dans la base.

Les commentaires sont fermés.

%d blogueurs aiment cette page :