Технический SEO-аудит сайта: этапы, инструменты и отчёт, который берут в работу

Что такое технический SEO-аудит и зачем нужен воспроизводимый процесс

Технический SEO-аудит это повторяемая последовательность этапов, которая отвечает на три вопроса: как поисковые роботы обходят сайт, какие страницы попадают в индекс и что мешает этим страницам получать показы. На выходе получается набор задач с приоритетами, оценкой трудозатрат и критериями приёмки. Список из 300 красных строк в краулере задачей ещё не является.

Процесс состоит из пяти шагов: подготовка и сбор вводных, сканирование, разбор данных панелей вебмастера и аналитики, приоритизация находок, оформление отчёта. Шестой шаг, который теряют чаще всего, это контроль исправлений и повторная проверка. Без него аудит превращается в разовую консультацию с непредсказуемым результатом.

Аудит не заменяет SEO-стратегию. Он даёт фактуру для решений: где теряется обход, на каких участках рвутся цепочки индексации, какие разделы технически готовы к продвижению, а какие сначала нужно чинить. Проведение аудита само по себе не двигает позиции, рост появляется после исправлений, и то не всегда линейно.

Чем аудит отличается от разовой проверки

Разовая проверка отвечает на вопрос «что сломано сейчас». Аудит отвечает на вопрос «что и в каком порядке менять, чтобы через месяц не искать те же ошибки».

Разовая проверка уместна для нового сайта, после переезда или крупного релиза, когда нужно быстро понять масштаб проблем. Процесс нужен там, где сайт меняется постоянно. Интернет-магазин с ежедневными обновлениями каталога и десятками новых комбинаций фильтров обесценивает любой вывод из проверки примерно за неделю: то, что вчера было корректно закрыто от индексации, сегодня снова открыто новым шаблоном.

Если нужен минимальный стартовый набор проверок без полного процесса, его разбирает пошаговая инструкция по самостоятельному SEO-аудиту: она полезна как вход в тему и как основа для первых задач, но не заменяет приоритизацию под конкретный проект.

Какие задачи решает технический аудит

Находки удобно раскладывать по эффекту: обход, индексация, видимость. Такая группировка экономит время на этапе приоритизации, потому что каждая группа уже несёт подсказку о критичности.

Важная оговорка: закрытие всех найденных ошибок не гарантирует роста трафика. Часть ошибок вообще не влияет на поиск, часть исправлений даёт эффект только вместе с работой над контентом и структурой. Задача аудита в том, чтобы отделить дорогие по последствиям проблемы от косметики.

Этап 1. Подготовка и сбор вводных

Подготовка определяет скорость всей остальной работы. Когда известно, сколько URL на сайте, какие есть типы страниц и что менялось за последние месяцы, находки сортируются почти механически. Когда специалист сканирует сайт «вслепую», он получает тысячу строк и тратит день на выяснение того, что можно было спросить в начале.

Каждый источник вводных закрывает свой вопрос. Панели вебмастера показывают сайт глазами поисковой системы: что проиндексировано, что исключено, какие ошибки сканирования фиксируются. Аналитика показывает поведение людей: какие страницы приносят трафик и конверсии. Серверные логи показывают реальный обход роботами: какие URL запрашиваются, как часто и с каким кодом ответа. Без логов легко не заметить, что робот тратит краулинговый бюджет на параметрические URL, которые никогда не должны попадать в индекс.

Какие доступы и данные запросить у клиента или команды

• Доступ к Яндекс.Вебмастеру и Google Search Console: подтверждённые права на нужные домены и поддомены.
• Доступ к аналитике (веб-аналитика и, если есть, данные по заказам или лидам): нужен, чтобы приоритизировать находки по трафику и деньгам.
• Серверные логи за период от двух недель до месяца: реальный обход, коды ответов, частота заходов.
• Доступ к CMS или админке: объём страниц, шаблоны, возможность править метатеги.
• Staging-среда или тестовый домен: чтобы предлагать правки без риска для продакшена.
• Список ключевых разделов и приоритетных страниц: категории, карточки, посадочные.
• История изменений: релизы, переезды, смена CMS, массовые редиректы, запуск новых поддоменов.
• Известные проблемы и ранее предпринятые попытки их решить.

Часть данных может быть недоступна: хостинг не отдаёт логи, у клиента нет прав в панели, staging отсутствует. Это не повод останавливать аудит. Повод зафиксировать ограничение в методологии: например, «логи недоступны, оценка обхода построена на отчётах панелей вебмастера». Такая честная пометка защищает и отчёт, и специалиста.

Как зафиксировать границы аудита

Без зафиксированных границ аудит расползается: сначала проверяем основной домен, потом поддомены, потом личный кабинет, потом тестовые среды. Заканчивается это тем, что часть работы не оплачена, а отчёт лежит без движения.

Границы описывают четырьмя параметрами: домены и поддомены, количество URL, типы страниц, исключения. Рабочая формулировка выглядит так: «Аудит охватывает до 50 000 URL основного домена и поддомена блога, включая категории, карточки товаров и статьи; исключены /admin/, личный кабинет, тестовый поддомен и партнёрские лендинги». Цифры здесь условные, они подставляются по факту.

Параллельно стоит зафиксировать глубину проверки. Одно дело, когда нужно найти блокировки обхода и ошибки индексации, другое, когда к этому добавляется анализ Core Web Vitals по всем шаблонам. Разная глубина, разный объём работ, разный срок.

Этап 2. Сканирование сайта и сбор технических данных

Краулер обходит сайт по ссылкам и собирает технические характеристики страниц. Ключевое ограничение нужно держать в голове с самого начала: сканер видит то, что доступно по ссылкам из точки старта, и ведёт себя не так, как поисковый робот. Пропущенные по ссылочной структуре разделы он не найдёт, а частоту обхода в принципе не покажет.

Screaming Frog и другие краулеры: что они дают и где ограничены

Screaming Frog это десктопный краулер, который закрывает базовый технический срез: коды ответов, цепочки редиректов, canonical, meta robots, hreflang, дубли title и description, битые внутренние и внешние ссылки, глубину, объём HTML, наличие микроразметки. Сильные стороны: работает локально, гибко настраивается, умеет сверять сканы между запусками. Слабые: зависит от ссылочной структуры, ограничен в рендеринге JavaScript, бесплатная версия урезана по количеству URL, а частоту и распределение обхода он не видит вовсе.

Ни один краулер не покрывает аудит целиком. Нормальная практика: сканирование плюс логи плюс панели вебмастера, потому что каждый источник видит свой слой реальности.

Логи сервера: как увидеть реальный обход

Логи показывают фактические запросы: какой URL запрошен, когда, с каким user-agent и каким кодом ответа. Именно здесь вылезают расхождения между «как видит пользователь» и «как видит робот». Классический пример: страница отдаёт 200 для браузера и 503 для робота из-за защиты или перегрузки, а краулер видит только успешный ответ.

Что искать в логах: частоту заходов по разделам, долю ответов 4xx и 5xx именно для роботов, распределение обхода между важными и мусорными URL, попытки обхода закрытых в robots.txt адресов, всплески после релизов. Для ручного разбора хватает фильтрации по user-agent и группировки по шаблонам URL.

Ограничения работы с логами: нужен доступ к серверу, объёмы файлов большие, боты подделывают user-agent, а ротация логов может съесть историю. Инструменты вроде Screaming Frog Log File Analyser, GoAccess или собственных скриптов решают задачу быстрее, чем таблицы вручную, но фильтры всё равно придётся настраивать под сайт.

Как не утонуть в данных сканирования

Сырой скан большого сайта легко даёт сотни тысяч строк. Работать с ними напрямую бессмысленно, нужны четыре приёма:

1. Сегментировать по типам страниц: категории, карточки, статьи, пагинация, фильтры, служебные страницы. Ошибка в карточке и ошибка в туристическом разделе блога имеют разный вес.
2. Сравнивать текущий скан с предыдущим: новые проблемы важнее старых, потому что показывают, что сломалось недавно.
3. Отсекать шаблонные ошибки: если проблема повторяется на одинаковых страницах, это один дефект шаблона, а не тысяча задач.
4. Группировать однотипные находки в одну строку отчёта. Десять тысяч страниц пагинации с одинаковым title это одна задача, а не десять тысяч.

Такой фильтр занимает час-два, но сокращает список до десятков пунктов, с которыми реально можно работать.

Этап 3. Данные из панелей вебмастера и аналитики

Панели вебмастера и аналитика не заменяют сканирование, а дополняют его. Краулер отвечает на вопрос «что есть на сайте», панели на вопрос «что с этим сделала поисковая система», аналитика на вопрос «что из этого приносит деньги». Интерфейсы и названия отчётов периодически меняются, поэтому при разборе стоит сверяться с актуальным видом панели, а не с сохранёнными скриншотами годичной давности.

Яндекс.Вебмастер: что смотреть в первую очередь

Для технического аудита значимы несколько блоков: диагностика сайта, разделы про индексирование и страницы в поиске, статистика обхода, файлы Sitemap, проверка безопасности. Что именно искать:

• ошибки сканирования и причины, по которым страницы выпали из индекса;
• страницы в статусе исключённых: важно понять, закрыты ли они robots.txt, отдают ли noindex или просто ещё не обойдены;
• проблемы с sitemap: сколько URL отправлено и сколько принято, расхождение показывает либо битые адреса, либо лишние;
• признаки вредоносных вставок и подозрительных редиректов;
• статистику обхода: какие разделы робот посещает охотнее, а какие игнорирует.

Ограничение: данные запаздывают на несколько дней, а часть отчётов агрегируется с задержкой. Свежий релиз может ещё не отразиться в панели. Подробный разбор причин выпадения страниц из индекса и порядка действий собран в материале про проверку индексации сайта, он помогает не путать техническую блокировку с обычной задержкой обхода.

Google Search Console: отчёты для технического аудита

В Google Search Console для аудита полезны отчёты об индексировании страниц, проверка URL, файлы Sitemap, показатели эффективности и отчёт об опыте страницы с метриками Core Web Vitals. Логика чтения похожа: сначала статус страницы, затем причина, затем проверка каждой из них по цепочке.

Различия с Яндексом существенны. Наборы статусов, формулировки причин исключения и скорость обновления данных не совпадают. Вывод, сделанный по одной панели, нельзя механически переносить на другую поисковую систему: причина «Исключено» в одной панели и причина появления той же страницы в отчёте другой панели могут относиться к разным техническим состояниям страницы в разное время.

Аналитика: как связать технические находки с поведением

Аналитика не показывает технических ошибок, зато расставляет веса. Если проблема найдена на странице, которая собирает заметную долю органического трафика или конверсий, её приоритет сразу выше. Сравните две ситуации: битая ссылка в футере на всех страницах и неверный canonical на странице категории с трафиком. Первая выглядит масштабнее по количеству URL, вторая обычно дороже по последствиям.

Полезно держать под рукой три среза: страницы с органическим трафиком, страницы с конверсиями и точки входа в воронку. Любая техническая находка пересекается с одним из них, и это пересечение задаёт приоритет.

Этап 4. Приоритизация находок по влиянию на обход, индексацию и видимость

Приоритизация строится по двум осям: влияние на обход, индексацию и видимость, а также трудозатраты на исправление. Одна ось без другой бесполезна: критичная, но полугодовая задача не решается сегодня, а лёгкая правка в подвале не изменит ничего.

Критерии оценки влияния на обход и индексацию

• Блокировка обхода. Директива в robots.txt, закрывающая раздел, который должен ранжироваться, отсекает страницы от индекса целиком.
• Коды ответов 4xx и 5xx. Четырёхсотые убивают страницу сразу, пятисотые и таймауты снижают частоту обхода и могут выкинуть URL из индекса.
• Ошибочный canonical. Если страница указывает канонической другую, в индексе остаётся она, а оригинал теряет показы.
• Noindex на страницах с трафиком. Прямая потеря видимости, если директива осталась после тестов или релиза.
• Дубли и параметрические URL. Раздувают индекс и расходуют краулинговый бюджет, то есть время робота на обход сайта.
• Медленный ответ сервера. Замедляет обход и ухудшает пользовательские метрики.
• Конфликты сигналов. Страница закрыта в robots.txt и одновременно отдаёт noindex, а специалист считает, что она просто исключена.

Практическое правило: если ошибка мешает роботу увидеть страницу или заставляет его видеть не ту страницу, приоритет высокий независимо от того, сколько URL она затрагивает.

Как оценить трудозатраты на исправление

Вторая ось показывает, кто и как быстро закроет задачу. Разброс здесь большой, и именно он часто определяет порядок работ.

Дальше работает простая логика: высокое влияние плюс низкие трудозатраты это первый спринт. Высокое влияние плюс высокие трудозатраты это планирование и оценка отдельно. Низкое влияние плюс низкие трудозатраты закрывается попутно, если правка того стоит. Низкое влияние плюс высокие трудозатраты обычно не стоит вообще.

Матрица приоритетов: пример для интернет-магазина

Для интернет-магазина с фасетной навигацией и десятками тысяч URL матрица выглядит примерно так:

Приоритеты зависят от типа сайта и целей. Для магазина с узким ассортиментом фасетные дубли могут оказаться куда менее важными, чем для каталога с сотнями тысяч комбинаций фильтров. Общий порядок разбора технических находок с таблицами для фиксации результатов разобран в чек-листе внутренней оптимизации сайта: он удобен как рабочая форма для четвёртого этапа.

Этап 5. Отчёт: как оформить, чтобы задачи взяли в работу

Отчёт это не список ошибок, а набор задач с контекстом. Каждая задача содержит описание проблемы, примеры URL, влияние на поиск, приоритет, ответственного и критерии приёмки. Если из формулировки нельзя понять, что именно сделать и как проверить результат, задача вернётся с уточняющими вопросами, а часть находок просто потеряется.

Структура отчёта: от резюме до приложений

1. Титульный лист: сайт, период данных, дата отчёта, границы аудита.
2. Резюме для руководства на одну страницу: сколько задач, сколько критических, что это даёт бизнесу. Руководитель обычно читает только этот блок.
3. Методология и ограничения: какие данные использованы, что было недоступно, какие проверки не проводились.
4. Находки по приоритетам с группировкой по темам: обход, индексация, видимость.
5. Задачи для разработчиков и отдельный блок задач для контент-команды.
6. Приложения: выгрузки из краулера, срезы логов, таблицы URL.

Разделение на блоки для разработчиков и контент-команды экономит время обеим сторонам: никто не читает чужие задачи и не спорит о зоне ответственности.

Как формулировать задачи для разработчиков

Шаблон задачи: что не так, пример URL, ожидаемое поведение, критерий приёмки, приоритет. Пример формулировки:

Страница /catalog/ отдаёт код 200, но canonical указывает на /catalog/?page=1. Нужно, чтобы canonical на /catalog/ ссылался на саму /catalog/. Проверка: в исходном коде /catalog/ значение canonical равно https://site.ru/catalog/. Приоритет: высокий.

Формулировки вида «починить canonical» или «поправить редиректы» приводят к переписке на несколько дней. Разработчику нужны конкретные адреса и понятный результат, а не тема для обсуждения.

Как формулировать задачи для контент-команды

Здесь работает тот же принцип, но с акцентом на примеры. Контент-команде нужно видеть, как выглядит правильный результат на одной странице, прежде чем тиражировать его на пятьдесят.

На 50 страницах блога дублируется title. Нужно переписать title с учётом запроса страницы. Пример: /blog/seo-audit/ сейчас имеет title «Блог», нужен title «Технический SEO-аудит: этапы и инструменты». Проверка: title уникален в пределах блога и содержит основной запрос страницы.

Если объём таких правок измеряется сотнями страниц, подготовку черновиков заголовков и метатегов имеет смысл автоматизировать: платформа вроде SerpJet умеет работать с семантикой и тематическими направлениями сайта и собирать черновики материалов, а финальное решение по каждому заголовку остаётся за редактором.

Аудит или разовая проверка: как выбрать и как часто повторять

Разовая проверка подходит для точечных ситуаций: новый сайт перед запуском, переезд, смена CMS, крупный релиз, подозрение на техническую поломку. Регулярный аудит нужен там, где сайт живёт: контент публикуется, шаблоны меняются, каталог обновляется, подключаются новые модули.

Критерии выбора частоты аудита

Периодичность определяется не привычкой, а темпами изменений. Полезные критерии:

• количество URL и число типов шаблонов: чем больше шаблонов, тем чаще появляются новые дефекты вывода;
• частота публикаций контента: активный блог быстрее накапливает дубли, битые ссылки и устаревшие метатеги;
• частота технических релизов: каждый релиз это риск задеть canonical, robots.txt, редиректы, разметку;
• наличие динамических разделов: фильтры, сортировки, поиск по сайту, личный кабинет;
• история ошибок: если одни и те же проблемы возвращаются, интервал стоит сократить;
• число поддоменов и языковых версий: каждое зеркало добавляет свои правила индексации.

Ориентиры по частоте: малый статичный сайт - раз в год, средний проект с публикациями - раз в полгода, крупный сайт - раз в квартал, интернет-магазин - раз в квартал или чаще. Это ориентиры, а не норматив: проект с ежедневными выкатами и десятками тысяч параметрических URL требует другой частоты, чем лендинг с десятью страницами.

Внеплановый аудит стоит запускать после крупного релиза, смены CMS или хостинга, массового изменения URL, подключения нового CDN, а также при резком падении органического трафика. В последнем случае сначала важно отделить техническую причину от алгоритмической: порядок диагностики при подозрении на санкции разбирает материал про проверку сайта на фильтры Яндекса, и его выводы полезно держать в голове, чтобы не чинить то, что не сломано.

Как встроить аудит в регулярный процесс

Цикл выглядит так: аудит, задачи в трекере, исправление, проверка результата, следующий аудит. Ключевые элементы, без которых цикл рвётся:

• у каждой задачи есть ответственный и срок;
• у каждой задачи есть критерий приёмки, по которому её можно закрыть;
• критические находки уходят в работу сразу, остальные планируются в бэклог;
• исправленное проверяется повторно: часть правок откатывается следующими релизами.

Пример распределения: после аудита сформировано 20 задач, пять из них критические (блокировка обхода, noindex на трафиковой странице, битые канонические адреса), их берут в ближайший спринт. Остальные пятнадцать распределяются по приоритету и уходят в план на квартал. Без контроля исправлений через три месяца аудит придётся начинать с того же места.

Где в процессе аудита уместна автоматизация

Автоматизация ускоряет сбор и хранение данных, но не отменяет интерпретацию. Граница проходит примерно посередине: машина собирает и сравнивает, человек решает, что важно.

Что можно автоматизировать, а что требует экспертизы

Наглядный пример: скрипт собирает данные из панелей и складывает в таблицу, но решение о критичности конкретной страницы принимает специалист, потому что для этого нужно сопоставить технический статус с трафиком, конверсиями и планами по разделу.

Как автоматизация помогает не терять находки между аудитами

Между полными аудитами полезно держать лёгкий мониторинг: появление новых 404 и 5xx на важных шаблонах, изменения в robots.txt и sitemap, резкие колебания обхода по разделам, рост числа исключённых страниц. Такой набор проверок не заменяет аудит, зато показывает, что проблема появилась, до следующего планового запуска.

SerpJet в этой схеме закрывает свою часть работы, связанную с контентом: помогает организовать производство материалов, работать с семантическим ядром и тематическими направлениями, готовить статьи с учётом поискового намерения, анализировать и обновлять уже опубликованное. Технический аудит платформа не проводит: она автоматизирует рутинные операции контент-процесса, а решения по обходу и индексации остаются за специалистом.

Практический шаг, с которого стоит начать: зафиксируйте границы аудита и соберите доступы до первого сканирования, а список находок сразу оформляйте в виде задач с URL и критериями приёмки. Тогда следующий аудит будет сравнением с предыдущим, а не новой работой с нуля.