Технический аудит сайта

Анатолий Кузнецов

SEO-оптимизатор с 20-летним стажем. Автор блога hozyindachi.ru о продвижении и доработке сайтов.

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

Почему порядок важнее полноты

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

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

Шаг 1. Доступность и коды ответа

Начинаю с самого грубого: отвечает ли сервер и что именно он отвечает. Здесь важно смотреть не в браузере, а через запрос, максимально похожий на робота.

• Главная и типовые страницы каждого шаблона отдают 200 OK.
• Несуществующий адрес отдаёт 404, а не 200 с красивой картинкой. Псевдо-404 — одна из самых частых находок: сайт бесконечно плодит страницы, которые робот считает настоящими.
• Удалённые разделы отдают 410 или редирект на осмысленный аналог, а не на главную скопом.
• Все варианты домена — с www и без, http и https, со слешем и без — сведены к одному через 301. Цепочек редиректов быть не должно: каждый лишний переход теряет часть сигнала и время робота.
• Нет случайных 302 там, где переезд постоянный.
• Ответы 5xx отсутствуют даже эпизодически. Плавающие пятисотки под нагрузкой робот запоминает и снижает частоту обхода.

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

Шаг 2. Индексация: что в поиске и что должно там быть

Дальше сверяю три множества страниц: те, что есть на сайте; те, что открыты для обхода; те, что реально попали в поиск. Расхождения между ними и есть основная работа.

Смотрю в панели вебмастера разбивку по статусам исключения. «Малоценная или маловостребованная» на десятках однотипных страниц означает, что шаблон генерирует пустышки. «Дубль» массово — проблема с параметрами. «Ошибка обхода» — возвращаемся к первому шагу.

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

Шаг 3. Дубли и каноничность

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

Проверяю каноникал внимательно: он должен указывать на существующую страницу, отдающую 200, быть абсолютным и единственным. Каноникал на закрытую в robots.txt страницу — распространённая и бессмысленная конструкция: робот не может её прочитать, значит и указание не сработает.

Шаг 4. robots.txt и карта сайта

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

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

Шаг 5. Структура, ссылки и обход

Робот приходит на сайт с ограниченным бюджетом обхода. Тратить его надо на полезное.

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

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

Шаг 6. Скорость, мобильная версия и разметка

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

Мобильная проверка — это не «сайт открывается на телефоне». Смотрю, совпадает ли контент мобильной и десктопной версий, доступны ли те же ссылки, не спрятан ли важный текст, не перекрывают ли всплывающие блоки экран, удобны ли элементы для нажатия.

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

Что чинить в первую очередь

Такой порядок я закладываю в любой аудит сайта: сначала снимаем блокировки, потом устраняем размывание, потом ускоряем. Обратная последовательность встречается часто и почти всегда объясняется тем, что мелкие правки проще согласовать.

Чего делать не стоит

• Закрывать проблемные разделы в robots.txt вместо того, чтобы их починить. Запрет обхода не убирает страницу из поиска, если на неё есть ссылки.
• Ставить массовый редирект всех несуществующих адресов на главную: робот трактует это как псевдо-404.
• Одновременно применять к странице каноникал, запрет в robots.txt и noindex — сигналы противоречат друг другу.
• Удалять разделы без плана: сначала смотрим трафик и ссылки, потом решаем, что склеивать.
• Гнаться за идеальными баллами в сервисах оценки скорости в ущерб функциональности сайта.
• Проводить аудит один раз. После крупного обновления, переезда или доработки сайта проверку блокирующего уровня надо повторять.
• Считать краулер истиной: он не видит того, что подгружается скриптами, и переоценивает часть ошибок.

Частые вопросы

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

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

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

Нужно ли делать аудит перед созданием сайта? Перед созданием сайта аудировать нечего, но техтребования закладывать нужно заранее: ЧПУ-адреса, управление метатегами, каноникал, генерация карты сайта, скорость. Исправлять это потом дороже, чем предусмотреть на этапе проектирования.

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

Чеклист технического аудита

• Все зеркала склеены 301, цепочек редиректов нет.
• Несуществующие адреса отдают 404, псевдо-404 отсутствуют.
• Ошибки 5xx не фиксируются, время ответа сервера стабильно.
• robots.txt не закрывает нужное и не блокирует стили и скрипты.
• Карта сайта содержит только канонические страницы с кодом 200.
• Каноникал корректен, единственный и указывает на индексируемый адрес.
• Параметры фильтров и сортировок не плодят дубли в индексе.
• Пагинация имеет уникальные title и не дублирует текст раздела.
• Страниц-сирот и битых внутренних ссылок нет.
• Мобильная версия содержит тот же контент и те же ссылки, что десктопная.
• Микроразметка проходит валидацию и соответствует видимому контенту.
• Логи сервера проверены: робот обходит полезные разделы, а не мусор.

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

Если нужно SEO-оптимизатор Анатолий Кузнецов — помогу вывести сайт в топ Яндекса и удержать позиции.

Увеличьте позиции и продажи вашего сайта

Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:

01 Бесплатный аудит сайта 02 SEO-продвижение 03 Создание сайтов 04 SEO-статьи для сайта

Получить консультацию

Остались вопросы по продвижению?

Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.

Связаться со мной →