Сканируем большие сайты через Screaming Frog SEO Spider
Привет! Последнее время всё чаще начал сталкиваться со сканирование больших сайтов (от 1 млн страниц), а также встретился со множеством заблуждений от людей, которые этим никогда не занимались. Этот пост не про то, зачем вам парсить сайт, вы наверняка знаете, а про то, как не бояться этого делать и правильно всё настроить.
Главные заблуждения:
- Лягушка регулярно падает;
- Сканировать можно до 500 тысяч;
- Это крайне долго;
Более того, полезной и практической информации о сканировании больших сайтов именно этим софтом в интернете просто нет, есть инструкция от разработчиков, где демонстрируется работа с 8 млн страницами и на этом всё.
Своим опытом я делюсь у себя на канале, но поскольку в рамках сообщения в телеге сложно раскрыть отдельные нюансы, не перегружая его, решил оформить в виде поста-мануала здесь, поехали.
Задача - просканировать сайт с Х миллионами страниц и не попасть на передачу "Сдохни или умри". Конечно, можно оплатить тариф у JetOctopus, но проводя аналитику не только своих сайтов, но и конкурентов, разорение неминуемо.
Конфигурация сервера
Чтобы парсинг не мешал основной работе я использую сервер, собранный из китайских запчастей. Моя конфигурация не самая удачная (много жрёт электричества, сильно греется), но с задачей краулинга справляется отлично - два 8 ядерных процессора E5-2689, 1080 (другой не было), 48 GB RAM (REG ECC), ну и Windows Server на борту, поскольку бесплатная на полгода и не перегружена всякой шелухой от майкрософта. Нужен ли такой монстр? Разумеется нет, для объективности, установил в BIOS 2 ядра по 3.5 ггц и запустил те же самые настройки. Скорость парсинга не упала, но загрузка процессоров была 80-90%. Краулить реально без выполнения других задач.
Настройки программы
Теперь к основному, настройки программы. Первое и самое главное:
Configuration - Systeam - Storage Mode - Устанавливаем DataBase.
Теперь парсинг идёт не в оперативную память, а на диск. Диск крайне желательно должен быть SSD. Основной плюс в том, что все результаты просто дозаписываются в базу и если произойдет краш, ничего не потеряется (забегая наперёд, после переключения в этот режим падений ни разу не было).
Вторым шагом зададим размер оперативной памяти (Configuration - Systeam - Memory Allocation). Разработчики рекомендуют от 4 гб для парсинга 2 млн страниц и 8 гб для 5 и более. У меня стоит 24, потому что могу. На самом деле, выставлять 16-32-48 гб памяти здесь нет необходимости, она нужна только для работы каждого из потоков.
Сканирование большого числа страниц = большой размер проекта. Отключаем лишнее. Залетаем в Configuration - Spider. Здесь оставляем парсинг только внутренних ссылок (если планируете искать битые внешние ссылки и прочее, разумеется включаем):
Т.к. часто на сайтах изображения являются ссылками, софтина их продолжает собирать, несмотря на запрет, лезем в Configuration - Exclude и вставляем следующие исключения, они универсальный для любого парсинга:
http.*\.jpg
http.*\.JPG
http.*\.jpeg
http.*\.JPEG
http.*\.png
http.*\.PNG
http.*\.gif
http.*\.pdf
http.*\.PDF
Отлично, теперь изображения точно не будут собираться.
Напоследок, Configuration - Speed. Здесь всё крайне индивидуально и зависит от:
- Возможностей сервера с которого идёт парсинг;
- Возможностей сервера который парсим;
- От интернет канал;
Я ставлю от 7 до 10 потоков (10-30 урлов в секунду), этого хватает для комфортной работы всех сторон.
Подводные
Куда без них. Опытным путем выяснил, что от уровня вложенности страниц сайта, при прочих равных, зависит скорость парсинга и размер базы данных, причем зависит серьезно, об этом ниже.
К цифрам
Всё это было бы бессмысленными теориями, если бы не было обкатано в бою.
Парсинг любого проекта я выполняю в два этапа:
- Первичный, понять очевидно проблемные разделы с мусорными страницами. Собирается 5-10% от будущего объема сайта и на основе данных структуры (Site Structure в сайдбаре) оцениваем что за разделы и для чего они нужны по количеству страниц в них;
- Вторичный, с отключенными проблемными разделами (через Exclude), чтобы найти более мелкие ошибки в рамках всего сайта.
Итак, на последнем проекте изначально было несколько проблемных разделов с 17-ю(!) уровнями вложенности. Размер проекта раздувался в космос, каждый следующий миллион страниц весил дополнительные 100 гб места на диске. Скорость через 1.5 млн страниц упала с 20-30 урлов в секунду до 2-3. Всего урлов в ожидании к тому моменту было 5 млн и это явно не предел.
Вторым этапом, исключив мусорные разделы, запустил парсинг повторно. В итоге, на сайте осталось 2 млн страниц и в 10 потоков (20-30 урлов в секунду, да там хороший сервер) он парсился ровно сутки. Удивился сам, но совпало с теоретическими расчётами: 2 000 000 / 20 (урлов в сек) / 3600 (часов) = 28 часов. При этом размер базы для всего проекта составил порядка 50 гб, что в 4 раза меньше прошлого парсинга для того же количества страниц.
Выводы
Краулинг значительного объёма страниц реален и не так страшен, как о нём думают. Достаточно 4-х ядерной машины с 8-16 гб оперативной памяти и не сильно большого SSD. Сама лягушка такие объемы тянет и не падает.
При любом сканировании после первых 10-15%, оцените структуру сайта и посмотрите, какие разделы могут генерировать много лишних страниц. Исключите их из парсинга и перезапускайте сканирование уже до финала. Успехов!
Тема полезная, но мало, душа больше требует.
Я всё это использую, но парсинг интернет-магазина среднего объёма всё равно занимает от суток. Ключ, конечно, в рендере HTML и во включенных правилах для UA, но никакие серверные ресурсы ускорить процессы мне не позволяют.
А парсить надо, и не по разу, с эмуляцией хотя бы основных поисковых ботов, иначе можно прохлопать пачку важных ошибок.
А сейчас вот с появлением рендера JS и вовсе боюсь экспериментировать. А надо.
Про исключение проблемных страниц и разделов не понял. Зачем? Если это именно те места, где боты ломают ноги и шеи - нужно как минимум понять, в чём там трабл.
Очень помогает команда \? в Exclude, которая отсекает страницы с параметрами.
Также помогает просканировать 10%, выявить то, что можно добавить в Exclude, а потом выключить парсер и перенастроить с отсечением выявленного мусора+пагинацию тоже выключить исключением (если настройка и \? не помогли, может генерироваться иначе).
+ перечисленное в статье.
Сутки - вполне неплохое достижение.
Каждый случай индивидуален, поэтому общие рекомендации, которые подойдут для любого проекта
Я всё это использую, но парсинг интернет-магазина среднего объёма всё равно занимает от суток.Сколько страниц на сайте? Какая цель регулярного парсинга?
Про исключение проблемных страниц и разделов не понял. Зачем?Тут речь вот про что, начиная парсинг нового проекта еще не знаешь его структуры, велика вероятность наличия проблемных разделов. Под проблемными я понимаю страницы, которые не должны быть в индексе и в структуре, но они там есть по разным причинам. К проблемным легко можно отнести ссылки с параметрами, распространенная ситуация с календарем записей, где краулер до бесконечности может перебирать даты и так далее. Понятно, что тратить ресурсы на перебор такого типа страниц нет смысла, понятна маска урла и как это исправить, поэтому при повторном парсинге, такие разделы исключаю и уже ищу действительно неочевидный мусор.
Речь не о регулярном парсинге в основном. Заходит сайт на аудит или продвижение - надо понимать, с чем придётся иметь дело. Ну и вот тут вскрывается: кольцевые редиректы, мёртвые каноникалы, практически полные дубли по контенту на разных страницах, отсутствие доступа ботов к чему-то важному и т.п.
Раньше можно было понять о чём идёт речь буквально за полчаса. А сейчас - чем дальше в лес, тем толще партизаны.
Берем зену, катаем шаблон, зацикливаем его на повторы и в 5 потоков юзаем демку бесконечно...
А тем, кто наверняка в 1-й раз об этом слышит (хотя и имеет представление о SEO), объясните, зачем?
Парсинг сайта для последующего анализа позволяет провести почти полный технический аудит: обнаружить дубли, проблемы сервера, битые ссылки, пустые страницы, проверить возможность доступа поисковых ботов к каким-то страницам и разделам и т.п.
Классический пример: у вас целый раздел с товарами не ранжируется и не сканируется. В панелях вебмастеров об этом практически никакой полезной информации нету. Смотрим скан - и видим кольцевое перенаправление. То есть робот фактически не может дойти до целевой страницы.
Ну или у вас полсайта отдаёт 404 из-за битых внутренних ссылок, и роботу просто не хватает ресурсов, чтобы ходить не по битым ссылкам, а по реальным и важным для вас.
На мой взгляд существует множество сервисов проверки сайтов. Они с таким не справляются?
JetOctopus, упомянутый автором - справляется. Но это чуть дороже, чем комфортно лично для меня и повседневной работы. Возможно, ещё есть аналоги, но мне не попадались.
Другие сервисы автоматической проверки - практически, все - на такое не способны.
Задач у парсинга много, начиная от поиска ссылок и их местонахождения на 301, 404 страницы, страниц с дублями метатегов (тайтлы, дескрипшены) и анализом структуры сайта, заканчивая выгрузкой URL страниц для сравнения с анализом логов сервера, опять же с целью найти, например:
- страницы, которые есть на сайте, но на которые не заходят боты;
- страницы, на которые заходят боты, но нет в структуре (нет ссылок на них с сайта);
- страницы, которые есть в индексе, но на которые нет ссылок и на которые не заходят боты
Вариантов множество, но инструмент маст хев, особенно для больших ресурсов.
Спасибо за статью, очень полезно! Было бы интересно почитать мануал об анализе логов сервера, о поиске страниц, на которые заходят и не заходят боты (как определить ботов).
Обязательно будет
А site analyzer бесплатный не пробовали для парсинга?
Кстати, да.
А как он справляется с 1млн+ страниц?
Нормально справляется, недавно парсил 5 млн, под это дело арендовал мощный сервер.
Сталкивался, но честно не тестировал для больших объемов, дружу с лягушкой, минута гугления и она тоже становится бесплатной.
Очень годная статья, спасибо
Благодарю, продолжение следует
Статья полезная. Спасибо!
Может кто сможет подсказать как просканировать сайт с мультирегиональностью
Например: https://lovely-mebel.ru/
Или например как просканировать только основной адрес без поддоменов?
Привет, пользуйся директивой Configuration - Include.
Для примера основной домен можно просканировать так:
https://lovely-mebel.ru/.*
В данном случае точка означает любой символ после адреса сайта, * - любое количество
После работы попробую, спасибо
При редкой надобности хочется эту процедуру делегировать. Насколько это хорошая идея?
Если надобность действительно редкая, тогда может стоит спарсить самостоятельно? Именно для таких людей и писалась статья, кто хочет с первого раза правильно настроить, спарсить и работать с полученными данными. В любом случае, уверен найдётся фрилансер, который возьмется за эту задачу, если не найдете - напишите мне, сейчас сервер простаивает, смогу просканировать проект
Напишу в ЛС.
Спасибо! Хотелось бы также увидеть обзор SiteAnalyzer - https://site-analyzer.ru/ - вполне достойный бесплатный аналог Screaming Frog