robots.txt и meta robots: чем они отличаются и как случайно закрыть сайт от поисковых систем

Сайт обновили вечером.

Новый релиз успешно запустился.

Главная открывается.

Статьи работают.

Формы отправляются.

PageSpeed в норме.

Через несколько дней владелец замечает странное:

Новые страницы не появляются в Яндексе и Google.

Ещё позже начинают исчезать старые.

Разработчик проверяет:

HTTP 200 ✓
TITLE ✓
H1 ✓
canonical ✓
sitemap.xml ✓

На первый взгляд SEO исправно.

Потом открывается:

https://example.ru/robots.txt

а там:

User-agent: *
Disallow: /

Эта конфигурация была нужна на staging.

Но вместе с очередным deployment попала в production.

С точки зрения пользователей сайт продолжал работать.

С точки зрения поисковых роботов владелец фактически сообщил:

Не обходите мой сайт.

Это один из тех SEO-дефектов, которые почти невозможно заметить глазами при обычном просмотре приложения.

И одновременно хороший пример того, почему важно понимать разницу между:

robots.txt

и:

<meta name="robots">

На первый взгляд оба инструмента «что-то запрещают поисковикам».

Но на самом деле они решают разные задачи.

Главное различие в одном предложении

robots.txt в первую очередь отвечает на вопрос:

Разрешено ли роботу запрашивать этот URL?

А:

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

отвечает:

Если робот получил эту страницу, разрешено ли включать её в поисковый индекс?

Именно поэтому нельзя считать эти механизмы взаимозаменяемыми.

Упрощённо:

                 URL
                  │
                  ▼
             robots.txt
                  │
          Можно скачать?
             /         \
           нет          да
            │            │
      crawler stop       ▼
                    HTTP response
                          │
                          ▼
                    meta robots
                 / X-Robots-Tag
                          │
                    Индексировать?
                     /         \
                   нет          да
                    │            │
                 noindex       возможно
                              попадёт
                              в индекс

Это различие кажется небольшим.

Но большая часть опасных ошибок возникает именно из-за его непонимания.

Что такое robots.txt

robots.txt — обычный текстовый файл в корне сайта:

https://example.ru/robots.txt

В нём сайт сообщает поисковым роботам, какие URL им разрешено или запрещено обходить.

Google прямо описывает robots.txt как механизм управления доступом crawler к URL, а не как способ гарантированно удалить веб-страницу из Google.

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

Простейший robots.txt

Например:

User-agent: *
Disallow:

Концептуально означает:

всем роботам
можно обходить всё.

А вот это уже запрет всего сайта

User-agent: *
Disallow: /

Символ:

/

означает корень сайта.

Следовательно:

/example
/expert
/services
/prices
/

попадают под запрет обхода.

Это одна из самых опасных строк технического SEO.

Почему такой файл часто появляется случайно

Потому что на staging он вполне оправдан.

Например:

staging.example.ru

не должен появляться в поиске.

Разработчик создаёт:

User-agent: *
Disallow: /

В тестовой среде всё правильно.

Позже происходит:

staging config
      ↓
production build
      ↓
robots.txt
      ↓
Disallow: /

Приложение работает идеально.

Но crawler получает совершенно другую картину.

Поэтому robots.txt — часть production-конфигурации

Его нельзя воспринимать как статический файл:

Один раз сделали — больше не трогаем.

Он должен проверяться после deployment так же, как:

/api/ready
/sitemap.xml
/robots.txt

и ключевые public routes.

Что делает User-agent

Например:

User-agent: *

означает:

Следующие правила предназначены для всех подходящих роботов.

Можно задавать правила и конкретному crawler.

Например логически:

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

Но чем сложнее индивидуальные правила, тем выше риск, что:

Google видит одно;
Яндекс — другое;
другой crawler — третье.

Поэтому без реальной необходимости конфигурацию лучше сохранять простой.

Disallow запрещает crawling

Например:

User-agent: *
Disallow: /admin/

говорит crawler:

Не запрашивай URL, начинающиеся с /admin/.

Это логично для технических страниц.

Например:

/admin/
/internal-search/
/logs/

если они вообще публично доступны.

Но здесь появляется важное заблуждение

Разработчик думает:

Раз Googlebot не может зайти на страницу, значит она точно не появится в Google.

Не обязательно.

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

Яндекс сообщает аналогичную важную особенность: страницы, запрещённые в robots.txt, всё ещё могут участвовать в поиске.

Как такое возможно

Представим:

https://example.ru/private-page

закрыта:

Disallow: /private-page

Но десять других сайтов ссылаются на неё.

Поисковая система может знать:

URL существует;
на него ссылаются;

хотя содержимое ей получить нельзя.

Поэтому robots.txt — не защита конфиденциальных данных

Это принципиально.

Если страница содержит:

личные данные;
документы;
платёжную информацию;
внутреннюю CRM;
административную панель,

нельзя считать:

Disallow: /admin/

системой безопасности.

Правильная защита:

authentication;
authorization;
server-side access control.

Для недоступных посторонним страниц сервер должен реально отказывать в доступе.

Яндекс также рекомендует для конфиденциальных страниц использовать авторизацию и соответствующие HTTP-коды, а не полагаться на поисковые директивы как на защиту информации.

Robots.txt — инструкция добросовестному crawler

Не firewall.

Не authorization.

Не ACL.

Не защита от злоумышленника.

Любой клиент может вручную открыть:

/robots.txt

увидеть:

Disallow: /secret-admin/

и затем попробовать запросить:

/secret-admin/

Если сервер отдаёт страницу без авторизации, проблема уже не SEO.

Это security defect.

Что такое meta robots

Теперь другой механизм.

В HTML страницы можно добавить:

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

Эта директива говорит поддерживающему её поисковому роботу:

Страницу можно получить и прочитать, но включать её в результаты поиска не нужно.

Google именно так определяет noindex: после обхода страницы и обнаружения директивы документ удаляется из результатов Google Search.

Яндекс также поддерживает:

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

и указывает, что такая страница не должна включаться в поисковые результаты.

Это принципиально другая модель

robots.txt:
не приходи читать страницу

а:

meta robots noindex:
приходи,
прочитай,
но не включай в индекс

Именно поэтому noindex должен быть доступен crawler

И вот здесь возникает одна из самых распространённых SEO-ошибок.

Разработчик хочет удалить страницу из поиска.

Он делает одновременно:

robots.txt:
Disallow: /old-page

и внутри HTML:

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

Кажется:

Запретили два раза — значит наверняка.

На самом деле эти правила могут мешать друг другу.

Почему Disallow + noindex — опасная комбинация

Чтобы поисковик увидел:

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

ему нужно получить HTML страницы.

Но robots.txt говорит:

HTML получать нельзя.

Получается:

Crawler
   ↓
robots.txt
   ↓
Disallow
   ↓
HTML не скачан
   ↓
noindex не прочитан

Google прямо предупреждает: noindex работает только тогда, когда Googlebot может получить страницу. Если URL заблокирован через robots.txt, Google не увидит noindex, а URL при определённых обстоятельствах всё ещё способен оставаться в результатах поиска.

Яндекс тоже отдельно указывает: если страница запрещена в robots.txt, meta- или HTTP-директива страницы не применяется, поскольку робот не может её получить и прочитать.

Поэтому для удаления уже известной страницы из поиска

Обычно требуется разрешить crawler получить её:

robots.txt:
Allow crawling

и вернуть:

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

либо соответствующий:

X-Robots-Tag: noindex

Тогда логика последовательна:

crawler получает страницу
          ↓
читает noindex
          ↓
поисковая система
обновляет индекс

А если страница вообще удалена

Тогда noindex может не понадобиться.

Например документ больше не существует:

/article-old

Без замены:

404

или:

410.

Это уже корректно описывает состояние ресурса.

Не нужно одновременно:

404
+
noindex
+
Disallow
+
canonical на главную.

Чем меньше противоречивых сигналов, тем лучше.

X-Robots-Tag — тот же уровень, но через HTTP

Вместо HTML:

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

сервер может вернуть:

HTTP/1.1 200 OK
X-Robots-Tag: noindex

Для Google X-Robots-Tag позволяет использовать те же robots rules на уровне HTTP response. Особенно полезно это для ресурсов, где HTML <meta> вообще невозможно добавить, например PDF.

Яндекс также поддерживает:

X-Robots-Tag: noindex

для запрета индексирования конкретного URL.

Например PDF

Есть:

/files/internal-report.pdf

HTML <head> там нет.

Но Nginx может вернуть:

X-Robots-Tag: noindex

Теперь ресурс остаётся доступным по ссылке, но поисковым системам передаётся индексная политика.

Почему X-Robots-Tag особенно опасен при ошибочной конфигурации

Потому что его не видно глазами.

Страница:

/services/crm

выглядит нормально.

Исходный HTML:

noindex отсутствует.

Но Nginx возвращает:

X-Robots-Tag: noindex

В браузере пользователь ничего не заметит.

Даже frontend-разработчик может ничего не увидеть.

Например ошибочная конфигурация

Концептуально:

location / {
    add_header X-Robots-Tag "noindex";
}

была нужна тестовой среде.

Попала в production.

Теперь:

/
 /services
 /expert
 /portfolio

все получают:

X-Robots-Tag: noindex.

Сайт визуально полностью работает.

Но весь public URL-space попросил поисковиков не индексировать его.

Поэтому нужно проверять не только HTML

Для SEO-аудита:

View Source

недостаточно.

Нужны ещё реальные HTTP headers.

Например:

GET /expert/article

проверяем:

status;
Content-Type;
X-Robots-Tag;
Location;

Самая опасная ошибка №1: staging noindex попал в production

На staging:

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

совершенно логичен.

Мы не хотим, чтобы тестовый сайт индексировался.

После deployment

Тот же общий layout используется в production.

Получаем:

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

уже на:

https://example.ru/

Пользователь ничего не замечает

Но поисковику мы сказали:

не добавлять страницы
в результаты.

Это классическая массовая SEO-регрессия.

Более безопасная архитектура

Не:

if (maybeProduction) ...

с неясной логикой.

А явная production-конфигурация:

ENVIRONMENT=production
PUBLIC_INDEXING=true

и preflight:

если production
и PUBLIC_INDEXING != true
→ deployment запрещён.

То есть индексирование production должно быть fail-closed для релиза

Лучше вообще не развернуть сайт, чем случайно выкатить:

noindex

на весь домен и обнаружить это через неделю.

Самая опасная ошибка №2: Disallow: /

Это robots-аналог той же проблемы.

Staging:

User-agent: *
Disallow: /

Production должен иметь другую политику.

Но release забирает staging robots.txt.

Как обнаружить

Обычный production smoke test:

GET /robots.txt

и проверка:

не содержит ли production
глобального Disallow: /

если такой запрет не является осознанным.

Полезно иметь отдельный тест важных URL

Например:

/
/expert
/expert/article
/services/crm
/prices

должны быть разрешены правилами production robots.txt.

Самая опасная ошибка №3: закрыли целый раздел вместо одной страницы

Хотели запретить:

/admin/login

написали слишком широкое:

Disallow: /a

или неудачное wildcard-правило.

И вместе с admin блокируются другие URL, подходящие под шаблон.

Особенно осторожно со специальными символами

Яндекс прямо предупреждает о неочевидной ошибке с символом #: поскольку в robots.txt он обозначает начало комментария, правило вида:

Disallow: /#

будет интерпретироваться иначе, чем разработчик может ожидать, и способно превратиться фактически в запрет корня.

Чем хитрее шаблон — тем обязательнее автоматический тест.

Самая опасная ошибка №4: CMS поставила noindex всему разделу

Например в CMS есть настройка:

Не индексировать страницу

Разработчик хотел применить её к одной тестовой публикации.

Но значение наследуется:

Экспертный центр
      ↓
все статьи

И получается:

35 / 50 / 100 материалов

с:

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

Именно поэтому noindex должен быть частью модели страницы

Например:

SEO policy:
INDEX
NOINDEX

и админ-панель должна ясно показывать состояние.

Не скрытый checkbox в глубокой настройке шаблона.

Можно даже показывать предупреждение

Например:

⚠ Страница опубликована,
но закрыта от поисковой индексации.

Это намного понятнее для редактора.

Самая опасная ошибка №5: новый layout получил noindex

Допустим:

/security
/terms

изначально создавались как служебные страницы.

Общий template:

noindex.

Позже тот же layout начинают использовать:

/services/*

Но индексная политика наследуется автоматически.

В результате коммерческие страницы оказываются закрыты.

Индексная политика должна принадлежать типу страницы

Например:

expert_article
→ index

service_page
→ index

public_portfolio
→ index

internal_search
→ noindex

admin
→ authentication

customer_account
→ authentication

Это безопаснее общих CSS/layout-категорий.

Не всё, что не нужно индексировать, нужно закрывать robots.txt

Представим:

/search?q=crm

Мы не хотим поисковые результаты сайта в Google.

Можно подумать:

Disallow: /search

Иногда это часть crawl policy.

Но если цель именно:

Страница доступна crawler, но не должна попадать в индекс,

то noindex описывает намерение намного точнее.

Robots.txt больше связан с crawl budget и пространством URL

Например сайт генерирует огромное число технических маршрутов:

/calendar/2030/...
/search?...
/logs/...

Crawler вообще не обязательно должен туда постоянно ходить.

Тогда robots rules могут уменьшать ненужный crawling.

Google прямо указывает, что robots.txt используется в первую очередь для управления crawler traffic.

А meta robots — про судьбу полученного документа в поиске

Например:

/thank-you

должна работать для пользователя.

Но отдельная поисковая посадочная страница из неё не нужна.

Можно вернуть:

200

и:

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

Но не используйте noindex вместо авторизации

Например:

/account/invoices

содержит счета клиента.

Если просто поставить:

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

страница всё равно доступна любому, кто знает URL, если сервер больше никак её не защищает.

noindex только просит поисковые системы не показывать документ.

Он не контролирует доступ человека.

Безопасность:

authentication
+
authorization.

SEO:

robots/indexing directives.

Это разные слои.

Что означает index, follow, noindex и nofollow

Самые известные директивы:

index
noindex
follow
nofollow

index

Фактически обычное разрешённое состояние.

Если специального ограничения нет, поисковик может индексировать страницу.

Google указывает, что all является значением по умолчанию и явное его указание обычно ничего не меняет.

Поэтому:

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

чаще всего не требуется.

noindex

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

означает:

Не показывать эту страницу в поисковой выдаче.

nofollow

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

означает для поддерживающего crawler:

Не переходить по ссылкам этой страницы в соответствии с данной директивой.

У Google nofollow является именно page-level правилом в robots meta/X-Robots-Tag.

none

Например:

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

у Google эквивалентно:

noindex, nofollow.

Не добавляйте nofollow автоматически ко всему noindex

Иногда встречается шаблон:

если noindex
→ всегда nofollow.

Но это не одно и то же решение.

Страница может быть не нужна в индексе, но содержать полезные ссылки на:

товары;
статьи;
категории.

Поэтому индексную политику и link-follow policy лучше определять осознанно.

Что если в HTML несколько robots meta

Например:

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

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

Не стоит рассчитывать:

Последний победит.

Для Google при конфликтующих robots rules применяется более ограничительная комбинация. Например сочетание общего и специфического правила может в итоге сформировать noindex, nofollow.

Это важно для компонентных приложений

Например:

BaseLayout

добавляет:

index,follow

а:

ArticlePage

случайно добавляет:

noindex.

В DOM находятся оба.

Сайт визуально работает.

Но поисковый робот получает запрещающий сигнал.

Поэтому meta robots должна формироваться в одном месте

Например SEO layer принимает:

page.indexability

и создаёт один итоговый robots contract.

Не несколько компонентов, каждый из которых независимо добавляет <meta>.

То же касается X-Robots-Tag + meta robots

HTML:

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

HTTP:

X-Robots-Tag: noindex

Теперь присутствуют противоречивые правила.

Ограничительный сигнал может победить.

Следовательно:

HTML

и:

HTTP headers

нужно проверять вместе.

Что использовать для PDF

У PDF нет:

<head>

поэтому:

meta robots

не подходит.

Но:

X-Robots-Tag: noindex

подходит отлично.

Google прямо приводит не-HTML файлы — PDF, видео и изображения — как типичный сценарий X-Robots-Tag.

Например

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

Файл можно скачать.

Но поисковику сообщено:

Не показывать этот ресурс как отдельный результат.

Robots.txt и JavaScript/CSS

Есть ещё одна менее очевидная проблема.

Раньше некоторые сайты массово запрещали crawler:

Disallow: /js/
Disallow: /css/

из идеи:

Зачем поисковой системе наши технические файлы?

Но современным crawler может понадобиться JavaScript и CSS, чтобы корректно отрендерить страницу.

Если SEO зависит от JavaScript

например:

HTML shell
↓
JavaScript
↓
Article rendering

а важный JS-файл закрыт для crawler, поисковая система может получить неполный документ.

Поэтому не нужно блокировать ресурсы только потому, что:

Пользователь их напрямую не ищет.

Нужно понимать, участвуют ли они в rendering.

Для SSR/SSG риск меньше

Если сервер сразу отдаёт:

<h1>...</h1>
<p>...</p>

основное содержимое доступно без выполнения клиентского JavaScript.

Но CSS/JS всё равно может быть важен для понимания итогового представления страницы.

Robots.txt не должен конфликтовать с Sitemap

Представим:

sitemap.xml

содержит:

/expert/article

а robots.txt:

Disallow: /expert/

Сайт одновременно говорит:

Вот мои важные страницы.

и:

Не заходите на них.

Такие противоречия нужно ловить автоматически

Например CI получает все URL из sitemap и проверяет:

robots policy:
ALLOWED

для каждой indexable страницы.

Если:

/expert/a
→ blocked

release падает.

Это очень сильный технический SEO-тест

Потому что один:

Disallow: /expert/

может одновременно сломать:

10;
50;
500;
5000

страниц.

Robots.txt и canonical

Представим duplicate page:

/article?ref=x

содержит:

canonical → /article

Но /article?ref=x закрыт:

Disallow

Crawler может не получить HTML и, соответственно, не увидеть canonical.

Это ещё один пример, почему нельзя смешивать механизмы без понимания уровня, на котором они работают.

Если хотите, чтобы crawler обработал canonical

ему нужно получить документ.

То же правило, что и с noindex.

Поэтому crawl control и index control нужно проектировать вместе

Например URL-класс:

tracking_variant

может иметь:

crawl: allow
index: canonical-to-base

Другой:

internal_search

может иметь:

crawl: allow
index: noindex

или другую осознанную политику.

А:

private_account

вообще:

authentication required.

Не robots.

Можно формализовать SEO-policy

Например:

PAGE TYPE          CRAWL      INDEX

Expert article     ALLOW      INDEX
Service page       ALLOW      INDEX
Portfolio case     ALLOW      INDEX
Search results     ALLOW      NOINDEX
Tracking variant   ALLOW      CANONICAL
Admin              AUTH       —
Client account     AUTH       —
Deleted page       404/410    —

Это значительно понятнее набора случайных directives.

Тогда robots.txt строится из архитектуры

Не наоборот.

Сначала определяем:

Какие URL-классы вообще существуют?

Потом:

Какие должны crawled?

Потом:

Какие indexable?

И только после этого создаём технические правила.

Частая ошибка: закрывать фильтры одной строкой

Например:

Disallow: /*?

чтобы не обходить query parameters.

Но среди URL с параметрами могут существовать разные классы:

?utm_source=
→ tracking

?sort=
→ представление

?brand=
→ возможно самостоятельная landing page

?page=
→ пагинация

Одна маска может закрыть полезные страницы.

Особенно осторожно с динамическим каталогом

Правило:

всё с ? запрещаем

может неожиданно убрать доступ crawler к страницам, которые бизнес хотел продвигать.

Сначала классификация URL.

Потом robots policy.

Не наоборот.

Яндекс имеет отдельный Clean-param

Для параметров, которые не меняют содержимое документа, Яндекс поддерживает Clean-param в robots.txt. Он предназначен именно для сигнализации о незначимых GET-параметрах, например tracking-параметрах.

Но это специфическая возможность Яндекса.

Не нужно считать её универсальным стандартом для всех поисковых систем.

Для общей архитектуры URL всё равно полезны:

canonical;
чистые внутренние ссылки;
последовательная parameter policy.

Почему robots.txt не должен использоваться для секретных URL

Допустим существует:

/internal-backup/

и robots.txt содержит:

Disallow: /internal-backup/

Теперь адрес фактически опубликован всем, кто открыл robots.txt.

То есть:

robots.txt

может даже помочь обнаружить чувствительный маршрут.

Настоящее решение:

не публиковать;
аутентифицировать;
закрыть на сетевом уровне.

Как действительно скрыть страницу от посторонних

Например клиентский документ.

Правильная схема:

GET /account/document/123
          ↓
authentication
          ↓
authorization
          ↓
200 / 403

А не:

robots.txt
→ Disallow.

SEO-директивы никогда не должны быть единственной линией security.

Что произойдёт, если robots.txt вообще отсутствует

Не нужно считать:

Без robots.txt поисковики не смогут индексировать сайт.

Обычно отсутствие запретительных правил означает, что crawler не получает от этого файла специальных ограничений.

Яндекс прямо отмечает: если robots.txt не соответствует требованиям или отсутствует в применимом смысле, сайт считается открытым для индексирования/обхода.

То есть robots.txt не обязательно должен быть огромным

Для небольшого нормального публичного сайта он может быть очень простым.

Например концептуально:

User-agent: *
Disallow:

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

И всё.

Не нужно придумывать сто правил только ради того, чтобы файл выглядел «профессионально».

Чем сложнее robots.txt, тем выше цена ошибки

Например:

15 User-agent blocks;
40 wildcard rules;
Allow;
Disallow;
несколько Sitemap;
parameter rules.

Через год уже никто не понимает:

Почему /expert/article запрещён Googlebot, но разрешён Яндексу?

Инфраструктурные правила должны быть настолько простыми, насколько позволяет продукт.

Как случайно закрыть только Google или только Яндекс

Например:

User-agent: Googlebot
Disallow: /

При этом:

User-agent: Yandex
Allow: /

В результате владелец смотрит:

Яндекс индексирует ✓

и думает:

С robots всё нормально.

А Google целиком закрыт.

Или наоборот

Это одна из причин проверять индексируемость отдельно для целевых crawler, а не только визуально читать robots.txt.

Google Search Console и Яндекс Вебмастер

Для диагностики полезно использовать инструменты обеих систем.

В Google проверяем:

может ли Googlebot получить URL;
есть ли noindex;
какой HTML увидел crawler.

Google сам рекомендует при проблемах с присутствием страницы в поиске проверять доступ Googlebot и случайную блокировку в robots.txt, а также искать noindex в HTML.

В Яндекс Вебмастере

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

разрешён ли обход;
есть ли запрещающая директива;
какой статус страницы видит робот.

Но внешние инструменты не заменяют собственные тесты

Search Console обнаружит проблему после того, как Google уже столкнулся с ней.

Гораздо лучше:

CI
↓
deployment
↓
SEO smoke tests
↓
production accepted

и только потом:

Googlebot/YandexBot.

Поисковый робот не должен быть первым автоматическим тестом SEO-конфигурации.

Что тестировать перед релизом

Минимальный набор:

GET /robots.txt
→ 200

проверяем содержание.

Для главной:

/

ожидаем:

crawl allowed;
no noindex.

Для статьи:

/expert/article

ожидаем:

crawl allowed;
index allowed;

Для services:

/services/crm

то же самое.

Для technical/private:

проверяем уже соответствующую продуктовую политику.

Проверяем HTML

У indexable страницы не должно неожиданно появиться:

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

Проверяем headers

Не должно быть:

X-Robots-Tag: noindex

на публичной индексируемой странице.

Проверяем случайное глобальное правило

Например тест должен явно упасть при production:

User-agent: *
Disallow: /

если продукт не находится на запланированной технической паузе.

Можно сделать SEO invariant

Например:

PRODUCTION_PUBLIC_PAGE:
- status = 200
- robots.txt allows URL
- noindex absent
- X-Robots-Tag noindex absent
- canonical valid
- sitemap contains canonical

Это уже не рекомендация.

Это формальный contract.

Очень полезный тест Sitemap vs robots

Берём все:

<loc>

из sitemap.

Для каждого спрашиваем:

разрешён ли URL robots policy?

Если Sitemap говорит:

индексируй

а robots:

не обходи,

CI предупреждает о конфликте.

И обратная проверка

Для всех опубликованных SEO-страниц:

indexable = true

проверяем:

не получили ли они noindex.

Так CMS не сможет случайно опубликовать материал:

Published
+
Noindex

без явного предупреждения.

Как безопасно работать со staging

Лучший вариант — не надеяться только на поисковые директивы.

Например:

staging.example.ru

доступен только:

VPN;
Basic Auth;
internal network.

Теперь поисковый робот физически не сможет получить контент.

Это сильнее, чем просто:

noindex.

Почему

Потому что staging может содержать:

неопубликованные материалы;
тестовые аккаунты;
черновики;
экспериментальные функции.

SEO-директива не является security boundary.

Но если staging всё же публичен

можно добавить дополнительную страховку:

robots.txt:
Disallow: /

и/или соответствующую index policy.

Главное — гарантированно не переносить staging-настройку на production.

Можно сделать environment-aware test

Например:

IF ENV=production
THEN
  robots must allow public routes
  public routes must not noindex

и:

IF ENV=staging
THEN
  public indexing must be disabled

Так правила перестают зависеть от человеческой памяти.

Почему просто проверять наличие meta robots недостаточно

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

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

Разработчик доволен.

Но:

robots.txt:
Disallow: /

Crawler до HTML вообще не доходит.

robots.txt:

Allow

но HTML:

noindex.

Crawler проходит.

Документ всё равно не должен попадать в результаты.

Поэтому нужно проверять весь pipeline

URL
↓
robots.txt
↓
HTTP status
↓
X-Robots-Tag
↓
HTML meta robots
↓
canonical
↓
content
↓
indexing

Каждый слой отвечает за своё.

Где находится canonical

Canonical не разрешает индексирование и не запрещает crawling.

Он отвечает на другой вопрос:

Какой URL считать основным среди одинаковых или очень похожих документов?

То есть:

robots.txt
→ crawl

meta robots
→ indexability

canonical
→ canonicalization.

Это три независимых понятия.

Пример правильной обычной статьи

URL:
/expert/api-versioning

robots:
ALLOW

HTTP:
200

X-Robots-Tag:
нет запрещающих правил

meta robots:
indexable/default

canonical:
/expert/api-versioning

sitemap:
yes

Сигналы согласованы.

Пример удалённой статьи

URL:
/expert/old

HTTP:
410

sitemap:
no

internal links:
no

Не нужно добавлять ещё:

Disallow
+
noindex
+
canonical /

Ресурс уже честно сообщил своё состояние.

Пример внутреннего поиска

/search?q=crm

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

HTTP 200
meta robots noindex

может быть понятной политикой.

Пример аккаунта пользователя

/account

Главная политика:

authentication
+
authorization.

А SEO становится вторичной задачей.

Пример tracking URL

/article?utm_source=telegram

Не обязательно закрывать его в robots.txt.

Можно позволить crawler увидеть:

canonical → /article.

Почему этот принцип важен

Если заблокировать tracking-вариант до получения HTML:

Disallow

crawler не сможет прочитать canonical на основной URL.

Иногда запрет обхода технически оправдан.

Но он должен быть выбран сознательно, а не потому, что:

Параметры выглядят некрасиво.

Нужно ли использовать robots.txt для экономии crawl budget

На огромных сайтах — иногда да.

Если существуют:

сотни тысяч;
миллионы

бесполезных комбинаций URL, crawl management становится серьёзной задачей.

Google действительно позиционирует robots.txt прежде всего как инструмент управления crawler traffic.

Но для сайта с несколькими десятками или сотнями полезных страниц

не нужно превращать crawl budget в мистическую оптимизацию.

Гораздо важнее:

правильные URL;
внутренние ссылки;
sitemap;
HTTP;
canonical;
отсутствие случайного noindex.

robots.txt не улучшает ранжирование сам по себе

Нельзя написать:

Disallow: /bad-pages/

и получить:

+10 позиций.

Его задача техническая:

управление crawling.

Так же:

noindex

не является способом повысить позиции нужной страницы автоматически.

Это управление составом поискового индекса.

Нужно быть осторожным с массовым noindex

Представим SEO-аудит показывает:

500 слабых страниц.

Команда одним release ставит:

noindex

на весь тип страниц.

Но среди них оказывается:

20 страниц

с реальным organic traffic.

SEO-cleanup превращается в потерю поиска.

Поэтому перед массовым noindex нужна классификация

Например:

traffic;
impressions;
backlinks;
business value;
content uniqueness.

И только потом решение.

Не:

этот template кажется неважным
→ noindex всё.

То же относится к robots Disallow

Маска может затронуть намного больше страниц, чем предполагает человек.

Поэтому любые wildcard/широкие правила должны проходить:

positive tests;
negative tests.

Должно быть заблокировано:

/internal-search/

Должно оставаться разрешено:

/expert/search-engine-indexing

Если правило случайно блокирует оба — CI падает.

Роботы разных поисковых систем могут интерпретировать детали по-разному

Яндекс прямо напоминает, что роботы других поисковых систем и сервисов могут по-разному обрабатывать отдельные robots directives.

Поэтому лучше строить критичную индексную политику на хорошо поддерживаемых стандартных механизмах:

HTTP;
robots.txt crawling rules;
meta robots;
X-Robots-Tag;
canonical.

А search-engine-specific возможности использовать только там, где они действительно нужны.

Самый безопасный public robots.txt часто самый скучный

Это нормально.

SEO-инфраструктура не должна впечатлять количеством правил.

Она должна быть предсказуемой.

Например:

User-agent: *
Disallow:

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

плюс только действительно необходимые ограничения.

Когда robots.txt становится длинным

это хороший повод спросить:

Почему у нашего публичного сайта вообще существует столько crawler-доступных технических URL?

Возможно проблема не в robots.txt.

А в routing architecture.

Лучший способ бороться с нежелательными URL — не создавать их без необходимости

Например вместо:

100 вариантов параметров

можно:

нормализовать routing;
не создавать ссылки;
использовать canonical;
ограничить генерацию.

Robots — последняя часть системы.

Не первая.

Как выглядит хороший SEO lifecycle страницы

Публичная статья

Published
↓
HTTP 200
↓
crawl allowed
↓
index allowed
↓
self-canonical
↓
sitemap

Черновик

Не должен становиться обычной публичной SEO-страницей вообще.

Лучше:

authorization / preview token

чем:

public URL + надежда на noindex.

Удалённая

404/410
↓
нет в sitemap
↓
нет внутренних ссылок.

Внутренняя

auth
↓
crawler не получает private content.

Это намного понятнее смешанной схемы

Disallow
+
noindex
+
nofollow
+
canonical /
+
302

на одном URL.

Когда требуется пять механизмов одновременно, почти наверняка стоит заново сформулировать:

Что именно мы хотим сказать поисковику?

Практическая таблица

Практический production checklist

Перед каждым значимым релизом SEO-системы стоит проверить:

• /robots.txt существует и возвращает ожидаемый ответ;
• production robots.txt не содержит случайный Disallow: /;
• главная доступна crawler;
• /expert, /services, /portfolio, /prices и другие SEO-разделы не заблокированы;
• Sitemap URLs разрешены robots policy;
• публичные indexable страницы не содержат meta robots noindex;
• публичные indexable страницы не получают X-Robots-Tag: noindex;
• нет противоречивых robots meta tags;
• staging не индексируется;
• production и staging используют разные проверяемые policies;
• private pages защищены авторизацией, а не только robots.txt;
• removed pages используют правильный HTTP lifecycle;
• canonical-страницы доступны crawler;
• важные JS/CSS assets не закрыты без причины;
• правила для параметров не блокируют полезные landing pages;
• широкие Disallow проходят тесты на конкретных URL;
• Search Console и Яндекс Вебмастер не показывают неожиданные crawl/index blocks.

Очень полезный автоматический тест

Создаём список обязательных indexable routes:

/
/services
/prices
/portfolio
/expert
/expert/test-article

После deployment проверяем каждый:

HTTP = 200
robots.txt = allowed
meta noindex = false
X-Robots-Tag noindex = false

Если хотя бы одно условие нарушено:

release failed.

Отдельный тест staging

environment = staging

ожидает противоположную политику:

public indexing disabled.

Так одна и та же система тестов одновременно гарантирует:

production открыт

и:

staging закрыт.

Это намного надёжнее человеческого правила

Перед релизом не забудь поменять robots.txt.

Человек однажды забудет.

CI — не должен.

Почему это особенно важно для динамической редакционной системы

Когда статей:

10

их ещё можно проверить вручную.

Когда:

100;
500;
5000,

невозможно открывать каждую и искать:

noindex.

Индексная политика должна автоматически следовать состоянию контента.

DRAFT
→ private preview

SCHEDULED
→ private/not public

PUBLISHED
→ indexable

ARCHIVED
→ определяется бизнес-политикой

DELETED
→ 404/410

Тогда редактор не занимается техническими тегами.

Он управляет жизненным циклом материала.

А SEO-система сама формирует правильный HTTP/robots contract.

Это лучший вариант

Редактор принимает бизнес-решение:

Опубликовать.

Система автоматически выполняет:

route
TITLE
description
canonical
robots policy
structured data
sitemap
internal listing

И тестирует результат.

Тогда noindex становится осознанным исключением

Например:

спецстраница для рекламной кампании,
которую нельзя показывать в organic search.

Администратор явно выбирает:

Search indexing:
OFF

и получает предупреждение.

Не должно существовать скрытого noindex

Самая плохая ситуация:

Почему страница не индексируется?

А ответ:

Потому что два года назад в layout случайно поставили meta tag.

SEO-policy должна быть наблюдаемой.

Что можно показывать в админ-панели

Например возле статьи:

Search:
INDEXABLE ✓

Canonical:
https://...

Sitemap:
INCLUDED ✓

Robots:
ALLOWED ✓

или:

Search:
NOINDEX ⚠

Теперь даже контент-менеджер видит техническое состояние страницы.

А ещё можно добавить глобальную SEO-диагностику

Например:

Indexable pages: 184
Noindex pages: 12
Blocked by robots: 4
Canonical conflicts: 0
Sitemap conflicts: 0

Тогда ошибка Disallow: / становится видна сразу, а не после падения поискового трафика.

Что делать, если сайт уже случайно закрыли

Представим production несколько дней содержал:

User-agent: *
Disallow: /

или:

X-Robots-Tag: noindex.

Первое действие — не паниковать и не начинать хаотично менять всё SEO.

Сначала исправляем реальную причину

Например robots.txt:

public routes разрешены.

Или удаляем:

noindex

из production response.

Затем проверяем реальный HTTP

Не repository.

Не локальную версию.

А:

production domain.

Проверяем:

/robots.txt
/
/expert
несколько статей.

После этого — поисковые инструменты

В Google:

URL Inspection.

В Яндексе:

Проверка страницы;
robots.txt analysis;
переобход при необходимости.

Google рекомендует URL Inspection именно для проверки того, какой HTML и какие index directives реально получил Googlebot.

Яндекс предоставляет аналогичные инструменты проверки страницы и анализа robots.txt.

Но возврат не обязан быть мгновенным

Поисковой системе нужно:

повторно получить robots.txt;
повторно обойти URL;
увидеть изменившиеся directives;
пересчитать состояние документа.

Это асинхронный процесс.

Поэтому правильная задача после исправления:

подтвердить,
что технический запрет снят.

А не:

Через пять минут страница обязана вернуться на старую позицию.

Самый важный принцип

Не нужно думать:

robots.txt = запрет индексации

и:

meta robots = ещё один способ
сделать то же самое.

Правильнее:

robots.txt
=
управление crawling

meta robots / X-Robots-Tag
=
управление индексированием
и представлением документа

Из этого следует почти всё остальное

Если поисковику нужно увидеть:

noindex;
canonical;
контент;

нужно позволить ему получить страницу.

Если URL содержит конфиденциальные данные:

robots.txt и noindex

вообще не являются основной защитой.

Если страница удалена:

HTTP 404/410

лучше описывает состояние.

Если URL переехал:

301.

Если есть технический дубль:

canonical.

Каждый инструмент имеет свою область ответственности.

Вместо вывода

robots.txt и meta robots часто находятся в одном разделе SEO-инструкций, поэтому легко решить, что они делают почти одно и то же.

На практике разница фундаментальная.

robots.txt стоит до страницы:

Crawler
   ↓
robots.txt
   ↓
можно ли вообще запросить URL?

А meta robots находится внутри уже полученной страницы:

HTTP
   ↓
HTML
   ↓
<meta name="robots">
   ↓
что делать с документом
в поисковом индексе?

X-Robots-Tag решает похожую индексную задачу на уровне HTTP response и особенно полезен для не-HTML ресурсов.

Именно поэтому один из самых опасных SEO-антипаттернов выглядит так:

robots.txt:
Disallow: /page

page:
noindex

Разработчик думает:

Дважды запретили индексирование.

А crawler отвечает:

Вы не позволили мне получить страницу, поэтому второй запрет я вообще не увидел.

Ещё опаснее массовые ошибки:

Disallow: /

или:

X-Robots-Tag: noindex

на production.

Сайт продолжает работать для пользователей, поэтому дефект может долго оставаться незаметным.

Поэтому правильная SEO-архитектура должна исходить не из тегов, а из состояния каждого класса страниц:

Можно ли crawler её получать?
Нужно ли её индексировать?
Она публичная или приватная?
Она существует или удалена?
Это самостоятельная страница или дубль?

После этого механизм выбирается естественно:

crawl control
→ robots.txt

index control
→ meta robots / X-Robots-Tag

security
→ authentication / authorization

deleted
→ 404 / 410

moved
→ 301

duplicate
→ canonical

А главное правило production звучит ещё проще:

поисковая индексация не должна зависеть от того, вспомнил ли разработчик перед релизом удалить Disallow: / или noindex.

Эти условия должны проверяться автоматически.

Тогда поисковые роботы перестают быть первыми, кто обнаруживает ошибку конфигурации сайта.