Как провести SEO-аудит сайта: чек-лист по блокам

Зачем нужен SEO-аудит и когда его делать

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

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

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

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

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

• Корректность robots.txt — не закрыты ли случайно нужные разделы;
• Наличие и актуальность sitemap.xml;
• Код ответа сервера на ключевых страницах (не должно быть 5xx или неожиданных 3xx);
• Скорость загрузки (Core Web Vitals) на мобильных устройствах;
• Корректность настройки HTTPS и редиректов с http на https;
• Микроразметка Schema.org на страницах, где она уместна.

Отдельно стоит проверить, как сайт выглядит для робота при рендеринге JavaScript, если сайт построен на современном фреймворке. Разница между тем, что видит пользователь в браузере, и тем, что реально получает поисковый робот при обходе, — частый источник скрытых проблем, которые не видны при обычном визуальном осмотре страницы.

Индексация и дубли

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

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

Контентный блок

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

• Есть ли страницы под все приоритетные кластеры запросов, или в семантике зияют дыры;
• Нет ли двух страниц, конкурирующих за один запрос;
• Актуальны ли даты и факты в старых статьях (особенно критично для тем с быстро меняющейся информацией);
• Соответствуют ли заголовки и мета-теги реальному содержанию страниц.

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

Поведенческие и коммерческие факторы

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

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

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

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

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

Ссылочный блок

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

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

Как приоритизировать найденные проблемы

После сбора списка проблем — обычно их набирается 20–60 на среднем сайте — нужно расставить приоритеты, а не чинить всё подряд по порядку обнаружения. Рабочая матрица: влияние на трафик × сложность исправления.

Классический пример «просто и с высоким влиянием» — закрытые в robots.txt по ошибке важные разделы. Классический пример «сложно и с низким влиянием» — косметическая переработка мета-описаний у страниц с единичными визитами.

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

Как ускорить SEO-аудит через нейросети

Нейросеть эффективно берёт на себя первичную обработку больших выгрузок: анализ списка URL из краулера на признаки дублей, группировку найденных проблем по типам, черновой текст рекомендаций по каждому пункту. Финальную приоритизацию и проверку критичных находок (особенно всё, что касается индексации и технических ошибок) должен подтверждать человек — цена ошибки в аудите высокая. Общий подход к применению ИИ в SEO-задачах — в статье нейросети в SEO-оптимизации.

Хороший практический сценарий — выгрузить сырые данные из Search Console и краулера в единый файл и попросить модель составить черновую сводную таблицу находок с предварительной оценкой влияния. Человек дальше проверяет и корректирует эту оценку, опираясь на знание бизнеса и приоритетов конкретного проекта, — но сама механическая сборка разрозненных данных в единый список экономит часы ручной работы, особенно на крупных сайтах с большим числом источников данных.