Вы здесь

Моя борьба с Интернет-роботами. Часть 2

Spam
 
Представим, что сайт – это офис, в большом офисном центре под названием «Интернет». Сегодня открытие. Подтягиваются приглашённые посетители, «зеваки» и случайные прохожие. С каждым днём их будет больше, и вы познакомитесь с огромным числом приятных и интересных людей.
 
Наша задача – оказать им то внимание, которое они заслуживают.
 
 
В настоящее время, люди преимущественно ищут информацию в поисковиках. А значит, они - наш главный контрагент. Мы бесплатно пользуемся их услугами, а они по-своему собирают информацию о нас. Правильное поведение – помочь найти и показать наши лучшие стороны, а худшее – убрать. Чтобы это сделать превосходным образом, стоит понять и использовать логику их поведения.
 
Помните, анонимности не существует. Всё, что может быть найдено – будет найдено и использовано.
 
«Офис». Внезапно появляются странные и неприятные «гости», разбрасывающие мусор. Вежливо улыбаясь, вы ходите с тряпкой и наводите лоск. Но, очень скоро вам придётся следить за входом (поставив капчу, вы разрешите оставлять записи только тем, кто знает волшебное слово), а затем – наймёте охранника (включите премодерацию). А когда «доброжелатели» найдут такие места, о которых вы даже не догадываетесь, вы составите «чёрные» списки (и начнёте блокировать по IP).
 
А как же вечные соседи и наблюдатели (поисковые и SEO-системы), что они видят? А видят они грязный офис и странных незнакомцев, за которыми вы бегаете с тряпкой, орёте и стучите дверью. Какие-то странные типы, которые ничего не делают, но ежеминутно входят и выходят (роботы, специально нанятые для увеличения отказов обслуживания). Какое будет представление о хозяине этой квартиры?
 
Правильный выход – встречать «гостей» у парадной. Мы ненавязчиво интересуемся, кто они (USER-AGENT), откуда (IP и REFERER), к кому (REQUEST) и зачем (комбинация METHOD, REQUEST, REFERER и USER-AGENT). Если это «наш клиент» - бесшумно выводим на улицу, а если дорогой Гость – радостно проводим к лифту, со скромной табличкой правил поведения («robots.txt»). Применив именно такой подход, вы значительно улучшите ваше реноме. Плюс, у вас появится масса свободного времени.
 
Итак, что же нам надо? В первую очередь – хороший рейтинг в поисковиках. Если он будет плохой, информацию о нас можно будет найти где-то на сотой странице. А пользователи, обычно, дальше пятой не заглядывают. Поисковикам нравятся быстрые сайты с хорошей родословной (имеющие честные внешние ссылки и достойные рейтинги у других), непротиворечивой структурой и минимумом ошибок (сокращает время на анализ), пользующиеся популярностью у пользователей (каждому - своё).
 
Если с частью вещей мы не можем справиться, то с другими – вполне. Не знаешь, с чего начать – делай, что знаешь.
 
Вернёмся и начнём с «robots.txt». Многие на него «плюют», а на самом деле – он очень даже имеет смысл. Более того, часто его действие не прямое, а косвенное. И по ходу статьи вы это будете замечать. Первый пример: в прошлой статье я рассказал, что запретил индексацию роботам «Baidu.com». А потом ещё и «so.com» и «HaoSou.com». Дней через пять, они перестали стучаться, но иногда по-прежнему заглядывают под фальшивым «User-Agent»-ом. Правильно, мой сайт у них «просел», и комментарии с иероглифами исчезли. «Вот тебе и первая выгода!»
 
На самом деле, я запретил индексацию ещё одной группе роботов. Что снизило нагрузку на сайт и уменьшило лог (где-то на 20%). Его стало проще и быстрее просматривать. Вновь чётко проступило изменение нагрузки по времени (ночью – Америка, раннее утро – Камчатка и Китай, обед – Европа, а вечером – снова Туманный Альбион). А ещё – стали чётко заметны «хамелеоны». «Вот тебе и вторая выгода!»
 
Итак, «robots.txt» – это, на самом деле, важно и полезно! Давайте его «добьём». И первое, что стоит сразу сделать – учесть особенности синтаксиса (отступы, комментарии, спец-символы) и нюансы с директивами. Дело в том, что в мире полно старых роботов, которые работают по старым правилам. Поэтому, забываем новое и вспоминаем былое:
 
  1. При обнаружении ошибки или сомнений – робот вправе игнорировать текущую часть текста, последующие или все настройки целиком.
=>   Лучше отказаться или минимизировать использование новых директив и строк с новыми спец-символами. Если иначе нельзя – использовать только в соответствующих разделах для роботов, которые их поддерживают, в крайнем случае - в самом конце нужного раздела.
 
  1. Пробел(ы) в начале строк – недопустимы.
  2. Есть только два специальных символа: «#» - это начало комментария и «$» - конец строки (для запрета индексации конкретных файлов или страниц).
  3. Символ комментария «#» может быть только в начале строки. Т.е., комментарий – это всегда отдельная строка.
  4. Существуют только две директивы: «Usergent» и «Disallow».
  5. Пустая (пробельная строка) строка – используется только для разделения «User-agent»-ов. Т.е., между директивами не должно быть пустых строк. Но, перед новой директивой «User-agent» - делается специальная пустая (одна) строка-разделитель. (Строки-комментарии не в счёт.)
# Роботы китайского поисковика Baidu
#
# Baiduspider       - Основной робот
# Baiduspider-image
# Baiduspider-video
# Baiduspider-news
# Baiduspider-favo
# Baiduspider-cpro
# Baiduspider-ads
#
User-agent: Baiduspider
Disallow: /
 
User-agent: *
# Directories
Disallow: /includes/
Disallow: /misc/
Disallow: /modules/
Disallow: /profiles/
Disallow: /scripts/
Disallow: /themes/
 
  1. Роботы принимают символ «*» только в директиве «User-agent: *», которая начинает раздел правил для всех неуказанных роботов.
 
 
А теперь о нюансах.
 
  1. Напоминаю, что директивы «Disallow», где вы применяете спец-символ «*», лучше помещать в самый конец (не все роботы понимают «звёздочки», поэтому могут игнорировать все строки, начиная с этой).
  2. Директивы «Host» и «Sitemap» – Яндекс умудряется читать из всех разделов (если у вас их несколько). Это может создавать эффект «задвоения» и «затроения». Таким образом, имеет смысл указывать их – только в разделе «UserAgent: *».
Если у вас есть раздел для Google, и вы беспокоитесь за него – не стоит: директиву «Sitemap» он, как и Яндекс читает даже из чужих разделов. А если вы зарегистрируетесь в разделах веб-мастеров Яндекса и Гугла, то можете прямо там указать ваш файл «sitemap.xml». Кстати, Гугл после этого будет регулярно проверять, и сообщать о проблемах вашей карты сайта.
 
С директивой «Host» работает только Яндекс. Для остальных – это ошибка. Поэтому, если вы вдруг создадите отдельный раздел для Яндекса – её надо забрать именно туда. «Host» применяется только для ускорения распознавания, где ваш основной сайт, а где его «зеркало». Если зарегистрируетесь в разделе веб-мастеров Яндекса и укажите там ваш основной домен – можете смело её закомментировать в файле «robots.txt»
 
В Гугле с этим сложнее. В принципе, он должен сам понимать, что есть что. Но это не так. Эксперимент показал, что даже через 3 (три!) года Гугл продолжал путать, где у меня прямая, а где «зеркальная» ссылка. Решение – одно: в инструментах веб-мастера Гугла зарегистрировать «зеркальный» домен, а потом в его настройках указать имя «основного». Кстати, это устранит ошибки, возникшие из-за «перекрёстных» ссылок.
 
  1. Интересная «картина» для «Crawl-delay»: Гугл её официально игнорирует. При проверке файла «robots.txt» в его инструментах – он даст предупреждение (не ошибку!). При этом, эту директиву Гугл находит в любом месте.
Считаю, что на это можно не обращать внимание. И использовать лишь в разделе «User-agent: *».
 
  1. Таким образом, стоит избегать использования директивы «Host» (альтернативные средства есть). А директивы «Sitemap» и «Crawl-delay» писать в конце соответствующих разделов, после всех «Disallow», но перед «Disallow», использующие спец-символ «*».
  2. Особенность запрета индексации страниц. Если ваш сайт многоязычный, и вы используете вариант отображения языка в ссылках в виде суффикса, то знайте, что при стандартном запрете (типа, «Disallow: /contacts$») – многие боты этого не поймут, Яндекс - с огромным трудом, а Гугл – не намного быстрее. Поэтому, лучше сразу указать все варианты (можно, конечно, обойтись одной строкой, используя волшебную «звёздочку», но я сомневаюсь, что у вас их будет десяток).
# \"Контакты\"
Disallow: /ru/contacts$
Disallow: /en/contacts$
Disallow: /contacts$
Disallow: /?q=contacts$
#
# Задержка
Crawl-delay: 10
#
# Карта сайта
#
# Основное имя сайта
# С этой директивой работает только Яндекс. Она станет лишней после регистрации.
# Host: example.com
#
#
#######
# !!! Особые исключения для устранения дублей страниц
#     Эти директивы могут игнорировать некоторые роботы!
#
# This will block all of the URLs created by the Tracker Module which are in the format
Disallow: /*/track$
 
 
Вот так! Ничего сложного. Если раньше у меня были неприятности и недопонимания с некоторыми уважаемыми роботами, то теперь они испарились. Они перестали лазить туда, куда не надо. «Вот тебе и третья выгода!»
 
 
27 октября 2014 года у Гугла появилось интересное сообщение. Гугл требует разрешения индексации изображений, файлов CSS и JavaScript. В противном случае, страницы, где они используются – будут отображены неверно.
 
Можно этого не делать? Можно. Они пишут, что это никак не отразится на ранжировании сайтов. Но, «лгунишки» тут же умудряются проговориться. Дело в том, что сайты, содержащие большое количество недочётов (по мнению Гугла) отодвигаются в очереди на индексацию, индексируются всё реже, обрабатывая всё меньшее количество страниц. Каков будет результат? Можно не отвечать.
 
Это проблема. Дело в том, что большинство роботов как раз этого не любят. В частности, Яндекс. И, что значит «разрешить»? Мы, ведь, только запрещаем. Да? Собственно говоря, я это дело «прошляпил», а когда заинтересовался, куда так резво пропали мои страницы из поиска – увидел их в переполненном разделе «Заблокированные ресурсы» (это в веб-мастере Гугла). Нужно было срочно принимать меры.
 
«И меры были приняты». С некоторых пор роботы Гугл и Яндекс стали использовать директиву «Allow». Она, в отличие от «Disallow» - разрешает. Т.е., можем сначала что-то запретить, а потом нужное - разрешить. Чудесно! Я сделал перед «User-agent: *» новый раздел «User-agent: Googlebot», и скопировал в него все настройки (кроме Crawl-delay). Т.к., Гугл понимает директивы «Disallow» со «звёздочками», я смело их применил, сократив код. А после этого – добавил недостающие разрешения («Allow»).
 
Вопрос: надо ли создавать разрешения для каждого каталога отдельно? Нет, это даже вредно. Например, пару недель назад, меня пытался взломать какой-то «любитель». Он просканировал файл «robots.txt» и при атаке использовал обнаруженные там имена каталогов. Да и, собственно, зачем так много писать, когда можно сократить:
 
#######
# Закрываем каталог с дополнительными модулями
# Файлы .css и .js - используются с параметрами (поэтому, без $)
#
Disallow: /sites/all/
# Файлы дополнительных модулей
Allow: /sites/all/modules/*.css
Allow: /sites/all/modules/*.js
Allow: /sites/all/modules/*.gif$
Allow: /sites/all/modules/*.ico$
Allow: /sites/all/modules/*.png$
 
Рассматривая список «Заблокированные ресурсы», можно обнаружить интересные вещи. Если при индексации страницы робот на чём-то «споткнётся», то он бросит это дело и пометит все оставшиеся скрипты и файлы этой страницы, как заблокированные. Т.е., в списке заблокированных не всё является недоступным. Но, этот анализ позволяет найти «подводные камни».
 
Гугл не любит «чужие» java-скрипты. Хотя, от Яндекса – официально поддерживает, и я использовал его панельку социальных сетей. Теперь, Гугл считает этот скрипт недоступным. В его текст Яндекс вписал строку с ссылкой на «Яндекс-метрику» (счётчик), который в свою очередь тоже является скриптом, но индексировать его Гуглу не позволяет… Для решения подобных ситуаций, Яндекс придумал новый мета-тег «Noindex», а Гугл, естественно… Ну, вы поняли. Помучавшись, я убрал эту панельку.
 
Гугл резво оценил мои усилия. Некоторые материалы прыгали за сутки в поисковых результатах аж на пять страниц за раз. Очень приятно. Результат – страницы вышли из исключений. Все разговоры, что на сайте самое важное – это объём информации – глупость. Информации может быть море, а сайт – на помойке. Важно правильно приподнести. И тогда на наш «огонёк» слетятся мотыльки. «Вот тебе и четвёртая выгода!»
 
 
Прежде чем перейти ко «вкусным» темам (о борьбе со спам-ботами и взломщиками), я хочу сделать ряд важных и полезных замечаний к моим прошлым материалам.
 
 
Дополнение к заметке об обновлении Drupal и его модулей.
 
Стоит отметить, что многие роботы умеют читать и анализировать файлы. Поэтому, после установки (или обновления) лучше удалить текстовые файлы, содержащие описание текущего состояния и обновлений:
 
  • CHANGELOG.txt
  • COPYRIGHT.txt
  • INSTALL.txt
  • INSTALL.mysql.txt
  • INSTALL.pgsql.txt
  • LICENSE.txt
  • MAINTAINERS.txt
  • UPGRADE.txt
 
Для повышения безопасности от взлома, рекомендую удалить файл «install.php». Если вы не используете (средствами API) удалённое подключение для создания постов и изменения контента – удалите файл «xmlrpc.php». В прошлом году (2014) через него массово проводились DDoS-атаки, но сейчас (в новых обновлениях) Drupal эта «лазейка» закрыта. Зато, по-прежнему применяют для скрытого «bruteforce»-подбора паролей. Зная имена пользователей (находят при сканировании материалов сайта), делают их перебор. Плюс этого метода – Друпал этого не видит (но видно в логах Апач).
 
Если вы по какой-то причине решите всё-таки оставить эти файлы – запретите работу с ними со всех адресов, кроме вашего (в файле «.htaccess»).
 
В примечании об обновлении Друпала я сообщил о бюллетене безопасности и о необходимости создания файлов .htaccess в папках, которые могут использоваться пользователями для загрузки материалов на сайт (в частности, в папку «/sites/default/files»). Поговорим о тонкостях:
 
  • Если вы не укажите конкретный запрет на типы загружаемых файлов или разрешите всё (по умолчанию) – у вас появятся «дубли» страниц. Например, если вы положите рекомендуемый файл из бюллетеня в папку «\sites\default\files», то появится страничка «hxxp://test.ru/sites/default/files/» - дубль главной страницы сайта.
 
Чтобы этого не допустить, в этот файл (в директории «\sites\default\files») стоит дописать, какие загружаемые файлы вы разрешаете смотреть. Где взять этот список? В ваших настройках сайта. Вспомните допустимые файлы для загрузки и прикреплённые файлы в публикациях (Главная » Управление » Настройка сайта » Загрузки Файлов) и допустимые файлы для загрузки пользователей (Главная » Управление » Настройка сайта » Файловый менеджер). После этого – проблема рассосётся.
 
  • Но, действие этого файла распространяются и на подкаталоги. А у меня есть модуль мультиязычности, который создал свою папку «languages», в который положил свой Java-скрипт. Т.к., я запретил в «\sites\default\files» смотреть скрипты, то получается, что Гугл начнёт меня ругать за отсутствие доступа к файлу настроек языка. Ай-яй-яй!
 
Выход есть – положить туда дополнительный файл .htaccess:
 
# Turn off all options we don't need.
Options None
Options +FollowSymLinks
 
# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
 # Override the handler again if we're run later in the evaluation list.
 SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>
 
# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
 php_flag engine off
</IfModule>
# PHP 4, Apache 1.
<IfModule mod_php4.c>
 php_flag engine off
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
 php_flag engine off
</IfModule>
 
# Сначала всё запрещаем, а потом - кое-что разрешим.
Order deny,allow
deny from all
<Files ~ "\.(js)$">
 allow from all
</Files>
 
Здесь символ «~» используется для работы с регулярными выражениями. И ничего страшного, всё работает замечательно!
 
 
 
  • Как я так быстро определил список управляемых ботов? Смотрим в логе посещения, кто читает файл «robots.txt». Они почти все там.
  • Как убедиться, что робот фактически не управляем? Если после запрета в «robots.txt» он продолжит сканировать страницы сайта. Обычно, я это проверяю через неделю после установки запрета (на принятие решения всем требуется время).
  • Иногда у хостера может быть отключёна (или не настроена) работа с файлом .htaccess. Как это проверить? Если в этом файле удалить всё содержимое и написать «кракозябры», то при попытке зайти на сайт вы получите страницу с кодом 500. Она выдаётся при обнаружении ошибки, что означает, что файл работает. А если ошибки нет – увы…
  • Прежде чем экспериментировать с запретами на User-Agent-ы, неплохо проверить самого себя. И для этого воспользоваться каким-нибудь специализированным сайтом, который покажет текст вашего агента.
  • Если у вас IE, то у Microsoft есть страница проверки его UA, которая найдёт и покажет ошибки в тексте агента. Они могут возникать после повреждения вирусами, установки плохих плагинов или неудачных обновлений. В частности, у меня длина агента оказалась больше 200 символов (некоторые сайты на это плохо реагируют) и часть информации задвоена (неудачное обновление).
  • Для проверки моих запретов по User-Agent-ам я использовал FireFox, с установленным плагином «User-Agent Owerrider». Очень удобно, агенты меняются просто «на лету». Аналогичный плагин есть и для IE от Microsoft. Но, я его не испытывал.
  • При тестировании, если вы вдруг начнёте применять переадресацию и подобные трюки, помните, что у браузеров есть кэш, который нужно сбрасывать после таких экспериментов.
  • Собственно, ботов, которые реагируют на «robots.txt» и не работают на поисковики – немного. Бояться работать с ними (что будет слишком много) – не надо. На скорость работы сайта - «robots.txt» никак не влияет. Но, снижает нагрузку за счёт запрета ненужной индексации.
  • Других ботов, которые имеют свою подпись, но не работают по правилам «robots.txt» – больше, но их число тоже ограничено (у меня пока три). Так что не стоит думать, что этим можно испортить .htaccess и заметно снизить скорость загрузки страниц сайта. Плюс, опять же, записи об их проказах не будут загрязнять логи Друпала (но в лог Apache – по-прежнему попадут, что позволит контролировать ситуацию на предмет актуальности).
  • В итоге, лучше не использовать блокировку по диапазону (там могут быть и хорошие пользователи). Кроме того, IP-адреса надо хоть раз в год пересматривать. А это много работы. Использование диапазонных блокировок по IP повышают вероятность ошибочных несправедливых блокировок…
 
 
Наша цель: найти и применить средства раннего обнаружения и запрета действия нежелательным посетителям. Честные пользователи должны страдать минимально.
 
Напоминаю, что поисковики любят быстрые сайты с большим количеством реальных пользователей. Большую часть роботов они знают. Для остальных – они используют критерии поведения. Например, время чтения пользователя (раньше это было от 3 (трёх) секунд). Систему переходов. И считывают такой параметр, как «показатель отказов». «Bounce rate» - термин в веб-аналитике, обозначающий процентное соотношение количества посетителей, покинувших сайт прямо со страницы входа или просмотревших не более одной страницы сайта. Если у вас высокий показатель отказов – ваш сайт не интересен или фальшивка (у вас не то, что ищут пользователи).
 
Легко видеть, что всякие «левые» роботы не только спамят и ломают, но повышают показатель отказа. Нюанс – поисковики примут в расчёт только тех, кто зашёл на сайт, а если его успеет завернуть Apache – нет. Раннее обнаружение и реакция – наше всё!
 
 
Как мы делим незнакомых людей хороших и нехороших? Наблюдая за их поведением. То же и с роботами. Очень часто их выдаёт первый же запрос. Бывают очень необычные, которые не сделает человек в здравом уме. Например? Например, у меня на сайте включены «чистые ссылки» (Главная » Управление » Настройка сайта » Чистые ссылки), поэтому параметрические запросы, использующие знаки «?», «&» у меня есть, но люди их не видят и не используют.
 
Если вы правильно настроили свой «robots.txt» и запретили индексацию комментариев, страничек добавления материалов и регистрации пользователей, то мы можем это использовать. Просто запрещаем их открывать по параметрическим ссылкам:
 
<IfModule mod_rewrite.c>
 
 RewriteEngine on
 
 RewriteCond %{REQUEST_METHOD} ^(GET|POST)$
 RewriteCond %{THE_REQUEST} /\?q=comment/reply [NC,OR]
 RewriteCond %{THE_REQUEST} /\?q=node/add [NC,OR]
 RewriteCond %{THE_REQUEST} /\?q=user [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
</IfModule>
 
Так я запретил вход каждому пятому спамеру. Примечание: если у вас сайт многоязычный – этот код надо подправить.
 
 
Следующий шаг – принять важное решение: нам интересны полностью анонимные читатели или нет? Кто это такие? Это те, которые отказываются давать нам честную информацию о себе, в том числе и о своих переходах (Referer). Я решил, что мне они не нужны. Поэтому, смело применил следующий трюк: те, кто нарушают порядок действий – «злые» роботы.
 
Следующий шаг. Используя локальную копию, и проделал операции регистрации, создания материалов и комментариев всевозможными способами. Анализируя логи, я получил правильный порядок действий. Нарушитель – бот. А именно: комментарии можно делать только внутри материала, а не неизвестно где, эти ссылки должны относиться к моему сайту. Регистрация пользователей происходит похожим образом.
 
# !!! Комментарий только из конкретного материала
   # REFERER при GET    hxxp://test.ru/node/xxx
 RewriteCond %{REQUEST_METHOD} ^GET$
 RewriteCond %{THE_REQUEST} /comment/reply [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?test\.ru [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
   # REFERER при POST  hxxp://test.ru/comment/reply/xxx
 RewriteCond %{REQUEST_METHOD} ^POST$
 RewriteCond %{THE_REQUEST} /comment/reply [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?test\.ru/comment/reply/ [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
 # Добавление материала
 RewriteCond %{REQUEST_METHOD} ^(GET|POST)$
 RewriteCond %{THE_REQUEST} /node/add [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?test\.ru [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
# Регистрация пользователя
# / => register OR /user => register OR /user/password => register
 RewriteCond %{REQUEST_METHOD} ^(GET|POST)$
 RewriteCond %{THE_REQUEST} /user/register [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?test\.ru [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
# Восстановление пароля
# /user => password OR /user/register => password
 RewriteCond %{REQUEST_METHOD} ^(GET|POST)$
 RewriteCond %{THE_REQUEST} /user/password [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?test\.ru/user [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
Естественно, вместо «test.ru» должно быть настоящее имя нашего сайта.
 
 
На самом деле, я ещё учёл ещё ряд особенностей структуры моего сайта, в том числе – языковые. И на этом «попалились» все обычные спам-роботы. Уже две недели, как у меня нет ни одного спам-комментария (попытки есть – я их вижу, но у них ничего не выходит). В конце первой недели лог уменьшился в два раза, и время на его анализ. Не говоря уже о том, что я освободился от печальной миссии удаления комментариев.
 
А это значит, что наконец-то я увидел то, о чём смутно представлял, но не знал подробностей.
 
Referrer-спам (спам через счётчики посещаемости). Спам-боты обращаются к сайту, указывая в заголовке referrer – адрес рекламируемого сайта. Такой вид спама легко портит SEO-рейтинги страниц. Частично, я писал об этом раньше в заметке «Манипуляция (подмена)». Можно блокировать часто встречающие слова в адресах рекламируемых сайтах, можно – адреса полностью…
 
Но самое интересное у меня происходило с Яндексом. Если в Гугле мой сайт был в полном порядке, то в Яндексе – он «провалился». Его веб-мастер в популярных запросах к моему сайту показывал мне полную ахинею.
 
Надо осмотреться и осмыслить. Дело в том, что Яндекс (как и Гугл) уже давно не даёт истинные ссылки. Он их шифрует и что там – никто не скажет. Это произошло под флагом заботы о безопасности пользователей (не передавать третьим лицам кто и что искал). На самом деле – обычное желание монетизировать своё положение и привязать Интернет-пользователей к своим ресурсам и инструментам (для веб-мастеров).
 
Такая политика поисковиков породила ряд интересных вещей.
  1. Они лишили веб-мастеров ряда возможностей (анализа и защиты).
  2. Фактически заставили веб-мастеров регистрироваться у себя (в разделах поддержки веб-аналитиков). Ау, анонимность?
  3. Из-за возникших трудностей у веб-мастеров по анализу и блокированию фальшивых ссылок из поисковиков – боты, использующие такой механизм, стали «безнаказанными».
  4. Эти боты (их адреса) практически отсутствуют в чёрных списках на общедоступных интернетовских ресурсах.
=>  Расширился рынок платных сайтов, программ и инструментов поисковиков, предоставляющих такую информацию и защиту,
 
Двойной профит. Как говорится, мы закрыли колхозный рынок – здравствуй, супермаркет! А главное – все за всё платят!
 
 
Очень интересна позиция Яндекса: обещает фильтровать и не использовать в своей аналитике обнаруженные фальшивые запросы. Да-да, конечно, мы верим. Да только Гугл об этом ничего не знает. И ключевое здесь слово - «обнаруженные». И ещё один «подводный камень» - Яндекс периодически меняет свою систему шифрования. «Но, мы не привыкли отступать!»
 
Как поймать хитрецов, имитирующих переход с Яндекса? Если заметили, в логах посетителей с Яндекса есть некоторый реферал (referer). Если мы по ней щёлкнем – то должны попасть на искомую страницу или на страницу предупреждения о фишинге. В первом случае – всё хорошо, а во втором, скорее всего – это наша «рыбка». Если присмотреться, то можно заметить, что подобные запросы всегда идут группой.
 
Как говорится, «мы с Тамарой ходим парой». А у меня – пятёрками. Эти «друзья» находят самые рейтинговые страницы и периодически долбят с разных адресов. А блокировать по IP или его диапазону – малоинтересно. Не, ну бывают конечно исключения, когда какой-то один и тот же адрес раз в день «долбит» одну и ту же страницу… Да, тут я с вами согласен. Но, блокировка по диапазону – потенциальный путь создания проблем.
 
Заходим в Яндекс (отдельно в русскую и отдельно в украинскую версию), ищем свой сайт, делаем переход. После этого идём в админку и смотрим, с какими рефералами мы туда попадаем. Это правильные ссылки. Сравниваем их с ссылками ботов и находим маркеры, по которым мы можем их определить. Блокируем по таким ссылкам (referer) в «.htaccess». Проблема частично решена. Почему частично? На каждый хитрый… есть свой…
 
Текст, как я их ловлю – не привожу, это моя безопасность. К тому же, Яндекс меняет правила. А это значит, что то, что работает сегодня – завтра может перестать. Ещё: если при проверке реферала ссылка откроется правильно, это всё равно может быть фальшивкой (которую можно поймать по маркерам), которая и даёт Яндексу фальшивый запрос. Помните, выше я писал о странных словах в популярных запросах в веб-инструментарии?
 
 
Через неделю лог стал ещё чище. Плюс, первые результаты – сайт начал возвращать свои позиции, а страницы – правильный вес. В логе стали заметны другие интересные «косяки». Например, частый просмотр технической страницы «hxxp://<мой сайт>/node». Это – «дубль» основной страницы сайта. Скажите, как человек, вы бы стали набирать такой адрес? И я тоже.
 
Для контроля я зашёл в Google Analytics и посмотрел популярные страницы входа на сайт и процент «отказа обслуживания». На первом месте – «/node» (40% посетителей, 100% отказа), а на втором – «/comment/reply/80» (7% и 100% соответственно). Со вторым – понятно, ну и в первом случае это явно делают роботы. Т.к. в своём «robots.txt» я закрыл все дубли, поэтому смело поставил запрет:
 
# Запрещаем просмотр бесполезных и технических страниц
# /node
 RewriteCond %{THE_REQUEST} ^GET\s/(\?q=)?node(/)?\sHTTP/ [NC]
 RewriteRule ^(.*)$ "" [L,F]
 
Понятно, что если у вас многоязычный сайт – нужно маленькое дополнение.
 
 
Favicon. А потом посмотрел логи ещё раз на предмет ошибки «404». И обнаружил, что очень многим роботам в «корне» сайта крайне необходим файл «favicon.ico». Я как-то не задумывался об этом, т.к. он у меня подключён через тему. Но «старые» роботы не хотят его искать. Кроме того, если у вас на страничке есть ошибки, файл может быть не найден и тогда уже «новые» роботы пойдут его искать в «корне». Что интересно, Яндекс его всегда ищет обоими способами. Пришлось скопировать.
 
 
Похоже, что у меня вырисовывается серия о борьбе с роботами. Конечно же, это ещё не конец! «There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy».
 
 
 
Скорее всего, продолжение будет после обновления движка сайта. Не прощаюсь, всегда ваш,
 
         01.06.2015 г.    Карандаш.
 
 
P.S.: Спасибо Марку Бернесу за его добрые песни!
 

Комментарии

Статья супер.
А "уважаемые роботы" изрядно повеселили :)

Есть ещё один простой трюк, который позволяет не тратить время на раздумья: "правда это плохой User-agent или нет?", а сразу блокировать до половины плохих роботов. Основан на психологии. Подсказка: как определить, записку писал школьник или взрослый человек? :)
 
Очень интересна тема ловушек для роботов.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer