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

 ·  Актуализировано в 2026 году  ·

Сайт запущен, страницы наполнены, но в поисковой выдаче их нет или видна лишь малая часть. Это не всегда технический сбой: роботы поисковых систем могут регулярно заходить на сайт и при этом сознательно не добавлять страницы в базу. Разобраться, где именно обрывается цепочка от сканирования до ранжирования, и устранить причину в правильном порядке — задача этого материала. Интерфейсы Google Search Console и Яндекс.Вебмастера периодически обновляются, поэтому названия отчётов стоит сверять с текущими панелями.

Главное

• Плохая индексация не всегда означает техническую ошибку: сайт может сканироваться, но не попадать в базу из-за дублей, слабого контента, canonical, структуры или фильтров.
• Проверку начинают не с покупки ссылок, а с robots.txt, noindex, HTTP-статусов, sitemap.xml и доступности страниц для роботов.
• Для нового сайта задержка обнаружения нормальна, но ожидание не заменяет проверку карты сайта, внутренних ссылок и настроек в панелях вебмастера.
• Порядок действий: сначала техника, затем структура и дубли, потом качество контента, скорость, внешние сигналы и возможные санкции.

С чего начать диагностику

Определите свой сценарий — это сэкономит время:

• Новый сайт и его вообще нет в поиске — читайте раздел «Новый проект не появился в поиске», затем «Технические запреты».
• Страницы пропали после редизайна или переезда — начните с раздела «Страницы пропали из поиска после индексации».
• Часть страниц есть в поиске, часть нет — переходите к разделу «Страница просканирована, но не добавлена в базу».
• Число страниц в индексе резко упало без изменений на сайте — проверьте раздел «Фильтры, безопасность и доверие», затем «Ошибки сервера».
• Сайт давно в поиске, трафик упал без явной причины — читайте раздел «Страницы пропали из поиска после индексации», затем «Фильтры, безопасность и доверие».

Плохая индексация: что именно происходит с сайтом в поиске

Сканирование, индексирование и ранжирование: три разные проблемы

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

• Сканирование — робот получает HTML-код страницы.
• Индексирование — система анализирует содержимое и решает, добавлять ли страницу в базу.
• Ранжирование — уже проиндексированная страница выдаётся по конкретному запросу.

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

Когда сайт не индексируется совсем, а когда в поиске видна только часть страниц

Полное отсутствие в поиске чаще всего вызвано директивой Disallow: / в robots.txt или тегом noindex на всех страницах — технический запрет, который не позволяет роботу даже начать обработку контента.

Частичная ситуация выглядит иначе: количество страниц в отчёте «Страницы» (Google Search Console) или «Индексирование» (Яндекс.Вебмастер) снижается без явных HTTP-ошибок. Это сигнал либо блокировки отдельных разделов, либо низкого качества контента на части страниц.

Почему страницы могут пропадать из индекса без явных ошибок в панелях вебмастера

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

Какие симптомы указывают на техническую проблему, а какие — на качество или доверие

Технические проблемы дают резкую картину: сайт полностью отсутствует в поиске, оператор site:домен возвращает ноль результатов, в панели вебмастера видны массовые ошибки сканирования или статус «Заблокировано robots.txt».

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

Проверка индексации сайта: как быстро увидеть реальную картину

Оператор site:домен: что он показывает и почему ему нельзя верить как единственному источнику

Оператор site:домен отображает только те страницы, которые поисковая система решила показать в этом конкретном срезе выдачи. Он игнорирует страницы, заблокированные через noindex, скрытые в дополнительном индексе или временно исключённые. Разрыв между числом страниц по site: и реальным количеством проиндексированных URL в Google Search Console может достигать десятков процентов. Опираться только на него при диагностике — значит видеть половину картины.

Google Search Console: какие статусы смотреть в первую очередь

• Страницы в индексе. Резкое снижение числа без технических изменений на сайте — первый сигнал для аудита.
• Просканировано, но не проиндексировано. Робот получил страницу, но система решила не добавлять её в базу. Чаще всего причина — низкая ценность контента, дубль или шаблонность.
• Обнаружено, но не проиндексировано. Google знает о URL, но ещё не сканировал страницу или отложил обход. Типично для новых сайтов с низким краулинговым приоритетом.
• Исключено из-за noindex, canonical или редиректа. Страница намеренно или случайно исключена через технические директивы — требует проверки: исключение может быть корректным (служебные страницы) или ошибочным (важные посадочные).

Яндекс.Вебмастер: где смотреть индексирование и исключённые страницы

В разделе «Индексирование» доступна статистика по страницам в поиске, исключённым URL и ошибкам обхода. Отдельно стоит проверить раздел «Проблемы» — Яндекс, в отличие от Google, явно уведомляет о наложенных фильтрах и нарушениях прямо в интерфейсе вебмастера.

Инспектор URL: как проверить конкретную страницу

Инструмент «Проверка URL» в Google Search Console и аналогичная функция в Яндекс.Вебмастере показывают статус конкретной страницы: когда она последний раз сканировалась, какой код ответа получил робот, есть ли блокировки и как выглядит отрендеренная версия. Это самый точный способ диагностировать проблему с отдельным URL — без анализа всего сайта сразу.

Анализ логов: как понять, заходят ли Googlebot и ЯндексБот

Файлы access_log сервера фиксируют каждый запрос к сайту, включая обращения поисковых роботов. При анализе журналов ищите три конкретных паттерна:

• Полное отсутствие строк с User-Agent «Googlebot» или «YandexBot» за 7 дней. Означает блокировку или нулевой приоритет домена.
• Высокая доля запросов к URL с параметрами вида ?sort=, ?page=, ?utm_. Если такие адреса составляют больше 30–40% всех обращений робота, краулинговый бюджет расходуется на мусор вместо приоритетных страниц. Это видно в логах буквально построчно.
• Ответы 5xx на запросы именно от поисковых роботов. Пользователи могут не замечать нестабильности, а журналы покажут, что бот регулярно получает ошибки сервера и снижает частоту визитов.

Новый проект не появился в поиске: когда ожидание нормально, а когда уже есть проблема

Почему поисковику нужно время на обнаружение нового домена

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

Как отсутствие внешних ссылок замедляет первичный обход

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

Почему sitemap.xml не гарантирует попадание страниц в индекс, но помогает роботу найти URL

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

Какие проверки выполнить, если после запуска прошло больше ожидаемого времени

• Доступность главной страницы. Убедитесь, что главная отдаёт код 200 OK без авторизации и без редиректов на технический домен или заглушку.
• Отсутствие запрета в robots.txt и noindex. Проверьте файл /robots.txt на наличие директивы Disallow: / и убедитесь, что ни одна важная страница не содержит метатег noindex в шаблоне CMS.
• Отправка карты сайта в панели вебмастера. Добавьте sitemap.xml в Google Search Console и Яндекс.Вебмастер вручную — это даёт роботу полный список URL для обхода.
• Наличие внутренних ссылок на новые страницы. Страница без единой внутренней ссылки с точки зрения робота выглядит как изолированный тупик. Добавьте ссылки с главной или из релевантных разделов.

Из практики: из примерно сорока молодых проектов, прошедших через SEO-аудит за последние два года, ни разу проблема не оказалась в «плохом отношении» поисковика. Чаще всего робот просто не получил достаточно сигналов — нет карты сайта, нет ссылок с главной, нет обновлений и внешних упоминаний. Устранение этих четырёх пунктов решает большинство случаев задержки первичной индексации.

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

Технические запреты: что физически не пускает робота к страницам

Robots.txt, noindex и случайные запреты: что чаще всего блокирует индексацию

Disallow: / после разработки и забытый запрет перед запуском. Самая распространённая и при этом самая незаметная ошибка. Во время разработки сайт закрывают от роботов директивой Disallow: /, чтобы незаконченные страницы не попали в поиск. После запуска эту строку забывают удалить. Результат — сайт работает для пользователей, но полностью невидим для поисковых систем.

Закрытые разделы, которые должны быть доступны поисковому роботу. Иногда в robots.txt закрывают не весь сайт, а отдельные папки — например, /catalog/ или /blog/. Если эти разделы содержат коммерчески важные страницы, они выпадают из базы полностью, даже если на них ведут внутренние ссылки.

Разные правила для Googlebot и ЯндексБота. Ошибка в одном блоке может закрыть сайт только для одной поисковой системы — именно так возникает ситуация, когда Яндекс индексирует сайт, а Google нет, или наоборот.

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

Метатег noindex в шаблоне CMS: как одна настройка закрывает сотни страниц

Если noindex случайно включён на уровне шаблона категорий или карточек товаров, все страницы этого типа мгновенно исчезают из базы при следующем обходе. Проверить это можно через инспектор URL: если страница получает статус «Исключено по noindex», а вы не планировали её закрывать, проблема именно в шаблоне.

X-Robots-Tag в HTTP-заголовках: скрытый запрет, который не видно в HTML-коде

Директива X-Robots-Tag передаётся не в HTML-коде страницы, а в заголовках HTTP-ответа сервера. При просмотре исходного кода в браузере запрет не виден — его не существует с точки зрения «посмотреть исходник». Проверить его можно только через анализ заголовков ответа с помощью инструментов разработчика в браузере или специализированных сервисов.

Пароль, тестовый контур, ограничения по IP и антибот-системы

Если сайт требует авторизации для просмотра контента, поисковый робот получит код 401 или 403 вместо HTML-страницы. Аналогичная ситуация возникает при срабатывании антибот-защиты, которая принимает Googlebot за нежелательный трафик и возвращает капчу или блокирующий ответ. Тестовый контур, оставшийся активным после запуска, — отдельный риск: если продакшн-домен перенаправляет на тестовый сервер с закрытым доступом, робот не получит контент вообще.

CDN, WAF и хостинг: когда блокировка выглядит как техническая защита

Системы защиты от DDoS-атак и веб-файерволы (WAF) иногда блокируют поисковых роботов, принимая их за подозрительный трафик из-за высокой частоты запросов. CDN может кешировать страницы с устаревшими заголовками или отдавать роботу другой контент, чем пользователю. Хостинг с нестабильной работой и частыми ответами 503 снижает краулинговый приоритет сайта: робот запоминает, что ресурс часто недоступен, и сокращает частоту визитов.

Ошибки сервера, карты сайта и редиректов, которые срывают обход

Технические ошибки, из-за которых робот не может нормально просканировать сайт

Нестабильный хостинг и ответы 5xx. Единичные случаи не критичны, но систематические ответы 5xx снижают краулинговый приоритет: робот начинает заходить реже, чтобы не перегружать нестабильный сервер. Проверить это можно через отчёт об ошибках сканирования в Google Search Console и через логи сервера.

Страница отдаёт 200 OK там, где должен быть 404 или 410. Удалённые страницы, которые продолжают отдавать код 200 с сообщением «страница не найдена» внутри HTML, называют мягкими 404. Поисковая система видит успешный ответ, но обнаруживает пустое содержимое. Такие страницы расходуют краулинговый бюджет — настройте корректный 404 для удалённых страниц или 410, если страница удалена навсегда.

Цепочки редиректов, циклы и ошибки после переезда. Цепочка из трёх и более редиректов замедляет обход и увеличивает риск, что робот не дойдёт до финального URL. Цикл редиректов (A → B → A) делает страницу недоступной полностью.

Разные версии сайта: http/https, www/без www, слеш в конце URL. Все варианты должны сводиться к одной версии через 301-редирект, а canonical должен указывать на неё же. Временный 302-редирект вместо постоянного 301 приводит к тому, что вес старой страницы не передаётся новой.

Sitemap.xml: какие ошибки мешают обнаружению важных страниц

В карту попали закрытые, битые или неканонические URL. Карта сайта должна включать только те URL, которые реально открыты для индексации и отдают 200 OK.

В карте отсутствуют новые и приоритетные страницы. Для крупных сайтов с активным добавлением контента карту стоит обновлять при каждой публикации.

Lastmod указан формально. Атрибут lastmod должен отражать реальную дату последнего значимого изменения страницы. Если он проставляется автоматически как текущая дата при каждой генерации карты, поисковик перестаёт доверять этому сигналу. Признак потери доверия прямой: страницы с недавними датами в карте сайта месяцами висят в статусе «Обнаружено, но не проиндексировано» без каких-либо технических блокировок.

Страница просканирована, но не добавлена в базу: как поисковик решает, что оставить

Дубли страниц, метатеги и canonical: когда поисковик выбирает не ту страницу

Canonical — это сигнал, а не приказ. Тег rel=canonical сообщает поисковику, какую версию страницы считать основной. Если canonical указывает на другой URL (например, из-за ошибки в шаблоне), поисковик индексирует именно тот адрес, а оригинальная страница получает статус дубля и исключается.

Если одно и то же содержимое доступно по адресам с www и без, с http и https, со слешем в конце и без него, поисковик видит несколько копий одной страницы. Без явного canonical или 301-редиректа система сама выбирает «победителя», и этот выбор может не совпасть с вашими ожиданиями.

URL с параметрами ?sort=price&order=asc или ?utm_source=email технически отличаются от базового адреса, но содержат идентичный контент. На крупных каталогах это создаёт тысячи дублей, которые расходуют краулинговый бюджет и размывают сигнал релевантности.

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

Низкое качество контента: почему поисковик может не включать страницу в базу

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

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

Статус «Просканировано, но не проиндексировано» в GSC без дополнительных пояснений — главный сигнал того, что страница получена роботом, но не прошла оценку качества. Практический способ проверить это: откройте инспектор URL для такой страницы и сравните отрендеренную версию с тем, что видит пользователь. Затем откройте топ-5 результатов по целевому запросу и сравните структуру, объём и глубину раскрытия темы. Если конкуренты отвечают в трёх абзацах с примерами, а ваша страница — в одном абзаце без конкретики, поисковик сделает тот же вывод, что и читатель.

Структура сайта и перелинковка: как «тупиковые» страницы выпадают из базы

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

Страницы на уровне 2–3 клика от главной получают больший краулинговый приоритет, чем те, что находятся на 5–6 уровне. Навигационные элементы — главное меню, хлебные крошки, блоки «похожие материалы» — формируют внутреннюю ссылочную структуру. Если важные посадочные страницы не включены в навигацию, они получают меньше внутреннего веса и хуже индексируются.

JavaScript, мобильная версия и скорость

Контент появляется только после выполнения JavaScript. Если основной контент формируется только после выполнения JS на стороне клиента, поисковый робот при первом запросе получает пустую или минимальную HTML-оболочку. Диагностический признак: откройте инспектор URL в GSC и сравните отрендеренную версию страницы с тем, что видит пользователь в браузере. Если в отрендеренной версии отсутствует основной текст или навигация, поисковик оценивает страницу как пустую.

SSR, CSR и гибридный рендеринг. Серверный рендеринг (SSR) отдаёт роботу уже сформированный HTML — это наиболее предсказуемый вариант для индексации. Клиентский рендеринг (CSR) передаёт минимальную оболочку и требует выполнения JavaScript, что создаёт риск пустой страницы для робота. Для Яндекса подробной официальной спецификации по SSR/CSR нет, но общее требование к полноте HTML при первом ответе актуально для обоих поисковиков.

Мобильная версия. Google использует mobile-first indexing: при оценке страницы система опирается на её мобильную версию. Контент, доступный только на десктопе, с точки зрения Google фактически не существует.

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

Страницы пропали из поиска после индексации: где искать причину

Смена CMS, шаблона или структуры URL

Если старые адреса перестали существовать без настроенных 301-редиректов на новые, поисковик видит тысячи несуществующих страниц и начинает удалять их из базы. Новые URL стартуют с нуля — накопленный вес остаётся на мёртвых адресах.

Массовое изменение robots.txt, noindex или canonical

Правка одной строки в robots.txt или изменение шаблонного noindex может мгновенно закрыть сотни страниц от индексации. Поисковик обнаружит изменение при следующем обходе и начнёт исключать страницы.

Удаление внутренних ссылок на старые страницы

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

Переезд сайта без корректной карты редиректов

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

Обновления алгоритмов и пересмотр качества раздела

Алгоритмические обновления могут пересмотреть оценку целых разделов сайта без каких-либо уведомлений в панелях вебмастера. Резкое падение за 1–3 дня, совпадающее с Core Update, указывает на алгоритм. Снижение, растянутое на 2–4 недели, чаще оказывается техникой или контентом.

Рост доли дублей и параметрических URL

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

Если в отчёте GSC число исключённых страниц превышает число проиндексированных — это сигнал для немедленного аудита краулингового бюджета через логи сервера.

Фиксируйте даты всех значимых изменений на сайте: релиз новой версии, правки robots.txt, обновление sitemap.xml, массовые изменения URL, редизайн навигации. Сопоставление этих дат с динамикой числа проиндексированных страниц в GSC позволяет быстро найти причину падения даже без явных уведомлений от поисковиков.

Фильтры, безопасность и доверие

Фильтры и санкции поисковых систем

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

Взлом, дорвеи и скрытые ссылки

Один из нетривиальных сценариев взлома — избирательная блокировка: вредоносный код проставляет тег noindex только для User-Agent Googlebot, оставляя страницы видимыми для всех остальных посетителей и сканеров. Владелец открывает страницу в браузере — всё выглядит нормально. Но инспектор URL в GSC показывает статус «Исключено по noindex». Проверить это можно, запустив краулер с User-Agent Googlebot Smartphone: если страница получает noindex только в этом режиме — это признак взлома, а не ошибки настройки.

Где искать уведомления в панелях вебмастера

Раздел «Ручные меры» в GSC показывает санкции вручную от сотрудников Google. Раздел «Проблемы безопасности» фиксирует обнаруженный вредоносный код и фишинговые страницы. Алгоритмические ограничения в GSC не отображаются — их диагностируют только по совпадению падения трафика с датами обновлений. Яндекс явно уведомляет о наложенных фильтрах в разделе «Проблемы» Яндекс.Вебмастера.

Миф о ссылках и ручной отправке URL

Почему ссылочный всплеск не исправит robots.txt, noindex и ошибки сервера

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

Разница между «помогает» и «вредит» определяется не количеством ссылок, а их качеством и естественностью прироста. Резкий прирост с нерелевантных доноров поисковик расценивает как манипуляцию и может наложить ручные меры.

Какие действия выглядят быстрыми, но ухудшают ситуацию

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

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

Закрыть дубли так, что исчезают полезные страницы. При работе с дублями важно точно определить, какая версия является канонической. Ошибочное закрытие «правильной» версии через noindex или неверный canonical — из базы исчезает именно та страница, которая должна была ранжироваться.

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

Неочевидные нюансы, которые меняют тактику исправления

Canonical — рекомендация, а не абсолютный приказ

Поисковик может проигнорировать canonical, если считает, что другая версия страницы более релевантна. Если canonical указывает на страницу, которая сама закрыта noindex или отдаёт 404, поисковик проигнорирует директиву и примет собственное решение. Проверять корректность canonical нужно не только на наличие тега, но и на то, что адрес за ним живой и отдаёт 200.

Если Google систематически игнорирует ваш canonical и продвигает другую версию страницы — это не баг. Это сигнал либо о техническом конфликте (canonical указывает в никуда), либо о том, что выбранная вами «каноническая» версия слабее альтернативной по контенту или ссылочному профилю.

Google и Яндекс: ключевые различия в индексации

Сложные случаи: региональность, языковые версии и большие каталоги

Доменная зона, язык интерфейса и региональные сигналы

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

Когда нужен hreflang, а когда он только усложняет обработку страниц

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

Фасетная навигация: как фильтры создают тысячи слабых URL

Каждая комбинация фильтров в каталоге генерирует отдельный URL с уникальным адресом, но идентичным содержимым. На крупном каталоге это создаёт десятки тысяч параметрических страниц. Выход стандартный: закрывать комбинированные фильтры через canonical на базовую страницу категории или через noindex, оставляя открытыми только те фильтры, которые имеют самостоятельный поисковый спрос. Если в логах сервера более 30–40% обращений робота приходится на параметрические URL — прямой сигнал для аудита фасетной навигации.

Пагинация, сортировки и календарные страницы

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

Часто задаваемые вопросы

Почему Google не индексирует новую страницу

Чаще всего по одной из четырёх причин: нет внутренних ссылок с уже проиндексированных страниц, страница не включена в sitemap.xml, содержимое признано недостаточно ценным, либо страница случайно закрыта через noindex в шаблоне CMS. Проверить статус конкретного URL можно через инспектор URL в Google Search Console — инструмент покажет причину исключения и дату последнего сканирования.

Почему Яндекс индексирует сайт, а Google нет

Проверьте robots.txt на разные правила для Googlebot и ЯндексБота — ошибка в одном блоке может закрыть сайт только для одного поисковика. Google строже оценивает качество контента и мобильную доступность: страница, которую Яндекс добавил в базу, может не пройти порог качества Google. Проверьте также раздел «Ручные меры» в GSC.

Сколько ждать индексации после исправления ошибок

После устранения технических запретов и запроса переобхода через инспектор URL — от нескольких дней до 2–3 недель. Для Яндекса сроки сопоставимы. Если страница содержала серьёзные проблемы с качеством контента, одного технического исправления недостаточно — нужно улучшить содержимое и ждать повторной оценки при следующем обходе.

Что делать, если число страниц в индексе резко упало

Немедленная диагностика в порядке: проверить robots.txt и noindex на случайные изменения → посмотреть отчёт об ошибках сканирования в GSC → проверить «Ручные меры» и «Проблемы безопасности» → сопоставить дату падения с датами технических изменений и обновлений алгоритмов. Если причина не найдена в технике — аудит качества контента на страницах, которые исчезли из базы.

Нужно ли закрывать от индексации фильтры, теги и пагинацию

Зависит от поискового спроса. Фильтры и теги с реальным спросом — оставлять открытыми с уникальным контентом. Комбинированные фильтры без спроса, теги с единственной записью и страницы пагинации глубже второй-третьей — закрывать через canonical или noindex.

Что делать, если все проверки пройдены, ошибок нет, а страниц в базе всё равно меньше ожидаемого

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

Индексация — это не разовая задача. Поисковики регулярно пересматривают ценность страниц, алгоритмы обновляются, структура сайта меняется. Большинство проблем, описанных в этой статье, решаются на этапе техники — до анализа контента и внешних сигналов. Если проверка robots.txt, noindex и HTTP-статусов ничего не дала, двигайтесь по чек-листу последовательно: структура — качество контента — поведенческие сигналы — санкции. Один правильно выстроенный порядок действий сокращает время диагностики в разы.

Не знаете с чего начать? Оставляйте заявку на SEO-аудит и команда WEBMART поможет разобраться!