Manual:Robots.txt/fr

Les fichiers robots.txt font partie des Standards d'exclusion des robots, et peuvent aider à l'. Ils indiquent aux robots web comment explorer un site. Un fichier robots.txt doit être placé à la racine du web d'un domaine.

Empêcher toute exploration
Ce code empêche les robots d'explorer toutes les pages de votre site :

Si vous souhaitez uniquement bloquer un certain robot d'idexation, remplacez l'astérisque par l'agent utilisateur de l'arborescence.

Empêcher l'exploration des pages qui ne sont pas des articles
MediaWiki génère de nombreuses pages qui ne sont utiles que pour les humains vivants : les anciennes révisions et différences ont tendance à dupliquer le contenu trouvé dans les articles. Les pages d'édition et la plupart des pages spéciales sont générées dynamiquement, ce qui les rend utiles uniquement aux éditeurs humains et relativement coûteuses à servir. If not directed otherwise, spiders may try to index thousands of similar pages, overloading the webserver.

Avec les URLs courtes
Il est facile d'empêcher les robots d'indexation d'explorer les pages qui ne sont pas des articles lorsque vous utilisez des URLs courtes dans le style de Wikipedia. En supposant que les articles sont accessibles au travers de  et que les autres éléments soient disponibles par $query : Assuming articles are accessible through /wiki/Some_title and everything else is available through /w/index.php?title=Some_title&someoption=blah:

Soyez prudent, néanmoins ! Si par accident, vous introduisez cette ligne :

Vous bloquerez l'accès au répertoire /wiki, et les moteurs de recherche vont ignorer votre wiki !

Notez bien que cette solution fera que le CSS, le JavaScript et les fichiers d'images seront bloqués, et donc les moteurs de recherche tels que Google, ne seront pas en mesure d'afficher les aperçus des articles du wiki. Pour contourner ceci, au lieu de bloquer le répertoire /w dans sa totalité, seulement index.php a besoin d'être bloqué :

Ceci fonctionne parce que CSS et JavaScript sont ramenés via /w/load.php. D'une autre façon, vous pourriez le faire comme il est fait dans la ferme Wikimedia :

Sans les URLs courtes
Si vous n'utilisez pas les, restreindre les robots est un peu exagéré. Si vous exécutez PHP comme CGI et que vous n'avez pas magnifié les URLs, les articles étant accessibles au travers de /index.php?title=Some_title :

Si vous utilisez PHP comme un module Apache et que vous n'avez pas magnifié les URLs, les articles étant accessibles par  :

Les lignes sans les deux points à la fin restreignent les pages de discussion de ces espaces de noms.

Les wikis qui ne sont pas en anglais devraient ajouter diverses traductions des lignes ci-dessus.

Vous pouvez ne pas mettre de restrictions sur , sinon cela empêche d'accéder aux images appartenant à l'habillage. Les moteurs de recherche qui affichent l'aperçu des images, tel Google, vont afficher les articles avec des images absentes s'ils ne peuvent pas accéder au répertoire /skins/.

Vous pouvez aussi essayer :

parce que cetains robots comme Googlebot acceptent cette extension avec joker dans le robots.txt standard, ce qui arrête la plupart de ce que nous ne voulons pas que les robots passent au crible, tout comme la solution /w/ ci-dessus. Toutefois, ceci présente les mêmes limites en ce que cela bloque l’accès au CSS, empêchant ainsi les moteurs de recherche de restituer correctement les images d’aperçu. Il est possible de résoudre ce problème en ajoutant une autre ligne Allow: /load.php cependant, au moment de la rédaction de cet article, ceci n’a pas été testé.

Autoriser l'indexation des pages brutes par l'archiveur internet
Vous pouvez vouloir autoriser l' Archiveur internet à indexer les pages brutes de sorte que les texte wikit brut des pages soit un enregistrement permanent. De cette manière, il sera plus facile, au cas où le wiki devriendrait corrompu, pour les contributeurs de mettre le contenu sur un autre wiki. Vous feriez alors :

Contrôle des seuils
Vous ne pouvez spécifier quels chemins un robot a le droit d'explorer. Même le fait d'autoriser simplement la zone entière de la page peut devenir un lourd fardeau lorsque deux ou trois pages par seconde sont demandées par un robot d'indexation sur les deux cent mille pages.

Certains robots ont une spécification adaptée pour cela; Inktomi répond à une ligne « Crawl-delay » (délai d'attente) qui peut spécifier le temps minimum en secondes entre les demandes (par défaut 15 secondes).

Les robots diaboliques
Quelquefois, un robot fait maison n'est pas très intelligent ou est purement malveillant et n'obéit pas du tout à robots.txt (ou obéit aux restrictions sur les chemins mais fouine très rapidement, dégradant les performances du site). Il peut donc être nécessaire de bloquer les chaînes des agents utilisateur spécifiques ou des adresses IP individuelles des contrevenants.

Plus généralement, le request throttling (intervention différée) peut arrêter de tels robots sans nécessiter votre intervention répétée.

Une alternative ou stratégie complémentaire est de déployer un spider trap (piège à robot d'indexation).

Fouiner en indexant
Alors que robots.txt empêche les robots bienveillants de télécharger les URL, il n'empêche pas de les indexer. Cela signifie qu'ils pourraient encore réapparaître dans les résultats de Google ou d'autres moteurs de recherche, tant qu'il existe des liens externes permettant de les atteindre (et même pire, comme ils ne téléchargent pas de telles pages, les balises meta noindex qui s'y trouvent n'ont aucun effet). Concernant les pages wiki uniques, le mot magique $noindex pourrait être une option plus fiable pour les garder hors d'atteinte des résultats de la recherche. This means that they might still show up in the results of Google and other search engines, as long as there are external links pointing to them. (What's worse, since the bots do not download such pages, noindex meta tags placed in them will have no effect.) For single wiki pages, the  magic word might be a more reliable option for keeping them out of search results.