SEO-аудит сайта: что проверяют и какой результат вы получите

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

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

Что согласовать до начала аудита сайта

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

• Границы. Какие домены, поддомены, языковые версии, разделы и типы страниц входят в работу.
• Приоритеты бизнеса. Какие услуги и товары компания действительно предлагает, в каких регионах и что считает полезным обращением.
• История. Когда менялись адреса, шаблоны, каталог, счётчики и условия продажи; были ли периоды недоступности.
• Данные. За какой период смотрят поиск и аналитику, какие доступы есть, какие проверки останутся недоступны.
• Результат. Нужны ли постановки задач, обсуждение с разработчиком и повторная проверка после внедрения; входят ли они в согласованный объём.

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

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

Техническая часть: доступны ли нужные страницы поисковикам

Индексация и ответы сервера

Отправная точка — список страниц, которые должны привлекать посетителей: услуги, категории, карточки и полезные материалы. Его сопоставляют с результатами обхода и сведениями поисковых систем. В Яндекс Вебмастере есть причины исключения страниц; в Search Console проверяют индексирование и конкретные URL.

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

В отчёте указывают ответы сервера, примеры URL и даты проверки. Ответ 200 означает успешный HTTP-ответ, но не гарантирует индексирование. Если вместо услуги показывается заглушка или сообщение об отсутствии страницы с таким ответом, это повод проверить обработку ошибок. Для удалённого адреса и временной неисправности нужны разные решения.

Robots.txt, noindex и Sitemap

Проверяют фактические правила в robots.txt, метатег robots и заголовок X-Robots-Tag, если он используется. Нужно найти случайные запреты на нужных страницах и понять, как обрабатываются служебные разделы. Наличие файла robots.txt само по себе ничего не говорит о правильности настройки.

Не переносите поведение одной системы на другую. Для Google robots.txt регулирует обход и не гарантирует удаления URL из поиска. Если требуется прочитать noindex, робот должен иметь доступ к странице. В Яндексе страница, закрытая в robots.txt, попадает в исключённые со статусом «Запрет в robots.txt (страница)», а в Google такой URL может остаться в выдаче без описания. Поэтому итог проверяют в данных каждой системы отдельно.

Sitemap сверяют с перечнем страниц, которые вы хотите видеть в поиске: нет ли старых адресов, ненужных дублей, редиректов и ошибок; доступны ли нужные карты. Включение URL в карту не гарантирует индексирование в Google. Поэтому совет «добавить Sitemap» должен сопровождаться проверкой его содержимого.

Результат этого блока — таблица нужных страниц и обнаруженных препятствий, а не рекомендация открыть для поиска все адреса подряд. Настройки разбираем подробнее в материале о robots.txt и sitemap.xml.

Дубли, canonical и редиректы

Дубли ищут среди вариантов домена и протокола, адресов с параметрами, сортировок, фильтров и альтернативных путей к одному материалу. Но похожие URL ещё не доказывают проблему. Важны содержание страниц, их назначение и то, какие адреса поисковик считает основными.

В Google rel=canonical — сильный сигнал о предпочтительном адресе для одинаковых или очень похожих страниц, но не безусловная команда. Закрывать дубли в robots.txt вместо canonical Google не советует: URL, запрещённый к обходу, может попасть в индекс без содержимого. В Яндекс Вебмастере такие страницы получают статус «Дубль», и справка предлагает указать основной адрес 301-м редиректом или rel="canonical". Предложение направить все страницы услуг на canonical главной требует объяснения: самостоятельные услуги не становятся дублями от общего шаблона.

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

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

HTTPS и согласованность адресов

В аудит включают проверку сертификата, открытия сайта по HTTPS, переходов с HTTP и загрузки ресурсов. Сверяют адреса во внутренних ссылках, canonical и карте сайта. Если основной вариант выбран по HTTPS, остальные настройки не должны указывать на старый вариант без понятной причины.

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

Скорость и мобильная версия: проверить рабочие сценарии

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

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

Уточните, к чему относятся полевые данные: к проверяемому URL или к сайту в целом (origin в интерфейсе сервиса). При нехватке наблюдений по странице PageSpeed Insights может показать сводные данные origin. Их нельзя выдавать за отдельное измерение выбранной услуги или карточки.

Core Web Vitals оценивают загрузку основного содержимого — LCP, отзывчивость — INP, стабильность расположения элементов — CLS. Просите связать проблемный показатель с причиной и задачей: например, проверить главное изображение, выполнение скриптов или место под поздно загружаемый блок. Один цветной балл не заменяет такого объяснения.

Google сообщает, что Core Web Vitals используются в ранжировании, но хорошие значения не гарантируют верхних позиций. Результатом аудита скорости должна быть последовательность доработок с повторным измерением.

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

• Меню открывается и позволяет перейти к нужной услуге.
• Таблицы и длинные названия читаются на узком экране.
• Фильтр применяется, результат понятен, выбор можно изменить.
• Форма доступна, ошибки объяснены, результат отправки виден.
• Уведомления и плавающие элементы не закрывают нужные действия.

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

Контент, метатеги, структура и семантика

Совпадает ли содержание с задачей посетителя

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

В рекомендациях о полезном контенте Google предлагает оценивать оригинальность и полноту ответа. Поэтому в отчёте полезно показать конкретный пробел: какое условие отсутствует, где устарели данные, какой вопрос заголовка остался без ответа. Совет «дописать SEO-текст» без темы и назначения слишком общий.

Title, description и заголовки

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

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

Вместо команды «сделать все заголовки уникальными» попросите пример исправленного шаблона и страницы, на которых его проверять. Одинаковые заголовки могут указывать на дубли, но причина бывает и в настройке вывода полей. Подробнее о формулировках — в статье о заполнении title, description и H1.

Есть ли нужные страницы и понятные связи между ними

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

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

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

Коммерческие факторы: понятно ли предложение компании

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

• Предложение. Понятно, что продаётся, кому подходит и какие есть ограничения.
• Цена. Указана актуальная стоимость либо объяснён порядок расчёта; условия на странице и при обращении согласованы.
• Контакты. Можно узнать компанию, географию работы и доступный способ связи.
• Условия. Раскрыты применимые способы оплаты, доставки или выполнения работ.
• Подтверждения. Документы, примеры работ и отзывы относятся к реальному предложению и не противоречат ему.
• Действие. Можно отправить запрос, выбрать вариант или оформить заказ по понятному сценарию.

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

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

Ссылки и инструменты: что проверяет каждый источник данных

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

Внешние ссылки оценивают по доступным данным: откуда ведут, на какие адреса, сохранилось ли соответствие после переезда. Просите объяснить основания вывода о риске. Формулировка «слабая ссылочная масса» и предложение закупить ссылки без разбора ничего не говорят о качестве диагностики.

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

Возможности сервисов описаны в справках Вебмастера и Search Console. Краулер — это программа обхода, и её предупреждения требуют интерпретации.

Поведенческие сигналы в Метрике: найти препятствие для посетителя

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

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

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

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

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

1. Выбрать страницу входа и сегмент, где возник вопрос.
2. Проверить, корректно ли считаются действия и цели.
3. Найти воспроизводимое затруднение на странице.
4. Предложить изменение и заранее определить способ проверки.

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

Что должно быть в отчёте по SEO-аудиту

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

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

Пример задачи, которую можно передать разработчику

Учебная ситуация: на страницах услуг обнаружен noindex, хотя компания хочет привлекать на них посетителей из поиска. В карточке проблемы должны быть список URL, фрагмент итогового HTML и сведения о том, где проверка подтвердила исключение. Само предположение о потере выручки доказательством не является.

Такое правило размещают в разделе <head> HTML-документа; пример из документации Google по noindex:

<meta name="robots" content="noindex">

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

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

Как расставить приоритеты

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

• Критично. Важный раздел недоступен, на нужных страницах стоит случайный запрет или не работает основной путь обращения.
• Высокий приоритет. Проблема повторяется на значимой группе: неверные canonical, ошибочный маршрут переноса, отсутствующее содержание услуг.
• Планово. Точечные уточнения метаданных, отдельных ссылок и оформления, если они не скрывают более серьёзную неисправность.

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

Как оценить качество чужого аудита: чек-лист приёмки

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

1. Понятен охват? Указаны разделы, типы страниц, доступы, период данных и ограничения.
2. Есть подтверждения? Вы можете открыть примеры и воспроизвести проверку; старые наблюдения имеют дату.
3. Разделены факт и гипотеза? Предположение о причине падения не представлено как установленная связь.
4. Учтена задача страницы? Служебные URL не предлагают открыть для индексирования только ради зелёной отметки в отчёте.
5. Есть приоритеты и задачи? Понятно, кто и что меняет, какие решения надо согласовать заранее.
6. Определена проверка? Есть критерий исправления и отдельный план наблюдения за поиском и обращениями.

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

Ошибки, из-за которых отчёт трудно использовать

• Общий балл «SEO-здоровья» заменяет разбор важных разделов.
• Выгрузка содержит предупреждения, но не показывает, какие из них являются проблемами проекта.
• Всем задачам присвоена одинаковая срочность, зависимости не описаны.
• Предлагаются массовые удаления или смена URL без оценки назначения страниц и маршрута переноса.
• Обещается конкретный рост позиций, трафика или заявок без проверяемого обоснования.
• Не указано, кто и когда повторно проверит изменённые страницы после внедрения.

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

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

Можно ли провести SEO-аудит без доступов?

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

Достаточно ли автоматической проверки сайта?

Она помогает собрать массовые данные и найти места для исследования. Затем нужно проверить назначение страниц, реальные ошибки и порядок действий. Например, одинаковый title может быть следствием настройки шаблона или дубля; решение зависит от причины, а не от самого предупреждения.

Когда аудит нужен повторно?

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

Почему после исправлений трафик сразу не вырос?

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

Как сравнить предложения на аудит?

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

Источники

Официальная документация проверена 26 октября 2026 года. Чек-лист приёмки, шкала приоритетов и учебные ситуации — рекомендации автора, а не обязательный регламент поисковых систем.

• Индексирование и диагностика — Яндекс Вебмастер, «Страницы в поиске» и «О сервисе»; Google Search Central, Get started with Search Console.
• Управление обходом и адресами — Google Search Central: Introduction to robots.txt, Learn about sitemaps, How to specify a canonical URL, Redirects and Google Search.
• Ответы сервера — Google Crawling Infrastructure, How HTTP Status Codes Affect Google's Crawlers.
• Производительность и мобильное содержание — документация PageSpeed Insights; Google Search Central, Understanding page experience и Mobile site and mobile-first indexing best practices; определения метрик — web.dev, Web Vitals.
• Содержание и ссылки — Google Search Central: Creating helpful, reliable, people-first content; Influencing your title links; Link best practices; Spam policies. Описания результатов — Control your snippets.
• Условия покупки и качество — Яндекс Вебмастер, «Недобросовестные действия» и «Отличия качественного сайта от некачественного».
• Аналитика — Яндекс Метрика, «Термины и определения»; цели — «Что такое цели».