У страницы вне поиска может быть несколько состояний. Один URL робот ещё не обнаружил, другой не смог загрузить, третий успешно обработал, но объединил с дублем. Одновременная правка текста, отправка на переобход и пересборка sitemap смешают следы причины. Надёжнее пройти путь страницы в той же последовательности, в какой его проходит поисковая система.
Сначала зафиксируйте, что именно считается проблемой
Запрос site: годится для быстрой ориентировочной проверки, но не доказывает отсутствие конкретного URL в индексе. Для Google откройте инструмент проверки URL в Search Console: он показывает сведения о последней известной индексированной версии, а отдельный live-тест проверяет текущую доступность. Эти два состояния нельзя смешивать — официальная справка Google прямо разделяет индексированную и живую версии.
Для Яндекса сопоставьте данные Вебмастера, дату последнего обхода и сохранённую поиском версию. Запишите полный URL, включая протокол, поддомен, регистр пути и параметры. Иногда команда обсуждает https://example.ru/page, а в sitemap находится версия со слешем, canonical ведёт без слеша, внутренние ссылки используют HTTP. Тогда вопрос уже не «почему не индексируется страница», а «какую из нескольких версий система считает основной».
Зафиксируйте дату публикации или существенного обновления, источник обнаружения URL и ожидаемый поисковый спрос. Новому документу нужен фактический обход; старому, внезапно выпавшему из индекса, требуется поиск изменения или сбоя.
Проверьте ответ сервера вне браузерной сессии
Откройте URL в приватном окне, затем получите заголовки командой curl -I и полный ответ с переходом по редиректам. Нужен конечный код 200, разумная цепочка и тот же документ, который видит незалогиненный пользователь. Редирект на главную, страницу выбора города, форму входа или защитную заглушку делает исходный адрес непригодным для индексации.
Проверьте несколько вариантов user-agent. CDN, WAF и антибот иногда отдают поисковому роботу 403, 429, пустой HTML или проверку JavaScript, хотя обычный браузер получает страницу. Случайный 5xx тоже нельзя оценивать одним запросом: повторите проверку в разное время и посмотрите журналы origin-сервера. Разбор значений кодов и типовых переходов есть в материале о HTTP-статусах.
Критерий этого этапа прост: робот способен стабильно получить содержательный HTML по окончательному URL. Если нет, мета-теги и качество текста пока не имеют значения.
Исключите прямые запреты на обход и индексирование
Проверьте robots.txt именно для нужного поискового робота и нужного пути. Правило Disallow ограничивает загрузку, но не является способом удалить уже известный URL из поиска. Поэтому сочетание запрета обхода с noindex особенно неудачно: робот может не загрузить страницу и не увидеть указание об исключении.
Затем исследуйте исходный HTML и HTTP-заголовки. Ищите meta name="robots", отдельные директивы для Googlebot или Yandex, а также X-Robots-Tag. Значение noindex может добавляться не шаблоном страницы, а прокси, плагином безопасности или настройкой тестового окружения. Убедитесь, что после выполнения JavaScript директива не меняется неожиданно.
Результат должен быть однозначным: URL разрешён к получению, а в фактическом ответе нет указания не индексировать его. Если запрет был снят, сохраните время изменения и попросите переобход только после повторной проверки ответа.
Сопоставьте canonical, sitemap и фактический URL
Страница с 200 и без noindex всё равно может не появиться как самостоятельный результат, если поисковик считает её копией. Посмотрите rel="canonical" в исходном и отрисованном HTML. Цель canonical должна отвечать 200, быть доступной для индексирования и соответствовать смыслу документа. Ссылка на категорию, главную или товар другого варианта не исправляет дубли — она предлагает объединить разные сущности.
Сверьте четыре места: адрес страницы, canonical, URL в sitemap и конечную цель редиректа. Для индексируемой основной версии они обычно должны указывать на один вариант. Google описывает редирект и rel="canonical" как сильные сигналы, а присутствие в sitemap — как более слабый; конфликт сигналов оставляет окончательный выбор за системой. Подробности собраны в официальной документации и нашем руководстве по canonical.
Если поисковая консоль выбрала другой canonical, сравните документы: одинаковые ли основной текст, title, изображения, параметры товара и язык. Исправьте источник дублирования или противоречивую разметку. Повторная отправка того же URL причину не устранит.
Убедитесь, что робот может обнаружить страницу
Sitemap помогает сообщить об адресе, но не заменяет навигацию сайта. Найдите входящие внутренние ссылки на URL. Они должны быть обычными HTML-ссылками с href, располагаться на доступных страницах и вести сразу на каноническую версию. Ссылка, возникающая только после поиска по сайту, выбора фильтра или клика, может остаться недоступной для обхода.
Страница-сирота часто встречается после переноса каталога, отключения блока рекомендаций или смены URL. Добавьте её в подходящую категорию, хлебные крошки либо тематический материал. Не создавайте десятки механических ссылок из футера: задача — встроить документ в понятную структуру. Принципы выбора доноров и анкоров разобраны в статье о внутренней перелинковке.
После изменения краулер должен находить URL, начиная с главной или карты раздела, за ограниченное число переходов. Sitemap при этом содержит только каноническую индексируемую версию с корректной датой изменения.
Оцените содержимое глазами поисковой системы
Когда технических блокировок нет, сравните исходный HTML, отрисованный DOM и видимый пользователю экран. Основной текст, заголовок, товарные свойства и ссылки не должны зависеть от запроса к API, который падает у робота. Пустой каркас с индикатором загрузки формально отвечает 200, но не даёт материала для индексирования.
Далее задайте предметные вопросы. Отличается ли страница от соседних? Решает ли отдельную задачу пользователя? Нет ли сотен URL, где меняются только город, одно предложение или порядок товаров? Соответствуют ли title и H1 фактическому содержанию? Слабый или почти повторяющийся документ поисковая система может обойти, но не выбрать для показа.
Это не повод увеличивать текст до условной нормы. Добавьте отсутствующие характеристики, условия, авторскую экспертизу, сравнение вариантов или ответы на реальные вопросы — только то, что делает страницу самостоятельной. Служебной странице без поискового назначения можно осознанно назначить noindex; добиваться её включения в индекс незачем.
Разделите исправление и подтверждение результата
Меняйте одну группу причин за раз. Сначала восстановите доступность, затем снимите запрет, приведите к одному варианту URL, добавьте путь обнаружения и только после этого улучшайте содержание. В журнале укажите исходное состояние, изменение, дату выкладки и способ проверки. Так через неделю можно отличить задержку переобхода от неработающего исправления.
После выкладки повторите HTTP-проверку, live-тест и обход внутренним краулером. Запрос на индексирование ускоряет передачу сигнала, но не отменяет технические и качественные требования. Технический аудит reChecker проверяет ответ страницы, мета-директивы, canonical и ссылки; его отчёт удобно приложить к журналу вместе с данными поисковой консоли. Решение о включении URL всё равно принимает поисковая система.
Перед следующим запросом на индексирование проверьте карточку URL:
- конечный ответ стабильно равен
200; - запреты на индексирование отсутствуют;
- canonical и sitemap указывают на выбранную версию;
- внутренняя ссылка доступна роботу.
Если после подтверждённого обхода страница по-прежнему не индексируется, сравните её с выбранным поиском canonical и соседними документами. Зафиксируйте новое наблюдение отдельно, не повторяя весь набор изменений одновременно.