Screaming Frog SEO Spider при обходе крупного сайта: настройка режима БД на SSD, лимитов JVM-памяти и рендеринга Chromium

Screaming Frog SEO Spider при обходе крупного сайта: настройка режима БД на SSD, лимитов JVM-памяти и рендеринга Chromium

На небольшом корпоративном сайте до 20 тысяч страниц Screaming Frog прощает любые настройки «из коробки». Но стоит запустить на ноутбуке технический аудит интернет-магазина автозапчастей, классифайда недвижимости или федерального каталога на 500 000 – 5 000 000 URL, как всплывают три классические беды: интерфейс намертво замирает на сборке мусора Java (Garbage Collection), системный раздел диска переполняется за два часа, либо встроенные вкладки headless-Chromium при рендеринге SPA съедают всю свободную память системы.

Ниже — проверенная инженерная конфигурация краулера и аппаратной части ноутбука, опирающаяся на официальную документацию разработчиков Screaming Frog.

Парадокс выделения памяти: почему «отдать программе все 28 из 32 ГБ ОЗУ» — ошибка

Начинающие специалисты думают: «У меня на ноутбуке 32 ГБ оперативной памяти — выставлю в File -> Settings -> Memory Allocation 28 ГБ, чтобы краулер летал!». Для старого режима хранения в оперативной памяти (Memory Storage Mode) это имело смысл, но в современном режиме хранения в базе данных на диске (Database Storage Mode) завышенный пул кучи JVM (-Xmx) работает строго во вред:

1. В режиме базы данных основная таблица графа ссылок, кодов ответа и извлечённых тегов сбрасывается на быстрый внутренний NVMe SSD, а оперативная память нужна не только самой оболочке Java, но и файловому кэшу операционной системы плюс отдельным дочерним процессам браузера Chromium (если включён режим JavaScript Rendering, его потоки живут за пределами выделенного лимита Java!).
2. Огромная куча Java в 24–28 ГБ накапливает гигабайты временных строковых объектов, после чего пауза сборки мусора (Stop-the-World GC) подвешивает окно программы на десятки секунд.

Четыре настройки Configuration -> Spider, которые экономят 60 % диска и времени обхода

На интернет-магазине с фасетными фильтрами (?color=red&sort=price&brand=...) 90 % дисковой базы краулера забивают мусорные комбинации параметров и сквозные ссылки в мега-меню шапки и подвала на каждой из миллиона страниц:

1. Отключите хранение ненужных ресурсов (Crawl / Store Images, CSS, SWF), если цель аудита — перелинковка и индексация HTML: в режиме без JS отключение обхода внешних скриптов и картинок ускоряет сборку графа в 3–4 раза. Если же включён JS Rendering, обязательно оставьте разрешённым чтение CSS и JS (иначе клиентский роутер и вёрстка не соберут DOM!), но заблокируйте тяжёлые видео, веб-шрифты .woff2 и внешние рекламные пиксели через Exclude!
2. Не храните полный сырой и отрендеренный HTML (Store HTML / Store Rendered HTML) на обходах свыше 500 тыс. страниц без крайней нужды: миллион сохранённых DOM-слепков по 180 КБ превратят проектную базу во внутреннем каталоге Screaming Frog в 180–250 ГБ на SSD за один вечер! Вместо хранения всей вёрстки пропишите целевые Custom Extraction (XPath / CSS Path / Regex) до старта краула — в базу запишутся только нужные 200 байт текста хлебных крошек, цены или JSON-LD на страницу.
3. Ограничьте фасетные ловушки до старта: проверьте правила Exclude и URL Rewriting на тестовой выборке в 5 000 страниц, сопоставив структуру URL с реальными посещениями поисковых роботов из анализа серверных логов в DuckDB.
4. Следите за нагрузкой на боевой сервер клиента (Speed -> Max Threads / Max URLs/s): современный ноутбук с гигабитным каналом и 20 потоками легко отправляет 40–80 запросов в секунду и валит слабый PHP/Bitrix-сервер интернет-магазина ошибками 502 / 504 или попадает под бан WAF / Cloudflare / DDoS-Guard по IP офиса. Для продакшн-сайта без предварительного согласования с DevOps ограничивайте скорость до 3–8 URL/с и прописывайте согласованный User-Agent.

Где живёт база краулов на ноутбуке и как не убить системный SSD

По умолчанию Screaming Frog складывает гигабайтные папки всех прошлых обходов в скрытый системный профиль пользователя (%USERPROFILE%\.ScreamingFrogSEOSpider\ProjectInstanceData на Windows или ~/.ScreamingFrogSEOSpider/ на macOS/Linux) и не удаляет старые проекты автоматически при закрытии окна. Через полгода работы в агентстве эта папка незаметно разрастается до 300–600 ГБ, забивая системный диск под завязку!

Практическое решение:

• в меню File -> Crawls удаляйте отработанные промежуточные обходы сразу после выгрузки отчётов и архивного .dbseospider-файла на внешний архивный накопитель;
• при покупке или модернизации рабочего ноутбука технического SEO-специалиста ставьте второй NVMe SSD M.2 на 1–2 ТБ на TLC-памяти с высоким ресурсом перезаписи (TBW) специально под рабочие базы Screaming Frog, локальные дампы выгрузок GSC и Вебмастера и серверные логи (как подобрать накопитель без просадки скорости записи — в статье про апгрейд оперативной памяти и SSD в ноутбуке, а про нативную работу arm64-сборки краулера от батареи без шума вентиляторов — в сравнении MacBook на Apple Silicon M1, M2 и M3).

Чек-лист перед запуском ночного многомиллионного обхода на ноутбуке

• [ ] Включён режим Database Storage Mode на быстром внутреннем NVMe SSD со свободным запасом минимум 100–200 ГБ.
• [ ] Лимит памяти Java выставлен разумно (4–8 ГБ), с запасом не менее 8–16 ГБ свободной ОЗУ для ОС и процессов Chromium.
• [ ] В ОС отключён уход ноутбука в сон при работе от сети (на macOS запущена штатная команда caffeinate -i, на Windows — профиль «Никогда не переводить в спящий режим»).
• [ ] На выборке первых 2 000 URL проверено отсутствие бесконечных календарных/фильтровых ловушек, 429 Too Many Requests и блокировки WAF.
• [ ] Проверена корректная сборка XPath/CSS-извлечений и API-коннекторов до ухода из офиса.

Частые вопросы

Почему на MacBook с процессором Apple Silicon Screaming Frog раньше тормозил, а у коллег работает мгновенно? Если перенести программы со старого Intel Mac через «Ассистент миграции», остаётся x86_64-версия под эмуляцией Rosetta 2. Скачайте с официального сайта установочный образ именно архитектуры Apple Silicon (arm64 / aarch64) — нативная Java-машина и ARM-сборка Chromium работают в разы быстрее и заметно меньше расходуют заряд батареи.

Что делать, если посреди обхода 1,5 млн страниц моргнул свет или перезагрузился роутер? В режиме Database Storage Mode прогресс транзакционно сохранён на SSD! Откройте File -> Crawls, выберите незавершённый проект, дождитесь восстановления связи и нажмите Resume — краулер продолжит обход с очереди необработанных URL без повторного скачивания уже пройденного миллиона страниц.