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

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

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

Какие данные нужны до начала

Публичного обхода сайта недостаточно. Для нормальной диагностики обычно нужны:

• Google Search Console и Яндекс Вебмастер;
• система веб-аналитики;
• список приоритетных направлений бизнеса;
• история миграций и крупных изменений;
• выгрузка URL из CMS или базы товаров;
• по возможности — логи веб-сервера.

Без бизнес-приоритетов специалист может потратить время на идеальную обработку страниц, которые не приносят спроса, и пропустить проблему в основном разделе.

1. Сканирование и доступность

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

• ответы сервера и цепочки перенаправлений;
• правила robots.txt;
• директивы noindex и nofollow;
• доступность CSS, JavaScript, изображений и API;
• контент, появляющийся только после действий пользователя;
• ошибки DNS, TLS и нестабильные ответы сервера.

Особое внимание уделяют мобильному рендерингу. Google индексирует сайты преимущественно мобильным роботом, поэтому сокращённая мобильная версия способна лишить страницу части релевантности.

2. Индексация и канонизация

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

Проверяются:

• self-referencing canonical;
• противоречия между canonical, sitemap и внутренними ссылками;
• дубли HTTP/HTTPS и www/non-www;
• параметрические и фасетные URL;
• страницы пагинации;
• мягкие 404 и пустые листинги;
• результаты URL Inspection в Search Console.

Файл robots.txt не используют для канонизации. Если закрыть дубль от сканирования, Google может увидеть ссылку на URL, но не сможет прочитать canonical на самой странице.

3. XML sitemap

Карта сайта должна содержать только индексируемые канонические URL со статусом 200. В неё не следует включать:

• редиректы и ошибки;
• страницы с noindex;
• служебные результаты поиска;
• дубли с параметрами;
• тестовые и закрытые разделы.

Дата lastmod должна изменяться после содержательного обновления, а не при каждом автоматическом пересохранении.

4. Архитектура и внутренние ссылки

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

• есть ли ссылки на все целевые страницы;
• понятны ли анкоры пользователю;
• не получают ли служебные URL больше ссылок, чем коммерческие;
• связаны ли статьи с услугами и соседними материалами;
• нет ли страниц-сирот;
• работает ли навигация без выполнения JavaScript.

5. Шаблоны и метаданные

Для каждого типа страниц анализируют правила формирования:

6. JavaScript и отрисованный HTML

Исходный HTML сравнивают с DOM после выполнения JavaScript. Проверяют, присутствуют ли в отрисованной версии основной текст, ссылки, метаданные и структурированные данные. Отдельно моделируют отказ внешнего API и медленное соединение.

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

7. Скорость и Core Web Vitals

Лабораторный Lighthouse помогает найти причину, а полевые данные показывают реальный опыт посетителей. Google рекомендует ориентироваться на:

• LCP до 2,5 секунды — скорость появления основного элемента;
• INP менее 200 мс — отзывчивость интерфейса;
• CLS не более 0,1 — визуальная стабильность.

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

8. Структурированные данные

Разметку проверяют на техническую валидность и соответствие видимому контенту. Наличие JSON-LD не гарантирует расширенный результат. Использовать следует только типы, подходящие конкретной странице: например, Product, Article, BreadcrumbList или LocalBusiness.

9. Изображения, видео и доступность

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

Как должен выглядеть результат аудита

Итог — не таблица из тысячи строк, а дорожная карта. Для каждой задачи нужны:

1. описание проблемы и примеры URL;
2. влияние на сканирование, индексацию или результат;
3. рекомендуемое решение;
4. критерий приёмки;
5. приоритет и оценка сложности;
6. ответственный;
7. способ проверки после релиза.

Что проверять после внедрения

Исправление в коде ещё не означает исправление в поиске. После релиза повторно обходят затронутые URL, проверяют ответы сервера и отрисованный HTML, затем наблюдают за Search Console. Для крупных изменений полезно вести журнал релизов: дата, список URL и ожидаемый эффект.

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