Технический аудит сайта: что проверять в первую очередь

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

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

Уровень 0: сайт вообще виден поиску?

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

Что проверить

• robots.txt. Нет ли строки, запрещающей индексацию всего сайта. Чаще всего она остаётся после разработки на тестовом домене и переезжает на боевой.
• Мета-тег robots и заголовок X-Robots-Tag. Нет ли noindex на важных страницах или во всём шаблоне.
• Количество страниц в индексе. Сравниваем с реальным числом страниц. Если в индексе в разы меньше — проблема с индексацией. Если в разы больше — проблема с дублями.
• Панели вебмастеров. Есть ли уведомления о санкциях, нарушениях, проблемах безопасности.

Из практики: интернет-магазин после редизайна три недели терял трафик. Причина нашлась за пять минут — разработчики перенесли на сайт robots.txt с тестовой площадки, где был закрыт весь каталог. Три недели и заметная часть месячной выручки ушли на одну строку.

Уровень 1: коды ответа и редиректы

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

Отдельно проверяем «мягкую» 404: когда несуществующая страница отдаёт код 200 и показывает текст «страница не найдена». Для поисковика это полноценная страница, и таких страниц на сайте может оказаться бесконечно много — по любому выдуманному адресу.

Уровень 2: дубли и главное зеркало

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

Типичные источники дублей

• версии сайта с www и без, с http и https;
• адреса со слешем на конце и без него;
• index.php или index.html в адресе главной;
• GET-параметры: сортировки, фильтры, метки рекламных кампаний;
• страницы пагинации без корректной настройки;
• один и тот же товар в нескольких категориях с разными URL;
• версии для печати, мобильные поддомены.

Лечится это комбинацией 301-редиректов, атрибута canonical и правил в robots.txt. Важно не перестараться: закрыть от индексации фильтры, которые на самом деле собирают трафик, — тоже ошибка. Решение принимается вместе с семантикой.

Уровень 3: скорость и Core Web Vitals

Скорость загрузки влияет и на ранжирование, и — что важнее — на поведение пользователей. Если страница грузится пять секунд на мобильном интернете, значительная часть посетителей уйдёт, не дождавшись.

Мы смотрим на три ключевых показателя:

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

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

Уровень 4: мобильная версия

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

• Весь значимый контент доступен на мобильном — не вырезан «для краткости».
• Текст читается без масштабирования, кнопки удобно нажимать пальцем.
• Нет горизонтальной прокрутки.
• Всплывающие окна не перекрывают контент сразу после загрузки.
• Формы заявки работают и не требуют ювелирной точности.

Мы всегда проверяем мобильную версию руками на реальных устройствах, а не только в эмуляторе. Эмулятор не покажет, как сайт ведёт себя на медленном соединении в метро.

Уровни 5 и 6: структура и тонкие настройки

Карта сайта и структура

• Файл sitemap.xml существует, доступен и указан в robots.txt.
• В карте только индексируемые страницы с кодом 200 — без редиректов, 404 и закрытых адресов.
• Карта обновляется автоматически при добавлении страниц.
• Нет «сирот» — страниц, на которые не ведёт ни одна внутренняя ссылка.
• Важные страницы находятся не глубже трёх-четырёх кликов от главной.

Всё остальное

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

• корректность микроразметки;
• настройка hreflang для мультиязычных сайтов;
• смешанный контент на HTTPS;
• оптимизация рендеринга JavaScript;
• анализ логов сервера — как часто и какие страницы обходит робот;
• битые внешние ссылки, устаревшие ресурсы.

Это тоже важно, но если сайт отдаёт ошибки сервера или наполовину состоит из дублей, разметка FAQ ничего не изменит.

Как превратить аудит в результат

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

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

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

Инструменты: чем мы проверяем

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

• Панели вебмастеров поисковых систем. Единственный источник данных «из первых рук»: что в индексе, какие ошибки видит робот, есть ли санкции. С них начинается любая проверка.
• Краулер. Программа, которая обходит сайт как поисковый бот и собирает коды ответа, теги, canonical, глубину вложенности и внутренние ссылки.
• Инструменты оценки скорости. Показывают не только итоговую оценку, но и конкретные ресурсы, которые тормозят загрузку.
• Браузер и реальные устройства. Режим разработчика, просмотр исходного кода, проверка с отключённым JavaScript и тест на нескольких телефонах.
• Логи сервера. Для крупных сайтов — чтобы понять, какие разделы робот обходит часто, а до каких почти не добирается.

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

Вывод

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

Проверять сайт стоит не только перед стартом продвижения, но и после каждого релиза, редизайна или переезда на новую CMS — именно в эти моменты чаще всего что-то ломается. Если хотите получить не отчёт ради отчёта, а план с приоритетами, закажите аудит сайта у нашей команды.