Site Audit в Semrush запускается за пару минут, и через полчаса у вас на руках Site Health в процентах и список из сотен проблем. Дальше начинаются сложности: какие настройки нужно было поменять до запуска, почему процент так легко поднять, ничего не исправив, и с чего начинать правки. Ниже разбор именно этого инструмента, от настройки до повторного обхода. Общий порядок технических проверок, который не зависит от сервиса, описан в нашем чеклисте технического аудита, здесь речь о том, как получить его данные из Semrush.
Что умеет Site Audit и чего не видит
Site Audit обходит ваш сайт собственным ботом и проверяет найденные страницы. По данным базы знаний Semrush, инструмент выполняет более 140 технических и on-page проверок, от битых ссылок и дублей до HTTPS и AMP (semrush.com/kb/31-site-audit, проверено 27 сентября 2026).
Важно понимать границу. Краулер видит сайт так, как его видит бот Semrush, и ничего не знает о том, что происходит в индексе поисковых систем. Сколько страниц реально проиндексировано и по каким причинам остальные исключены, показывают только Search Console и Яндекс Вебмастер. Аудит в Semrush отвечает на вопрос «что сломано на сайте», панели вебмастера отвечают на вопрос «что из этого мешает поиску», и для решений нужны оба ответа.
Вторая граница касается Яндекса. В опубликованном списке проверок Site Audit ни Яндекс, ни его директива Clean-param для robots.txt не упоминаются (semrush.com/kb/542-site-audit-issues-list, проверено 27 сентября 2026). Всё, что касается правил именно этой поисковой системы, придётся проверять отдельно.
Настройка проекта по шагам
Настройки аудита в Semrush разбиты на несколько экранов. Порядок и названия ниже взяты из инструкции Configuring Site Audit (проверено 27 сентября 2026).
Область и лимит страниц
В поле Scope указывается домен, поддомен или папка. Там же задаётся лимит страниц на один аудит. Лимит зависит от тарифа, поэтому для большого каталога его стоит проверить до запуска: обход, который упёрся в потолок, покажет только часть сайта, и выводы по нему будут неполными.
Источник страниц
Варианты в Pages to crawl: обход сайта по ссылкам, карта сайта из robots.txt, карта сайта по адресу или список адресов из файла. Для первого аудита лучше обход по ссылкам: он находит то, что реально связано перелинковкой. Обход по карте сайта полезен вторым запуском, об этом ниже.
User agent и задержка
По умолчанию Semrush обходит сайт как мобильный бот SiteAuditBot. Кроме него доступны десктопная версия и OpenAI-Search. Мобильный вариант по умолчанию разумен, индексирование давно идёт по мобильной версии. Задержку между запросами можно выбрать минимальную, одну страницу в две секунды или по правилам robots.txt. Если сайт на слабом хостинге, минимальная задержка может дать волну ошибок 5xx, которых при обычной нагрузке нет.
Разрешённые и исключённые разделы, параметры
В Allow и Disallow subfolders можно ограничить обход нужными разделами. В поле Parameters to ignore стоит сразу вписать параметры, которые не меняют содержимое страницы: метки UTM, идентификаторы сессий, параметры сортировки. Иначе аудит насчитает тысячи дублей, половина которых существует только в глазах краулера.
Обход ограничений и расписание
Если сайт закрыт паролем или защитой от ботов, в разделе обхода ограничений можно загрузить файл подтверждения, указать логин и пароль или использовать подпись Web Bot Auth. Расписание настраивается как еженедельное, ежедневное или однократное.
Настройки, которые стоит поменять перед первым запуском
Настройки по умолчанию годятся для небольшого сайта. Для остальных полезно поменять несколько вещей сразу.
- Вписать параметры для игнорирования. Это самая частая причина раздутого отчёта о дублях.
- Проверить лимит страниц относительно реального размера сайта. Если каталог больше лимита, ограничьте обход разделом и аудируйте сайт частями.
- Если на сайте тяжёлый JavaScript, проверить, включён ли рендеринг. По данным базы знаний Semrush, рендеринг JavaScript включается по выбору и доступен не на всех тарифах.
- Для сайта на слабом сервере выбрать задержку по robots.txt, чтобы аудит не превратился в нагрузочный тест.
Страницы-сироты, которые есть в карте сайта, но на которые не ведёт ни одна внутренняя ссылка, Semrush находит сам: в списке проверок есть пункт Orphaned pages (in sitemap). Обратную задачу он решает хуже. Чтобы увидеть, каких рабочих страниц не хватает в карте сайта, запустите два аудита одного сайта, по ссылкам и по карте, и сравните выгрузки. Адреса, которые нашлись только при обходе по ссылкам, и есть кандидаты на добавление в карту или на закрытие от индексации.
Как считается Site Health и почему ему не стоит верить слепо
Site Health виден первым в обзоре, и именно его обычно выносят в отчёт. По описанию Semrush (semrush.com/kb/114-total-score, проверено 27 сентября 2026), показатель строится по числу ошибок и предупреждений на обойдённых страницах. Ошибки весят больше предупреждений, уведомления влияют меньше всего.
Две детали из той же статьи меняют то, как стоит читать процент.
Во-первых, исправление всех проблем одного типа поднимает Site Health сильнее, чем исправление двух ошибок разных типов. Полностью починить битые ссылки выгоднее для процента, чем закрыть по одной проблеме в нескольких категориях.
Во-вторых, исключённые проверки перестают учитываться при расчёте на следующих обходах. То есть, спрятав неудобную категорию, вы поднимете Site Health без единой правки на сайте.
Вывод для работы с клиентом: Site Health годится как внутренний индикатор динамики, если набор проверок не меняется от обхода к обходу. Как KPI подрядчика он не годится, потому что управляется настройками. В отчёт лучше выносить конкретные цифры: сколько страниц отдают ошибку, сколько дублей, сколько сирот. Какие цифры вообще имеет смысл показывать клиенту, разобрано в статье про отчёт по SEO.
Обзор и тематические отчёты
На экране Overview, по данным базы знаний Semrush (semrush.com/kb/540-site-audit-overview, проверено 27 сентября 2026), собраны Site Health, разбивка по ошибкам и предупреждениям, виджеты о видимости для ИИ-поиска и блок Top issues. Top issues Semrush определяет как проблемы, отсортированные по приоритету и числу затронутых страниц. Для первого знакомства это хорошая отправная точка, но приоритет там общий для всех сайтов и не знает вашего бизнеса.
Тематические отчёты группируют проверки по задачам. В той же статье перечислены Robots.txt, Crawlability, HTTPS, International SEO, Performance и Internal Linking. Для практики полезнее всего три.
- Crawlability собирает то, что мешает боту добраться до страниц и понять их. С него удобно начинать, потому что проблемы обхода отрезают страницы от поиска целиком.
- Internal Linking показывает, насколько хорошо страницы связаны между собой, и выделяет проблемные. Здесь обычно находится объяснение, почему часть разделов плохо индексируется.
- International SEO проверяет hreflang. Для сайтов с русской и английской версией это один из самых частых источников ошибок, которые незаметны глазом.
Отчёт Issues: как разложить сотни строк
Все найденные проблемы собраны в отчёте Issues на трёх вкладках: Errors, Warnings и Notices. По описанию Semrush (semrush.com/kb/541-site-audit-issues-report, проверено 27 сентября 2026), у каждой проблемы есть объяснение, как её исправить, а расширенные фильтры позволяют сузить отчёт до конкретного раздела сайта.
Порядок работы, который экономит время:
- Сначала отфильтруйте отчёт по разделам. Проблема на двух служебных страницах и та же проблема на всём каталоге весят очень по-разному, а общая цифра это скрывает.
- Скройте то, что вы сознательно не будете исправлять, но записывайте, что скрыто и почему. Помните, что скрытые проблемы выпадают из расчёта Site Health.
- Для разработчиков отдавайте выгрузку по одной проблеме со списком адресов. Semrush умеет отправлять задачи в Trello, для остальных трекеров подходит выгрузка.
Что чинить первым
Деление на ошибки, предупреждения и уведомления отражает общую серьёзность проблемы. Приоритет для конкретного сайта считается иначе: сколько страниц затронуто и что эти страницы теряют. Удобно раскладывать находки аудита по той же воронке, по которой поисковая система добирается до страницы.
| Очередь | Что искать в отчётах Semrush |
|---|---|
| Сначала | Ошибки 5xx и 4xx на важных страницах, страницы, закрытые в robots.txt или noindex по ошибке, массовые дубли из-за параметров |
| Потом | Цепочки и петли редиректов, неверные канонические адреса, страницы без входящих внутренних ссылок, ошибки hreflang |
| Дальше | Скорость загрузки и тяжёлые ресурсы, дубли title и description |
| Когда дойдут руки | Большая часть уведомлений: длина заголовков, отсутствующие alt у декоративных картинок |
Чтобы быстрее находить нужное в отчёте Issues, полезно знать, как проверки называются в самом интерфейсе. Для первой очереди это Pages returning 5XX status code и Pages returning 4XX status code, Pages that were blocked from crawling и Pages blocked by X-Robots-Tag: noindex HTTP header. Для второй очереди Redirect chains and loops, Pages with a broken canonical link, Pages with multiple canonical URLs, Orphaned pages (in sitemap) и группа проверок hreflang. Названия взяты из опубликованного списка проверок Semrush (kb/542, проверено 27 сентября 2026). В английской версии интерфейса проверки называются именно так.
Перед тем как ставить задачу из первой строки, сверьтесь с панелями вебмастера. Если Semrush нашёл страницы с noindex, а Вебмастер показывает, что они и так не должны быть в индексе, задачи здесь нет. Если Вебмастер показывает исключённые страницы, которых в аудите нет вовсе, значит, краулер до них не дошёл, и разбираться надо с перелинковкой. Как отличаются причины исключения у Яндекса и Google, описано в статье Яндекс и Google.
Повторные обходы и контроль правок
Одиночный аудит показывает срез. Польза появляется со второго обхода, когда видно, что исправлено, а что появилось заново. Для этого в Site Audit есть отчёты Compare Crawls и Progress, они перечислены в базе знаний Semrush среди стандартных отчётов инструмента.
Расписание стоит привязать к циклу выпуска правок на сайте. Еженедельный обход имеет смысл, если разработчики выкатывают изменения каждую неделю. Для сайта, который меняется раз в месяц, ежедневный обход только создаёт шум и расходует лимит.
Полезная привычка: после каждого релиза запускать аудит вручную, не дожидаясь расписания. Сломанные канонические адреса или случайный noindex на шаблоне ловятся так в тот же день. По расписанию их заметили бы через неделю, когда страницы уже начали бы выпадать из индекса.
Когда одного Semrush не хватит
Для большинства сайтов Site Audit закрывает обход полностью. Есть три случая, когда нужно что-то ещё.
Очень большой сайт. Если страниц больше, чем лимит тарифа, придётся аудировать разделами или использовать отдельный десктопный краулер.
Анализ логов. Какие страницы реально посещают боты Яндекса и Google, видно только в логах сервера. Semrush их не читает.
Проект под Яндекс. Причины исключения и специфичные директивы проверяются в Вебмастере вручную.
Если Semrush вы только осваиваете, начните с материала Semrush для начинающих: там расписан порядок первой недели, где аудит стоит шестым днём. Доступ к Semrush можно посчитать в калькуляторе на главной.
Частые вопросы
Сколько проверок делает Site Audit в Semrush?
По данным базы знаний Semrush на 27 сентября 2026, более 140 технических и on-page проверок. Список конкретных проверок опубликован в той же базе знаний.
Можно ли проверить Semrush сайт, закрытый паролем?
Да. В настройках обхода ограничений можно загрузить файл подтверждения, указать логин и пароль или использовать подпись Web Bot Auth.
Почему Site Health вырос, хотя на сайте ничего не меняли?
Скорее всего, изменился набор проверок: скрытые или исключённые проверки не учитываются в расчёте. Ещё одна причина в другом лимите страниц или другом источнике обхода.
Проверяет ли Semrush требования Яндекса?
В опубликованном списке проверок Яндекс не упоминается. Специфичные для Яндекса директивы и причины исключения из индекса нужно смотреть в Яндекс Вебмастере.
Как часто запускать аудит?
С той частотой, с которой на сайт выкатываются изменения, плюс ручной запуск после каждого крупного релиза. В расписании Semrush есть ежедневный, еженедельный и однократный запуск, так что для сайта, который почти не меняется, хватит еженедельного обхода или ручного запуска раз в месяц.