Шаг 1. Определите, что именно защищаете
Каталог, цены, остатки, поиск, фильтры, контакты и API имеют разную ценность и стоимость запроса. Защита должна быть сильнее на маршрутах, которые scraper может эксплуатировать массово.
- какие URL дают наиболее дорогую нагрузку;
- что нельзя кэшировать;
- какие страницы обязаны видеть поисковые роботы;
- какие endpoints не должны быть публично индексируемыми.
Шаг 2. Снимите baseline по логам
До блокировок измерьте нормальные requests/min, URLs/session, долю 404, наиболее частые последовательности, IP/ASN distribution и verified crawler traffic. Это снижает риск принять пик обычной активности за атаку.
Шаг 3. Включайте защиту слоями
- Hard allow для подтверждённых crawler/служебных клиентов.
- Точные URL/rate rules для очевидных сценариев.
- Browser/network evidence как дополнительный risk.
- Sequence/reputation после накопления выборки.
- Challenge для подозрительных сессий.
- Block только там, где evidence и policy достаточно сильны.
- robots.txt — policy для добросовестных crawler, но не security barrier;
- anti-flood/rate limiting — scoped по дорогим routes, а не один глобальный порог;
- cache/CDN — снижает стоимость повторного чтения публичных страниц;
- Browser/automation evidence — полезно против headless и части anti-detect сценариев;
- residential proxy/IP rotation требуют корреляции identity/behavior, а не IP-only ban;
- AI crawlers и известные боты лучше регулировать отдельной crawler/policy логикой.
Шаг 4. Не создавайте SEO-проблему
Самая опасная ошибка — общий Challenge или rate limit, который не отличает поискового crawler. Второй риск — закрыть важные CSS/JS/resources, из-за чего crawler не сможет корректно отрендерить страницу.
После включения защиты проверяйте access logs, Search Console/Вебмастер, HTTP-коды ключевых URL и фактическую доступность для verified crawler.
Шаг 5. Снижайте экономику scraping
Абсолютно запретить получение публичных данных невозможно, но можно сделать массовый сбор дороже: ограничить скорость, потребовать устойчивую session identity, добавить Challenge на рискованные маршруты и убрать технические endpoints из публичного доступа.
TLS/JA3/JA4 fingerprinting и edge/network filtering находятся вне PHP-runtime AntiPF. Не стоит считать отсутствие этих сигналов недостатком конкретного правила: это другой слой архитектуры.
AntiPF как один из слоёв защиты
Для scraping AntiPF использует scoped Rule Engine, crawler verification, Browser/Network evidence, Adaptive sequences и Challenge. Shadow-first режим позволяет проверить логику до enforcement.