# Страница отвечает 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
Проверяйте сверху вниз:
- настройку индексации страницы и SEO-плагина в CMS;
- общий шаблон
headи условие для категории, фильтра или пагинации; - middleware приложения и переменные окружения, особенно после переноса со стенда;
- конфигурацию nginx, Apache или панели хостинга;
- правила reverse proxy и CDN;
- кэш страницы и заголовков на каждом слое.
После изменения очистите только относящийся к 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, время проверки и приложите обезличенные заголовки ответа.