Два разных механизма

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

Для Google запрет обхода через robots.txt не является надёжным способом убрать HTML-страницу из поиска: адрес может быть известен по внешним ссылкам и появляться без обхода содержимого. Google отдельно предупреждает об этом ограничении. Документация robots.txt.

Правило noindex передают через метатег или HTTP-заголовок. Чтобы Google прочитал его, ресурс должен быть доступен для обхода; закрытие той же страницы в robots.txt способно помешать обнаружить правило. Эти условия относятся к поведению Google и не заменяют проверку документации другой поисковой системы. Документация noindex.

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

Исследовать нужно конкретный URL, имя робота и фактический ответ сайта. У основного домена и поддомена могут быть разные настройки. Правило для одного пути не обязательно действует на похожий адрес. Кроме того, HTTP-заголовок может добавляться сервером, промежуточным кешем или системой доставки контента, поэтому отсутствие noindex в исходнике HTML не завершает проверку.

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

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

Практический чек-лист

  • Запишите цель настройки: уменьшить обход технических адресов, исключить публичную страницу из поиска или ограничить доступ к данным.
  • Уточните поисковую систему и робота; не переносите автоматически правила интерпретации между разными системами.
  • Получите robots.txt именно для проверяемого адреса сайта и сохраните его ответ вместе с датой.
  • Проверьте применимость правил к полному пути страницы, включая важные параметры и различия адресов.
  • Исследуйте метатеги в HTML и HTTP-заголовки; запишите все обнаруженные указания, а не только первое.
  • Сопоставьте текущий тест с датой обхода и статусом конкретного URL в панели поисковой системы.
  • Проверьте несколько страниц каждого затронутого шаблона и отделите массовое ограничение от единичного.
  • До изменения конфигурации сохраните материалы, а после — повторите тот же набор проверок.

Гипотетический пример

Предположим, служебную страницу сначала опубликовали без ограничений. Позднее для её раздела добавили Disallow, а затем вставили noindex в HTML. Адрес продолжает появляться в Google. Это не позволяет заключить, что noindex «не работает»: робот мог не получить новую версию из-за запрета обхода. Проверяются последовательность изменений, время обхода и фактическая доступность, а не только наличие обеих строк сейчас.

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

Границы технического вывода

Можно подтвердить наличие ограничения и условия, при которых оно обнаружено. Можно сопоставить его с известной историей. Но без сохранённых версий нельзя уверенно назвать дату появления директивы, а без дополнительных данных — объяснить ею весь спад трафика. Исправление настройки также не означает мгновенного изменения поисковой выдачи: повторный обход и обновление поисковых данных являются отдельными событиями.