Технический SEO-аудит: полный чек-лист перед продвижением

Что входит в технический SEO-аудит

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

Базовый технический аудит сайта охватывает домен и протокол, серверные ответы, правила обхода и индексирования, canonical — указание предпочтительного URL, дубли, Sitemap, редиректы, внутренние ссылки, JavaScript-рендеринг, мобильную версию, производительность, структурированные данные и сообщения поисковых систем.

Слово «полный» здесь не означает один универсальный список на все случаи. Лендингу не нужна проверка страниц фильтров, а интернет-магазину с фильтрами недостаточно проверить только главную страницу. Полный аудит состоит из двух частей:

1. обязательной базы для большинства публичных индексируемых сайтов;
2. условных модулей, которые добавляют под архитектуру проекта.

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

Что подготовить до запуска краулера

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

1. Зафиксировать цель и границы

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

Определите дату снимка. Данные Search Console, Яндекс Вебмастера, аналитики, краулера и серверных логов должны относиться к понятному периоду. Иначе команда будет сравнивать разные состояния сайта и спорить не о причине, а о датах.

2. Собрать ожидаемый реестр страниц

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

Этот реестр станет контрольной группой. Без него нельзя отличить ошибочно исключенную страницу от служебного URL, который правильно не участвует в поиске.

3. Собрать контрольную выборку

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

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

Минимальный маршрут проверки

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

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

Этап 1. Домен, протокол, хосты и серверные ответы

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

Проверьте:

• открывается ли HTTPS без ошибок и соответствует ли сертификат нужным хостам;
• сходятся ли HTTP, www и альтернативные хосты в одну выбранную версию;
• не создают ли регистр, слеш, индексные файлы и параметры параллельные адреса;
• отвечают ли главная и типовые страницы ожидаемыми кодами без циклов и длинных цепочек;
• нет ли смешанного содержимого, периодических 5xx, таймаутов или различий для браузера и поискового робота.

Минимальные технические требования Google включают доступ Googlebot, успешный ответ страницы и индексируемое содержание. При этом ответ 200 лишь передает документ в дальнейшую обработку и не гарантирует индексирование. Яндекс позволяет проверить код, содержимое и доступность для выбранного робота через Проверку ответа сервера, но отдельно оговаривает, что ответ инструмента может отличаться от реального запроса робота из-за другого IP. При спорной картине нужны логи сервера.

Этап 2. Разделить обход и индексирование

Robots.txt, meta robots и X-Robots-Tag решают связанные, но разные задачи.

• robots.txt сообщает роботам, какие URL им разрешено запрашивать;
• meta robots управляет индексированием HTML-страницы и показом ее элементов в поиске;
• X-Robots-Tag передает аналогичные правила в HTTP-заголовке и подходит, например, для PDF;
• авторизация и контроль доступа защищают закрытые данные.

Google прямо указывает, что robots.txt не предназначен для сокрытия страницы из поиска: URL может остаться известен по ссылкам, даже если содержание не обходится. Для конфиденциальных данных robots.txt тем более не подходит.

Проверьте доступность /robots.txt на нужных хостах, правила для фактических User-Agent и ссылку на актуальный Sitemap. Отдельно найдите случайные запреты для важных страниц и ресурсов, noindex в HTML или HTTP-заголовке и расхождения директив после JavaScript-рендеринга. Тестовую среду закрывайте контролем доступа, а не надеждой на robots.txt.

В Анализе индексации страницы Яндекса можно отдельно проверить влияние robots.txt и meta robots. Положительный результат означает доступность, но не подтверждает присутствие страницы в поиске.

Этап 3. Сопоставить нужные страницы с индексом

Здесь я не ставлю задачу проиндексировать каждый URL. Важно понять, совпадает ли фактический состав поиска с ценными страницами сайта.

Разделите URL на три группы: должны участвовать в поиске, не должны участвовать и требуют решения. Затем сопоставьте их с массовыми отчетами Search Console и Яндекс Вебмастера, проверкой отдельных URL, статистикой обхода, Sitemap и внутренним обходом сайта.

Page Indexing в Search Console дает массовую картину, а URL Inspection показывает состояние конкретного URL, известную Google версию, выбранный canonical и результат проверки текущей опубликованной версии. Такая проверка доступности не охватывает все условия индексирования и не обещает появление страницы в поиске.

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

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

Этап 4. Проверить canonical и дубли

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

Само отсутствие canonical, указывающего на текущий URL, еще не доказывает проблему. Сначала нужно найти альтернативные версии, дубли или конфликтующие сигналы и понять, какой адрес должен быть основным.

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

Google относит редиректы и rel="canonical" к сильным сигналам, а включение URL в Sitemap — к более слабым. Сигналы можно усиливать согласованностью, но поисковая система все равно принимает итоговое решение. Яндекс также называет canonical рекомендацией и перечисляет случаи, когда робот может ее проигнорировать: недоступная цель, существенно отличающееся содержание, несколько адресов или цепочка.

Не исправляйте все дубли одним шаблонным canonical на главную. Сначала определите, действительно ли страницы взаимозаменяемы для пользователя. Если старый URL окончательно заменен, чаще нужен постоянный редирект. Если страница должна существовать и приносит отдельную пользу, ей может требоваться самостоятельное содержание.

Этап 5. Проверить Sitemap как декларацию нужных URL

Sitemap помогает обнаруживать важные URL, но не заменяет внутренние ссылки и не гарантирует обход или индексирование. Это прямо указано в справке Google о Sitemap.

Проверьте ответ 200, доступность роботам, домен, протокол и валидность XML. В Sitemap должны оставаться конечные canonical URL без 3xx, 4xx, 5xx, noindex и запретов обхода; важные индексируемые страницы не должны выпадать. Сверьте lastmod со значимыми обновлениями, а сам список — с canonical, внутренними ссылками и отчетом обработки в панелях поисковых систем.

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

Этап 6. Разобрать коды ответа, редиректы и soft 404

Код ответа должен описывать реальное состояние ресурса: 200 — содержание доступно; 301 и 308 — постоянный перенос; 302, 303 и 307 — временный; 404 и 410 — ресурс отсутствует; 429 и 5xx — запрос не обработан штатно.

И Google, и Яндекс различают постоянные и временные перенаправления. Для окончательной смены адреса предпочтителен прямой серверный постоянный редирект на эквивалентную страницу. Цепочки увеличивают число запросов и усложняют контроль сигналов.

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

Google может определить страницу с ответом 200, но с сообщением об ошибке или пустым содержанием как soft 404. Поэтому недостаточно смотреть только на колонку с кодом: нужно сопоставлять ответ и фактическое содержание.

Не все 404 требуется перенаправлять. Если эквивалентной замены нет, честный 404 или 410 лучше редиректа на нерелевантную страницу. Исправлять в первую очередь нужно битые внутренние ссылки, URL из Sitemap и удаленные страницы с реальным подходящим преемником.

Этап 7. Проверить, как робот находит страницы

Sitemap помогает обнаружению, но важная страница не должна зависеть только от файла или внутреннего поиска.

Google обычно обходит ссылки в элементах <a href>, а кнопки и span с обработчиком клика может не распознать. В рекомендациях по внутренним ссылкам каждой важной странице советуют дать хотя бы одну входящую ссылку.

Проверьте, есть ли на каждый важный URL доступная входящая ссылка, ведет ли она сразу на canonical и понятен ли ее текст. Найдите страницы, доступные только через Sitemap, поиск, фильтр или действие пользователя; проверьте пагинацию, навигационные тупики, хлебные крошки и исчезающие после рендеринга ссылки.

Нулевое число ссылок в одном краулере еще не доказывает изоляцию. Убедитесь, что инструмент видел все шаблоны и выполнил JavaScript, затем проверьте входы в HTML после рендеринга.

Этап 8. Сравнить исходный и отрендерованный HTML

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

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

Яндекс сканирует исходные URL AJAX-сайта и может выполнять JavaScript. В Вебмастере есть отдельные инструменты рендеринга и управления индексированием JavaScript-страниц.

Для нескольких шаблонов сравните исходный HTML, документ после выполнения JavaScript и версию в инструментах поисковых систем. Сверьте основной текст, заголовки, ссылки, Title, Description, H1, canonical, meta robots и структурированные данные. Отдельно проверьте существующие и несуществующие маршруты, ошибку API и мобильный User-Agent.

Основной текст не должен появляться только после клика, свайпа или ввода. Google предупреждает, что при использовании мобильной версии для индексирования может не найти содержание, которое загружается только после пользовательского действия.

На этом же срезе ищут пропавшие и массово повторяющиеся Title, Description и H1. Технический аудит фиксирует дефект шаблона и масштаб, но не подменяет отдельную работу над метаданными под интент каждой страницы.

Этап 9. Проверить мобильную версию и производительность

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

Сверьте основной текст, ключевые ссылки, Title, Description, правила индексирования и структурированные данные. Убедитесь, что ресурсы доступны, формы работают, содержание не появляется только после взаимодействия и нет перекрытий или горизонтальной прокрутки. Для отдельных мобильных URL проверьте взаимные сигналы и редиректы.

При поиске причин смотрят не только итоговый балл: проверяют время ответа сервера, тяжелые изображения, блокирующие CSS и JavaScript, загрузку шрифтов, кеширование и сторонние скрипты. В реестр попадает конкретная причина и затронутый шаблон.

Производительность оценивают двумя типами данных:

• полевыми. что испытывают реальные пользователи;
• лабораторными. что воспроизводится в контролируемом тесте.

По состоянию на 14 августа 2026 года хорошие пороги Core Web Vitals составляют:

• LCP — не более 2,5 секунды;
• INP — не более 200 миллисекунд;
• CLS — не более 0,1.

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

Хорошие показатели важны для опыта посетителей и рекомендуются Google, но не гарантируют высокие позиции. В бэклог нужно записывать конкретную причину и затронутый шаблон, а не задачу «сделать 100 баллов».

Этап 10. Проверить структурированные данные

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

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

Google рекомендует размечать содержание той страницы, на которой находится JSON-LD, и не добавлять сведения, отсутствующие в видимой части. Даже корректная разметка не гарантирует расширенное представление в выдаче.

Этап 11. Проверить безопасность и ручные ограничения

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

В Google Search Console откройте:

• Manual Actions;
• Security Issues;
• сообщения о критических проблемах;
• доступы и подтвержденных владельцев.

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

В Яндекс Вебмастере проверьте «Диагностику сайта» и «Безопасность и нарушения». Уведомление нужно разбирать по описанию и затронутым страницам, а после исправления — отправлять на повторную проверку предусмотренным способом.

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

Какие модули добавлять по типу сайта

Я отмечаю каждую базовую область как проверено, неприменимо или недостаточно данных. Дополнительные модули включаю только при соответствующей архитектуре.

Отдельный анализ ресурсов обхода нужен не каждому сайту. Google адресует расширенное руководство прежде всего сайтам примерно с 1 млн и более уникальных страниц, меняющихся еженедельно; сайтам примерно с 10 тыс. и более страниц, меняющихся ежедневно; а также проектам с большой долей URL в состоянии «Страница обнаружена, но пока не проиндексирована». Google отдельно отмечает, что эти числа являются ориентировочными.

Как отличить сигнал инструмента от реальной проблемы

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

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

Другой пример: инструмент находит тысячу 404. Если это старые внешние URL без внутренних ссылок, без Sitemap и без эквивалентной замены, массовый редирект может создать больше вреда, чем пользы. Если один из этих 404 стоит в основном меню, проблема приоритетнее всего списка.

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

Для каждой находки нужны четыре подтверждения:

• правило. какое состояние ожидается;
• факт. что происходит сейчас;
• масштаб. какие URL и шаблоны затронуты;
• влияние. чему именно мешает дефект.

Если хотя бы одного элемента нет, запись остается гипотезой или задачей на дополнительную диагностику.

Как назначить приоритет исправления

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

Удобна четырехуровневая шкала.

Blocker: блокирующий приоритет

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

High: высокий приоритет

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

Medium: средний приоритет

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

Monitor: наблюдение

Инструмент показывает сигнал, но пока не хватает данных, выборки или повторного измерения для назначения исправления.

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

Эта логика помогает выбрать один следующий приоритет и не превращать технический отчет в очередь из сотен равнозначных задач.

Шаблон реестра проблем

В рабочей таблице к этим полям добавляют дату и область проверки, подтвержденное количество URL, зависимости, ссылку на задачу и историю статусов новая, в работе, выпущена, проверена или отклонена.

Выпущено не означает исправлено. После релиза нужно повторить проверку.

Как принимать исправления

Я считаю задачу закрытой не в момент отправки отчета, а после того, как исправление выпущено, повторно проверено тем же способом и принято без двусмысленности.

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

Если для шаблона выбран canonical на текущий URL, рабочая формулировка может выглядеть так:

Для всех индексируемых страниц шаблона услуги исходный HTML содержит один абсолютный canonical на текущий HTTPS-URL без параметров. Этот URL отвечает 200, разрешен к индексированию и указан во внутренних ссылках. Если проект включает такие страницы в Sitemap, там указан тот же URL. Проверка проводится на заранее зафиксированной выборке и массовым обходом.

После выпуска повторите исходный запрос и выборочный обход тем же User-Agent, сравните исходный и отрендерованный HTML и проверьте массовую выборку. Зафиксируйте дату, переведите задачу в статус проверено, а затем наблюдайте за повторным обходом поисковой системой.

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

Хороший аудит заканчивается не отправкой отчета. Исправление принято только после повторной проверки тем же способом и ясного решения без спора между маркетингом и разработкой.

Чего технический аудит не гарантирует

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

Технический аудит создает условия для работы SEO, но не заменяет само продвижение. По той же причине для Google AI Overviews и AI Mode не нужен отдельный «AI-технический аудит»: официальная справка Google сохраняет обычные требования SEO и не требует специального AI-файла или отдельной schema.

Что делать после аудита

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

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