Сайт из ста тысяч URL это территория, где краулинг превращается из рутинной процедуры в инженерную задачу. Бесплатная лицензия Screaming Frog обрывается на пятисот адресах, обход в оперативной памяти упирается в железо, а неудачная конфигурация растягивает трёхчасовую работу на неделю. В статье собран рабочий порядок настройки: переключение режима хранения, лимиты обхода, работа с параметрами, сегментация аудита и типичные ошибки, из-за которых команда теряет дни на повторные запуски.
Лимит бесплатной версии и годовая лицензия как порог входа в полноценный аудит
Арифметика простая. Бесплатная версия ограничена пятьюстами URL, экспорт результатов в ней урезан, поэтому о серьёзном аудите стотысячной площадки с ней говорить не приходится. Платная лицензия оформляется на год и на одного пользователя, стоит на уровне нескольких часов работы подрядчика и окупается на первом же проекте. После окончания оплаченного периода программа продолжает работать в установленной версии, просто перестают приходить обновления. Для агентства это значит, что лицензия не превращается в тыкву ровно через двенадцать месяцев, и на длинном проекте можно спокойно сидеть на проверенной сборке.
Требования к рабочей машине важнее цены. Обязательна 64-битная система, а дальше начинается главное различие больших проектов: где программа держит собранные страницы. От ответа зависит, долетит ли паук до конца каталога или упадёт на семьдесят пятой тысяче адресов. Из практики комфортный минимум для стотысячника это 16 ГБ оперативной памяти, а спокойный вариант 32 ГБ: краулер прожорлив не столько сам по себе, сколько при разборе тяжёлых страниц с сотнями ссылок, скриптов и картинок.
Режим Database Storage, который снимает потолок оперативной памяти
Исторически краулер держал весь обход в оперативной памяти. Двадцать тысяч URL на офисной машине ощущались легко, пятьдесят требовали аккуратности, а сотня тысяч превращалась в лотерею: любой скачок потребления памяти завершал работу, и всё приходилось начинать заново. В феврале 2018 года вышла версия 9.0 с режимом Database Storage Mode, и потолок снялся. Собранные страницы пишутся в базу на диске, поэтому объём обхода ограничен скорее свободным местом на накопителе, чем гигабайтами оперативки. Разработчики называют ориентиром миллионы адресов.
Логика выбора режима такая. Обход в памяти быстрее: фильтры и поиск по результатам откликаются мгновенно, экспорт летит. Если проект укладывается в двадцать-тридцать тысяч страниц и на машине есть запас памяти, менять ничего не нужно. На стотысячнике режим базы оправдан даже при 32 ГБ оперативной памяти: длинный обход становится устойчивым к сбоям, а падение программы на десятой тысяче обходится дешевле, потому что собранное уже на диске. Переключение находится в меню Configuration, раздел System, пункт Storage Mode. Базу кладите на быстрый локальный SSD, сетевую папку оставьте для резервных копий: запись по сети замедляет краулинг в разы. После переключения прогоните короткий тест на пару тысяч адресов и посмотрите на поведение счётчика. Если запись данных тормозит весь обход, проблема в накопителе, а не в настройках паука. Перед ночным обходом проверьте свободное место на диске: база стотысячника весит гигабайты, и остановка посреди прохода из-за переполненного накопителя это самый обидный способ потерять ночь. Планируйте объём с запасом и держите предыдущую базу до конца сдачи отчёта, к ней ещё вернётесь за уточнениями.
Во время длинного прогона следите за расходом памяти в диспетчере задач. Если график ползёт к потолку, лучше остановиться, переключиться в режим базы и начать снова, чем ждать аварийного завершения на восьмидесятой тысяче. Закройте лишние программы, отключите фоновую проверку антивируса и запретите машине уход в сон: паук не любит сюрпризов посреди ночного обхода.
Лимиты обхода, которые стоит перепроверить перед стартом на большой площадке
Дефолты рассчитаны на средний сайт и на вежливое отношение к чужому хостингу. Пять потоков по умолчанию дают безопасную скорость, но стотысячный каталог с дефолтными лимитами будет обходиться бесконечно долго. Перед длинным обходом параметры приводят к возможностям площадки: потоки поднимают до десяти-двадцати и следят за долей ошибок 5xx и временем ответа, лимит URL ставят выше ожидаемого числа адресов, лимит перенаправлений держат умеренным, а цепочки редиректов проверяют отдельно, потому что длинная цепочка на большой площадке почти всегда признак устаревших правил в nginx.
Порядок настройки перед запуском длинного обхода выглядит так:
1. переключить хранение в режим базы данных и указать быстрый локальный диск;
2. поднять лимит URL выше ожидаемого числа адресов с запасом процентов на двадцать;
3. выставить число потоков и таймаут ответа под реальные возможности хостинга;
4. закрыть регулярными выражениями параметры сортировки, поиска и служебные шаблоны;
5. прогнать тестовый обход на десять тысяч адресов и убедиться в скорости и полноте выборки.
Тестовый прогон не блажь. Он показывает фактическую скорость на вашем железе и на хостинге клиента, ловит кривые регулярные выражения до старта и даёт цифру, на которой строится план: сколько часов займёт полный проход и когда выгружать промежуточные результаты. Заодно прогон отвечает на вопрос о выдержке сервера: если витрина начинает отдавать ошибки уже на десяти потоках, боевой обход запускают ночью или с меньшей параллельностью.
Срез ссылок и ресурсов, который экономит половину времени обхода
Настройки ссылок во вкладке Links экономят часы. Если цель аудита в контенте и индексации, снимите обход изображений, стилей и скриптов: они попадут в отчёт как ресурсы страниц, но паук не будет тратить запросы на их загрузку. Внешние ссылки оставьте в списке, но отключите следование по ним, иначе пара битых ссылок с форумов утащит паука в чужой сайт. Отрисовка JavaScript по умолчанию выключена, и для первого прохода это правильно: чистый HTML быстрее в разы. Второй проход с отрисовкой делайте по выборке, например по разделу каталога с подгружаемым контентом, и не забывайте, что отрисовка резко поднимает расход памяти.
Уважение к robots.txt на первом прогоне оставьте включённым. Аудитор позже отдельно посмотрит, что магазин закрыл от роботов, но обход должен видеть честную картину. Вот типовой каркас ограничений для большого каталога:
Include: ^(https?://)(www\.)?example\.com/catalog/
Exclude: .*(\?|&)(sort|direction|view)=.*
Exclude: .*/(search|feed|print|compare)/Первая строка держит паука в каталоге, вторая отрезает клоны страниц с параметрами сортировки и вида, третья закрывает служебные шаблоны. На стотысячнике эти три строки сокращают обход на четверть, а иногда и вдвое. Регулярные выражения в настройках работают с полным адресом, поэтому экранируйте точки и помните про вариант параметра после знака амперсанда, а не только после вопросительного знака.
Отдельный прогон имеет смысл сделать на тестовом окружении: там robots.txt не мешает, лимиты можно поднять смелее, а ошибки сервера не бьют по продажам. Сравнение теста и боевой версии потом покажет, что именно различается между средами: набор тегов, заголовки ответов, генерация канонических адресов. Для страниц с тяжёлым интерфейсом настройте захват скриншотов при отрисовке и сравнивайте картинки до и после релиза: таблицы не покажут съехавшую кнопку покупки, а снимок покажет.
Параметры фильтров и другие генераторы дублей, которые раздувают объём обхода
Каждый параметр в адресе магазина умножает стотысячный каталог на собственное число значений. Фильтр цвета, фильтр размера, сортировка, постраничная разбивка: без ограничений паук находит не сто тысяч страниц, а четыреста. До старта собирают полный список GET-параметров из логов, из прошлых обходов и из Search Console, делят его на мусор и полезные комбинации и закладывают мусор в Exclude. Полезные комбинации с реальным поисковым спросом в обход оставляют.
Дубли после обхода ищут во встроенных отчётах. Вкладка Content показывает точные и почти точные копии страниц, отчёты по метатегам собирают повторяющиеся заголовки и описания, отдельная вкладка выводит цепочки канонических адресов, где часто всплывают конфликты: страница ссылается каноником на закрытый раздел, а закрытый раздел в свою очередь ссылается на первую страницу каталога. Для большого аудита сразу настройте Custom Extraction: вытяните цены, остатки и артикулы через CSS-селекторы, чтобы после обхода работать с готовой таблицей, а не открывать страницы руками. На ста тысячах строк ручная проверка не вариант, а выборка по маске URL экономит вечер. Отдельно проверьте вкладку с каноническими адресами после первого прогона: на больших магазинах классическая проблема это опечатки в параметрах, когда открытая страница объявляет главной адрес с другим написанием фильтра. Такие вещи всплывают только на объёме, и вычищать их лучше до полного аудита.
Сегментация аудита, расписание обходов и сравнение повторных прогонов
Стотысячник целиком обходят один-два раза в год, а между полными аудитами работают сегментами. Сохранённые конфигурации позволяют держать отдельный профиль для каталога одежды, для блога, для служебных поддоменов и для мобильной версии. Каждый сегмент обходят по своему расписанию: каталог раз в неделю, блог раз в месяц, полная площадка раз в квартал. Встроенный планировщик запускает обход в назначенное время и автоматически выгружает результаты в папку, поэтому понедельничный отчёт по ценам и ошибкам появляется без участия человека.
Второй инструмент зрелого процесса - сравнение двух обходов. После правок конфигурации свежий проход сверяют с прошлым и смотрят, что появилось, что исчезло и как изменилось число ошибок. Для стотысячника это единственный способ вовремя заметить, что новый блок фильтров снова генерирует дубли. Отдельно полезен модуль анализа логов: он показывает, какие адреса робот запрашивает на самом деле, и часто выясняется, что из найденных ста тысяч страниц поисковик регулярно трогает только сорок.
Выгрузки на сто тысяч строк готовьте заранее. Excel переваривает такой объём, но открывается дольше, чем закипает чайник, поэтому для команды сразу собирайте сводку: десяток главных ошибок, число затронутых страниц, медиана времени ответа по разделам. Клиенту нужен список из десяти задач, а не таблица на двести мегабайт, из которой он сам должен добыть суть.
Контроль качества обхода и типичные ошибки конфигурации на больших проектах
Финальная проверка сводится к нескольким цифрам. Сверьте число обойдённых адресов с ожидаемым из базы клиента: расхождение больше пяти процентов означает, что либо конфигурация режет лишнее, либо в каталоге завёлся скрытый генератор страниц. Посмотрите распределение кодов ответа, медиану и худшие значения времени ответа, долю страниц с каноническим адресом на себя, конфликты каноников и noindex. Список адресов из карты сайта загрузите через List Mode и прогоните отдельно: так проверяется, что карта соответствует реальности и не тащит за собой перенаправления и страницы с ошибками.
Следующий уровень проверки это сопоставление с индексом. Откройте в Search Console отчёт по индексации страниц и сравните причины исключения с тем, что показал обход: дубли без канонического адреса часто оказываются теми самыми фильтрами, а мягкие ошибки это скрытые пустые разделы. Кросс-проверка обхода и индекса закрывает вопросы, которые не решает ни один отчёт краулера по отдельности.
Типичные ошибки повторяются от проекта к проекту. Запуск с дефолтными пятью потоками в разгар рабочего дня подвешивает витрину, и техническая поддержка магазина превращается в оппонента SEO-отдела. Забытые Exclude-правила умножают обход на четыре и растягивают вечерний прогон на неделю: типичная картина, когда каталог из девяноста пяти тысяч адресов без правил по параметрам разрастается до трёхсот тысяч. Отрисовка JavaScript на всей площадке без нужды превращает аудит в марафон. База на сетевом диске замедляет запись так, что паук не добирается до глубины каталога за ночь. Отсутствие лимита URL оставляет обход без предохранителя, и зацикленный параметр месяцами крутится в фоне. На больших проектах выигрывает не тот, кто обходил быстрее всех, а тот, кто обошёл один раз и с правильной конфигурацией.