Поделиться статьей
SEO-аудит сайта: 7 проверок с примерами ошибок и готовыми заданиями на исправление
SEO-аудит сайта: 7 проверок с примерами ошибок и готовыми заданиями на исправление
Семь направлений проверки сайта: от индексации и адресов до мобильной версии и доставки заявок. Примеры ошибок и критерии приёмки работ.
После обновления сайта упал трафик. В отчёте сканера — сотни предупреждений. Начните с пяти страниц, которые важны для продаж: категории, услуги, популярного товара и двух URL с заметным падением переходов. Для каждой проверьте доступность в поиске, адрес, содержание и отправку заявки.
Ниже — семь проверок по схеме «симптом → действие → исправление → приёмка». Примеры ситуаций учебные: они показывают порядок диагностики и не являются результатами аудита конкретного клиента.
1. Страница открывается, но исчезла из поиска
Где проверить. Откройте проблемный адрес в инструменте проверки URL Google Search Console и в анализе страницы Яндекс Вебмастера. Сопоставьте состояние последней известной поисковику версии с текущей доступностью. Затем проверьте исходный HTML и HTTP-заголовки.
Ищите ограничение индексации, например:
Или заголовок:
Такое правило могло остаться после разработки. Проверять нужно конкретный URL: наличие разрешения на главной не доказывает, что оно есть во всём каталоге.
Что исправить. Если страница должна участвовать в поиске, уберите случайный запрет в том месте, где он формируется: шаблоне, настройках CMS или конфигурации ответа сервера. Сохраните необходимые ограничения для служебных страниц.
Как принять. На целевых URL запрета больше нет; страница доступна роботу; изменение проверено на нескольких страницах того же шаблона. Факт возвращения в индекс отслеживайте отдельно — он не наступает автоматически в момент исправления.
Запрет обхода в robots.txt не заменяет noindex. Если Googlebot не может обойти страницу, он может не увидеть директиву noindex. Подробности — в документации Google.
2. После редизайна старые ссылки ведут на ошибку или главную
Где проверить. Возьмите адреса из прежнего sitemap, выгрузки поисковых переходов и карты миграции. Для каждого зафиксируйте код ответа и конечную страницу после перенаправлений.
Что исправить. Если новая страница действительно заменяет старую, настройте постоянное перенаправление на соответствующий адрес. Для Nginx правило для точного пути может выглядеть так:
Это пример для разработчика: правило применяют с учётом конфигурации проекта, сначала проверяют синтаксис и конфликтующие маршруты. URL назначения должен существовать и соответствовать прежнему содержанию.
Как принять. Старый адрес одним перенаправлением приводит на нужную действующую страницу; новые внутренние ссылки и sitemap используют новый URL. Проверьте, нет ли цикла и цепочки из нескольких редиректов.
Если материал удалён без замены, ответ 404 или 410 может быть корректным. Не перенаправляйте все удалённые товары на главную ради отсутствия ошибок в отчёте. О временных колебаниях при переносе и подготовке соответствий URL — в руководстве Google по миграции.
3. Поисковик выбирает не ту версию страницы
Где проверить. Посмотрите canonical в HTML и основной адрес, выбранный Google в Search Console. Сверьте с sitemap и внутренними ссылками.
Для основного адреса сигнал может выглядеть так:
Что исправить. Согласуйте сигналы: основная страница, ссылки и sitemap должны указывать на выбранную рабочую версию. Дублирующие варианты должны корректно сообщать о ней. Не назначайте canonical на страницу с другим содержанием только потому, что хотите продвигать её сильнее.
Как принять. На проверяемых URL нет противоречивых canonical; основной адрес доступен и содержит нужный материал; внутренние ссылки исправлены. Выбор поисковой системы проверяется после повторного обхода.
Canonical — сигнал предпочтения, а не команда с гарантированным исполнением. Google может выбрать другой адрес; порядок диагностики описан в справке о канонических URL.
4. Услуга есть у компании, но под неё нет подходящей страницы
Где проверить. Сопоставьте приоритетные услуги со спросом и существующими URL. По каждой группе запросов посмотрите состав выдачи: коммерческие предложения, каталоги или информационные материалы.
| Группа запросов | Задача посетителя | Что проверить на посадочной странице |
|---|---|---|
| Окна для загородного дома | Подобрать и заказать решение | Варианты конструкций, ограничения, примеры объектов, расчёт |
| Стоимость замены окон | Понять состав бюджета | Комплектация, состав работ, возможные доплаты |
| Как выбрать стеклопакет | Разобраться в различиях | Сравнение по критериям, подтверждённые характеристики |
Что исправить. Создайте или переработайте страницу под конкретную задачу. Для коммерческого запроса подготовьте предложение с условиями заказа; для сравнения — материал, который помогает выбрать между вариантами.
Как принять. У группы запросов есть целевой URL, его содержание отвечает намерению посетителя, на него ведут понятные внутренние ссылки. Новая страница не дублирует уже существующее предложение без причины.
Задание редактору: «Для страницы остекления загородных домов подготовить варианты конструкций, ограничения применения, три примера выполненных объектов при наличии подтверждённых материалов и перечень данных для расчёта. Характеристики согласовать с техническим специалистом». Это определяет результат точнее, чем «написать SEO-текст на 5 000 знаков».
5. Посетители приходят, но не понимают предложение
Где проверить. Сопоставьте страницу с вопросами менеджерам и причинами отказов. Откройте её на телефоне и найдите ответы без обращения в компанию.
Что исправить. Раскройте состав предложения. Для условной услуги это может быть таблица:
| Работа | Как показать условие |
|---|---|
| Замер | Указать действующий порядок и условия оплаты |
| Демонтаж | Объяснить, включён ли он в расчёт |
| Монтаж | Указать, что входит в работу и материалы |
| Дополнительная отделка | Перечислить, что рассчитывается отдельно |
| Итоговая стоимость | Объяснить, какие данные нужны для точного предложения |
Не переносите условия из примера на сайт без согласования с бизнесом. Если цена зависит от объекта, покажите расчёт на конкретной комплектации и перечислите его ограничения.
Как принять. Менеджер подтверждает условия; посетитель видит состав предложения до формы; рекламное обещание и реальный расчёт не противоречат друг другу. Эффект на качество обращений оценивают после накопления сопоставимых данных.
6. Форма сообщает об успехе, но заявка не приходит
Где проверить. Согласуйте тест с командой. Отправьте помеченную тестовую заявку и проследите путь: браузер → сервер → CRM или уведомление → ответственный менеджер. Сопоставьте время отправки, идентификатор обращения и запись в системе.
Проверьте два сценария: успешную отправку и контролируемую ошибку на тестовом окружении. При ошибке пользователь не должен видеть ложное сообщение «заявка отправлена».
Что исправить. Если цель аналитики привязана только к нажатию кнопки, перенесите фиксацию успешной заявки на подтверждённый результат обработки. Если уведомление теряется, исправьте интеграцию и предусмотрите сохранение обращения, чтобы сбой доставки не уничтожил данные.
Как принять. Тестовое обращение сохранено и доступно ответственному; событие успеха соответствует успешной обработке; повторный клик не создаёт непреднамеренные дубли; ошибка понятна пользователю.
Кнопка мессенджера требует отдельной цели: переход в мессенджер ещё не равен полученному обращению.
7. На телефоне страница мешает читать и обращаться
Где проверить. Пройдите путь на реальном телефоне: открыть страницу, прочитать условия, перейти к форме, заполнить поля, исправить ошибку. Дополнительно проверьте узкую ширину 320–390 пикселей в браузере.
Что исправить. Для широкой таблицы используйте прокрутку внутри контейнера, не всей страницы. Для формы — постоянные подписи полей, понятные сообщения ошибок и доступную кнопку. Для изображений — заданные размеры, чтобы загрузка не сдвигала соседний контент.
Скорость измеряйте на типовых страницах. Ориентиры Core Web Vitals: LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1 на 75-м процентиле загрузок с разделением по устройствам. Определения — в документации Web Vitals.
Как принять. Страница не имеет случайной горизонтальной прокрутки; таблица доступна целиком; форма работает с экранной клавиатурой; ошибки можно исправить. Лабораторный балл скорости и данные реальных посетителей фиксируются отдельно. Зелёный балл сам по себе не гарантирует рост позиций.
Как превратить находки в задания на неделю
Не ставьте разработчику задачу «исправить техническое SEO». Одна задача должна содержать конкретные адреса, найденную причину, изменение и проверку результата.
| Задача | Ответственный | Критерий приёмки |
|---|---|---|
| Убрать случайный noindex на страницах услуг | Разработчик; проверяет SEO-специалист | Запрет отсутствует на согласованных URL, остальные ограничения сохранены |
| Восстановить переходы со старых адресов | Разработчик | Карта редиректов отрабатывает без циклов и лишних переходов |
| Уточнить состав услуги | Редактор и менеджер продукта | Условия опубликованы и соответствуют реальному предложению |
| Исправить доставку заявок | Разработчик и ответственный за CRM | Помеченный тест проходит весь путь до менеджера |
Сначала устраняйте подтверждённые проблемы, которые блокируют важные страницы или обращения. Затем беритесь за структуру и содержание приоритетных направлений. Замечания, не связанные с текущей задачей, сохраняйте в отдельном списке с объяснением их значимости.
Что запросить в результате SEO-аудита
Для каждой находки нужны URL, доказательство, масштаб, приоритет, ответственный и критерий приёмки. Если причина пока предполагается, она должна быть обозначена как гипотеза.
После внедрения повторите технические проверки. Динамику индексации, кликов и целевых обращений отслеживайте отдельно: эти показатели меняются с разной скоростью и зависят не только от исправлений.
Заказать SEO-аудит в ЭНТЕРНО. Для постановки задачи пришлите адрес сайта, пять приоритетных страниц и дату, когда заметили проблему. Если предстоит переезд или редизайн, укажите планируемую дату запуска — проверку адресов и структуры лучше провести до него.