WRInaute passionné
Bonjour,
avec l'émergence des robots pour l'IA (création de contenu via IA), pour les diverses APP (applications mobiles) et autres comparateurs copie (plagiat) de textes, j'avoue que l'augmentation du trafic non-vu m'était devenue agaçante... (en restant poli!). Tous les fetchers et autres applis lisent le contenu d'un site sans jamais rien renvoyer. Et ça commence vraiment à faire beaucoup, trop à mon goût.
Le trafic dit "non-vu" est celui généré sur un serveur par des lecteurs non-humains automatisés. Par antonymie, le trafic "vu" est celui (tout à fait théoriquement...) réellement lu par des humains.
J'ai donc décidé de bloquer une bonne partie du trafic "non-vu" pour ne laisser que les "majors" utiles. La solution proposée ci-après est en place sur un site à bon volume et est efficace pour les cas traités.
Evidemment, la première chose à faire si un problème de trafic non-vu existe est de gérer proprement le fichier "robots.txt". C'est la base. Je ne reviens pas sur ce sujet (assez trivial : accédez à celui de WRI ou le mien sur AquaPortail.com en guise d'exemples). Le problème est que la plupart des lecteurs automatisés qui ne sont pas des robots officiels ne suivent pas du tout les instructions du robots.txt !
Voici un état de situation récent:
Bref, de 1 million de pages non-vues il y a 2 ans, c'est passé à plus de 2,3 millions par mois, et surtout avec une forte augmentation depuis le début de l'année.
Une solution pour bloquer les lecteurs indésirés est de commander les refus d'accès avec le fichier HTACCESS sur un serveur Apache. Il existe une bonne source (loin d'être la seule) en Perl : https://github.com/eldy/AWStats/blob/develop/robots.pm Ce fichier avec une longue liste de robots donne des idées des indésirables (ligne 798 et +, puis ligne 1574 et +). Il a fallu l'adapter pour htaccess.
Voici un code (sous toute réserve! à n'utiliser qu'avec les connaissances adéquates!). La syntaxe -pour les variables- peut varier d'un serveur à un autre, il faut donc adapter à la situation de chacun. Non-experts, fuyez!
J'explique un peu le code ci-dessus à insérer dans un htaccess (au début du fichier, après une éventuelle section Deny). Tout d'abord, pour déterminer s'il s'agit ou non d'un "robot", il faut tester le HTTP_USER_AGENT.
La première ligne va éviter aux "bons" robots de subir les lignes de test qui suivent. Ainsi, les "googlebot, bingbot, etc..." ne seront pas ralentis par un excès de vérification, surtout qu'ils sont légitimes. Les lignes suivantes sont tous les lecteurs automatisés qui doivent être bloqués. On y trouve (en vrac) ceux qui renvoient un User-Agent vide (c'est la grande mode...), tous ceux qui sont des "fetchers", etc.
À tous ces indésirés, on leur octroie une réponse 403 : forbidden! OUT, dehors, exit...
Optionnellement, en deuxième filtre, on peut tester le "referer" qui n'est pas son propre serveur. Ainsi, il faut remplacer "lenomdedomainedusite" par son propre nom de domaine (ex.: "webrankinfo" pour ici). Ensuite, on peut bloquer certaines extensions (.xyz, .top, ...), ou des sites nominativement (avec le mot "porno" dans le nom de domaine, ou qui commencent par "app." pour beaucoup d'applis mobiles).
Voilà pour quelques idées : ça pourrait soulager quelques serveurs et diminuer la bande passante consommée valablement.
Jef
avec l'émergence des robots pour l'IA (création de contenu via IA), pour les diverses APP (applications mobiles) et autres comparateurs copie (plagiat) de textes, j'avoue que l'augmentation du trafic non-vu m'était devenue agaçante... (en restant poli!). Tous les fetchers et autres applis lisent le contenu d'un site sans jamais rien renvoyer. Et ça commence vraiment à faire beaucoup, trop à mon goût.
Le trafic dit "non-vu" est celui généré sur un serveur par des lecteurs non-humains automatisés. Par antonymie, le trafic "vu" est celui (tout à fait théoriquement...) réellement lu par des humains.
J'ai donc décidé de bloquer une bonne partie du trafic "non-vu" pour ne laisser que les "majors" utiles. La solution proposée ci-après est en place sur un site à bon volume et est efficace pour les cas traités.
Evidemment, la première chose à faire si un problème de trafic non-vu existe est de gérer proprement le fichier "robots.txt". C'est la base. Je ne reviens pas sur ce sujet (assez trivial : accédez à celui de WRI ou le mien sur AquaPortail.com en guise d'exemples). Le problème est que la plupart des lecteurs automatisés qui ne sont pas des robots officiels ne suivent pas du tout les instructions du robots.txt !
Voici un état de situation récent:
Bref, de 1 million de pages non-vues il y a 2 ans, c'est passé à plus de 2,3 millions par mois, et surtout avec une forte augmentation depuis le début de l'année.
Une solution pour bloquer les lecteurs indésirés est de commander les refus d'accès avec le fichier HTACCESS sur un serveur Apache. Il existe une bonne source (loin d'être la seule) en Perl : https://github.com/eldy/AWStats/blob/develop/robots.pm Ce fichier avec une longue liste de robots donne des idées des indésirables (ligne 798 et +, puis ligne 1574 et +). Il a fallu l'adapter pour htaccess.
Voici un code (sous toute réserve! à n'utiliser qu'avec les connaissances adéquates!). La syntaxe -pour les variables- peut varier d'un serveur à un autre, il faut donc adapter à la situation de chacun. Non-experts, fuyez!
Code:
# remarque : ^-?$ = user_agent_vide ou avec juste le signe -
RewriteCond %{HTTP_USER_AGENT} !(Google|mediapartners|bing(bot|preview)|Applebot|facebook|adsbot|Dalvik|CFNetwork|quantify|DuckDuckGo) [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$|fetcher|(.*)bot|spider|crawler|^app\.|seek|feed|indexer|checker|discover|scanner|hunter|survey|validator [NC,OR]
RewriteCond %{HTTP_USER_AGENT} sitemap|perl|curl|ripper|Python|archive|download|extract|stripper|sucker|leacher|collector|provider|grabber [NC,OR]
RewriteCond %{HTTP_USER_AGENT} core|motor|megaindex|Libwww|larbin|nutch|httplib|HTTrack|urllib|Wget|Speedy|ezooms|yie8|Xenu|cfetch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} picker|ninja|clshttp|ruby\/|heritrix|phantom|web(collage|copy|zip|picture)|entireweb|fake [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla$|^mozilla\/3\.0\s\(compatible$|^mozilla\/4\.0$|^mozilla\/4\.0\s\(compatible;\)$|^mozilla\/5\.0$|^mozilla\/5\.0\s\(compatible;$|^mozilla\/5\.0\s\(en\-us\)$|^mozilla\/5\.0\sfirefox\/3\.0\.5$|^Mozilla/6\.0[\x20]\(compatible\)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} MSIE[\x20][2-6]|^msie8|MSIE\+6\.0\;|Windows[\x20](95|98)|firefox/([0-9]|[0-1][0])\.|^Mozilla/(.*)Beta[\x20]\(Windows\) [NC]
RewriteRule (.*) - [F]
#accessoirement : |yandex|baidu|mail\.ru|netcraft|butterfly
RewriteCond %{HTTP_REFERER} !lenomdedomainedusite [NC]
RewriteCond %{HTTP_REFERER} localhost [OR]
RewriteCond %{HTTP_REFERER} (.*)\.(xyz|top$|pw|tk|space|world|app|today) [OR]
RewriteCond %{HTTP_REFERER} ^app\.|porno [NC]
RewriteRule (.*) - [F]J'explique un peu le code ci-dessus à insérer dans un htaccess (au début du fichier, après une éventuelle section Deny). Tout d'abord, pour déterminer s'il s'agit ou non d'un "robot", il faut tester le HTTP_USER_AGENT.
La première ligne va éviter aux "bons" robots de subir les lignes de test qui suivent. Ainsi, les "googlebot, bingbot, etc..." ne seront pas ralentis par un excès de vérification, surtout qu'ils sont légitimes. Les lignes suivantes sont tous les lecteurs automatisés qui doivent être bloqués. On y trouve (en vrac) ceux qui renvoient un User-Agent vide (c'est la grande mode...), tous ceux qui sont des "fetchers", etc.
À tous ces indésirés, on leur octroie une réponse 403 : forbidden! OUT, dehors, exit...
Optionnellement, en deuxième filtre, on peut tester le "referer" qui n'est pas son propre serveur. Ainsi, il faut remplacer "lenomdedomainedusite" par son propre nom de domaine (ex.: "webrankinfo" pour ici). Ensuite, on peut bloquer certaines extensions (.xyz, .top, ...), ou des sites nominativement (avec le mot "porno" dans le nom de domaine, ou qui commencent par "app." pour beaucoup d'applis mobiles).
Voilà pour quelques idées : ça pourrait soulager quelques serveurs et diminuer la bande passante consommée valablement.
Jef
