Semrush Site Audit: как запустить и что исправлять первым

Что такое Semrush Site Audit и чего он не покажет

Site Audit — модуль Semrush, который обходит сайт так, как это делает поисковый робот: переходит по ссылкам, смотрит коды ответа, заголовки, мета-теги, редиректы, canonical и карту сайта. Результат — отчёт с проблемами и сводная оценка «здоровья» сайта.

Важно понимать границу. Инструмент видит сайт изнутри, но не знает, как его на самом деле проиндексировал Google. Поэтому выводы аудита нужно сверять с Google Search Console: какие страницы в индексе, какие исключены и почему. Аудит отвечает на вопрос «что на сайте не так технически», а не «почему упали заявки». Для второго вопроса нужны ещё данные о запросах, поведении посетителей и конкурентах.

Настройка проверки: пошагово

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

• Создайте проект и выберите область: весь домен, поддомен или папка. Если магазин на основном домене, а блог на поддомене, проверяйте их отдельно — так проще читать результаты и назначать исполнителей.
• Выберите источник адресов: обход по ссылкам, карта сайта или готовый список URL. Для первого знакомства подходит обход, для контроля после правок — список ключевых страниц.
• Задайте лимит страниц. Для большого каталога охватите основные разделы или проверяйте сайт по частям, а не одним проходом.
• Выберите тип робота. Для большинства сайтов разумнее мобильный: Google оценивает сайты именно так.
• Исключите маской адреса фильтров, сортировок и внутреннего поиска — иначе тысячи почти одинаковых URL съедят лимит.
• Если сайт закрыт паролем или находится на тестовом домене, настройте авторизацию. Если его защищает хостинг от ботов, добавьте сканер в разрешённые.
• Включите проверку по расписанию, чтобы сравнивать отчёты между собой.

Как читать отчёт: ошибки, предупреждения, замечания

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

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

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

Что исправлять первым

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

• Страницы с ответами 4xx и 5xx, на которые ведут внутренние ссылки, включая ссылки из меню и карточек товаров.
• Цепочки и циклы редиректов, особенно после смены адресов или перехода на новую CMS.
• Ошибки HTTPS и смешанный контент: когда страница открыта по защищённому адресу, а часть ресурсов грузится по обычному.
• Нужные разделы, закрытые от индексации по ошибке: noindex или запрет в robots.txt, оставшиеся с этапа разработки.
• Дубли title и description на важных страницах — категориях, услугах, карточках.
• Неверный canonical, который указывает на несуществующий или закрытый адрес.
• Страницы-сироты, на которые нет ни одной внутренней ссылки.

Что можно отложить

Есть пункты, которые выглядят тревожно, но почти не влияют на трафик. Их стоит делать в последнюю очередь или вовсе не делать:

• слишком длинный или короткий title на служебных страницах;
• низкое соотношение текста и кода;
• отсутствие alt у декоративных картинок;
• nofollow-ссылки на внешние сайты;
• мало текста на странице контактов — там он и не нужен.

Типичные ошибки при работе с аудитом

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

Вторая — аудит запущен на тестовой копии, а правки сделаны на рабочем сайте (или наоборот). Перед работой убедитесь, что адрес проекта совпадает с боевым.

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

Четвёртая — предупреждения о скорости берутся из лабораторных замеров. Реальную картину для пользователей смотрите в Search Console и в живом тесте с мобильного телефона на обычном мобильном интернете, а не только на офисном Wi-Fi.

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

Пример: цветочный магазин в Ташкенте

Представим небольшой сайт цветочной студии на WordPress: каталог букетов, оплата через Click и Payme, заказы дублируются в Telegram. Первый аудит показывает сотни замечаний, и кажется, что сайт в плохом состоянии.

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

Остальное — длинные title на служебных страницах и отсутствие alt у декоративных баннеров — откладывается. В итоге из пугающей таблицы получаются три задачи для разработчика, а не бесконечный список.

Как превратить отчёт в план работ и контролировать результат

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

После выкладки запустите повторную проверку и сравните её с предыдущей: модуль показывает, какие проблемы ушли, а какие появились. Это лучший способ вовремя заметить ошибки, возникшие после обновления CMS или правки шаблона. Если одна и та же ошибка возвращается, ищите причину в процессе: например, контент-менеджеры не заполняют title при создании страницы. Тогда нужна не разовая правка, а обязательное поле в шаблоне или внутреннее правило.

Чек-лист после каждой проверки: сканер не заблокирован; проект указывает на рабочий сайт; исключены фильтры и служебные адреса; найдено и закрыто всё, что мешает доступу и индексации; важные выводы сверены с Search Console; результаты записаны — что исправлено, что отложено и почему.

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