Распродажа создаёт два похожих внешне, но разных по смыслу потока: заинтересованных покупателей и автоматические запросы. Посетитель сравнивает товары, возвращается к корзине и открывает несколько вкладок. Парсер может последовательно выгружать весь каталог, а спам-скрипт — отправлять формы без намерения купить. Если реагировать только на рост запросов, можно ограничить именно клиентов в момент максимального спроса.
Это руководство помогает выстроить подготовку без универсальных «магических» порогов. Оно описывает методику проверки и принятия решений, а не обещает, что один инструмент устранит любые атаки. Базовую настройку удобно начать с пошагового плана защиты интернет-магазина, а здесь сосредоточимся на пиковых нагрузках, контрольных сценариях и сохранении SEO.
1. Соберите исходные показатели до распродажи
Сохраните картину обычной работы магазина за репрезентативный период: будни, выходные и прошлые рекламные всплески, если такие данные доступны. Сравнивайте одинаковые интервалы и сегменты. Суточное среднее скрывает короткую перегрузку, а общее количество посещений не показывает, какой маршрут расходует ресурсы. Отдельно смотрите категории, карточки товаров, поиск, корзину и отправку форм.
В access-логах полезны время, путь, метод, код ответа и длительность обработки. В аналитике — источник визита и последовательность действий; в CRM — качество обращений и подтверждение заказа. Не записывайте в журнал пароли, платёжные данные и полный текст персональных заявок. Для сопоставления используйте минимально необходимые идентификаторы с установленным сроком хранения. Подробная методика есть в статье о различиях полезного и вредного бот-трафика.
Заранее проведите контрольную покупку с телефона и компьютера: переход из рекламы, выбор варианта товара, изменение количества, применение промокода и оформление заказа. Зафиксируйте результат и ожидаемые уведомления. Если базовый сценарий уже нестабилен, сначала устраните проблему магазина: антибот-фильтр не исправляет ошибки платёжной интеграции или медленный запрос к базе данных.
2. Разделите риски по маршрутам, а не по одному IP
Открытие статической страницы и сложный поиск по каталогу имеют разную стоимость. Правило на весь домен может оказаться слишком строгим для просмотра товаров и слишком мягким для ресурсоёмкого endpoint. IP также не равен человеку: мобильные сети и корпоративные подключения объединяют многих пользователей за одним адресом. Принимайте решение по сочетанию признаков и назначению запроса.
| Сценарий | Что проверить | Возможная мера | Риск для клиентов |
|---|---|---|---|
| Выгрузка каталога | Последовательный обход, повторяемость, нагрузка | Ограничение дорогих маршрутов, наблюдение | Быстрое сравнение товаров похоже на автоматизацию |
| Спам в форме | Повторы, результат в CRM, контекст отправки | Серверная валидация и точечные ограничения | Повторная отправка после сетевой ошибки |
| Перегрузка поиска | Время ответа, ошибки, одинаковые запросы | Лимит по маршруту, кеширование где допустимо | Активный покупатель уточняет фильтры |
| Поисковый обход | Подлинность робота и коды ответа | Проверяемое исключение для индексации | Блокировка ухудшает доступ к страницам |
Таблица не является готовым набором правил. Например, быстрый обход не доказывает парсинг, а отсутствие JavaScript не доказывает вред. Подозрение должно подтверждаться повторяемостью, контекстом и последствиями. Для защиты форм отдельно прочитайте руководство по спам-заявкам и реальным лидам.
3. Как принимается решение о запросе
- Запрос
Покупатель, робот или интеграция обращается к маршруту.
- Проверка контекста
Учитываются цель, поведение, частота и проверяемые исключения.
- Соразмерная реакция
Разрешить полезный доступ или ограничить подтверждённый вредный сценарий.
Схема подчёркивает важную границу: защита должна учитывать контекст, а не считать любой автоматический запрос атакой. Платёжный callback и браузер покупателя взаимодействуют с сайтом по-разному. Если обязательная браузерная проверка попадёт на серверную интеграцию, заказ может остаться неоплаченным в системе даже после успешной оплаты у провайдера.
4. Введите правила постепенно и протестируйте всплески
Начинайте с наблюдения и наиболее понятного вредного сценария. Выберите один маршрут, опишите ожидаемый эффект и критерий остановки эксперимента. Сначала проверьте правило на тестовых запросах, затем на ограниченном реальном потоке, если инфраструктура позволяет такой запуск. Изменение нескольких условий одновременно затрудняет понимание причины ошибок и последующий откат.
При выборе rate limiting учитывайте краткие всплески: покупатель может открыть несколько карточек за секунду, обновить корзину или повторить действие после потери сети. Разделяйте просмотр, поиск и операции записи. Ответ об ограничении должен быть предсказуемым для клиента и интеграции; не подменяйте ошибку страницей с успешным кодом 200. Прикладную механику разбирает материал о rate limiting и поведенческой защите.
Нагрузочную проверку проводите только на своей инфраструктуре или с разрешения владельца и хостинга. Заранее согласуйте пределы, время и стоп-условия. Тест не должен мешать реальным покупателям или внешним сервисам. Сам по себе высокий показатель запросов в секунду не подтверждает готовность: проверьте время ответа, долю ошибок и завершение бизнес-операций.
5. Сохраните SEO, оплату и служебные интеграции
До включения новых правил проверьте главную, категории, карточки и посадочные страницы распродажи. Они должны отдавать ожидаемые коды ответа, корректный canonical и доступный контент. robots.txt регулирует обход для соблюдающих его роботов, но не заменяет контроль доступа. Закрытые данные нужно защищать авторизацией, а не запретом в robots.txt.
Не создавайте исключение только по строке Googlebot или Яндекс.Бота: User-Agent подделывается. Используйте актуальные способы проверки, опубликованные оператором робота, и контролируйте результат в логах. Практические ограничения описаны в статье как не заблокировать индексацию. AI-краулеры рассматривайте отдельно: у них могут отличаться цели и политика доступа.
Составьте список интеграций: платёжные уведомления, обмен остатками, доставка, CRM и мониторинг. Для каждой определите маршрут, механизм аутентификации и способ проверки после изменения. Не открывайте широкий доступ ради одного callback и не публикуйте секреты в документации. Если меняется DNS-маршрут, следуйте инструкции подключения и проверяйте TLS, origin и возможность возврата к прежней конфигурации.
6. Контролируйте продажи, ошибки и доступность
Число остановленных запросов — технический показатель, а не самостоятельное доказательство пользы. Сопоставляйте его с нагрузкой origin, временем ответа, ошибками, успешными заказами и качеством лидов. Конверсия зависит также от рекламы, ассортимента и цены: падение после настройки требует расследования, но не доказывает причинность без проверки сегментов.
| Этап | Проверки | Ожидаемый результат |
|---|---|---|
| До старта | Покупка, callbacks, роботы, исходные метрики | Понятна норма и известен способ отката |
| Во время пика | Ошибки, задержки, заказы, обращения в поддержку | Полезный трафик сохраняет доступ |
| После пика | CRM, журналы, индексация, ложные срабатывания | Решения подтверждены данными и документированы |
Назначьте ответственного и резервного сотрудника. Поддержке нужен простой способ передать время ошибки, маршрут и безопасный идентификатор обращения, а не просьба прислать пароль или платёжные сведения. При жалобе воспроизведите сценарий, сопоставьте его с журналом решений и определите, отвечает ли за проблему защита, приложение или внешняя интеграция.
7. Подготовьте откат и финальный чек-лист
Сохраните предыдущую конфигурацию и описанный порядок возврата. Укажите, кто может менять правила, где фиксируется изменение и каким тестом подтверждается восстановление. Не ждите универсального численного порога: для критического сбоя оплаты достаточно подтверждённого неработающего сценария. При менее очевидной аномалии сначала проверьте сегмент и сопутствующие изменения.
- Собраны исходные метрики и проверена контрольная покупка.
- Каталог, поиск, формы и checkout рассматриваются отдельно.
- Исключения для роботов и интеграций проверены, а не основаны только на названии.
- Доступны robots.txt, sitemap и публичные страницы с корректными ответами.
- Правила вводятся постепенно; тесты не затрагивают чужую инфраструктуру.
- Есть ответственные, журнал изменений, стоп-условия и готовый откат.
- После распродажи проверяются заказы, ложные ограничения и поисковый обход.
Что сделать после завершения кампании
Сопоставьте интервалы до и после настройки, выделите реальные проблемы и уберите временные исключения, которые больше не нужны. Зафиксируйте решения для следующего пика, но не переносите пороги автоматически: каталог, рекламные источники и поведение клиентов меняются. Приоритет подготовки — работающий путь покупки и управляемая нагрузка, а не максимальное количество заблокированных запросов.
Для следующего шага изучите защиту интернет-магазинов и оцените экономический контекст через калькулятор потерь от ботов. Расчёт помогает обсуждать приоритеты, но не заменяет проверку фактических логов и заказов.