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

Я начинаю аудит не с оценки «качества сайта в процентах», а с вопроса: может ли поисковая система получить нужную страницу, понять её основное содержание и показать пользователю корректную версию? Затем проверяю, не теряется ли смысл страницы из-за структуры, дублей, рендера или ошибок после релиза.

Что должно быть на входе в аудит

Без контекста даже верное техническое замечание может оказаться неважным. Перед работой я фиксирую:

  • какие услуги или товары дают бизнесу обращения;
  • в каких регионах и поисковых системах нужна видимость;
  • на какой CMS и хостинге работает проект;
  • были ли переезды, редизайн, смена домена, миграция или массовая правка URL;
  • какие данные доступны: Яндекс Вебмастер, Google Search Console, Метрика/Analytics, серверные логи, карты сайта;
  • какие страницы считаются ключевыми и какой результат от них ждут: заявка, заказ, звонок, переход в каталог.

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

Порядок проверки: от доступности к деталям

Я иду сверху вниз — так быстрее находятся блокеры.

1. Доступность сайта и критичных URL

Сначала проверяю, открываются ли главная, услуги или категории, статьи, карточки и формы. Смотрю HTTP-ответы, редиректы, HTTPS, доступность без авторизации и реакцию на мобильном устройстве. Если сайт периодически недоступен, нужно разобраться с этим раньше, чем менять метатеги.

Для каждой обнаруженной ошибки важно зафиксировать URL, время проверки, фактический ответ и способ повторной проверки. Фраза «сайт иногда тормозит» не позволяет разработчику воспроизвести проблему; «страница X трижды вернула 502 в такие-то моменты» — уже рабочая гипотеза для хостинга или команды.

2. Индексация и управляющие директивы

Дальше я проверяю, какие страницы поисковый робот вообще может обойти и добавить в индекс. В центре внимания:

  • robots.txt и XML-sitemap;
  • метатег robots и заголовок X-Robots-Tag;
  • canonical;
  • цепочки редиректов и страницы с ошибками;
  • внутренние ссылки на важные URL;
  • параметры, фильтры, поиск по сайту, пагинация и служебные разделы.

Здесь легко навредить чрезмерной «оптимизацией». Не каждая страница с параметрами — ошибка, и не каждую низкокачественную страницу нужно запретить в robots.txt. Способ закрытия зависит от задачи: иногда нужен noindex, иногда canonical, иногда нормализация URL, а иногда — удаление бессмысленной генерации адресов. Яндекс подробно описывает работу robots.txt; перед изменением директив стоит проверить их на конкретных URL, а не переносить типовой файл из другого проекта.

3. Дубли и выбор основной версии страницы

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

Я отдельно проверяю:

  • единый вариант домена, протокола и завершающего слеша;
  • self-canonical у индексируемых страниц;
  • редиректы со старых URL после миграции;
  • отсутствие ссылок в меню и контенте на промежуточные адреса;
  • совпадение URL в sitemap с каноническими адресами.

Рендер и содержание: робот должен увидеть не пустой шаблон

Современный сайт часто подгружает часть содержания через JavaScript. Это не делает его автоматически плохим для поиска, но требует проверки. На ключевых страницах я смотрю, попадают ли в доступный пользователю и роботу HTML заголовок, основной текст, цены или характеристики, ссылки и разметка; не требуют ли они клика, авторизации или ошибки внешнего API.

Проверка особенно нужна после смены шаблона, внедрения конструктора, CDN, антибот-защиты или нового кэша. Бывает, что браузер владельца сайта показывает страницу нормально, а краулер получает заглушку, бесконечный редирект или неполный ответ.

Скорость — важна, но не всегда первая в очереди

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

Сначала надо установить, кого и где проблема затрагивает: страницу оформления заказа, мобильную категорию с посещаемостью, единичную старую статью или весь сайт. Затем — подтвердить измерением и выбрать исправление с понятным эффектом. Уменьшить картинку на странице без трафика может быть полезно, но не должно вытеснить из очереди падение оплаты или закрытый от индексации каталог.

Как я расставляю приоритеты

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

ПриоритетКак выглядит задачаПримерЧто делать
P0 — блокерСтраницы недоступны, закрыты или некорректно перенаправляют важный трафик.Каталог отдаёт 5xx, после миграции нет редиректов, на ключевых URL стоит noindex.Исправить немедленно, проверить на проде и сохранить результат.
P1 — существенная потеряПроблема затрагивает группу ценных страниц или важный пользовательский сценарий.Тысячи дублей из фильтров, пустой JS-рендер категорий, сломанная каноникализация.Согласовать решение с разработкой и проверить на выборке URL.
P2 — улучшение с подтверждённой пользойОшибка не блокирует сайт, но ухудшает понимание или опыт пользователя.Неполная перелинковка, тяжёлые изображения на популярных страницах.Включить в ближайший спринт и измерить до/после.
P3 — наблюдениеКосметика, единичный случай без ценности или гипотеза без данных.Формальное предупреждение сервиса на служебном URL.Зафиксировать, но не выдавать за срочную проблему.

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

Что должно быть в хорошем результате аудита

Практический аудит заканчивается не PDF на 80 страниц, а рабочим планом. Для каждой существенной задачи я фиксирую:

  1. Наблюдение: что проверено, на каких URL и когда.
  2. Риск: как проблема влияет на пользователя, обход, индексирование, видимость или заявку.
  3. Решение: что именно изменить, без расплывчатого «улучшить SEO».
  4. Зависимость: что нужно сделать раньше и какие изменения нельзя выпускать отдельно.
  5. Владелец: кто выполняет и кто принимает работу.
  6. Проверка: как подтвердить исправление после выкладки.

Особенно важен последний пункт. Например, после исправления sitemap я проверяю HTTP-ответ файла, список URL, отсутствие блокировки, появление в панели вебмастера и затем — реальные данные обхода. Считать задачу завершённой только потому, что коммит попал в репозиторий, нельзя.

Типовые ошибки, которые не стоит маскировать отчётом

  • Объединять проверку доступности, контента и ссылок в один общий балл.
  • Отдавать клиенту тысячи URL без группировки, причин и приоритетов.
  • Советовать удалить или закрыть страницы, не разобравшись в их трафике и роли в пути пользователя.
  • Менять robots.txt, canonical или редиректы на боевом сайте без точки отката.
  • Закрывать задачу без повторной проверки на опубликованной версии.

Техническое SEO — это не охота за идеальной оценкой сканера. Это устранение препятствий между полезной страницей и человеком, который ищет решение.

Вывод

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

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