Технический аудит сайта: чек-лист из 40 пунктов

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

Зачем нужен технический аудит и когда его проводить

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

Проводить проверку полностью стоит раз в год, а отдельные блоки — регулярно. Быстрый контроль раз в месяц занимает 20 минут и ловит большинство аварий: пропавшую индексацию, закрытый robots.txt, упавшую скорость.

Стоит разделить два понятия, которые часто смешивают. Технический аудит отвечает на вопросы «поисковик видит сайт?», «быстро ли он открывается?», «нет ли ошибок?». SEO-аудит шире: он включает контент, семантику, ссылочный профиль и конкурентный анализ. Начинать всегда стоит с технической части: если сайт не индексируется, анализ контента бессмысленен.

Симптомы, при которых аудит нужен немедленно:

• трафик из поиска упал больше чем на 20% за неделю;
• в Search Console появились «ошибки сервера» (5xx);
• новые статьи не появляются в индексе больше месяца;
• сайт стал заметно медленнее открываться;
• после переезда на новый хостинг просели позиции.

Порядок действий: от общего к частному

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

1. Доступность и индексация.
2. Структура и дубли.
3. Скорость и Core Web Vitals.
4. Мобильная версия.
5. Разметка и мета-теги.
6. Безопасность и служебные файлы.

Часть 1. Индексация (пункты 1–8)

Это фундамент. Если здесь проблема, всё остальное не имеет значения.

1. robots.txt открывает нужное. Проверьте, что нет Disallow: / и что служебные

разделы закрыты осознанно, а не «на всякий случай».

1. Главное зеркало определено. Сайт с www и без, http и https — должно быть

одно каноническое. Остальные редиректят на него.

1. HTTPS работает везде. Ни одной страницы по http://; сертификат действителен,

без предупреждений в браузере.

1. sitemap.xml существует и актуален. В нём только индексируемые страницы, без

битых и редиректов.

1. sitemap привязан в Search Console и Вебмастере. Иначе о новых страницах поиск

узнаёт с задержкой.

1. Страницы в индексе. Сравните число страниц в sitemap с числом в индексе:

расхождение больше 30% — сигнал проблемы.

1. Нет «исключено, но не просканировано». В Search Console есть отчёт с причинами:

обычно это слабые страницы или технические блокировки.

1. Нет ошибок сканирования. Проверьте отчёт по ошибкам за последние 90 дней.

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

Ещё один быстрый тест: введите в поиск site:ваш-домен.ru и посмотрите примерное число страниц. Сравните с тем, что ожидаете увидеть. Большая разница в любую сторону — сигнал: либо в индексе мусор от параметров, либо половина сайта закрыта.

Часть 2. Структура и дубли (пункты 9–15)

1. Canonical корректен на всех страницах. Он указывает на саму страницу, а не

на главную — это частая ошибка при шаблонной вёрстке.

1. Пагинация настроена. Страницы списков не должны конкурировать с основными.
2. Нет дублей от параметров. Фильтры магазина, UTM-метки, сортировки — всё это

плодит дубликаты. Решение: canonical или закрытие от индексации.

1. Старые URL редиректят. После редизайна ни один старый адрес не должен отдавать 404.
2. Нет цепочек редиректов. Больше одного перехода в цепочке — потеря скорости

и путаница для робота.

1. 404 отдаёт правильный код. «Мягкие 404» (страница с 200 и текстом «не найдено»)

вредят индексации.

1. Структура URL читаемая. Адрес отражает раздел и тему, а не набор символов.

Дубли — самая коварная часть аудита, потому что их не видно при обычном просмотре сайта. Человек открывает страницу и видит нормальный контент; поисковик в это время видит пять её копий с разными адресами и не может выбрать главную. В итоге все пять показываются плохо.

Где искать дубли:

• Фильтры и сортировки в магазине. Каждый набор параметров создаёт новую версию страницы.
• Параметры отслеживания. Метки UTM попадают в индекс, если по ним есть внешние ссылки.
• Слеш на конце адреса. /uslugi и /uslugi/ могут отдавать одну страницу.
• Индексы и заглавные буквы. /Uslugi/ и /uslugi/ — для сервера разные адреса.
• Печатные версии и мобильные поддомены. Если они открыты, нужен canonical.

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

Часть 3. Скорость и Core Web Vitals (пункты 16–24)

1. TTFB до 500 мс. Проверяется в PageSpeed Insights с реального региона.
2. LCP до 2,5 секунд. Крупнейший элемент должен грузиться быстро.
3. INP до 200 мс. Отзывчивость интерфейса: кнопки и меню реагируют сразу.
4. CLS до 0,1. Элементы не прыгают при загрузке — иначе посетитель кликает не туда.
5. Включён кэш. Кэширование страниц на стороне хостинга или плагином.
6. Включён gzip или brotli. Сжатие уменьшает вес страницы в 3–5 раз.
7. Изображения оптимизированы. Формат WebP или AVIF, размер соответствует выводу.
8. Нет блокирующих скриптов. Всё лишнее — с defer или async.
9. Шрифты не блокируют отрисовку. font-display: swap и локальный хостинг шрифтов.

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

Метрика	Норма	Частая причина проблемы
LCP	до 2,5 с	неоптимизированная главная картинка
INP	до 200 мс	тяжёлые скрипты и сторонние виджеты
CLS	до 0,1	баннеры и шрифты без зарезервированного места
TTFB	до 500 мс	слабый хостинг, отсутствие кэша

Порядок устранения обычно такой: сначала кэш и сжатие на уровне сервера (даёт мгновенный эффект), затем изображения (самый большой вес страницы), затем скрипты (метрика INP). Сторонние виджеты — чат, карты, счётчики — стоит проверять отдельно: иногда один виджет добавляет больше секунды, чем весь остальной сайт.

Часть 4. Мобильная версия (пункты 25–29)

1. Контент одинаков на мобильном и десктопе. Скрытие блоков на мобильной версии

воспринимается как несоответствие.

1. Шрифт не мельче 16 px. Иначе посетитель масштабирует страницу и уходит.
2. Кликабельные элементы не ближе 8 px друг к другу. Промахи по ссылкам — прямой

путь к отказу.

1. Нет горизонтальной прокрутки. Проверяется на ширине 360 px.
2. Всплывающие окна не перекрывают контент. Навязчивые попапы на мобильных

особенно раздражают и ухудшают поведенческие факторы.

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

Часть 5. Разметка и мета-теги (пункты 30–35)

1. Title уникален на каждой странице. Дубли title — внутренняя конкуренция.
2. Description заполнен. Он не влияет на позиции напрямую, но влияет на кликабельность.
3. Один H1 на странице. И он соответствует теме.
4. Иерархия заголовков логична. H2 не «прыгает» через уровень.
5. Микроразметка валидна. Проверяется валидатором; ошибки в разметке лишают

страницу расширенного сниппета. Как это устроено — в материале про разметку схемы и структурированные данные.

1. Open Graph заполнен. От него зависит вид ссылки в соцсетях и мессенджерах.

Часть 6. Безопасность и служебное (пункты 36–40)

1. Нет вирусов и посторонних скриптов. Проверяется в Search Console и Вебмастере.
2. Служебные страницы закрыты. Панель администрирования, тестовые и технические

разделы не должны попадать в индекс.

1. Формы защищены от спама. Капча или скрытое поле — иначе мусор в заявках.
2. Резервные копии делаются. И лежат вне основного сервера.
3. Логи и мониторинг доступности. Вы должны узнать о падении сайта раньше клиента.

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

Отдельно про резервные копии: проверьте не только то, что они создаются, но и то, что из них можно восстановиться. Копия без тестового восстановления — это надежда, а не план.

Инструменты для проверки

Задача	Инструмент
Индексация и ошибки	Google Search Console, Яндекс.Вебмастер
Скорость и CWV	PageSpeed Insights, WebPageTest
Технические ошибки	Screaming Frog, Sitebulb
Микроразметка	Rich Results Test, валидатор схем
Доступность	Uptime-сервисы, мониторинг хостинга
Дубли и canonical	Ahrefs, Serpstat, ручная выборка

Начинать можно с бесплатного набора: Search Console, Вебмастер и PageSpeed Insights закрывают две трети чек-листа. Платные краулеры нужны, когда страниц больше тысячи или когда требуется регулярная автоматическая проверка.

Частые ошибки при аудите

• Начинать со скорости. Дни работы, а страницы всё ещё закрыты в robots.txt.
• Смотреть только на главную. Проблемы живут в глубине: в товарах, в пагинации, в карточках.
• Путать позиции и технику. Сайт может отлично индексироваться и быть на 30-м месте —

это вопрос контента, не техники.

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

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

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

Отдельно про порядок исправления: сначала блокирующие проблемы (индексация, 404, битые редиректы), затем скорость, затем косметика. Если сайт на WordPress, разумно сначала закрыть техническую базу, а потом наращивать контент — иначе новые страницы не принесут трафика. Технический фундамент входит и в продвижение и оптимизацию сайтов.

Как часто повторять аудит

• Ежемесячно. Быстрый контроль: индексация, ошибки сканирования, доступность, скорость.
• Раз в квартал. Полная проверка чек-листа по всем 40 пунктам.
• После каждого крупного изменения. Редизайн, переезд, смена CMS, массовая правка URL.
• При падении трафика. Аудит первым делом, до гипотез о «фильтре».

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

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

Что важно запомнить

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

разметка, безопасность.

• Canonical и пагинация — главный источник скрытых дублей.
• Core Web Vitals влияют и на позиции, и на конверсию одновременно.
• Проверять нужно глубину сайта, а не только главную страницу.
• Массовые правки без фиксации «до и после» обесценивают работу.
• Регулярный контроль раз в месяц дешевле, чем разбор последствий аварии.