Почему боты создают огромную нагрузку на динамические конечные точки в WordPress

Боты часто рассматриваются как проблема безопасности или SEO. Но в хостинговой инфраструктуре WordPress бот-трафик – это скорее проблема производительности, сосредоточенная на очень специфическом наборе URL-адресов.

Не все запросы оцениваются одинаково. Разница между кэшированной статической страницей и динамической конечной точкой – это далеко не погрешность вычислений. Это разница между запросом, который практически ничего не стоит, и запросом, который резервирует поток PHP, инициирует обращение к БД и создает накладные расходы сессии (overhead), независимо от того, является ли посетитель реальным клиентом или ботом.

Понимание причин, по которым одни конечные точки обходятся гораздо дороже других, отличает эффективную стратегию управления ботами от той, в которой блокируется слишком много или слишком мало.

Не все запросы одинаковы

Когда посетитель попадает на типичную страницу WordPress, например, на пост в блоге, страницу со списком товаров или страницу «О нас», сервер почти всегда отправляет ответ из кэша.

Полностраничное кеширование Kinsta обрабатывает это на периферии, поэтому запрос никогда не обращается к PHP-коду сервера или к БД.

Но когда запрос поступает на некэшируемый эндпоинт, серверу приходится выполнять реальную работу. Выделяется и удерживается поток PHP на протяжении всего запроса, выполняется обращение к базе данных. Если страница содержит информацию о состоянии корзины, пользовательских сессиях или персонализированном контенте, требуется еще и обработка сессий. Ничто из этого не может быть кэшировано, поскольку ответ уникален для каждого запроса.

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

Трафик ботов ломает эту модель. Веб-краулер не добавляет товары в корзину и не совершает конверсии, но запускает те же серверные операции, что и реальный клиент, с такой скоростью, которую не смог бы поддерживать человек.

Какие динамические эндпоинты страдают чаще всего

В магазинах WooCommerce следующие шаблоны URL-адресов и конечные точки не кэшируются по своей природе, и именно на них чаще всего нацеливается бот-трафик.

?add-to-cart=

Это самый ресурсоемкий пример, который мы задокументировали в нашем отчете о трафике, связанном с ИИ и ботами. Добавление товара в корзину требует выполнения PHP-кода, записи в базу данных и создания или валидации сессии. Кэшированной версии этого ответа нет, поскольку каждый запрос выполняется заново.

Для сравнения: данные инфраструктуры Kinsta однажды зафиксировали 7,67 миллиона добавлений в корзину от пяти ботов за 24 часа.

Это примерно один запрос каждые 11 миллисекунд, круглосуточно, каждый из которых требует полного выполнения PHP-кода и обращения к базе данных, при этом не генерируя никакого осмысленного результата для краулера.

/cart и /checkout

В WooCommerce эти страницы по умолчанию исключаются из страничного кэширования. Они содержат данные текущей сессии, персонализированное состояние корзины и (в случае оформления заказа) логику обработки платежей.

Бот, многократно обращающийся к /checkout, ничего полезного не делает, но сервер об этом не знает. Сервер обрабатывает каждый запрос так, как если бы это была реальная транзакция.

?s= (Поисковые запросы)

Поисковые запросы в WordPress и WooCommerce всякий раз обращаются к вашей БД. Нет кэширующего слоя, способного обработать уникальную поисковую строку.

Краулер, работающий с параметризованными вариантами URL-адресов или просто переходящий по каждой найденной ссылке, может генерировать длинный хвост уникальных, ресурсоемких запросов к базе данных.

Фасетная навигация и параметры фильтрации

Вот тут-то и усугубляется проблема. Типичный каталог товаров WooCommerce генерирует URL-адреса следующего вида:

/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2

Для человека это незначительные изменения той же самой страницы. Для бота, переходящего по ссылкам, каждая из них — это уникальный URL-адрес, который стоит просканировать, и для каждой ссылки серверу необходимо выполнить с нуля отфильтрованный запрос к базе данных.

В документации Google прямо указано, что фасетная навигация является источником неэффективности краулинга, поскольку поисковые роботы просматривают практически бесконечное количество вариаций одного и того же контента. Но проблема не только в том, что краулер тратит свои ресурсы впустую. Каждая вариация сжигает реальные серверные ресурсы, уходящие на ее генерацию.

Взаимодействия на основе AJAX

Плагины для вишлистов, проверок доступности, обновления цен в реальном времени и календарей используют AJAX-запросы, которые полностью обходят страничный кэш.

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

Что происходит, когда заканчиваются потоки PHP?

Каждый запрос к динамическому эндпоинту удерживает поток PHP на протяжении всего времени выполнения запроса. Эта деталь сама по себе кажется незначительной, но емкость потоков ограничена, и боты не ставят запросы в очередь.

Kinsta выделяет фиксированное количество потоков PHP для каждого WordPress-сайта, и каждый некэшируемый запрос резервирует один поток на время своего выполнения.

При нормальном трафике это редко становится препятствием. Запросы поступают, обрабатываются быстро, и потоки освобождаются.

При постоянной нагрузке ботов на динамические эндпоинты потоки резервируются и удерживаются. Когда все потоки заняты, новые входящие запросы ожидают в очереди. Реальные клиенты, пытающиеся добавить товар в корзину или завершить оформление заказа, сталкиваются с медленной загрузкой страниц, таймаутами или ошибками HTTP 504.

Это инфраструктурная реальность, из-за которой бот-трафик на динамических конечных точках существенно отличается от бот-трафика на страницах, которые можно кэшировать.

Проблема зацикливания: когда боты вязнут

Большая часть бот-трафика, наблюдаемого командой Kinsta, не является результатом преднамеренных атак. Это результат работы краулеров, которые переходят по каждой ссылке на каждой странице, не имея при этом механизма распознавания своего зацикливания.

Вот как на практике выглядит такой цикл:

1. Бот заходит на страницу /shop/
2. На этой странице находится ссылка на /shop/?color=blue (отфильтрованное представление)
3. На этой странице находится ссылка на /shop/?color=blue&size=M
4. На этой странице находится ссылка на /shop/?color=blue&size=M&orderby=price
5. На этой странице находится ссылка для добавления товара в корзину: /shop/?add-to-cart=123
6. Каждая из этих ссылок немного отличается от остальных, и бот еще не посещал эти страницы.

Бот проходит по всем страницам. Он не понимает, что «я уже видел эту страницу товара в другом состоянии фильтра». Каждый URL-адрес выглядит новым, а потому повторно запрашивается у сервера.

Именно такая закономерность обхода для ботов, обрабатывающих различные варианты строк запроса на динамических конечных точках, является одной из наиболее распространенных проблем, отмеченных в нашем отчете. Всего одно правило позволило нам отфильтровать 550 миллионов запросов за 30 дней в инфраструктуре Kinsta. Это не атака, а неэффективная автоматизация в масштабе, усугубляющаяся тем, что ее не выявили на ранней стадии.

Как выглядит эффективное управление ботами на уровне эндпоинтов

Для магазинов WooCommerce и сайтов WordPress с динамическим функционалом несколько принципов остаются в силе независимо от вашей конкретной конфигурации.

1. txt — это сигнал, а не защита. Вы можете (и должны) запретить краулерам использовать пути /cart, /checkout и ?add-to-cart= в вашем robots.txt. Googlebot это учитывает. Однако соблюдение требований robots.txt является добровольным. Всё большее число краулеров, обучающих ИИ, либо не проверяют его, либо не учитывают. Запрет пути в robots.txt сообщает о вашем намерении; для его принудительного соблюдения требуется правило уровня WAF.
2. Сузьте генерацию параметров URL. Дефолтная конфигурация WooCommerce генерирует длинный список вариантов URL с токенами сессии, параметрами количества товара и комбинациями фильтров. Урезание допустимых параметров на уровне источника с помощью канонических тегов, консолидированной структуры постоянных ссылок и правил Disallow в robots.txt уменьшает количество циклов, в которых могут застрять краулеры.
3. Отслеживайте ситуацию на уровне эндпоинтов, а не только общий объем запросов. Всплеск трафика в целом может указывать на рекламную кампанию. Всплеск запросов к ?add-to-cart= от пользователей без браузеров — на проблему с ботами. Логи сервера и аналитические инструменты, показывающие распределение запросов по шаблонам URL и пользовательским агентам, — это разница между обнаружением проблемы за несколько часов и обнаружением за несколько дней.
4. Емкость потоков PHP — ваша основная метрика. Если ваши потоки PHP регулярно работают на пределе своих возможностей, и при этом не наблюдается соответствующего всплеска реальных пользовательских сессий, то почти наверняка одним из факторов является бот-трафик на динамических конечных точках. Инструмент APM от Kinsta отображает самые медленные транзакции PHP по конечным точкам, поэтому, если виновником является путь корзины или оформления заказа, вы увидите это напрямую, а не будете гадать.

Как это выглядит для разных типов сайтов

Проблема динамических конечных точек наиболее остро стоит для магазинов WooCommerce, но она проявляется в различных формах на сайтах разных типов.

1. Магазины WooCommerce подвергаются наибольшему риску, поскольку их самые ресурсоемкие конечные точки, такие как корзина, оформление заказа и страницы товаров с фильтрами, — это именно те точки, которые боты находят, переходя по обычным ссылкам. Последствия очевидны: истощение потоков PHP во время пиковых нагрузок со стороны ботов ухудшает производительность оформления заказа для реальных покупателей.
2. Контентные сайты и блоги могут значительно пострадать от ботов, просматривающих постраничные архивы, страницы меток и результаты поиска. Каждый уникальный поисковый запрос — это новое обращение к базе данных. Агрессивный веб-краулер, систематически обрабатывающий большой архив, может создавать постоянную нагрузку на БД.
3. Сайты компаний и сервисов чаще всего сталкиваются с проблемами, связанными с эндпоинтами форм (контактные формы, формы запроса коммерческого предложения и формы бронирования), которые включают обработку сессий и часто запись в БД. Данные форм, отправленные ботами, представляют собой другую проблему (загрязнение CRM-системы, неэффективные усилия отдела продаж), но основной механизм тот же: динамические конечные точки, которые требуют реальных ресурсов при каждом обращении.
4. Веб-приложения и SaaS-продукты представляют собой наиболее уязвимый случай. Их API-интерфейсы, маршруты панели управления и логика приложений не кэшируемы, и любой трафик от ботов на уровне приложения полностью обходит инфраструктуру кэширования. В этом случае обычно следует жестко блокировать весь неаутентифицированный трафик к путям /api и /app, создавая явный allowlist для легитимных интеграций.

Углублённый анализ: полная картина бот-трафика

Проблема динамических конечных точек — это лишь часть более масштабных трансформаций того, как бот-трафик влияет на инфраструктуру WordPress. Количество ИИ-краулеров значительно возросло: они стали агрессивнее переходить по ссылкам, чаще игнорировать директивы сканирования, и всё больше трафика поступает именно на те конечные точки, обслуживание которых обходится дороже всего.

Для полного обзора изменений, данных, лежащих в их основе, а также структуры принятия решений по управлению ботами с учётом особенностей вашего сайта и приоритетов, ознакомьтесь с полным отчётом Kinsta «The AI & Bot Traffic Reality Check», который охватывает все аспекты, включая анализ более 10 миллиардов запросов на инфраструктуре, управляемой Kinsta.

Источник: https://kinsta.com