Всем привет! Меня зовут Алексей Малафеев, я Senior SEO‑специалист, ex‑Детский мир. Также работал в качестве лида в компании KazanExpress (нынешний Магнит Маркет).
В этой статье хочу показать несколько прикладных кейсов того, как можно упростить и автоматизировать рабочие процессы в SEO крупного e‑commerce проекта: от мониторинга технического состояния сайта и анализа трафика до работы с большими объёмами данных и сезонностью категорий.
По опыту могу сказать, что на разных проектах встречаются как похожие и повторяющиеся задачи, так и абсолютно специфические, которые возникают из‑за особенностей конкретного бизнеса, архитектуры сайта или внутренних процессов. Но чем крупнее проект, тем чаще возникает одна и та же проблема — данных становится слишком много для ручной работы.
Крупный e‑commerce — это сотни тысяч и миллионы страниц, большое количество запросов, URL, технических параметров и регулярных изменений. В какой‑то момент стандартных инструментов просто перестаёт хватать.
В моём случае отправной точкой стал довольно простой момент: необходимая мне выгрузка всех проиндексированных страниц сайта перестала помещаться на одном листе Excel. А это, напомню, 1 048 576 строк.
Поначалу для решения подобных задач мне хватало Power Query. Но со временем задачи становились сложнее: требовалось обрабатывать всё большие объёмы данных, сохранять историю, регулярно запускать проверки, сопоставлять между собой разные источники и автоматически получать результаты.
Так я постепенно пришёл к Python, базам данных SQL, API, построению дашбордов в Yandex DataLens и Power BI. А сегодня к этому набору инструментов добавляются и ИИ‑инструменты, которые позволяют ещё быстрее решать отдельные задачи.
В статье покажу несколько примеров того, что из этого получилось.
Сортировка URL по типу страниц
Одним из первых Python‑скриптов, который я написал, был скрипт для сортировки списка URL по типам страниц на основе структуры URL.
В чем была необходимость? Чем крупнее интернет‑ресурс, тем больше и разнообразнее типов страниц он может содержать. Вероятнее всего, ресурс не будет ограничиваться лишь листингами и товарами. Листинги могут делиться на страницы категорий, фильтров, брендов и так далее. Важно уметь быстро сортировать такие страницы и понимать, с каким типом страниц мы имеем дело.
К примеру:
site.ru/example_{pagetype_1}/
site.ru/product/{pagetype_2}
site.ru/category/{pagetype_3}
site.ru/category/example_{pagetype_4}/
Если проблема носит массовый характер, важно в первую очередь определить, с каким типом страниц она связана. Это позволяет при минимуме усилий найти и погасить источник «очага».
Объясню на примере. Разбираем технические проблемы, которые подсвечены в Google Search Console в разделе Pages. Как мы знаем, из интерфейса нельзя выгрузить полный список страниц — есть ограничение на количество строк в выгрузке. Но даже несколько сотен или тысяч URL могут дать нам понимание того, какой тип страниц содержит наибольшее количество невынужденных технических ошибок: редиректы, 404, проблемы с canonical и так далее
Скрипт показывает:
типы страниц;
количество страниц;
процентное соотношение от общего числа страниц, которые мы отдали на вход.
На основе полученных данных уже можно расставлять приоритеты: в первую очередь разбираться с тем типом страниц, который формирует наибольшую долю проблем.
Да, со списками в несколько сотен или тысяч строк сейчас вполне легко справятся ИИ‑инструменты. Достаточно достаточно точно описать паттерн и дать исходные данные. Более того, современные ИИ‑агенты уже способны самостоятельно написать подобный скрипт или обработать готовый файл.
Но здесь есть важный нюанс. Когда речь идет о регулярной работе с миллионами URL, автоматизация нужна уже не для того, чтобы один раз обработать файл. Нам нужно воспроизводимо выполнять одну и ту же операцию, сохранять результаты, сравнивать их между собой и встраивать этот процесс в общую систему мониторинга.
И в этом случае небольшой Python‑скрипт до сих пор остается гораздо более удобным инструментом, чем ручная работа с ИИ.
Дашборд трафика разных типов страниц
В стандартных отчётах Яндекс Метрики не всегда удобно получить единую картину динамики трафика по всем необходимым типам страниц. Почему стоит обратить на это внимание? Потому что релиз одной конкретной задачи может сказаться на разных типах страниц одновременно и с диаметрально разными результатами. Один тип страниц может демонстрировать прирост трафика в то время, как другой тип страниц будет показывать просадку.
Чтобы иметь полное представление об изменениях, приходится применять дополнительный инструментарий. Поэтому для более детального анализа можно вынести данные за пределы интерфейса Метрики: через API получить статистику, классифицировать URL по типам страниц с помощью регулярных выражений и сохранить результат в собственной структуре данных. После этого можно построить дашборд в DataLens, Power BI или любом другом удобном BI‑инструменте.
На этом этапе уже появляется возможность смотреть не только на общую динамику органического трафика, но и разбирать её на составляющие. Например, увидеть, что после определённого релиза общий трафик практически не изменился, хотя внутри него произошли заметные изменения: один тип страниц вырос, другой просел.
Если вы следите за хронологией релизов (а на крупных проектах без этого никак не обойтись), то вскоре у вас будут отправные данные для анализа того, как те или иные изменения отразились на трафике разных типов страниц. Иногда резкие колебания происходят именно там, где их совсем не ожидаешь.
При этом сам дашборд — скорее инструмент для поиска точки, на которую стоит обратить внимание. Дальше уже необходимо разбираться, что именно произошло: был ли это результат конкретного релиза, изменение поискового спроса, сезонность, действия конкурентов или какие‑то технические проблемы.
Мониторинг изменений в sitemap.xml
В крупном проекте важно мониторить не только наиболее важные и трафиковые страницы, но и в целом иметь возможность отслеживать состояние большого количества страниц. А также фиксировать тот момент, когда что‑то вдруг изменилось.
Закончился ассортимент не на самой популярной странице фильтра — легко. Ушёл бренд (продавец) с вашего маркетплейса — запросто. Страница в какой‑то момент в meta robots вдруг стала отдавать noindex — и такое проходили. Причин может быть уйма. Вовремя распознать проблему и предотвратить в дальнейшем подобное поведение — бесценно.
Именно поэтому особое внимание я уделяю тому, как функционирует и что входит в sitemap.xml. Карту сайта я использую как один из источников информации о том, какие страницы на сегодняшний день присутствуют на сайте и, по задумке проекта, должны быть доступны для сканирования и потенциальной индексации.
Внезапное исчезновение большого количества страниц из sitemap.xml без очевидных на то причин — довольно тревожный звонок. Поэтому я использую скрипт, который ежедневно парсит sitemap.xml и записывает полученные данные в базу. Каждая таблица соответствует отдельному типу страниц. URL выступает в качестве primary key, а помимо него мы сохраняем дату первого и последнего появления страницы в sitemap.xml.
Таким образом, со временем формируется история изменений. Можно определить, в какой момент конкретные страницы или целые группы страниц перестали попадать в sitemap.xml, а затем уже сопоставить это изменение с другими данными и найти причину.
Например, если одновременно исчезли тысячи товарных страниц, в тот же день изменился шаблон генерации sitemap и после этого в Google Search Console начала расти доля исключенных страниц, это уже совсем другая ситуация, чем исчезновение нескольких URL, на которых действительно закончился товар.
Автотесты
На крупных проектах, конечно же, есть свой отдел тестирования и свой пул автотестов, составленных на основе технических заданий SEO‑отдела. Но по мере роста проекта увеличивается количество объектов и частота необходимых проверок. Поэтому порой проще своими силами внедрить небольшой набор специализированных проверок на Python, чем каждый раз ставить отдельную задачу на разработку и встраивание новых тестов в существующую систему.
На сайте, где сотни тысяч или даже миллионы страниц, нет необходимости проверять каждую. Это будет слишком ресурсозатратный процесс и далеко не всегда даст дополнительную пользу. Достаточно выделить несколько репрезентативных страниц из каждого типа и впоследствии регулярно проверять именно их.
Заголовки, ссылки, наличие текста, плитка товаров — слететь может что угодно. Поэтому важно отслеживать наличие на странице ключевых элементов, которые влияют на on‑page SEO и перелинковку со стороны фронтенда.
При этом набор тестовых страниц не обязательно должен быть статичным. Если структура сайта меняется, появляются новые типы страниц или меняется шаблон существующих, набор URL для проверок тоже необходимо пересматривать. Иначе со временем можно получить автотесты, которые исправно проверяют уже не самую актуальную версию сайта.
Для сайтов на SSR также немаловажно тестировать страницы с разными User‑Agent. Может быть такое, что поисковые роботы получают либо слишком урезанную версию страницы, либо, наоборот, слишком много ненужного контента. Поэтому полезно контролировать не только то, что видит обычный пользователь, но и то, какую версию страницы получают Googlebot и YandexBot.
Для удобства мониторинга я использую уведомления в мессенджер, куда на постоянной основе приходят сообщения о состоянии тех или иных страниц и параметров.
В результате получается довольно простая схема: выбираем репрезентативные URL → регулярно проверяем ключевые элементы → сравниваем результаты с предыдущими запусками → при отклонениях отправляем уведомление.
Запуск скрипта можно настроить как локально, так и на сервере с помощью cron.
Сезонность категорий
В любом проекте SEO‑задачи должны помогать бизнесу добиваться своих целей. Поэтому помимо своих непосредственных обязанностей полезно контактировать и делиться данными со смежными отделами.
На маркетплейсе разные категории имеют разную специфику и, соответственно, разную сезонность. Для одних товаров пик спроса приходится на Новый год, для других — на начало учебного года, дачный сезон или определённые погодные условия.
Если коммуникация с коммерческим отделом налажена, такая информация может быть полезна не только SEO‑команде. Например, понимание того, когда начинает расти спрос на конкретную категорию, может помочь заранее подготовить ассортимент, запланировать закупки и обратить внимание на наличие товаров.
Для этого я использую следующий подход:
В рамках каждой вертикали собираем сопоставимый шаблон семантики с коммерческими запросами вроде «купить», «цена» и так далее
Собираем исторические данные по частотности запросов за максимально доступный период.
Нормализуем данные и сравниваем динамику между категориями.
Строим дашборд с учётом структуры каталога, чтобы сезонность было удобно анализировать не только по отдельным запросам, но и на уровне категорий и вертикалей.
Регулярно обновляем данные, чтобы постепенно накапливать собственную историю и видеть изменения спроса из года в год.
Заключение
В этой статье я привёл несколько примеров того, как с помощью небольших инструментов можно решать вполне конкретные задачи технического SEO: классифицировать URL, отслеживать изменения в sitemap.xml, контролировать состояние страниц, анализировать трафик по типам страниц и работать с сезонностью категорий.
При этом сами инструменты здесь не являются самоцелью. У каждого проекта свои особенности, ограничения и болевые точки. Где‑то достаточно обычного SQL‑запроса, где‑то имеет смысл написать небольшой Python‑скрипт, а где‑то уже понадобится полноценный дашборд в Power BI или Yandex DataLens.
Поэтому я стараюсь смотреть на задачу немного шире: искать повторяющиеся процессы, находить точки, которые можно автоматизировать, и не бояться самостоятельно собирать инструменты под конкретную проблему.
Не обязательно каждый раз изобретать сложную систему. Иногда несколько строк SQL или небольшой Python‑скрипт могут сэкономить часы ручной работы и, что гораздо важнее, позволить регулярно контролировать то, что раньше проверялось только время от времени.
Именно такой подход я стараюсь применять в своей работе: сначала найти проблему, затем понять, какие данные для её решения нужны, и уже после этого выбрать подходящий инструмент.
P. S. В качестве бонуса прикрепляю ссылку на GitHub, где публикую свои SEO‑скрипты: мониторинг мета‑тега robots, отслеживание изменений robots.txt, парсер sitemap.xml и другие инструменты, которые использую или дорабатываю в работе.
