DSpace и боты — попытка анализа ситуации и иллюзия контроля

Институциональные репозитории и поисковые роботы исторически образуют симбиотическую связь. Репозитории обеспечивают контент, поисковые сервисы — трафик. Такое положение вещей на протяжении долгого времени было нормой. Всё было просто и понятно. Фактически, многие институциональные репозитории на базе DSpace и некоторых других специализированных CMS обслуживали клиентов, 90% и более которых приходило из поисковых систем.
Операторы репозиториев регистрировали свои сервисы в «инструментах вебмастера» различных поисковых систем, наблюдали за динамкой обхода, ошибками, кликами и показами. Всё было просто и понятно. Индексирующие роботы поисковых систем в целом работали адекватно — нагрузку создавали аккуратно, user-agent не прятали, robots.txt уважали и всё было прозрачно и контролируемо.

С появлением массы аналитических систем, ранжирующих ресурсы в сети по различным признакам, систем обучения AI и других систем, которые используют индексирующих роботов в своей работе, ситуация резко изменилась. Запросов, генерируемых машинами, а не людьми, стало кратно больше, а в посетителей эти запросы стали конвертироваться кратно меньше. Рост нагрузки (от поисковых роботов) без роста числа посетителей — это не очень хорошо. Этим собственно и обусловлены «актуальность и научная новизна» фразы, вынесенной в заголовок.

Если продолжать в академичность, то наверное нужно сформулировать цели, или хотя бы цель. Попробуем остановится на чем-то типа «Уменьшить долю бесполезных запросов к серверу и/или увеличить качество конвертации индексации ресурса в посещаемость ресурса».

Для достижения целей нужно сформулировать и выполнить определенные задачи, такие как:

1. Понять что там вообще происходит с ботами, например посредством анализа логов.
2. Рассортировать ботов по группам (экспертная работа)
3. Оставить в покое понятных полезных ботов, наблюдая их активность в рамках решения первой задачи, прекратить отношения с понятными не желательными ботами, посредством каких-то дополнительных инструментов, проанализировать заметных в доле нагрузки, но не понятных пока ботов.
4. Решить подзадачи, которые могут возникнуть в рамках решения задачи номер три, либо уточнить цели.

Задача 1
Решать будем посредством анализа логов. В примерах ниже будет суточный лог сервиса apache httpd в формате combined. В принципе, подойдёт и localhost_access_log от apache tomcat, главное чтобы информация об user agent была.

Даём команду:

И удивляемся объёму выданной информации. Для работы команды понадобится какой-нибудь awk и какой-нибудь shell, но в целом я думаю всё понятно, в результате мы получаем список уникальных user-agent из лога, так же информацию о количестве вхождений, т.е. интенсивности индексирования, и сортировку по этому параметру.

Если команду еще чуть-чуть уточнить, то:

Мы получим в результате что-то такое (роботы с количеством вхождений в лог менее 100 не отражены):

Сутками ранее, Googlebot в сумме показывал на порядок больше запросов чм все остальные боты вместе взятые, сейчас в топе YandexBot с более скромной цифрой.

Задача 2
Что мы видим? В чемпионах Yandex нескольких сортов, Bing, Google тоже в количестве, Semrush, Ahrefs, Majestic и из ботов, условно попадающих в первую группу из задачи номер три, наверное всё. Ну хорошо, Semrush тоже не очень, но в целом к этой части вопросов нет.
Боты Apple, Facebook, Twitter и некоторые другие на поверку оказываются (заявляются операторами) не как индексирующие, а как генерирующие превью и выполняющие другие служебные функции, но тут тоже всё не всегда так, как заявляется. Facebook использует разных ботов для превью и для обучения AI — удобно [банить].
Такие боты, как keys-so-bot, ChatGPT и ClaudeBot с высокой долей вероятности можно отнести к той группе, которая не привлечет новых пользователей на сайт, но контент утащит и нагрузку создаст. С PetalBot и некоторыми другими сложнее — надо разбираться.
В рамках решения данной задачи автор не претендует на истинность суждений, лишь выражает частное мнение.

Задача 3
Отлично, ботов на кучи поделили, помечаем себе что гуглояндекс можно мониторить в течении суток командами типа:

И получать результат в виде:

Со второй группой ботов можно решать проблемы по-разному в зависимости от используемого программного обеспечения. Можно использовать простой .htaccess файл в случае использования прокси на apache2, который будет запрещать роботам доступ по user-agent. Это затруднит процесс нежелательного индексирования, но не снизит количество запросов. Можно использовать сервис fail2ban и фильтр apache-badbots, закрывая боту доступ к сервису по user-agent. Это как затруднит роботам доступ, так и снизит нагрузку на веб сервер. Каких-то готовых инструкций здесь не будет, т.к. в рассматриваемой инфраструктуре фильтруется пока всего три user-agent и анализ ситуации продолжается, но тенденция снижения нагрузки на сервер, измеряемой в строках лога (количестве запросов) и объёме отданного трафика определённо уже есть.

Третья группа ботов, которые не понятно полезные или нет, нуждается в дополнительном изучении. Сейчас автор увлеченно «играет» в это но в силу отсутствия прохождений на youtube процесс больше походит на изучение набора бессвязных игровых механик. Прошу прощения за такие аналогии.

Задача 4
Технические решения по блокировке — тема отдельной заметки. Ранжирование роботов по полезности — вопрос во многом субъективный. Анализ новых роботов — тоже. В итоге, можно заключить, что с поправкой на то, что мы верим передаваемому user-agent, мы можем решить все три поставленные задачи без особых проблем, а всё что в рамках задач выглядит слишком комплексно — перенесем в уточнение целей или выводы. Надо только упомянуть еще один момент:

Дальнейший анализ логов показывает что все запросы с конкретным user-agent выполняются с одного хоста конкретного облачного провайдера. Никакого web сервера на этом хосте на первый взгляд нет. Тут уже можно подумать о том, чтобы использовать abuse контакт или как-то иначе связаться с таким активным клиентом.

Выводы
В сухом остатке у нас есть возможность формировать логи так, чтобы иметь информацию о роботах и определённые инструменты для контроля доступа роботов, игнорирующих robots.txt, к сервису. Решит ли это все проблемы? Нет. Вот пример:

Обозреваемый ресурс точно не откроется в IE8, но 3500+ запросов, отраженных в логах укаpывают нам на некоторое противоречие, а еще в логах (май 2025) есть такой user-agent:

Так что, у нас есть инструмент только для контроля за роботами от крупных провайдеров, которым по статусу не положено подделывать user-agent, для роботов, которые представляются чем-то вроде «Интернет эксплорер на windows 95» нужны другие средства.

В моменте анализ логов может помочь найти причину и источник фактической DoS атаки, на дистанции — наблюдать за фактической активностью тех или иных групп сервисов. Анализировать логи не сложно даже без специализированных инструментов, использовать результаты анализа в дальнейшей работе — тоже не сложно, но простые действия решат только часть проблем. Отсечь всё лишнее не навредив нужному будет не просто.