Почему страницы сайта не индексируются: 15 причин и способы решения

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

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

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

Содержание

• Что означает «страница не индексируется»
• Как проверить индексацию страницы
• Как правильно проводить диагностику
• 15 причин отсутствия страницы в индексе
• Практические примеры
• Как ускорить повторную индексацию
• Типичные ошибки владельцев сайтов
• Чек-лист
• FAQ
• Вывод

Что означает «страница не индексируется»

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

Фраза «страница не индексируется» может описывать несколько разных ситуаций:

1. Робот не знает о существовании URL.
2. URL найден, но ещё не просканирован.
3. Робот не может получить страницу из-за запрета или ошибки сервера.
4. Страница просканирована, но не включена в индекс.
5. Поисковик выбрал другой URL как канонический.
6. Документ был в индексе, но позже исключён.
7. Страница есть в индексе, но не показывается по ожидаемым запросам.

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

Сканирование и индексация — не одно и то же

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

Например, сервер вернул код 200 OK, робот прочитал текст, но обнаружил почти идентичную страницу с более сильными сигналами. Тогда текущий URL может остаться вне индекса, а поисковик выберет другую версию.

Индексирование не гарантирует позиции

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

Как проверить индексацию страницы

Не стоит делать вывод только по оператору site:. Он удобен для быстрой проверки, но не показывает полную и постоянно актуальную картину. Основными источниками должны быть Google Search Console и Яндекс.Вебмастер.

Проверка в Google Search Console

Откройте инструмент проверки URL и вставьте полный адрес страницы. Сервис покажет:

• известен ли URL Google;
• находится ли он в индексе;
• когда выполнялось последнее сканирование;
• разрешено ли сканирование;
• какой canonical указал владелец сайта;
• какой canonical выбрал Google;
• обнаружен ли URL в sitemap;
• существуют ли проблемы с мобильной версией и обработкой страницы.

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

Проверка в Яндекс.Вебмастере

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

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

Проверка оператором site:

Для быстрой оценки введите в поиске:

site:kashirinweb.ru/адрес-страницы/

Для раздела можно использовать:

site:example.ru/catalog/

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

Проверка кода ответа

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

curl -I https://example.ru/page/

Обратите внимание на:

• итоговый HTTP-код;
• заголовок Location;
• X-Robots-Tag;
• различия между версиями с www и без него;
• различия между HTTP и HTTPS;
• ответы сервера для поисковых роботов.

Проверка исходного HTML

Нужно смотреть не только DOM после выполнения JavaScript, но и HTML, который сервер отдаёт роботу. Проверьте:

<meta name="robots" content="index, follow">
<link rel="canonical" href="https://example.ru/page/">

Убедитесь, что на странице нет noindex, canonical ведёт на правильный адрес, заголовок и основной текст присутствуют в доступном роботу документе.

Как правильно проводить диагностику

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

Если ошибка найдена на раннем этапе, сначала исправьте её, а затем продолжайте проверку. Например, бессмысленно улучшать текст страницы, если сервер возвращает 404 или meta robots содержит noindex.

15 причин, по которым страницы не попадают в индекс

1. Страница заблокирована в robots.txt

Файл robots.txt управляет сканированием. Ошибочная директива Disallow может закрыть отдельную страницу, каталог или большую часть сайта.

Пример опасной настройки:

User-agent: *
Disallow: /

Такой файл запрещает роботам обход всего сайта. Ошибка часто появляется после переноса настроек с тестового домена на основной.

Другой пример:

User-agent: *
Disallow: /catalog/

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

Проверьте:

• файл по адресу /robots.txt;
• правила для User-agent: *;
• отдельные секции для Googlebot и Yandex;
• чувствительность путей к регистру;
• совпадение начала URL с Disallow;
• доступ к CSS и JavaScript, необходимым для отображения страницы.

После исправления протестируйте конкретный URL в инструментах поисковых систем. Полное руководство с примерами размещено в статье о настройке robots.txt.

Не используйте robots.txt как основной способ удаления уже проиндексированной страницы. Если робот не может сканировать URL, он может не увидеть установленный на странице noindex.

2. На странице установлен noindex

Директива noindex прямо сообщает поисковой системе, что документ не следует включать в индекс. Она может находиться в HTML:

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

либо в HTTP-заголовке:

X-Robots-Tag: noindex

Частые причины случайного появления noindex:

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

Проверяйте не только исходный код браузера. X-Robots-Tag виден в HTTP-заголовках и может применяться к PDF, изображениям и другим файлам без HTML.

После удаления noindex страница не возвращается в поиск мгновенно. Робот должен повторно посетить URL, увидеть новую директиву и передать документ на обработку.

3. Ошибки в sitemap.xml

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

Проблемные ситуации:

• URL возвращает 404, 410 или 5xx;
• страница перенаправляет на другой адрес;
• URL закрыт в robots.txt;
• на странице установлен noindex;
• canonical указывает на другой документ;
• в карте находятся HTTP-версии вместо HTTPS;
• используются неправильные домен или поддомен;
• карта давно не обновлялась;
• один URL встречается в нескольких конфликтующих sitemap;
• указан некорректный lastmod.

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

После обновления отправьте карту в панели вебмастеров и проверьте число обнаруженных URL и ошибки обработки. Подробные требования и примеры XML разобраны в руководстве по sitemap.xml.

4. Неправильно настроен canonical

Canonical указывает предпочтительную версию среди похожих URL:

<link rel="canonical" href="https://example.ru/main-page/">

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

Типичные ошибки:

• все страницы сайта указывают canonical на главную;
• карточки товаров канонизированы на категорию;
• canonical ведёт на 404 или редирект;
• указан HTTP вместо HTTPS;
• canonical содержит тестовый домен;
• относительный адрес собирается неправильно;
• JavaScript меняет canonical после загрузки;
• sitemap содержит неканоническую версию;
• внутренние ссылки ведут на дубль, а canonical — на другой URL.

Canonical является сильной подсказкой, но поисковик может выбрать другую версию, если остальные сигналы противоречат указанному адресу. Нужно согласовать canonical, внутренние ссылки, sitemap, редиректы и hreflang.

Подробнее о самоканонических ссылках, фильтрах и дублях читайте в материале про rel=canonical.

5. Страница возвращает неправильный HTTP-код

Для обычной индексируемой страницы ожидается 200 OK. Другие ответы имеют другое назначение:

Отдельно проверяйте soft 404: сервер отвечает 200, но страница содержит сообщение «товар не найден» или почти пустой шаблон. Поисковик может самостоятельно признать такой документ ошибочным и не индексировать его.

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

6. Цепочки и циклы редиректов

Если URL последовательно перенаправляет робота через несколько адресов, обход становится медленнее, а конечный сигнал — менее очевидным.

Плохая цепочка:

http://example.ru/page
→ https://example.ru/page
→ https://www.example.ru/page
→ https://www.example.ru/new-page/

Лучше настроить каждую старую версию сразу на конечный URL. Особенно важно обновить внутренние ссылки и sitemap, чтобы они не отправляли робота на начало цепочки.

Цикл возникает, когда адреса перенаправляют друг на друга. В этом случае робот вообще не получает содержимое. Причиной могут быть конфликтующие правила веб-сервера, CDN, CMS и плагина перенаправлений.

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

7. Дублирование контента

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

• с www и без него;
• по HTTP и HTTPS;
• со слешем и без слеша;
• с параметрами аналитики;
• через фильтры и сортировку;
• по разным путям категорий;
• в версиях для печати;
• на страницах тегов и архивов;
• на региональных или языковых URL.

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

Для устранения дублей применяются:

• 301-редирект для полностью заменённых адресов;
• canonical для доступных пользователю вариантов;
• единый формат внутренних ссылок;
• очистка sitemap;
• управление параметрами и фильтрами;
• уникализация страниц, которые должны индексироваться отдельно.

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

8. Слабый или неуникальный контент

Технически доступная страница может не попасть в индекс, если не представляет самостоятельной ценности. Это особенно характерно для:

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

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

Перед расширением текста задайте вопросы:

1. Зачем поисковику хранить именно этот URL?
2. Чем страница отличается от других документов сайта?
3. Получает ли пользователь полный ответ?
4. Есть ли собственный опыт, данные или практические примеры?
5. Можно ли объединить её с более сильной страницей?

Добавление воды ради количества слов не решает проблему. Иногда правильное действие — объединить несколько слабых документов и настроить редиректы на один полный материал.

9. На страницу не ведут внутренние ссылки

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

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

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

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

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

10. Сайт или страница недавно опубликованы

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

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

Что можно сделать:

• добавить страницу в sitemap;
• поставить внутренние ссылки;
• отправить URL на проверку;
• убедиться в отсутствии технических конфликтов;
• продолжать публиковать качественные связанные материалы;
• получить естественные упоминания и ссылки.

Не отправляйте один и тот же URL на переобход каждый час. Частота запросов не повышает качество документа и не гарантирует ускорение.

11. Низкий или неэффективно расходуемый crawl budget

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

Признаки проблемы:

• новые страницы долго не сканируются;
• серверные логи показывают обход технических дублей;
• робот редко посещает важные разделы;
• sitemap содержит намного больше URL, чем реально индексируется;
• большое количество ответов 3xx, 4xx и 5xx;
• генерация URL практически не ограничена.

Оптимизация включает:

• устранение дублей;
• ограничение бесполезных комбинаций фильтров;
• улучшение скорости и стабильности сервера;
• актуальный sitemap;
• исправление цепочек редиректов;
• усиление внутренней перелинковки;
• удаление битых ссылок.

Не закрывайте хаотично все параметры в robots.txt. Сначала определите, какие URL робот обходит и какие из них должны передавать сигналы через canonical или редирект.

12. Ошибки после миграции сайта

При смене домена, CMS, структуры или протокола можно потерять значительную часть индексации. Основные причины:

• старые URL не перенаправлены;
• редиректы ведут на главную вместо релевантных страниц;
• новый сайт закрыт в robots.txt;
• остался глобальный noindex;
• canonical ведёт на тестовый домен;
• внутренние ссылки используют старые адреса;
• sitemap содержит прежнюю структуру;
• важный контент не перенесён;
• сервер возвращает ошибки под нагрузкой;
• изменились hreflang и региональные настройки.

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

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

13. Медленная загрузка и нестабильный сервер

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

Проверьте:

• время ответа сервера;
• ошибки в логах;
• нагрузку базы данных;
• ограничения хостинга;
• работу CDN;
• доступность из разных регионов;
• различия ответа обычному браузеру и поисковому боту;
• размер HTML и ресурсов;
• Core Web Vitals для пользователей.

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

Практические способы оптимизации собраны в статье о скорости загрузки сайта.

14. Основной контент зависит от JavaScript

На JavaScript-сайтах исходный HTML иногда содержит только контейнер:

<div id="root"></div>

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

Проблемы возникают, когда:

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

Для важных SEO-страниц предпочтительны SSR, SSG или предварительный рендеринг. Gatsby обычно генерирует HTML на этапе сборки, но каждую страницу всё равно нужно проверять в готовой папке public, а не только в режиме разработки.

Сравните исходный HTML, отрендеренный DOM и результат проверки URL. Основной заголовок, текст, canonical и ссылки должны быть доступны без ожидания сложного клиентского сценария.

15. Ручные меры, алгоритмические ограничения или проблемы доверия

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

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

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

Не пытайтесь «лечить санкции» массовой отправкой URL на индексирование. Сначала устраните причину, очистите взломанные материалы, повысьте качество и только затем отправляйте запрос на пересмотр, если такая возможность предусмотрена.

Как диагностировать массовое выпадение страниц

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

Сначала выгрузите из Google Search Console и Яндекс.Вебмастера списки проиндексированных и исключённых страниц. Дополните их URL из sitemap, внутреннего краулера, аналитики и серверных логов. Для каждого адреса полезно собрать:

• тип страницы;
• HTTP-код;
• индексируемость;
• canonical;
• глубину вложенности;
• количество входящих внутренних ссылок;
• наличие в sitemap;
• органический трафик;
• дату последнего обхода;
• статус в панели вебмастера.

После этого группируйте адреса не по отдельным формулировкам, а по шаблонам: товары, категории, статьи, страницы тегов, фильтры, города, пагинация. Если 90% исключённых URL относятся к одному шаблону, исправление следует искать в его коде или правилах генерации.

Сравните индексируемые и исключённые страницы одного типа

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

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

Сопоставьте начало проблемы с изменениями на сайте

Отметьте даты релизов, миграций, изменений robots.txt, шаблонов, canonical, CDN и системы генерации sitemap. Если число исключённых страниц резко выросло после определённого события, сначала исследуйте его последствия.

Полезно вести журнал SEO-изменений: дата, затронутые шаблоны, ожидаемый результат и ответственный специалист. Без такого журнала через несколько месяцев сложно понять, почему поисковый робот изменил поведение.

Анализируйте серверные логи

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

• какие разделы посещаются чаще;
• какие важные URL робот не запрашивает;
• сколько ресурсов уходит на параметры и дубли;
• какие коды получает Googlebot или YandexBot;
• как меняется скорость ответа сервера;
• повторяются ли ошибки на конкретном шаблоне.

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

Исправляйте причину на уровне шаблона

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

Практические примеры диагностики

Пример 1. Новая статья не появилась в Google

Исходные данные:

• статья опубликована пять дней назад;
• URL возвращает 200;
• robots.txt не блокирует страницу;
• noindex отсутствует;
• в sitemap URL есть;
• Google показывает статус «Обнаружена, не проиндексирована»;
• на статью ведёт только страница блога.

Действия:

1. Добавить контекстные ссылки из двух-трёх тематических статей.
2. Проверить, решает ли публикация отдельный интент.
3. Расширить практическую часть, если материал поверхностный.
4. Убедиться, что canonical указывает на саму статью.
5. После изменений запросить повторную проверку URL.

В этой ситуации нет смысла менять robots.txt или многократно отправлять sitemap. Основной риск — низкий приоритет URL и недостаточно сильные сигналы качества.

Пример 2. Карточки товаров массово исключены

Исходные данные:

• карточки доступны по нескольким URL из-за категорий;
• параметры сортировки попали во внутренние ссылки;
• canonical настроен непоследовательно;
• sitemap содержит и основные, и параметрические адреса.

Действия:

1. Выбрать единый постоянный URL товара.
2. Настроить self-canonical на основной версии.
3. На дублях указать canonical на основной URL либо использовать редирект, если дубли не нужны пользователям.
4. Обновить внутренние ссылки.
5. Оставить в sitemap только канонические карточки.
6. Проверить логи и сократить обход бесконечных параметров.

Здесь проблема не решится написанием дополнительных описаний для каждой копии: сначала нужно устранить техническое размножение URL.

Пример 3. Страницы исчезли после редизайна

Исходные данные:

• URL не изменились;
• сервер отвечает 200;
• исходный HTML почти пустой;
• текст загружается клиентским API;
• при проверке отрендеренной версии появляется ошибка JavaScript.

Действия:

1. Вернуть серверный или статический рендеринг основного контента.
2. Исправить ошибки выполнения JavaScript.
3. Сделать обычные ссылки с href.
4. Выводить title, description и canonical в серверном HTML.
5. проверить несколько шаблонов в инструментах поисковых систем.

Пример 4. Яндекс исключил региональные страницы

На сайте создано много страниц вида «услуга + город», но отличаются они только названием населённого пункта. Такие URL технически доступны, однако не дают пользователю уникальной региональной информации.

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

Как ускорить индексацию после исправлений

Ускорять индексирование нужно только после устранения причины исключения. Если страница по-прежнему закрыта noindex или canonical ведёт на другой URL, повторные запросы ничего не изменят.

Добавьте URL в sitemap

Карта должна содержать канонический адрес с ответом 200. После публикации проверьте, что новая версия sitemap доступна и успешно обработана.

Усильте внутренние ссылки

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

Используйте инструменты вебмастеров

После исправления отправьте URL на проверку в Google Search Console и Яндекс.Вебмастере. Не отправляйте сотни адресов вручную без анализа общей причины: для массовых изменений важнее sitemap и нормальная архитектура.

Обновите действительно важный контент

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

Обеспечьте стабильность сервера

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

Типичные ошибки при работе с индексацией

Ошибка 1. Считать sitemap гарантией индексации

Sitemap помогает обнаружить URL, но решение о включении принимает поисковая система. Если документ слабый, дублирующий или противоречивый, наличие в XML не исправит ситуацию.

Ошибка 2. Закрывать noindex-страницу в robots.txt

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

Ошибка 3. Отправлять URL на переобход до исправления

Повторная проверка только подтвердит существующую ошибку. Сначала устраните техническую или контентную причину.

Ошибка 4. Массово менять URL

Изменение адреса не делает контент качественнее и создаёт необходимость в редиректе. Сохраняйте стабильные URL, если нет веской архитектурной причины.

Ошибка 5. Увеличивать текст «для объёма»

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

Ошибка 6. Проверять только главную страницу

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

Ошибка 7. Игнорировать выбранный поисковиком canonical

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

Ошибка 8. Удалять слабые страницы без карты редиректов

Если URL имеет трафик или внешние ссылки, его нельзя просто удалять. Найдите релевантную замену и настройте 301. Если замены нет и документ удалён навсегда, допустим 410.

Чек-лист проверки страницы

Доступность

• URL открывается без авторизации и cookie-сценария.
• Сервер возвращает 200 OK.
• Нет циклов и цепочек редиректов.
• Сервер стабилен и не отвечает 5xx поисковым роботам.
• HTTPS и основное зеркало настроены единообразно.

Управление роботами

• URL разрешён в robots.txt.
• В HTML нет случайного noindex.
• В заголовке X-Robots-Tag нет noindex.
• CSS и JavaScript, необходимые для рендеринга, доступны.

Canonical и дубли

• Canonical ведёт на правильный URL с 200 OK.
• Внутренние ссылки используют каноническую версию.
• В sitemap находится каноническая версия.
• Нет конфликтов HTTP/HTTPS, www и слеша.
• Параметры, фильтры и сортировка контролируются.

Обнаружение страницы

• URL включён в актуальный sitemap.
• На страницу ведут контекстные внутренние ссылки.
• Страница доступна из тематического раздела.
• Глубина перехода от главной соответствует важности URL.
• Нет битых ссылок на старую версию адреса.

Содержание

• Страница отвечает отдельному поисковому интенту.
• Основной текст присутствует в исходном HTML.
• Title, description и H1 уникальны и соответствуют содержанию.
• Документ не является пустым шаблоном или слабым дублем.
• Есть практические сведения, примеры или характеристики.
• Страница полезна без необходимости переходить к конкуренту за ответом.

Контроль после исправления

• URL проверен в Google Search Console.
• URL проверен в Яндекс.Вебмастере.
• Зафиксирована исходная причина исключения.
• После исправлений отправлен запрос на повторный обход.
• Проверка повторена через разумный срок.
• Для массовой проблемы проверены все страницы одного шаблона.

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

Сколько времени занимает индексация новой страницы?

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

Почему страница есть в sitemap, но её нет в поиске?

Sitemap сообщает о существовании URL, но не гарантирует индексирование. Проверьте robots.txt, noindex, canonical, HTTP-код, дубли, внутренние ссылки и качество страницы.

Нужно ли отправлять каждую статью на переобход вручную?

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

Может ли страница индексироваться, если она закрыта в robots.txt?

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

Что важнее: robots.txt или noindex?

Они решают разные задачи. robots.txt управляет сканированием, а noindex — включением документа в индекс. Чтобы робот обработал noindex, он должен иметь возможность загрузить страницу.

Почему Google выбрал другой canonical?

Обычно сигналы противоречат друг другу: внутренние ссылки, sitemap, редиректы и сходство контента указывают на другую версию. Согласуйте все сигналы и усиливайте именно нужный URL.

Поможет ли изменение URL вернуть страницу в индекс?

Само по себе — нет. Новый URL может временно пройти обработку, но если контент слабый или техническая ошибка сохранилась, проблема повторится. Кроме того, смена адреса требует корректного 301-редиректа.

Может ли низкое качество исключить технически исправную страницу?

Да. Код 200, открытый robots.txt и правильный canonical не обязывают поисковик хранить документ. Страница должна иметь самостоятельную ценность и отличаться от уже известных материалов.

Как понять, что проблема массовая?

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

Нужно ли удалять из sitemap страницы с noindex?

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

Когда нужен SEO-аудит индексации?

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

Что делать, если все проверки пройдены, но URL всё равно не индексируется

Иногда страница возвращает 200 OK, доступна роботу, присутствует в sitemap, имеет self-canonical и внутренние ссылки, но поисковая система продолжает оставлять её вне индекса. В такой ситуации не следует бесконечно переключать технические настройки. Перейдите к сравнению документа с уже проиндексированными результатами по его основному запросу.

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

Затем проверьте, не конкурирует ли URL с другой страницей собственного сайта. Сравните title, H1, запросы, внутренние анкоры и содержимое. Если два документа отвечают на один вопрос, поисковик может постоянно менять выбранную версию или исключить более слабую. В этом случае полезнее объединить материалы, перенести уникальные фрагменты и настроить 301, чем продолжать усиливать оба URL.

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

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

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

Вывод

Отсутствие страницы в поиске — это не отдельная ошибка, а результат одного или нескольких конфликтующих сигналов. Диагностику следует проводить последовательно: HTTP-код, robots.txt, noindex, canonical, sitemap, внутренние ссылки, рендеринг и качество контента.

Для единичного URL достаточно пройти чек-лист и изучить данные Google Search Console и Яндекс.Вебмастера. При массовой проблеме нужно искать общий шаблон: тип страницы, каталог, настройки CMS, дату релиза или правило генерации адресов.

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

Дополнительно проверьте robots.txt, sitemap.xml, общую индексацию сайта, причины падения трафика, основы технического SEO и связанные определения в SEO-глоссарии.