Коротко
- Автоматизируйте сбор и сравнение. Решение о причине и исправлении остается за специалистом.
- Без базовой линии по каждому шаблону мониторинг шумит, потому что ему не с чем сравнивать.
- Search Console показывает последнюю проиндексированную версию страницы, а живую проверяет только live test в инспекции URL.
- Если noindex стоит в исходном HTML, Google может не запускать JavaScript, и снять тег скриптом не получится.
- Полевые данные CrUX считаются скользящим окном за 28 дней, поэтому эффект правки скорости виден не на следующий день.
- Каждое предупреждение должно содержать URL-примеры, шаблон, время появления и способ воспроизвести.
Что автоматизировать, а что нет
Разовый аудит отвечает на вопрос, что сломано сейчас. Мониторинг отвечает на другой вопрос, что изменилось с прошлого раза и после какого релиза. На сайте, где релизы выходят каждую неделю, разовый аудит устаревает быстрее, чем его успевают внедрить.
Автоматизация хорошо справляется с повторяемыми действиями. Обход выборки URL, снятие статусов и тегов, сравнение со вчерашним снимком, выгрузка отчетов Search Console по API, разбор логов сервера. Плохо она справляется с вопросом "почему". Скрипт видит, что на 4000 карточек пропал canonical. Что его убрал релиз фильтров, а не CDN, подтверждает человек по истории изменений.
Если аудита еще не было, начните с него. Что в нем проверяется и какой отчет на выходе, описано в нашей статье про SEO-аудит сайта. Базовую линию для мониторинга берут как раз из аудита.
Еще одно ограничение касается инструментов. Готовые сервисы мониторинга хорошо ловят типовые ошибки, битые ссылки, пропавшие теги, коды ответа. Логику вашего сайта они не знают. Что карточка без цены должна отдавать 200 и оставаться в индексе, а архивная акция должна уходить в 404, сервису придется объяснить правилами. Правила пишет специалист, который знает сайт и то, как он зарабатывает. Без них сервис засыпает команду предупреждениями о вещах, которые так и задуманы.
Базовая линия
Базовая линия фиксирует, каким должен быть каждый тип страниц. Без нее любое отклонение приходится разбирать вручную.
Словарь шаблонов
Разметьте сайт на типы страниц по паттернам URL. Главная, категория, фильтр, карточка, статья, страница услуги, служебные. Для каждого типа задайте ценность для бизнеса, чтобы потом сортировать предупреждения.
Эталонные значения
Для каждого шаблона запишите ожидаемые значения и возьмите контрольную выборку URL, от десятков до сотен на шаблон, в зависимости от размера сайта.
Снимок базовой линии хранится вместе с датой и номером релиза. Когда шаблон меняют намеренно, базовую линию обновляют отдельным решением, а не молча.
Обход и индексируемость
Здесь работают три источника, и ни один не дает полной картины. Краулер видит структуру и теги, но не знает, что из этого Google обошел. Search Console показывает решения Google, но с задержкой и выборкой. Логи сервера показывают реальные запросы робота, но ничего не говорят о содержании страниц.
Что брать из Search Console
Инспекция URL показывает статус индексации, canonical, заявленный сайтом, и canonical, выбранный Google. Эти два значения могут расходиться, и расхождение на выборке карточек говорит о дублях. При автоматизации чаще всего ошибаются на одном ограничении. Без live test инструмент показывает последнюю проиндексированную версию, а не текущую. На запросы инспекции и live test действуют дневные лимиты на ресурс, поэтому проверять по API можно выборку, а не весь каталог.
Отчет "Статистика сканирования" показывает число запросов робота, объем загрузки, среднее время ответа, разбивку по кодам ответа, типам файлов и целям обхода. Рост доли ответов 5xx или времени ответа заметен там раньше, чем в позициях.
Что проверять скриптом
- Ответы sitemap. Google ограничивает один файл 50 000 URL или 50 МБ без сжатия и учитывает lastmod, только если он стабильно совпадает с реальным изменением страницы.
- Параметры фильтров и сортировки в обходе. Если их доля растет, проверьте robots.txt и ссылки на фильтры.
- Canonical и noindex. Google не советует выбирать canonical через noindex или robots.txt, закрытые в robots.txt URL могут попасть в индекс без содержимого.
- Цепочки редиректов и внутренние ссылки на URL с редиректом.
Что брать из логов сервера
Логи отвечают на вопрос, по каким URL робот реально ходит. Отфильтруйте запросы Googlebot, проверьте, что это настоящий робот, а не подделка под его user-agent, и разложите запросы по шаблонам из словаря.
Полезных срезов немного. Доля запросов к каждому шаблону по неделям, доля URL с параметрами, коды ответа, которые получил робот, и время от публикации новой карточки до первого визита робота. Последний срез хорошо показывает, доходит ли обход до свежих страниц. Если он растет от недели к неделе, ищите причину в ссылках на новые товары и в обходе мусорных URL.
Если страница пропала из индекса, разбирайте ее по шагам из статьи о том, почему Google не индексирует сайт.
Шаблоны и JavaScript
Google обрабатывает JavaScript-сайты в три этапа, обход, рендеринг и индексация. Для мониторинга это значит, что нужно снимать два состояния страницы, исходный HTML с сервера и HTML после выполнения скриптов.
Что сравнивать
Сравнивайте title, canonical, meta robots, основной текст, ссылки и разметку в обоих вариантах. Если canonical есть только после рендеринга, а в исходном HTML его нет или он другой, это кандидат в регрессию.
Отдельный случай с noindex. Google пишет, что при noindex в исходном HTML он может пропустить рендеринг и выполнение JavaScript. Значит, схема "ставим noindex на сервере, снимаем скриптом" не работает. Такую проверку стоит включить в автоматический тест каждого релиза.
Как подтверждать
Отрендеренный HTML глазами Google показывает live test в инспекции URL и проверка расширенных результатов. Свой рендер в headless-браузере полезен для массовой проверки, но вывод о проблеме подтверждайте инструментом Google на нескольких URL.
Мониторинг изменений
Контур мониторинга устроен как цикл. Каждый шаг оставляет артефакт, по которому можно воспроизвести вывод.
- Снимок. По расписанию и после каждого релиза краулер обходит контрольную выборку по шаблонам и сохраняет статусы, теги, исходный и отрендеренный HTML.
- Сравнение. Скрипт сравнивает снимок с базовой линией и с прошлым снимком, на выходе diff по полям.
- Внешние данные. Подтягиваются отчеты Search Console, статистика сканирования, логи сервера и полевые данные скорости.
- Предупреждение. Если отклонение выше порога для шаблона, создается сообщение с URL-примерами, временем появления и связанным релизом.
- Проверка. Специалист воспроизводит проблему на примерах и подтверждает или отклоняет причину.
- Задача. Подтвержденная регрессия уходит в бэклог разработки с шагами воспроизведения.
- Приемка. После исправления проверяется тот же набор URL, базовая линия обновляется, если это нужно.
Таблица сигнал, проверка, действие
Пороги и шум
Порог задается для шаблона, а не для сайта. Пропавший title на трех служебных страницах и на трех процентах карточек весят по-разному. Первое время после запуска пороги приходится подстраивать, пока предупреждения не перестанут приходить по ложным поводам.
Приоритизация
Проблем всегда больше, чем часов разработки. Очередь задают масштаб, ценность шаблона, обратимость ущерба и цена исправления.
Масштаб считают в URL и в доле трафика шаблона. Ценность берется из словаря шаблонов. Обратимость означает, насколько быстро все вернется после исправления. Случайный noindex на категориях исправить просто, но восстановление в индексе займет время, поэтому такой случай идет первым. Тысяча страниц тегов без описания подождет. Дешевую правку конфигурации иногда выгодно сделать вне очереди, даже если ущерб небольшой.
Для разбора удобно свести все в одну таблицу и выставить баллы. Шкала у каждой команды своя, важно, чтобы она была записана и одинаково применялась.
Сумма баллов задает очередь в бэклоге. Спорные случаи с одинаковой суммой решает тот, кто отвечает за органический трафик.
Комментарий Q2 AgencyМониторинг у клиентов часто уже есть, только у него нет владельца. Отчеты падают в общий канал, и через месяц их никто не открывает. Поэтому до настройки скриптов мы договариваемся, кто в команде клиента получает предупреждения, кто принимает решение об откате и сколько времени на это есть.
Приемка и откат
Исправление считается принятым, когда тот же набор URL, на котором нашли проблему, проходит ту же проверку. Отчет "все исправлено" без повторного снимка не принимайте.
Порядок приемки
- Повторный снимок контрольной выборки после релиза с исправлением.
- Diff с базовой линией по затронутым полям.
- Live test в инспекции URL на нескольких примерах.
- Для индексации и скорости отдельная проверка через несколько недель, когда обновятся отчеты и полевые данные.
Когда откатывать
Откат дешевле исправления, когда релиз сломал сигнал на шаблоне с высокой ценностью, а быстрого решения нет. Договоритесь с разработкой заранее, какие поля считаются блокирующими. Обычно это статус, robots, canonical и hreflang на коммерческих шаблонах. Если такое поле сломано, релиз откатывают без обсуждения.
Отдельно стоит контролировать скорость. Как читать полевые и лабораторные данные и где помогают нейросети, мы разобрали в статье про ИИ и Core Web Vitals. Если хотите получить аудит с базовой линией и настроенным мониторингом, закажите технический SEO-аудит, техническое SEO мы ведем и после него.
Частые вопросы
Источники
Основатель Q2 Agency, бывший директор по маркетингу: работал в Яндексе, Xsolla, Cheelee и Allen Carr’s Easyway. Специализация - нейромаркетинг, воронки продаж и сквозная аналитика.
