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

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

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

Сначала определите границы и эталон

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

Соберите четыре набора данных:

• URL из навигации и внутренних ссылок;
• URL из XML Sitemap;
• страницы, известные Google Search Console и Яндекс Вебмастеру;
• URL из серверных логов, если они доступны.

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

Проверяйте путь страницы до индекса по этапам

Удобно рассматривать технический SEO как последовательность: обнаружение URL, разрешение обхода, HTTP-ответ, рендеринг, выбор канонической версии и индексирование. Если смешать этапы, легко лечить не ту причину. Например, добавление URL в Sitemap не поможет, когда сервер отвечает ошибкой, а правка заголовка страницы не решит запрет noindex.

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

HTTP-статусы и редиректы

Индексируемая страница должна возвращать содержимое с корректным статусом 200 OK. Удалённый адрес — честный 404 Not Found или 410 Gone, а не шаблон ошибки со статусом 200. Перемещённая страница должна вести постоянным редиректом на наиболее близкий актуальный аналог. Не стоит отправлять все старые URL на главную: для пользователя и поисковой системы это обычно неравнозначная замена.

Проверьте:

• цепочки из нескольких редиректов и циклы;
• ссылки внутри сайта, которые ведут через редирект;
• единый вариант HTTPS, домена и завершающего слеша;
• ответы сервера при несуществующем пути;
• временные ошибки 5xx и нестабильные ответы;
• зависимость статуса от User-Agent или cookies.

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

robots.txt, meta robots и доступ к ресурсам

robots.txt управляет обходом, но не является универсальным способом удалить страницу из поиска. URL, закрытый через Disallow, может оставаться известным поисковой системе по внешним ссылкам, при этом робот не увидит размещённый на странице noindex. В документации Google отдельно указано, что для запрета индексирования HTML применяют robots meta, а для не-HTML ресурсов — заголовок X-Robots-Tag; правило сработает только тогда, когда робот может его прочитать. Полезная сверка находится в официальной спецификации robots meta и X-Robots-Tag.

Проверьте, не закрыты ли по ошибке CSS, JavaScript, изображения и API-запросы, необходимые для отображения основного контента. Google рекомендует оставлять важные ресурсы доступными, чтобы робот мог отрендерить страницу. В Яндекс Вебмастере для отдельных URL доступен анализ индексирования страницы, который помогает проверить ограничения robots.txt, meta robots и доступность ответа.

XML Sitemap без технического мусора

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

Для динамического Sitemap проверьте генерацию после публикации, удаления и смены URL. Поле lastmod должно отражать существенное обновление страницы, а не автоматически меняться при каждом запросе. Google отмечает, что priority и changefreq не используются, а Sitemap является подсказкой; актуальные требования перечислены в руководстве по созданию Sitemap. Яндекс также рекомендует убедиться, что файл доступен со статусом 200 и не закрыт в robots.txt; это описано в разделе об использовании Sitemap.

Canonical и дубли страниц

Дубли появляются из-за параметров сортировки и фильтрации, UTM-меток, печатных версий, разных вариантов регистра, слеша, протокола или домена. Сначала нужно определить, какие URL действительно должны существовать для пользователя и поиска. Затем сигналы согласуют: внутренние ссылки, redirect, rel="canonical", Sitemap и языковые аннотации должны указывать на выбранную версию.

Canonical — рекомендация, а не команда. Канонический URL должен быть доступен, индексируем и содержательно соответствовать дубликату. Нельзя одновременно направлять canonical на одну страницу, ставить её в noindex и добавлять другую версию в Sitemap. Google считает редиректы и rel="canonical" сильными сигналами, а включение в Sitemap — более слабым; подробности есть в официальном руководстве по канонизации дублей. Яндекс также рассматривает canonical как рекомендацию и перечисляет условия, при которых она может быть не учтена, в справке о каноническом адресе.

Внутренние ссылки и глубина структуры

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

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

Рендеринг и основной контент

На JavaScript-сайтах сравните исходный HTML, итоговый DOM и то, что показывает инструмент проверки URL. Заголовок, основной текст, ссылки, canonical и структурированные данные не должны зависеть от действия пользователя. Если сервер отдаёт пустой контейнер, а загрузка данных падает для робота, формально успешный ответ не делает страницу пригодной для индексирования.

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

Мобильная версия и Core Web Vitals

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

Основные Core Web Vitals оценивают скорость появления крупного контента, отзывчивость и визуальную стабильность. Их актуальные определения и ориентиры следует проверять в документации web.dev о Web Vitals. В отчёте фиксируйте не только метрику, но и конкретный элемент или скрипт: hero-изображение без приоритета, баннер без зарезервированной высоты, обработчик, блокирующий интерфейс.

Метаданные и структурированные данные

У каждой индексируемой страницы должен быть осмысленный уникальный title и описание, соответствующее содержанию. Но длина метатега — не техническая гарантия показа: поисковая система может сформировать сниппет иначе. Важнее, чтобы title точно называл страницу, а description помогал человеку понять её ценность без повторения набора ключевых фраз. Набор посадочных страниц должен следовать бизнес-задаче и архитектуре продукта; подробнее об этом — в разборе, какой сайт нужен бизнесу.

Структурированные данные проверяют на валидность и соответствие видимому содержанию. Разметка не должна описывать рейтинг, автора, товар или вопрос, которых пользователь не видит. Ошибка schema.org не всегда мешает индексированию, поэтому её приоритет зависит от типа страницы и возможного расширенного результата.

Как расставить приоритеты

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

Повторная проверка завершает аудит

После внедрения снова просканируйте затронутый раздел, проверьте HTTP-ответы и исходный HTML, откройте несколько URL в инструментах поисковых систем. Сравните контрольный набор до и после изменения. Закрывать задачу по факту изменения кода недостаточно: важен ответ, который получает робот на опубликованном сайте.

Ценность технического SEO-аудита не в длине чек-листа, а в том, насколько точно он связывает симптом, первопричину, исправление и проверяемый результат.

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