SEO-специалист запускает технический аудит крупного сайта — и спустя 10 минут Screaming Frog начинает выдавать сплошные 403 Forbidden или 429 Too Many Requests. Сервер защиты принял краулер за атакующего бота и заблокировал IP-адрес. Результат — аудит придётся перезапускать, а клиенту объяснять, почему отчёт задержался. Решается проблема грамотной настройкой прокси для краулера — разберём, как именно.
Почему сайты блокируют Screaming Frog при аудите
Screaming Frog, Sitebulb, JetOctopus и Netpeak Spider технически работают так же, как боты поисковых систем: они быстро обходят тысячи URL подряд, скачивают HTML, CSS, JS и изображения, проверяют редиректы и статус-коды. С точки зрения защиты сайта (Cloudflare, Qrator, DDoS-Guard, встроенный WAF хостинга) это выглядит как подозрительная активность — слишком много запросов с одного IP за короткое время.
Особенно часто блокировки случаются при аудите:
- крупных интернет-магазинов на Wildberries-подобной инфраструктуре с собственной защитой от парсинга;
- сайтов за Cloudflare с включённым режимом "Under Attack" или высоким уровнем Security Level;
- порталов с динамическим контентом, где каждый запрос генерирует нагрузку на сервер (поиск, фильтры, листинг товаров);
- сайтов конкурентов, которые вы анализируете не со своего домена — у них нет причин доверять вашему IP.
Дополнительная сложность: если у агентства один статический IP офиса, а аудит сайтов идёт регулярно (несколько клиентов в день), этот IP быстро попадает в черные списки защитных систем. После этого блокируются не только текущий, но и будущие аудиты с того же адреса — даже для сайтов, которые раньше открывались без проблем.
Как распознать блокировку по кодам ответа
Прежде чем менять настройки прокси, важно понять, что именно происходит. Screaming Frog показывает код ответа в столбце Status Code — по нему легко определить причину остановки краулинга.
| Код ответа | Что это значит | Что делать |
|---|---|---|
| 403 Forbidden | IP заблокирован защитой сайта | Сменить IP, снизить скорость краулинга |
| 429 Too Many Requests | Превышен лимит запросов в единицу времени | Уменьшить число потоков, добавить задержку |
| 503 Service Unavailable | Сервер перегружен или включена защита от ботов | Сменить User-Agent, использовать резидентный IP |
| Нет ответа / Timeout | IP в чёрном списке, запросы не доходят | Полная замена прокси-пула |
Если в отчёте массово появляется один и тот же код на тысячах URL подряд — это почти всегда блокировка по IP, а не реальная проблема сайта. Проверить гипотезу просто: откройте проблемный URL в обычном браузере с того же IP. Если страница открывается нормально, а Screaming Frog получает 403 — дело в краулере, а не в сайте.
Какие прокси подходят для SEO-краулинга
Выбор типа прокси зависит от задачи: разовый аудит своего сайта, регулярный мониторинг конкурентов или сканирование защищённого маркетплейса. Разберём три основных типа и их применимость для краулеров.
| Тип прокси | Скорость | Риск блокировки | Когда использовать |
|---|---|---|---|
| Прокси дата-центров | Высокая | Средний-высокий на защищённых сайтах | Аудит собственного сайта без строгой защиты |
| Резидентные прокси | Средняя | Низкий | Аудит конкурентов, сайты за Cloudflare, маркетплейсы |
| Мобильные прокси | Средняя-низкая | Минимальный | Самые агрессивные защиты, редкий точечный аудит |
Для большинства регулярных технических аудитов оптимальный баланс дают резидентные прокси — они используют реальные IP-адреса провайдеров, поэтому защита сайта воспринимает запросы краулера как трафик обычного пользователя. Это особенно важно, если вы анализируете не свой домен, а сайт конкурента или маркетплейс с жёсткой антибот-системой.
Прокси дата-центров остаются хорошим вариантом, когда вы аудируете собственный сайт и можете заранее добавить IP-диапазон в белый список на уровне WAF или Cloudflare — тогда скорость сканирования будет максимальной без риска блокировок.
Пошаговая настройка прокси в Screaming Frog
Screaming Frog поддерживает прокси "из коробки", настройка занимает пару минут:
- Откройте программу и перейдите в меню Configuration → System → Proxy.
- Поставьте галочку Use Proxy Server for All Traffic.
- Введите адрес и порт прокси-сервера, полученные от провайдера.
- Если прокси требует авторизацию по логину и паролю — укажите их во всплывающем окне при первом запросе.
- Нажмите OK и перезапустите краулинг для применения настроек.
Важный нюанс: Screaming Frog в бесплатной и платной версии умеет работать только с одним прокси-сервером за раз через встроенный интерфейс. Если нужна ротация IP на лету (актуально при сканировании от 50 000 страниц), используйте прокси с автоматической сменой IP на стороне провайдера — это настраивается не в самом краулере, а в личном кабинете прокси-сервиса, где задаётся интервал смены IP (например, каждые 10 минут или при каждом новом запросе).
Такая схема снимает нагрузку с одного адреса: краулер продолжает работать с одним портом, а IP за ним меняется автоматически, и сайт не видит аномально высокую частоту запросов с одного конкретного адреса.
Настройки скорости и потоков для больших сайтов
Даже с рабочим прокси слишком агрессивные настройки скорости краулинга спровоцируют блокировку. В Screaming Frog за это отвечает раздел Configuration → Speed. Рекомендованные значения для сайтов от 100 000 страниц:
- Max Threads: 2–5 для защищённых сайтов, 10–15 для сайтов без строгой защиты;
- Max URI/s: ограничьте 2–3 запросами в секунду на старте, постепенно увеличивайте, наблюдая за кодами ответа;
- Custom User-Agent: в разделе Configuration → HTTP Header используйте User-Agent реального браузера вместо стандартного "Screaming Frog SEO Spider", если сайт блокирует краулеры по заголовку;
- Respect robots.txt / crawl-delay: учитывайте директиву Crawl-delay, если она прописана — игнорирование часто приводит к бану на уровне сервера.
Для сайтов с агрессивной защитой от ботов полезно также включить режим JavaScript Rendering только там, где это реально необходимо (SPA-сайты на React/Vue) — рендеринг JS резко увеличивает нагрузку на сервер и повышает шанс блокировки при краулинге через один IP.
Ротация IP при сканировании 100 000+ страниц
Чем крупнее сайт, тем важнее грамотно распределить нагрузку между IP-адресами. Для аудитов такого масштаба работают две схемы:
Ротация по времени. IP меняется автоматически каждые 5–15 минут независимо от количества запросов. Подходит для равномерного длительного краулинга, когда сканирование растягивается на несколько часов.
Ротация по запросу. Каждый новый HTTP-запрос уходит с нового IP из пула. Такой режим даёт максимальную защиту от блокировок, но может мешать корректной работе с cookie-based авторизацией или сессионными параметрами сайта — для чистого технического аудита (сбор статус-кодов, редиректов, мета-тегов) это не критично.
Для агентств, которые ведут параллельный аудит нескольких клиентских сайтов, разумно разделять пулы IP по проектам — это предотвращает ситуацию, когда блокировка на одном домене "по ошибке" распространяется на репутацию IP при работе с другим сайтом.
Совет на практике: перед большим аудитом запустите тестовый краулинг на 500–1000 URL с текущими настройками скорости и прокси. Если за это время не появилось 403/429 ошибок, можно смело масштабировать сканирование на весь сайт.
Чек-лист перед запуском аудита
- ✅ Прокси подключён и протестирован на доступность (проверка через curl или отдельный браузер);
- ✅ Max Threads и Max URI/s выставлены консервативно для первого прогона;
- ✅ User-Agent настроен корректно, не вызывает подозрений у WAF;
- ✅ Respect robots.txt включён, если сайт явно просит соблюдать Crawl-delay;
- ✅ JavaScript Rendering включён только при реальной необходимости;
- ✅ Настроена ротация IP при объёме сайта от 20 000–30 000 страниц;
- ✅ Сохранение прогресса краулинга включено (Configuration → Save Crawl) на случай обрыва сессии;
- ✅ Для аудита маркетплейсов и защищённых порталов выбраны резидентные или мобильные прокси вместо дата-центр.
Частые ошибки при краулинге через прокси
Слишком высокая скорость на старте. Специалисты часто ставят максимум потоков сразу, надеясь ускорить аудит. В результате защита сайта реагирует молниеносно, и уже через пару минут весь прокси-пул оказывается в чёрном списке.
Один статичный IP для всех клиентских проектов. Если агентство использует один и тот же дата-центр прокси для десятков аудитов в месяц, репутация этого IP быстро падает — защитные системы разных сайтов обмениваются данными о подозрительных адресах через общие базы (например, Cloudflare IP Reputation).
Игнорирование geo-таргетинга. Если аудируемый сайт настроен на конкретный регион (например, российский интернет-магазин с гео-блокировкой зарубежного трафика), использование прокси с IP другой страны само по себе спровоцирует ограничение доступа — даже без агрессивного краулинга.
Отсутствие мониторинга в процессе. Запустив краулинг на несколько часов, специалисты часто не проверяют промежуточные коды ответов. В итоге обнаруживают проблему только по завершении, когда половина отчёта состоит из ошибок блокировки, а не реальных данных о сайте.
Заключение
Блокировки при техническом аудите в Screaming Frog почти всегда решаются комбинацией трёх факторов: правильный тип прокси, разумная скорость краулинга и грамотная ротация IP. Для собственных сайтов без строгой защиты достаточно прокси дата-центров с добавлением в белый список. Для аудита конкурентов, маркетплейсов и сайтов за Cloudflare нужны IP, которые выглядят как обычный пользовательский трафик.
Если вы регулярно аудируете чужие домены или защищённые площадки, рекомендуем начать с резидентных прокси — они снижают риск блокировки на самых агрессивных антибот-системах. Для точечных задач на максимально защищённых ресурсах стоит рассмотреть мобильные прокси, а для масштабных аудитов собственной инфраструктуры хорошим и быстрым решением остаются прокси дата-центров.