robots.txt, noindex и X-Robots-Tag: три механизма, которые легко перепутать

robots.txt, noindex и X-Robots-Tag решают разные задачи. robots.txt управляет тем, какие URL crawler может запрашивать; noindex запрещает показывать полученный документ в поисковой выдаче; X-Robots-Tag передаёт такие же page-level директивы через HTTP-заголовок и особенно полезен для не-HTML файлов. Отсюда следует неочевидное, но важное правило: если закрыть страницу в robots.txt и одновременно поставить на неё noindex, поисковый робот может не увидеть noindex вообще. Для удаления URL из Google Search страницу, наоборот, нужно оставить доступной для обхода, чтобы Googlebot смог прочитать запрет на индексирование.

Сначала разделим crawling и indexing

Большинство ошибок здесь начинается с фразы «закрыть страницу от поисковика». Она слишком расплывчата. Что именно нужно закрыть?

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

Это разные задачи. Google описывает robots.txt прежде всего как механизм управления crawler traffic. Для исключения HTML-страницы из Search предназначен noindex. А если информация действительно приватная, neither robots.txt nor noindex is an access-control mechanism — нужен серверный контроль доступа, например авторизация.

Задача	Подходящий механизм	Что он не гарантирует
Не давать crawler запрашивать URL	`robots.txt`	Что сам URL никогда не появится в поиске
Не показывать HTML-страницу в Search	`<meta name="robots" content="noindex">`	Что пользователь не сможет открыть страницу напрямую
Не индексировать PDF или другой не-HTML файл	`X-Robots-Tag: noindex`	Физическую приватность файла
Скрыть приватные данные от посторонних	Авторизация / контроль доступа	Решать эту задачу через robots-директивы не следует

robots.txt управляет доступом crawler к URL

Robots Exclusion Protocol стандартизирован в RFC 9309. В практической конфигурации файл robots.txt размещается в корне сайта и содержит группы правил для crawler user agents.

User-agent: *
Disallow: /private-section/

User-agent: Googlebot
Allow: /private-section/public-page/

Sitemap: https://example.com/sitemap.xml

Для Google базовые поля — user-agent, allow, disallow и sitemap. При этом область действия robots-файла привязана к конкретным host, protocol и port. Например, правила из https://example.com/robots.txt не становятся автоматически правилами для https://sub.example.com/ или для нестандартного порта.

Это не формальность. После миграции между поддоменами или смены технической схемы легко проверить «правильный robots.txt», но не тот, который реально относится к исследуемому URL.

Disallow не означает noindex

Представим URL:

https://example.com/report/

robots.txt:
User-agent: Googlebot
Disallow: /report/

Googlebot не должен запрашивать содержимое этого URL. Но если на страницу ведут ссылки с других доступных страниц или внешних сайтов, Google может знать о самом адресе. В документации Search Central прямо отмечено: URL, закрытый в robots.txt, всё ещё может появиться в результатах поиска без нормального описания содержимого.

То есть Disallow отвечает на вопрос «можно ли crawler получить этот URL?», а не «может ли адрес существовать в индексе как известный URL?».

Поэтому robots.txt плохо подходит для задачи «эта веб-страница не должна присутствовать в Google Search». Для неё есть отдельный механизм.

noindex запрещает индексирование доступного документа

Для обычной HTML-страницы noindex можно передать через robots meta tag:

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

Когда Googlebot получает страницу и извлекает эту директиву, Google удаляет её из Search results или не добавляет туда. Директива может относиться ко всем поддерживающим её поисковым crawler через name="robots" либо быть адресована Google:

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

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

Отсюда и типовая ошибка:

robots.txt:
Disallow: /report/

HTML /report/:
<meta name="robots" content="noindex">

Google Search Central отдельно предупреждает, что такая комбинация может помешать применению noindex. Если crawler не может запросить страницу, он не видит ни robots meta tag, ни соответствующий HTTP header.

noindex в robots.txt для Google не поддерживается

Иногда встречается такая запись:

User-agent: *
Noindex: /old-section/

Для Google это не рабочий способ запретить индексирование. Search Central прямо указывает, что правило noindex в robots.txt не поддерживается.

Если URL должен быть доступен crawler, но не должен присутствовать в Search, используйте noindex в HTML или X-Robots-Tag в HTTP response. Если URL вообще не должен запрашиваться crawler, тогда задача уже относится к Disallow.

X-Robots-Tag переносит robots-директивы в HTTP-заголовок

Не каждый индексируемый ресурс является HTML-документом. У PDF, изображения или другого файла может не быть HTML <head>, куда можно вставить meta robots.

Для таких случаев существует response header:

HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex

Google поддерживает в X-Robots-Tag те же indexing and serving rules, которые доступны через robots meta tag. Поэтому этот механизм полезен не только для PDF: его можно применять и к HTML, если удобнее управлять директивами на уровне веб-сервера или приложения.

Главное различие не в силе noindex, а в месте передачи команды:

Механизм	Где находится	Подходит для
robots meta tag	В HTML	HTML-страниц
`X-Robots-Tag`	В HTTP response headers	HTML и не-HTML ресурсов, включая PDF

И для header действует та же зависимость: crawler должен получить HTTP-ответ, чтобы прочитать X-Robots-Tag.

Почему «закрыть PDF в robots.txt и поставить X-Robots-Tag» может не сработать

Допустим, сервер настроен так:

robots.txt:
User-agent: Googlebot
Disallow: /files/report.pdf

response /files/report.pdf:
X-Robots-Tag: noindex

Логика кажется двойной страховкой, но механизмы конфликтуют по порядку выполнения. Robots rule запрещает crawler запрашивать PDF. Значит, header с noindex он тоже не получает.

Если задача именно исключить PDF из Google Search через X-Robots-Tag, Googlebot должен иметь возможность запросить файл и увидеть header. Если цель другая — не давать crawler скачивать файл, — это уже crawling-control, и результат нужно оценивать именно в этой рамке.

index и follow обычно не нужно прописывать явно

Можно встретить:

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

Для Google это допустимо, но значения index и follow являются поведением по умолчанию и обычно не требуют явной записи.

Гораздо важнее проверять реальные ограничения: случайный noindex, crawler-specific директиву, ответ на уровне X-Robots-Tag, CMS-настройку или robots.txt rule. Особенно на сайтах, где несколько систем одновременно меняют HTTP headers и HTML head.

Конфликтующие robots meta rules работают не как «последняя строка победила»

Если на странице присутствует несколько robots directives, нельзя безопасно рассчитывать, что браузерный порядок тегов определит итог. Google агрегирует поддерживаемые правила, а при конфликте применяет более ограничивающую директиву.

Например:

<meta name="robots" content="max-snippet:50">
<meta name="robots" content="nosnippet">

Для Google сработает более ограничивающее nosnippet. Это полезно помнить при шаблонах CMS: один plugin может добавлять общую директиву, а другой — собственный meta robots.

Проверять нужно итоговый HTML и response headers, которые реально получает crawler, а не только настройки административной панели.

JavaScript может менять robots meta, но здесь есть опасная асимметрия

Google умеет обрабатывать robots meta tag, добавленный JavaScript. Например, приложение может поставить noindex, если API вернул пустой объект.

Но обратная операция ненадёжна: если исходный HTML уже содержит noindex, Google может не выполнять дальнейший rendering и JavaScript. Поэтому сценарий «сначала отдаём noindex, потом JS снимает его для хороших страниц» способен оставить индексируемый документ закрытым.

Google рекомендует не использовать noindex в исходном коде страницы, если она должна индексироваться. Разницу между source HTML и rendered DOM мы отдельно разберём в статье про JavaScript и индексирование.

robots.txt не является механизмом защиты данных

Файл robots.txt публичен. Любой пользователь может открыть его и увидеть закрытые path patterns. Более того, правила REP основаны на добровольном соблюдении crawler: добросовестные поисковые роботы учитывают их, но это не authentication layer.

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

Поэтому для счетов, персональных кабинетов, внутренних отчётов или документов с ограниченным доступом нужен серверный механизм: логин, ACL, VPN, signed URL или другая подходящая схема авторизации. Robots directives могут дополнять такую архитектуру, но не заменять её.

robots.txt и canonical решают разные задачи

Ещё одна частая подмена: закрыть дубли в robots.txt вместо того, чтобы определить основную версию URL. Но crawler blocking и canonicalization — не одно и то же.

Если поисковой системе нужно увидеть дублирующую страницу и её rel="canonical", блокировка этого URL в robots.txt мешает получить сам документ и прочитать canonical annotation.

Когда задача состоит в выборе основной версии среди доступных похожих URL, нужно отдельно проверить canonical-сигналы, редиректы, внутренние ссылки и sitemap. Эта логика разобрана в материале «Canonical URL и дубли страниц».

Матрица выбора: что использовать в конкретной ситуации

Ситуация	Что использовать	Чего избегать
Страница нужна пользователям, но не должна быть в Google Search	Разрешить crawling + `noindex`	Не блокировать её одновременно в robots.txt
PDF не должен индексироваться	Разрешить fetch + `X-Robots-Tag: noindex`	Не закрывать тот же PDF от Googlebot, если crawler должен увидеть header
Технический раздел не нужно обходить	`Disallow` в robots.txt, если это соответствует задаче	Не считать Disallow гарантией отсутствия URL в Search
Контент приватный	Серверная авторизация / access control	Не полагаться на robots.txt или noindex как на защиту
Нужно выбрать основную версию дублей	Canonicalization strategy	Не подменять canonicalization случайной блокировкой crawling
Страница должна индексироваться	Не блокировать Googlebot и не отдавать noindex	Не надеяться, что JavaScript потом снимет исходный noindex

Как проверить настройку без догадок

Для спорного URL полезно пройти по уровням:

Открыть robots.txt именно для нужного protocol, host и port.
Проверить, разрешён ли fetch конкретному crawler.
Получить фактический HTTP response и посмотреть X-Robots-Tag.
Проверить исходный HTML на robots meta tags.
Если страница JavaScript-зависимая, сравнить исходный и rendered HTML.
Посмотреть, нет ли crawler-specific rules вроде googlebot.
В Search Console использовать URL Inspection для того HTML, который получил Google.

Так быстро выясняется, на каком уровне возникло ограничение. Например, CMS может показывать в панели «индексация разрешена», а reverse proxy добавлять X-Robots-Tag: noindex ко всему разделу. В интерфейсе CMS такой header вообще не будет виден.

Эти директивы — только часть технической готовности страницы

Даже правильная настройка robots/noindex ещё не говорит, что целевой документ технически готов к продвижению. Нужно проверить HTTP-ответ, canonical, исходный и отрендеренный контент, внутреннюю связность и другие условия, которые влияют на доступность страницы для поиска.

Для целевой страницы эти проверки удобнее собирать в один последовательный контроль — от HTTP и robots-директив до canonical, HTML и внутренней структуры.

Самая полезная граница здесь остаётся простой: robots.txt отвечает за возможность обхода, noindex — за присутствие полученного документа в Search, а X-Robots-Tag — это способ передать robots-директиву через HTTP. Если сначала определить задачу, большинство «противоречивых» настроек перестают быть загадкой.

Источники

Источники проверены 19 августа 2026 года. Для Robots Exclusion Protocol использован RFC 9309; поведение Google сверено с актуальной документацией Google Search Central и Google Crawling Infrastructure.