Почему сайт не растёт в поиске: SEO-диагностика

Почему сайт не растёт в поиске

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

SEO-диагностика строится на данных Яндекс Вебмастера, сервис Google Search Console, аналитики, серверных логов и самого сайта. Мы фиксируем период, сегментируем данные и проверяем гипотезы по очереди. Результатом становится не список общих советов, а таблица причин, доказательств, приоритета и способа повторной проверки.

Определяем, где остановился рост

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

Основные сценарии различаются:

• показы снизились — проверяем спрос, индексирование, релевантность и позиции;
• показы стабильны, кликов меньше — изучаем позицию, сниппет и состав выдачи;
• клики сохранились, обращений меньше — проверяем страницу, аналитику и бизнес-условия;
• новые страницы не получают показов — изучаем обход, статус URL, дубли и соответствие запросу;
• позиции колеблются — сравниваем запросы, конкурентов, географию и даты изменений.

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

Сводная таблица строится по неделям и содержит показы, клики, среднюю позицию, целевые визиты и долю URL с выбранным статусом. Для каждого падения отмечаем дату релиза, сбоя, переноса, изменения ассортимента или поискового спроса. Так мы отделяем совпадение по времени от возможной причинной связи.

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

Спрос, сезонность и изменение выдачи

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

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

Обход и индексирование

Для важных URL проверяем ответ сервера, robots.txt, meta robots, canonical, sitemap и доступность основного содержания в формат HTML. Затем смотрим статус страницы в поисковых панелях и обращения робота в логах. Код 200 означает доступность документа, но сам по себе не гарантирует его включение в поиск.

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

• не закрыта ли страница от обхода или индексирования;
• не указывает ли canonical на другой документ;
• нет ли редиректа, 404, soft 404, 5xx или пустого ответа;
• присутствует ли URL во внутренних ссылках и sitemap;
• не создан ли близкий дубль параметром, городом или фильтром;
• видит ли робот тот же основной текст, что и пользователь.

После исправления отправляем ограниченную тестовую группу на переобход и ждём обработки. Массовая отправка адресов не заменяет устранение причины.

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

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

Релевантность и качество посадочной страницы

Страница должна отвечать намерению запроса. Для коммерческого спроса обычно важны услуга или товар, условия выбора, цена либо порядок расчёта, подтверждения компетенции и понятное действие. Информационная статья решает другую задачу. Если оба документа оптимизированы под один кластер, поисковая система может менять выбранный URL.

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

Отдельно проверяем заголовок H1, title, description и первый экран. Они должны ясно называть предмет страницы. Несовпадение обещания в сниппете и содержания повышает риск нецелевого перехода.

Каннибализация запросов

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

Строим таблицу «кластер → целевой URL → конкурирующие URL». Затем выбираем действие:

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

Решение принимаем по данным, а не по сходству двух title. После изменения отслеживаем выбранный поиском URL, показы и запросы.

Технические и шаблонные ограничения

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

Важный контент должен быть доступен без действия, которое поисковый робот не выполняет. Скрытие текста в интерфейсе само по себе не всегда проблема, но его отсутствие в полученном формат HTML или зависимость от ошибочного запроса API требует проверки.

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

Контент, доверие и коммерческие сведения

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

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

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

Внешние ссылки и нарушения

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

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

Не предлагаем покупать ссылки ради восстановления графика. Сначала исправляем источник проблемы и определяем, нужны ли публикации, партнёрские упоминания или цифровой PR для реальной аудитории.

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

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

Приоритеты и тестовый план

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

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

Одновременная смена структуры, текстов, ссылок и дизайна затрудняет вывод. Журнал релизов помогает связать наблюдение с конкретным изменением и не приписывать результат последнему действию без доказательств.

Что получает заказчик

На выходе передаём карту симптомов и причин, выгрузку затронутых страниц, сравнение с выдачей, технические проверки, матрицу запросов и URL, приоритетный backlog и задания для разработчика, редактора и SEO-специалиста. Для каждой задачи указываем способ приёмки.

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

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

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

Работа завершается не презентацией, а контролем внедрения. Проверяем production-страницы, коды ответа, метаданные, видимый текст, события аналитики и журнал релиза. Только после этого начинается измерение эффекта. Если команда заказчика внедряет рекомендации самостоятельно, предоставляем критерии приёмки и выборку URL для теста.

Финальный backlog делим по исполнителям и зависимостям. Редактор не начинает переписывание, пока не определён целевой запрос и канонический адрес; разработчик не закрывает параметр, пока не проверены внутренние ссылки; аналитик не сравнивает конверсию, пока событие не прошло тест. Такой порядок сокращает повторные правки и сохраняет воспроизводимость результата.

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