Технический аудит сайта: чек-лист маркетолога

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

Для маркетолога полезен ограниченный аудит с доказательствами и владельцами. Он начинается с критических страниц и недавних изменений, а заканчивается не оценкой «плохо», а проверяемой задачей: что сломано, какой охват, кто исправляет и как подтвердить результат.

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

1. Зафиксируйте границы аудита

До запуска инструментов опишите повод и объём. После релиза проверьте изменённые шаблоны и связанные сценарии. При падении органического трафика сравните даты, типы страниц, запросы и изменения сайта. При переносе домена добавьте редиректы, зеркала, canonical и sitemap.

Повод	Минимальный объём	Главный риск
Релиз или смена шаблона	Новые и изменённые страницы, формы, мобильный путь	Ошибка в разметке, ресурсах или аналитике
Падение трафика	Пострадавшие разделы, даты и поисковые страницы	Неверно связать технический симптом и причину
Перенос или смена адресов	Старые и новые URL, редиректы, canonical, sitemap	Потеря доступности и сигналов страниц
Плановая проверка	Выборка ключевых шаблонов и отчёты Вебмастера	Накопленные дубли, ошибки и бесхозные задачи

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

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

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

200 — страница доступна, но содержимое и индексируемость ещё нужно проверить;
301 или 308 — постоянное перенаправление допустимо, если ведёт сразу на целевой адрес;
302 или 307 — временный маршрут требует объяснения;
404 или 410 — адрес отсутствует; проверьте внутренние ссылки и ценность удалённой страницы;
5xx — сервер не обработал запрос; это приоритетный риск доступности.

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

3. Сверьте индексацию, robots.txt и sitemap

Доступность страницы для браузера не означает доступность для поискового робота. Проверьте правила robots.txt, метатег robots, заголовок X-Robots-Tag и настройки самого сервиса. Запрет должен быть осознанным и совпадать с ролью URL.

В Яндекс Вебмастере используйте анализ robots.txt, проверку ответа сервера и анализ индексирования страницы. Сопоставляйте не один сигнал, а цепочку: робот может получить страницу, она не закрыта от индексирования, canonical соответствует замыслу, а статус в Вебмастере объясним.

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

4. Найдите дубли и конфликтующие сигналы

Один материал часто доступен по нескольким адресам: с параметрами, разным регистром, завершающим слешем, HTTP и HTTPS, старым и новым путём. Выберите основной адрес и проверьте согласованность четырёх сигналов: внутренней ссылки, редиректа, canonical и sitemap.

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

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

5. Пройдите мобильный пользовательский путь

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

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

Показатели Core Web Vitals и их связь с конверсией помогают описать скорость загрузки, отзывчивость и визуальную стабильность, но не заменяют проверку сценария. Смотрите полевые данные по группам страниц, а лабораторную диагностику используйте для поиска причины. Не объявляйте проблему общей по сайту по одному тесту одного URL.

Если после релиза пострадала форма, проверьте всю цепочку: интерфейс, запрос, ответ сервера, запись в системе-получателе и цель аналитики. Сам визуальный экран «Спасибо» ещё не доказывает, что заявка сохранена.

6. Убедитесь, что измерение не сломано

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

сопоставьте дату релиза и момент изменения данных;
сравните органический трафик по посадочным, устройствам и типам страниц;
проверьте цели на тестовом сценарии и факт результата в CRM или другой системе;
сверяйте одинаковые периоды, часовой пояс и модель атрибуции;
не подменяйте отсутствие данных нулём без пояснения.

При резком изменении используйте последовательность из руководства «Трафик упал: что делать». Если проблема в целях, сначала восстановите один проверяемый бизнес-сигнал по чек-листу настройки целей Метрики.

7. Расставьте приоритеты по риску и охвату

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

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

Приоритет	Пример	Действие
Критический	5xx, закрыт важный раздел, не работает заявка	Назначить владельца и срок немедленно
Высокий	Массовые дубли, неверные canonical, цепочки редиректов	Оценить шаблонный охват и исправить причиной
Средний	Медленный или нестабильный шаблон без блокировки пути	Запланировать улучшение и измерить эффект
Низкий	Единичное замечание без влияния на сценарий	Зафиксировать, не вытесняя важные задачи

8. Превратите аудит в рабочий реестр

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

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

9. Чек-лист на 30, 60 и 90 минут

Чек-лист технического аудита на 30, 60 и 90 минут после релиза. — Ограничение по времени помогает сначала доказать критические риски, а затем расширять проверку без бесконечного сбора замечаний.

Первые 30 минут: ключевые URL, коды ответа, ресурсы, robots, noindex, canonical и мобильный сценарий.
К 60-й минуте: sitemap, редиректы, дубли, формы, события аналитики и выборка шаблонов.
К 90-й минуте: данные Вебмастера, полевые показатели, приоритеты, владельцы и план повторной проверки.

Когда проводить технический аудит сайта?

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

С чего начать технический аудит?

Сначала подтвердите доступность ключевых страниц и корректность ответов сервера. Затем проверьте ограничения индексации, sitemap, canonical, дубли, мобильный путь и аналитику.

Как расставить приоритеты исправлений?

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