SEO-аудит: что проверять в 2025
SEO начинается с аудита. А аудит начинается со сбора данных. Никакой аудит не поможет вам в продвижении сайта, если он не основан на конкретике. Разберем, на что стоит смотреть в первую очередь.
Хостовые метрики
Прежде, чем приступать к деталям, вы должны понять, с каким ресурсом вы имеете дело: оценить хост. Поисковые системы сканируют, индексируют и оценивают сайты в зависимости от характеристик хоста. Один и тот же контент, размещённый на разных хостах, будет оцениваться по-разному: то, что здесь пулей влетит в топы, там в лучшем случае займёт гордую позицию в топ-30+ где-нибудь через месяц.
На что смотреть:
Возраст домена. Домены-новореги возрастом до года, как правило, ещё не накопили данных по взаимодействию с пользователями, запросный индекс, возможно, они попросту даже не проиндексированы в полном объёме. Исключения тут бывают: если, например, домен принадлежит большому и популярному бренду уровня «Леруа-Мерлен» или «Тинькофф».
История домена. Обрывочная информация о пользе дропов (брошенных или перехваченных доменов) приводит к тому, что владельцы сайтов умудряются покупать домены с дурной историей и под фильтрами. Чаще всего речь идёт об обычном мусоре, но стоит убедиться, что сайт точно ничего дурного не унаследовал из времен динозавров.
Расположение сервера. Юридически все ресурсы, используемые хостом, хоть как-то обрабатывающим персональные данные, должны находиться в России. Помимо этого, физическое расположение сервера может влиять на множество других параметров (привязку к региону, техническое быстродействие и т.п.).
Индексирование. Надо сопоставить, какой объём страниц реально открыт для индексирования, а что уже есть в индексе. Существенная разница в этих показателях может означать, что у сайта есть технические проблемы, либо проблемы с контентом, если речь не о новом сайте.
Ссылочный профиль. Чаще всего таким образом оценивают «пузомерки», не имеющие никакого отношения к реальным метрикам поисковых систем, однако ценность аудита ссылок на этом не заканчивается. Таким образом можно понять, какие страницы «накачивали» оптимизаторы, какими средствами, и оценить результаты. Нерелевантные и нецелевые страницы, напичканные внешними «денежными» ссылками, могут серьёзно усложнить раскачку целевых.
Получив первое базовое представление о пациенте, можно приступать к оценке его физического состояния.
Серверные логи access_log
Серверные логи нужны, чтобы понять, как часто, с чем именно и как взаимодействуют поисковые роботы на вашем сайте. Это журнал посещений, где фиксируется, когда именно тот или иной поисковый робот зашёл на сайт, что ему на запрос ответил сервер, какой объём информации был предоставлен, куда робот перешёл дальше.
В зависимости от того, какой объём данных у вас под рукой, вы можете получить как очень общие представления о взаимодействии роботов с вашим сайтом, так и выявить какие-то общие шаблоны и тренды. В зависимости от объёмов серверных логов и доступа к архивам, речь может идти как о сотне адресов, так и о десятках гигабайт данных.
С моей точки зрения, наиболее важно понять следующие моменты:
Имеют ли поисковые роботы доступ к важнейшим страницам вашего сайта? Вполне может оказаться, что сервер по каким-то причинам блокирует отдельные UA вообще, и в результате люди получают полный доступ, а поисковые роботы – нет.
Отдаёт ли сервер информацию в полном объёме? Бывает так, что под нагрузкой сервер начинает отдавать либо пустые странички с кодом 200 (доступно), либо очень сильно «облегченные» (не хватает каких-то важных блоков). Это – ошибки софт-404, и я бы отнёс их к одной из самых серьёзных технических проблем.
Стабильность работы сервера. Может оказаться, что в какие-то моменты, регулярно воспроизводимые, сервер не может справиться с нагрузкой вообще, и поисковые роботы получают ошибки 500. На больших объёмах это может крайне негативно сказаться на процессах сканирования и индексирования сайта, что закономерно скажется и на ранжировании.
Есть ли проблемы с доступом к сайту у реальных пользователей. Недавний и всё ещё актуальный пример: пользователи Chrome не могут открыть некоторые формально доступные для других браузеров сайты, использующие ECH. Вы не увидите это из систем статистики, поскольку та же «Метрика» даже не загрузится.
Для проведения этих проверок вам понадобятся собственно серверные логи access_log и какой—то соответствующий инструмент, с помощью которого вы сможете фильтровать, сортировать и визуализировать информацию. Наиболее распространенное решение – Screaming Frog Log File Analyzer.
Оценка процессов сканирования и индексирования
Вам понадобится любой специализированный парсер уровня SFSS или SiteAnalyzer. Задача этого этапа – непосредственно воспроизвести процесс сканирования сайта с эмуляцией пользовательского агента выбранного робота конкретной поисковой системы. Наиболее полезен в этом случае набор правил Googlebot Smartphone, как наиболее нудный и последовательный. Если по сайту есть какие-то проблемы сканирования – этот набор правил выявит их с наибольшей вероятностью.
Задачи этого этапа:
Оценить, насколько легко сканируется сайт вообще. В данном случае ваш парсер выступает как эмулятор реального поискового краулера. Если сервер «прилёг» или вы получили слишком много URL без ответа на самых щадящих настройках парсинга – вы попросту не получите никаких данных, и это уже сам по себе диагноз для технических характеристик сайта. Точно такие же проблемы могут быть и у поисковика.
Проверить настройки индексирования: директивы по сканированию для роботов в robots.txt, список URL, подаваемых как канонические из sitemap.xml, собственно канонические адреса, редиректы, мета robots с директивами по индексированию, и т.п. Список ошибок, которые могут быть выявлены на этом этапе, слишком велик и причудлив. Ваша задача – убедиться, что все важные страницы и разделы действительно доступны для краулеров и открыты для индексирования.
Проверить внутреннюю перелинковку и пагинацию. Что бы у вас ни было указано в канонических адресах, поисковая система может это проигнорировать. Например, потому, что неканоническая страница имеет больше входящих ссылок. Надо убедиться, что канонические страницы – самые весомые. При этом надо проверить и фактическую доступность для робота-краулера: часто бывает, что коммерчески значимый раздел доступен по одной-двум дохленьким ссылкам, глубоко прикопанным в структуре, и добраться до них робот не может.
Проверки рендеринга JS. Нужно убедиться, что поисковые роботы могут в полном объёме получить весь важный контент, выводится ли он средствами HTML или потом добавляется средствами javascript. Критически важная информация должна выводиться сразу, на уровне HTML. Убедитесь, что средствами JS выводится только второстепенная и вспомогательная информация, не способная слишком глобально изменить контент страницы. Да, сейчас сканирование страницы и рендеринг – это почти параллельные процессы, идущие с минимальной разницей по времени. Но гарантий – нет, и лучше не рисковать.
Технические оценки контента
На этой стадии вам необходимо понять, каков объём на сайте чисто технически проблемного контента и характер этих проблем. На что смотреть:
Технические дубли: страницы с идентичным контентом, доступным по разным URL. Обычная история для коммерческих каталогов, при правильном подходе не оказывающая негативного влияния. Но бывают совсем причудливые случаи (например, маркетологи для удобства вшивают в меню или внутренние ссылки UTM-метки, не заботясь о склеивании дублей и консолидации сигналов).
Нечеткие дубли с совпадением контента (условно – от 90%). Чаще всего речь идёт о товарных карточках, где вся разница – артикул, цена, отдельные характеристики товара. Поисковая система без вспомогательных средств не поймёт, что это разные карточки и склеит их, или в качестве ранжируемой выберет не целевую страницу, а ту, где этот товар упоминается в числе прочих.
Страницы с малым объёмом контента. Сам по себе объём текста в зоне main content ничего не говорит о качестве страницы: это может быть страница, полностью отвечающая на запрос посетителя в полном объёме. Но гораздо чаще речь о страницах, не содержащих полезный контент.
Быстродействие
Я крайне редко использую сервисы, оценивающие быстродействие сайта, если речь идёт о каких-то абстрактных чек-листах уровня Google Speed Insight. Они, безусловно, небесполезны, но и не слишком информативны.
На этой стадии вам важно оценить скорость загрузки вашего сайта из целевых локаций, количество запросов, отправляемых к серверу, время ответа, процесс формирования DOM и скорость рендеринга.
Для получения данных вам понадобится сервис уровня express.loading или webpagetest.org.
Оценка семантической структуры
SEO-аудит не имеет смысла без анализа структуры сайта и семантики. Нужно понимать, по каким запросам сайт должен привлекать лиды и почему он не ранжируется или ранжируется недостаточно высоко. Для этого необходимы данные: карта ключевых слов, типовая структура сайта и семантическое ядро с кластерами запросов. И разумеется – общие данные по актуальной видимости сайта по запросам в поиске.
Оценку семантики я рекомендую делать только и исключительно на данных и требованиях Яндекс, если речь идёт о коммерческом сайте, продвигаемом в рамках рунет на русском языке.
Какие минимальные данные вам понадобятся:
Данные по запросам из систем статистики самого Яндекса («Вордстат» и «Директ»)
Поисковая выдача по этим запросам (для кластеризации и оценки конкурентной среды)
Видимость сайта по целевым запросам, включая информацию по ранжируемым и релевантным ключевым словам
Оценка основных конкурентов: их видимость в поиске, по каким запросам они получают поисковый трафик, как сформирована структура их сайтов
Текстовый анализ целевых посадочных страниц анализируемого сайта в сравнении с конкурентами и медианными данными по топу выдачи
Иными словами, вы должны понимать, как формулируют поисковые запросы потенциальные клиенты, что должна содержать целевая посадочная страница, соответствующая запросам клиентов, и чего именно не хватает анализируемой посадочной странице. Как правило, проблемы здесь достаточно типовые и систематизируемые:
- Словарный состав, не соответствующий типовой разметке для заданной ниши (Яндекс не понимает, что вы продаёте, или попросту фильтрует страницу за спамность)
Недостаточный ассортимент (в топе – каталоги с тысячей товаров и несколькими десятками подкатегорий, у вас – одна посадочная страница и пяток товарных позиций)
Неразвёрнутая презентация ассортимента (у вас достаточный объём товаров, но отсутствуют ожидаемые поисковиком подкатегории, срезы, подборки, коллекции)
В вашей товарной презентации представлены вовсе не те семантические срезы, что ищут люди, или вы используете терминологию, которой аудитория реально не пользуется
и т.п.
Недочёты такого рода Яндекс может простить своим сервисам, партнёрам и маркетплейсам с гигантскими объёмами брендового трафика, в любом другом случае наличие любой из этих проблем обнулит любые накрутки ПФ, ссылки, тайтлы в стихах и 100 зеленых попугаев по GSI. На данных такого рода Яндекс оценивает коммерческий потенциал как главную характеристику коммерческого ресурса. Отклонения возможны, если соблюден ряд некоторых условий (несформированная ниша, малая конкуренция, высокий тайпин – потому что в вашей нише вы один из немногих реальных лидеров), но рассчитывать на это не стоит.
Текстовый аудит
Так сложилось, что понятие «поисковый запрос» по какой-то причине принято подменять понятием «ключевые слова». Это определяет и соответствующий подход к работе с семантикой.
Ключевые слова – это те слова, которые предельно точно и кратко описывают содержание документа. Они могут содержаться в поисковых запросах – а могут и отсутствовать в них.
На следующей стадии аудита нужно понять, какие ключевые слова должны присутствовать на посадочной странице, соответствующей какому-то кластеру поисковых запросов.
Способы, используемые для этого, не меняются с самого начала развития SEO: вы анализируете поисковые запросы, страницы конкурентов, в данный момент занимающие топ поисковой выдачи, и ищете закономерности.
Хороший текстовый анализатор подразумевает возможность оценки n-грамм (достаточно однословников и двухсловников) по основным зонам (метатеги, заголовки, сквозные блоки, ссылочные анкоры, шинглы, текстовый блок) и возможность оценить медианные показатели. В качестве хорошего примера приведу SEOLemma, включая лайт-версию. Задаёте поисковый запрос (или целый кластер – в зависимости от версии), анализируемый URL, фильтруете сайты из сравнения и получаете наглядную статистику: здесь у нас – отсутствующие ключевики (и связанный с ними контент), здесь у нас перебор по сущностям, которые не нужны и неважны, а вот тут мы явно не добираем по ассортименту.
Однако как быть, если сайт вполне укладывается в медианную статистику, но есть проблемы с ранжированием или (и) конверсиями? На помощь приходят средства семантического аудита.
Аудит семантики
Не стоит путать исследование ключевых слов с семантическим анализом. Семантика исследует смысл текста, а не количество и характер лексических единиц, представленных на странице. Несмотря на обилие каких-то ключевых слов на странице смысл страницы может им соответствовать лишь частично или не соответствовать вовсе. Поисковые системы активно используют семантические алгоритмы, способные оценить фактическую релевантность запросу, и отфильтровать откровенный текстовый спам.
Кроме того, поисковые системы прекрасно знают, что именно пытаются узнать и сделать на сайте типовые посетители, конвертирующиеся в покупателей. Контент посадочной страницы и сайта в целом должен соответствовать этим запросам.
Проблема в данном случае состоит в том, что SEO чаще занимается сторонний специалист или агентство с чеклистом, очень приблизительно понимающее бизнес клиента, а наибольшее внимание уделяется средней температуре по больнице. Для эффективного аудита семантики сайта совершенно необходимо понимать, что и кому продаёт сайт, а также в чём УТП (уникальное торговое предложение) данной компании.
Если вы проводите аудит проекта, есть способы в какой-то мере решить эту задачу.
Оцените историю запросов страниц конкурентов из топа выдачи по анализируемому запросу и найдите те запросы, по которым они видны, а ваш сайт – нет.
Попробуйте получить ответы от специалистов отдела продаж: что спрашивают клиенты? Что они собой представляют?
Проанализируйте связанные запросы (известные как PAA) и отберите те, что могут иметь прямое отношение к целевой аудитории.
Полученный список используйте для оценки контента страницы, чтобы понять, содержит ли этот контент внятные ответы на эти запросы. Сделать это можно множеством способов, от самых простых до математических.
К простым способам можно отнести «способ бабушки»: откройте на смартфоне анализируемую страницу и попросите человека со стороны найти ответ на странице по своему списку. Разумеется, вручную таким образом вы не сможете оценить много посадочных страниц, но ошибки шаблонизируются.
Используйте векторные вложения (эмбеддинги). Если вы используете LLM не только для генерации ненужных текстов, то, возможно, вы уже создали базу данных, содержащую векторизованный контент вашего сайта. Далее – подать на вход векторные вложения запросов по списку, и обнаружить наиболее релевантные фрагменты на сайте. Оцените, находятся ли эти фрагменты там, где нужно, и достаточен ли объём контента для полноценного ответа.
Выборочный анализ с использованием чат-ботов: отдайте на вход чат-боту файл с контентом и попросите определить, соответствует ли этот контент списку ваших запросов. Если нет – пусть создаст соответствующий контент и оптимизирует существующий. LLM справляются с этим достаточно эффективно, и помимо анализа вы сразу получите контент для корректировок вместо абстрактных цифр.
Учитывайте, что «способ бабушки» не может воспроизвести уровень подготовки реальной целевой аудитории: тестер не знает, куда смотреть и может плохо понимать смысл запроса. LLM же имеет дело с «чистым» контентом, а не его реальной презентацией для людей. То есть фактически контент может присутствовать, быть высоко-релевантным, но при этом малозаметным для аудитории, скрытым какими-то элементами вёрстки и т.п. Но это уже территория UX, которая не должна разбираться в типовом SEO-аудите.
Коммерческие метрики
Поисковые системы (и в первую очередь – Яндекс) оценивают не сайт, а стоящий за ним бизнес. За последнюю пару лет те параметры, что оцениваются в этой группе метрик, приобрели критически важное значение. Реальному бизнесу с репутацией и лояльной аудиторией Яндекс простит технические косяки, малую текстовую релевантность, проблемный ссылочный профиль и прочие недочёты веб-представления. И вместе с тем он не станет ранжировать самый быстрый, красивый и запредельно уникальный сайт компании, которую он не знает.
На что смотреть в первую очередь:
Наличие брендового «колдунщика» по брендовым запросам. Он формируется из информации, почерпнутой из Яндекс-Карт и Яндекс-Бизнес. Выводится не по любому запросу, так что тут ещё придётся найти соответствующие.
Присвоенные Яндекс-сервисами категории. Проблема с ними в том, что выбирает их не Яндекс, а владелец учётки, и выбрать их он может неправильно. А это значит, что учётная запись может не соответствовать требованиям к заданной категории.
Рейтинги в Яндекс-картах, Яндекс-браузере на сайт и т.п. Этот фактор всё сильнее влияет на ранжирование по коммерческим запросам, и если рейтинг плохой – перебить его можно некоторыми другими метриками, но лучше бы его всё же улучшить.
Оценка входящего трафика
Для аудита трафика вам понадобятся Яндекс-Метрика и Яндекс-Вебмастер. Задачи:
Понять, насколько реальный трафик получает сайт, крутят ли ПФ в этой и смежных нишах, на каких объёмах и по каким запросам
Оценить, привлекает ли ваш сайт целевую с точки зрения Яндекса аудиторию
Второй момент я считаю более важным, чем попытки выследить злонамеренных конкурентов-накрутчиков. Главная коммерческая метрика – это конверсионность, способность сайта продавать. Для оценки трафика Яндекс использует две метрики: «Роботы» (те посетители, кого он однозначно отфильтровал из учёта) и «Роботность» (люди, не соответствующие ожидаемому профилю и напоминающие поведенческих ботов). Если сайт привлекает нецелевую аудиторию – вероятно, с ним что-то не так. Как минимум, на персонализации он будет показан преимущественно такой же нецелевой аудитории, и надо разбираться в причинах.
Итоги
Собрав всю необходимую информацию, можно делать какие-то выводы и определять точки роста. К этому моменту вы уже должны получить чёткое представление: какие проблемы проекта решить практически нереально, а какие можно устранить в кратчайшие сроки, чтобы сайт получил устойчивый прогнозируемый рост.
Нет особого смысла составлять список всех недочётов: на любом работающем проекте обязательно будет какой-то объём ошибок, это нормально. Однако далеко не все из них влияют хоть на что-то: отсутствующие или дублирующиеся метатеги Description, пустые теги alt картинок, пара десятков битых ссылок едва ли способны на что-то повлиять для сайта объёмом более сотни страниц. Хороший тон для аудитора в этом вопросе – уточнить приоритеты по каждому пункту: не стоит запугивать пациента баном в поиске из-за «тяжёлой» картинки или ошибок валидации HTML.
Проводя аудит, придерживайтесь медицинской этики. Вы – врач, который ставит диагноз, чтобы помочь пациенту с решением серьёзных проблем. Именно для этого аудит и проводится.