Страница отвечает 200, но закрыта noindex: где искать запрет

Пошагово проверяем meta robots, X-Robots-Tag, редиректы, robots.txt и настройки CMS, сервера или CDN, если страница отвечает 200, но не попадает в поиск.

# Страница отвечает 200, но закрыта noindex: где искать запрет

Код HTTP 200 означает только то, что сервер успешно отдал ресурс. Он не разрешает индексацию: страницу могут исключать метатег robots в HTML или заголовок X-Robots-Tag, добавленный приложением, веб-сервером, прокси либо CDN.

Короткий порядок проверки: зафиксируйте конечный URL после редиректов, посмотрите заголовки именно ответа на GET-запрос, сохраните HTML для неавторизованного посетителя и найдите все директивы для роботов. Затем определите слой, который добавляет запрет, исправьте его и дождитесь повторного обхода.

Почему HTTP 200 не гарантирует индексацию

Статус ответа описывает доставку страницы, а не решение поисковой системы. Запрет может находиться в HTML:

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

Или в HTTP-заголовке, которого не видно через обычный просмотр исходного кода:

X-Robots-Tag: noindex

Проверьте также значение none: оно объединяет noindex и nofollow. Кроме общей директивы robots встречаются правила для конкретного робота, например yandex или googlebot. Поэтому отсутствие одной строки name="robots" ещё не доказывает, что запрета нет.

Диагностика по шагам

1. Уточните точный URL и цепочку редиректов

Проверяйте тот адрес, который поисковая система считает исключённым: с нужным протоколом, доменом, путём и параметрами. Сначала посмотрите цепочку:

curl -sS -L -o /dev/null \
  -w 'final=%{url_effective} code=%{http_code}\n' \
  https://example.ru/page

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

2. Проверьте заголовки ответа на GET-запрос

Сохраните заголовки всех ответов в цепочке:

curl -sS -L -D headers.txt -o /dev/null https://example.ru/page
grep -i '^x-robots-tag:' headers.txt

В headers.txt могут быть несколько блоков: отделите последний ответ от промежуточных редиректов. Ищите все строки X-Robots-Tag, потому что сервер вправе вернуть заголовок несколько раз и перечислить несколько директив.

Не ограничивайтесь curl -I: обработка HEAD и GET иногда настроена по-разному. Для вывода о странице важен реальный GET-ответ без cookie и авторизации.

3. Проверьте HTML, который получает гость

curl -sS -L https://example.ru/page -o page.html
grep -inE 'robots|noindex|none' page.html

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

Проверка в панели CMS недостаточна. Сравните сохранённый ответ с исходным кодом страницы в приватном окне, где нет административной сессии.

4. Сравните проблемную и контрольную страницы

Возьмите заведомо индексируемую страницу того же типа и заполните короткую матрицу:

| Проверка | Проблемный URL | Контрольный URL | |---|---|---| | Конечный URL | | | | HTTP-статус | | | | meta robots | | | | X-Robots-Tag | | | | Правило для отдельного робота | | | | Шаблон или тип страницы | | |

Разница часто указывает на источник: настройку конкретной записи, шаблон раздела, окружение приложения или правило на уровне сервера.

5. Найдите слой, который добавляет noindex

Проверяйте сверху вниз:

  1. настройку индексации страницы и SEO-плагина в CMS;
  2. общий шаблон head и условие для категории, фильтра или пагинации;
  3. middleware приложения и переменные окружения, особенно после переноса со стенда;
  4. конфигурацию nginx, Apache или панели хостинга;
  5. правила reverse proxy и CDN;
  6. кэш страницы и заголовков на каждом слое.

После изменения очистите только относящийся к URL кэш и повторите внешний запрос. Не делайте вывод по панели управления: подтверждением служит фактический ответ сервера.

Ловушка robots.txt

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

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

Официальные справки Яндекс Вебмастера и Google Search Central отдельно отмечают, что директивы читаются только на доступной роботу странице.

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

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

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

Что контролировать дальше

Автоматический мониторинг в Web-Puls полезен для контроля доступности критичных URL, но один HTTP 200 не подтверждает отсутствие noindex. Проверку статуса стоит дополнять контролем индексирующих директив после релизов, переноса сайта и изменения SEO-шаблонов.

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

Проверьте свой сайт прямо сейчас

Введите адрес сайта: Web-Puls покажет HTTP-код, время ответа и базовую диагностику. Для постоянного контроля можно подключить мониторинг.

Нужна помощь с диагностикой ошибки?

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