Как запретить или открыть сайт для индексации в robots.txt – подробный гайд по настройке файла

ROBOTS.TXT – ЭТО ВАЖНЕЙШИЙ ФАЙЛ ДЛЯ САЙТА. В СВОЕЙ ПРАКТИКЕ КО МНЕ ПРИХОДИЛИ 10-КИ КЛИЕНТОВ, КОТОРЫЕ НЕ ПОНИМАЛИ, ПОЧЕМУ САЙТ НЕ ВИДЕН В ПОИСКОВЫХ СИСТЕМАХ. ПОСЛЕ РАЗРАБОТКИ ПРОЕКТА ПРОГРАММИСТЫ ПРОСТО ЗДАВАЛИ ПРОЕКТ, ЗАКРЫТЫЙ ОТ ИНДЕКСАЦИИ.

Я НАПИСАЛ НАИБОЛЕЕ ПОЛНУЮ ИНСТРУКЦИЮ, КОТОРАЯ ПОЗВОЛИТ ВАМ РАЗОБРАТЬСЯ, КАК ЗАПРЕТИТЬ ИЛИ, НАОБОРОТ, ОТКРЫТЬ САЙТ ДЛЯ ИНДЕКСАЦИИ. ПЛЮС ЕЩЕ МНОЖЕСТВО ПОЛЕЗНЫХ КОМАНД И НАСТРОЕК.

Содержание статьи

— Что такое robots.txt.
— Как полностью закрыть и запретить сайт от индексации.
— Частичная блокировка.
— Как запретить индексацию отдельных файлов или страниц по типу.
— Блокировка поддоменов и зеркал.
— Индексация при использовании CDN и копий сайта.
— Работа с конкретными поисковыми роботами Яндекс и Google.
— Дополнительные директивы в robots.txt.
— Использование мета-тегов для запрета индексации
— Проверка, находится ли страница в индексе.
— FAQ: ответы на частые вопросы.

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

В статье приведена инструкция, которая поможет запретить индексацию + бонусом множество других важных директив. Без лишней теории. Только практические шаги, проверенные на реальных проектах.

Что такое robots.txt

Роль файла в управлении индексацией

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

Где хранится и кто его читает

Файл должен лежать строго по одному адресу на каждом хосте/поддомене:
https://ваш-домен.ru/robots.txt. Его читают все крупные краулеры: Yandex, Googlebot/Bingbot, агрегаторы, парсеры. У каждого поддомена свой файл (например, blog.домен.ru/robots.txt). Если файл перемещен в подпапку или отдан редиректом, часть роботов его проигнорирует.

Ошибки, из-за которых роботы игнорируют файл

Даже один неверный символ в robots.txt может привести к тому, что поисковики просто перестанут его учитывать. Боты не «угадывают» ваши намерения – они читают файл построчно и строго по синтаксису. Поэтому важно не только знать, что запретить, но и как это оформить технически. Вот частые ошибки, из-за которых правила не срабатывают:

• неверное расположение (в папке, а не в корне хоста);
• коды ответа ≠ 200 (404/403/500) или бесконечные редиректы;
• поврежденная кодировка/ BOM, из-за чего первая строка не читается;
• опечатки в директивах (User-agent, Disallow, Allow), лишние символы;
• конфликтующие правила на одном и том же пути, хаотичный порядок;
• кеш на CDN/сервере (файл обновили, а роботы получают старую версию).

💡 Совет: проверьте доступность по прямой ссылке https://домен/robots.txt в браузере (должен вернуться 200 OK и актуальное содержимое). После правок очистите кеш CDN/веб-сервера и прогоните файл через инструменты проверки в Яндекс.Вебмастере и Google Search Console.

Как полностью закрыть и запретить сайт от индексации

Когда нужно временно спрятать сайт от поисковиков, достаточно внести пару строк в файл robots.txt. Основой служат две директивы – User-agent и Disallow. Первая сообщает, для какого робота задается правило, а вторая – какие разделы или страницы ему запрещено просматривать. Если после Disallow указать просто «/», под ограничение попадет весь сайт без исключений.

Чтобы ограничить доступ только для Яндекса, достаточно прописать правило, обращенное к его роботу. А если цель заблокировать все поисковые системы сразу (Google, Bing, Yahoo и др.), применяется универсальная запись с символом «*». Она сообщает любому сканеру: «просмотр запрещен».

Важно понимать, что такой запрет не стирает уже проиндексированные страницы. Они могут оставаться в поисковой выдаче, но обновляться не будут. Если нужно удалить их полностью, придется подключать мета-тег noindex или воспользоваться инструментами удаления в панелях вебмастеров.

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

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

САЙТ ЗАКРЫТ ОТ ИНДЕКСАЦИИ ВСЕМИ ПОИСКОВЫМИ СИСТЕМАМИ

САЙТ ОТКРЫТ ДЛЯ ИНДЕКСАЦИИ ВСЕМИ ПОИСКОВЫМИ СИСТЕМАМИ

Частичная блокировка

Иногда нет необходимости закрывать весь сайт от поисковиков. Нужно лишь скрыть отдельные разделы, например, тестовые страницы, административные панели или внутренние каталоги. В таких случаях применяется частичная блокировка в robots.txt. Это позволяет сохранить индексацию основного контента, но ограничить доступ к техническим или приватным материалам.

Частичная блокировка работает по простой логике. Вы указываете, какие пути должны быть закрыты для роботов. Но, именно здесь часто совершаются ошибки. Главное различать адреса со слэшем и без него.

Важно! Путь /folder и /folder/ – это не одно и то же.

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

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

• отсутствие слэша в конце закрываемой папки;
• использование относительных путей без начального «/»;
• пробелы в начале строки или неверная кодировка файла;
• дублирующие директивы, противоречащие друг другу.

После редактирования файла всегда стоит проверить, что поисковики его читают корректно. Проще всего сделать это через панели вебмастеров. В Яндекс.Вебмастере для этого предусмотрен инструмент «Проверка файла robots.txt». Он показывает, какие разделы сайта действительно закрыты, а какие остаются открытыми для индексации. В Google Search Console аналогичная функция находится в разделе «Тестирование robots.txt». Достаточно ввести нужный адрес страницы, и система сразу покажет, допускает ли ее текущая конфигурация к сканированию.

Такая проверка обязательна после каждой правки. Иногда роботы продолжают индексировать старые версии файла из кэша, особенно если используется CDN. Чтобы избежать путаницы, полезно обновить кеш вручную и проверить, видят ли поисковики актуальную конфигурацию.

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

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

Не всегда нужно закрывать целый раздел сайта. Часто стоит ограничить доступ поисковых роботов только к определенным видам файлов, например, изображениям, документам или архивам. Это важно, если на сайте размещаются коммерческие предложения, договора, внутренние инструкции или персональные данные клиентов. Такие файлы не должны попадать в выдачу, но при этом должны оставаться доступными по прямым ссылкам.

Поисковые системы умеют считывать маски с расширениями. То есть можно задать правило, по которому запрещается индексация всех файлов определенного типа, например, jpg, png, gif или pdf. Однако важно понимать, что маска *.jpg в robots.txt не всегда интерпретируется одинаково всеми поисковиками. Яндекс распознает подобные шаблоны корректно, а вот Google предпочитает точные пути. Поэтому, если задача стоит именно в защите медиаконтента, лучше комбинировать robots.txt с другими инструментами.

Я не раз сталкивался с ситуацией, когда клиент просил «спрятать» от поисковиков раздел с презентациями и коммерческими предложениями в формате PDF. После внесения запрета через этот файл Яндекс действительно переставал индексировать эти файлы, но Google продолжал отображать их в выдаче. Решение оказалось простым – добавить к таким документам мета-тег с параметром noindex, nofollow. Данный способ работает напрямую внутри HTML-документа и имеет более высокий приоритет, чем файлы конфигурации на сервере.

Когда стоит закрывать типы файлов от индексации:

— если это изображения или документы, не несущие ценности для поискового трафика (например, логотипы, технические схемы, прайс-листы в PDF);

— если контент может раскрывать внутренние процессы компании – шаблоны договоров, отчеты, формы;

— если на сайте дублируется графика, из-за чего растет количество технических дублей в поиске.

Важно понимать, что запрет индексации не делает файл недоступным. Любой человек, знающий прямую ссылку, все равно сможет его открыть. Поэтому robots.txt – это не инструмент защиты данных, а лишь способ регулирования видимости в поиске. Если нужно исключить конфиденциальные документы полностью, стоит использовать закрытые директории с авторизацией или хотя бы ограничение доступа по IP.

Иногда веб-мастера ошибочно пытаются решить все одним файлом, но поисковики не всегда уважают такие директивы. В этом случае мета-теги дают больше контроля. Они обрабатываются каждой страницей отдельно, без зависимости от кэша или зеркала.

💡 Совет: если вы хотите скрыть файлы навсегда, а не просто временно, используйте связку – запрет индексации в файле и мета-тег noindex в самом документе. Такой подход гарантирует, что данные не попадут в выдачу даже после обновления поисковых баз.

Блокировка поддоменов и зеркал

В крупных проектах сайт редко ограничивается одним доменом. Часто существуют поддомены – test.site.ru, cdn.site.ru, admin.site.ru или зеркала вроде www.site.ru
и site.ru. Для поисковиков это отдельные адреса, и, если не настроить правила корректно, они могут начать индексировать технические копии. В результате в выдаче появляются дубли, а авторитет страниц распределяется между ними, снижая общий вес основного домена.

Основной домен и зеркала

Главный домен – это тот, на который вы хотите направить весь трафик и который должен присутствовать в поисковой выдаче. Все остальные (в том числе www-, поддомены тестовых сред или CDN) считаются зеркалами. Они должны быть либо закрыты от индексации, либо правильно склеены. Самая частой ошибкой является отсутствие явного указания главного зеркала через директиву Host. Без нее Яндекс может сам выбрать, какой домен считать основным, и это далеко не всегда совпадает с вашим выбором.

Из своей практики могу привести пример. Сайт крупного дистрибьютора электроники имел два зеркала – site.ru и www.site.ru. Основной трафик шёл на первую версию, но robots.txt был прописан только для www. В итоге поисковик начал считать зеркалом именно www-домен, а основная версия потеряла позиции. Исправили ситуацию просто. Добавили директиву Host и корректный файл для обоих доменов, указав приоритет site.ru. Через пару апдейтов позиции восстановились.

Файл robots.txt на поддоменах

Каждый поддомен – это отдельный сайт с собственным корнем, поэтому у него должен быть свой документ. Если разместить один общий файл на основном домене, поисковики не будут применять его к поддоменам. Например, запрет, прописанный для admin.site.ru, нужно создавать именно там, а не на главном домене.

Типичной ошибкой является указание путей без учета структуры поддомена. Если на основном домене путь выглядит как /folder/, то на поддомене может быть совершенно другая структура, и правило просто не сработает. Иногда встречается и другая крайность, а именно, дублирование правил из основного домена на все поддомены подряд. Из-за этого роботы блокируются полностью, включая полезные разделы.

Конфликт с директивой Host

Host указывается только в одном файле на главном домене. Если прописать разные Host на зеркалах, поисковик может «растеряться» и проигнорировать их все. Это нередко случается при автоматической генерации robots.txt CMS-системами, где веб-мастера не проверяют конфигурацию. Чтобы избежать конфликта, достаточно оставить Host только в одном файле, на основном зеркале, а остальные версии просто закрыть от индексации.

💡 Совет: директива Host помогает поисковику однозначно понять, где «главный» сайт. Укажите ее в robots.txt только один раз – на основном домене, и не используйте в поддоменах. Это простое действие избавит от множества проблем с дублированием и потерей позиций.

Индексация при использовании CDN и копий сайта

Использование CDN (Content Delivery Network) давно стало стандартом для ускорения загрузки сайтов. Сеть распределяет изображения, скрипты, стили по серверам на всех материках, чтобы пользователь получал контент с ближайшего узла. Но, вместе с этим появляется риск, что поисковые системы видят эти CDN-дополнительные адреса как отдельные домены. В итоге сайт получает технические дубликаты, которые попадают в индекс, разбивая общий вес страниц.

Я сталкивался с этим не раз. Один из моих клиентов подключил CDN для ускорения изображений, но не настроил ограничения. Через пару месяцев часть картинок и даже HTML-страниц стала индексироваться по адресу cdn.site.ru. В поиске появились копии с тем же контентом, но другим доменом. Это привело к просадке позиций. Поисковик посчитал, что сайт дублирует собственные материалы. Исправили ситуацию через корректировку robots.txt для CDN-поддомена, запретив доступ к файлам напрямую.

В таких случаях важно понимать, что CDN не знает, что вы не хотите, чтобы его адреса индексировались. Он просто обслуживает копии контента. Поэтому именно вы должны явно закрыть эти зеркала от поисковиков. Делается это просто. Создается отдельный robots.txt в корне CDN-поддомена, где для всех агентов прописывается запрет на индексацию. Этого достаточно, чтобы роботы не заходили глубже и не фиксировали дубли.

Однако в некоторых ситуациях вместо полного запрета целесообразнее использовать тег rel= «canonical». Например, когда CDN-версия используется для статики и ускоренной загрузки основных страниц. В этом случае canonical позволяет объединить сигналы и поведенческие данные с разных доменов, указывая поисковику, где находится оригинал. Данный подход безопаснее. Страницы остаются видимыми, но все их метрики передаются основной версии.

Canonical действительно предпочтителен, если CDN применяется официально и служит зеркалом для ускорения, например, при использовании Cloudflare, Akamai или Fastly. В таких сетях роботы часто получают доступ к CDN-адресам напрямую, и полный запрет может нарушить корректную индексацию изображений или AMP-страниц.

Из опыта могу сказать, что, если проект уже индексируется через CDN и вы замечаете дубли, не стоит сразу закрывать все подряд. Лучше объединить сигналы с помощью canonical и только потом ограничить доступ в robots.txt. Такой комбинированный подход сохраняет SEO-эффект, но убирает риск потери веса страниц.

💡 Совет: всегда проверяйте, какие URL реально попадают в индекс. Иногда под видом CDN-дубликатов там оказываются страницы из кеша сторонних сервисов. Закройте их отдельным robots.txt и используйте canonical, чтобы поисковики чётко понимали, где оригинал.

Работа с конкретными поисковыми роботами: Яндекс, Google

Файл позволяет задавать общие правила для всех поисковых систем и управлять поведением конкретных ботов. Это особенно важно, когда сайт обслуживает разные типы контента (страницы, изображения, видео, документы). Каждый поисковик использует собственный набор роботов для разных задач, и если не разграничить их доступ, можно случайно либо перекрыть важные разделы, либо наоборот, открыть то, что не должно индексироваться.

ОСНОВНЫЕ БОТЫ, С КОТОРЫМИ ПРИХОДИТСЯ РАБОТАТЬ ЧАЩЕ ВСЕГО:

— Yandex. Основной поисковый робот Яндекса, отвечающий за индексацию страниц. Помимо него существуют вспомогательные: YandexImages (индексация изображений), YandexVideo (видео), YandexMetrika (сбор данных о поведении пользователей) и YandexNews (агрегатор новостей). Если вы не хотите, чтобы картинки попадали в поиск, можно запретить именно YandexImages, не затрагивая основной контент.

— Googlebot. Это главный индексатор Google. У него есть дочерние версии: Googlebot-Image (работает с изображениями), Googlebot-News, Googlebot-Mobile, Googlebot-Video. Важно, что при указании User-agent: Googlebot директивы наследуются и для остальных версий, если они не переопределены отдельно.

— Bingbot. Индексатор Microsoft Bing. Работает аккуратно, но склонен повторно запрашивать старые URL. Если проект небольшой, можно ограничить частоту обхода через Crawl-delay.

— Slurp. Робот Yahoo!, который иногда дублирует запросы от Bing, поскольку использует общий индекс.

— SputnikBot. Российский поисковый бот от Ростелекома, работает по тем же правилам, что и Яндекс, но используется реже.

Когда вы прописываете директивы, важно понимать, что User-agent: * распространяется на все боты сразу, но, если заданы отдельные блоки для конкретных агентов, они имеют приоритет. Например, если сначала разрешено все для всех, а потом запрещено для Googlebot-Image, то картинки не попадут в выдачу Google, но страницы останутся доступными.

Я сталкивался с ситуацией, когда клиент закрыл весь сайт директивой для Yandex, забыв, что у него был активен CDN с изображениями, индексируемыми Googlebot-Image. Через пару недель фотографии клиентов начали появляться в поиске Google, хотя сам сайт был скрыт. Решили проблему добавлением отдельного запрета именно для этого бота.

При работе с региональными версиями поисковиков стоит помнить, что они читают robots.txt только с главного домена. Если у вас есть локальные зеркала вроде site.ru и site.kz, нужно дублировать файл для каждой версии, чтобы исключить путаницу в региональной индексации.

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

💡 Совет: чтобы узнать, какой бот реально посещал сайт, анализируйте серверные логи. В строках User-Agent всегда указано имя робота. Это лучший способ отличить настоящих поисковых ботов от поддельных скриптов, которые маскируются под них, но на деле просто сканируют ваш сайт для сбора данных.

Дополнительные директивы в robots.txt

Многие считают robots.txt простой «запиской для поисковиков», мол, закрыл пару разделов, и хватит. На деле же именно дополнительные директивы делают из этого файла настоящий инструмент управления индексацией. Они регулируют, с какой скоростью робот обходит сайт, что считать дублем, какое зеркало считать основным и где искать карту страниц. Вроде мелочи, но на практике эти детали решают, будет ли сайт нормально индексироваться или утонет в дублях и ошибках 500.

Crawl-delay – регулировка нагрузки

Если сайт на слабом хостинге, поисковый бот может устроить настоящий DDoS, особенно когда пытается обойти тысячи страниц подряд. Директива Crawl-delay задает паузу между запросами. Например, значение 1 – это секунда между загрузками страниц.

Был у меня клиент с интернет-магазином, где бот Яндекса буквально валил сервер. Сайт вылетал ночью, позиции прыгали. Добавил Crawl-delay и через сутки все стабилизировалось. Робот стал обходить сайт мягко, нагрузка снизилась, и ошибки 503 исчезли. Но, если у вас мощный сервер, замедлять обход не нужно. Наоборот, можешь потерять скорость индексации новых страниц.

Clean-param – борьба с мусором в адресах

Фильтры, сортировки, UTM-метки, ref-ссылки – все это создает тысячи дублей, которые поисковики воспринимают как разные страницы. Clean-param как раз помогает очистить URL от мусора. Пример: если указать Clean-param: utm /, робот будет игнорировать параметры utm_source, utm_medium и т.д., считая страницу одной и той же.

Видел проект, где после запуска рекламы сайт за месяц «распух» до 50 000 URL из-за UTM-меток. После добавления Clean-param и пересканирования дублей осталось меньше тысячи. Сайт моментально подрос в выдаче просто потому, что поисковик перестал тратить бюджет на мусор.

Sitemap и Host – навигация и контроль зеркал

Sitemap является навигатором для поисковика. Он помогает боту быстрее находить нужные страницы. Если карт несколько (например, для каталога, блога и новостей), можно перечислить все. Главное обновлять их при изменении структуры.

Host – еще одна недооценённая директива. Она сообщает Яндексу, какой домен считать основным, с www или без. У меня был случай, когда сайт отображался в поиске в двух вариантах и позиции у каждого зеркала были разные. Добавили правильный Host, подождали пару апдейтов – все соединилось, видимость выросла.

Как все это взаимодействует

Важно понимать, что не все поисковики одинаково трактуют директивы. Яндекс учитывает Host и Clean-param, Google – нет. Crawl-delay у Google вообще игнорируется. Поэтому любые изменения нужно проверять в инструментах вебмастеров.

Именно здесь проявляется уровень профессионализма. Можно просто скопировать шаблон, а можно выстроить robots.txt под особенности конкретного сайта и поисковых систем. Второй вариант всегда выигрывает.

💡 Совет: после внесения изменений проверь файл в инструментах Яндекса и Google. Если хотя бы один из них выдает ошибку – исправляй сразу, иначе поисковики просто проигнорируют твои директивы.

Использование мета-тегов для запрета индексации

Robots.txt регулирует доступ извне. В свою очередь, мета-теги работают изнутри. Они сообщают поисковику, можно ли индексировать страницу и переходить по ссылкам. Это точный инструмент, когда нужно скрыть не весь сайт, а конкретные документы – корзину, личный кабинет или результаты поиска.

Различия заключаются в приоритете. Если робот все же зашел на страницу, несмотря на запрет в robots.txt, мета-тег становится последней линией защиты. Noindex запрещает индексацию содержимого, nofollow – передачу ссылочного веса, а комбинация noindex, nofollow полностью скрывает страницу и все ссылки внутри.

Часто вижу, как разработчики ставят запрет только в robots.txt, но поисковики все равно индексируют страницы через внешние ссылки. Добавление мета-тега в таких случаях решает проблему. Робот удаляет URL при следующем обходе. Но, важно не переусердствовать. Один клиент случайно поставил noindex в шаблон блога и потерял сотни страниц из выдачи. Всегда проверяйте, где именно применяется тег.
Мета-теги особенно удобны для временного скрытия страниц. После их удаления контент быстро возвращается в поиск. Robots.txt в этом плане медленнее. Обновления вступают в силу только после новой индексации.

💡 Совет: если нужно временно убрать страницу из поиска – ставьте noindex, nofollow. Для постоянного скрытия (например, договоров или тестовых страниц) комбинируйте с robots.txt. Данный подход стабильно работает и в Яндексе, и в Google, не создавая путаницы с кэшем и дублями.

Проверка, находится ли страница в индексе

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

Вбейте «site: ваш домен.ru/страница» – если документ есть в выдаче, значит он все еще в индексе.

Иногда полезно использовать команду cache. Она показывает последнюю сохраненную копию страницы. А info: (в Google) открывает сводку с метаданными. Эти простые приемы часто дают ответ быстрее, чем отчеты в консолях.

Если хочется убедиться наверняка, стоит заглянуть в панель вебмастера. В Яндекс.Вебмастере это делается через раздел «Индексация → Страницы в поиске». Там показывается, какие URL попали в поиск, а какие были исключены, и по какой причине. В Google Search Console есть аналог – инструмент «Проверка URL». Просто вставляете нужный адрес, и система показывает актуальный статус (проиндексирована страница или нет, а если нет – объясняет, что помешало индексации). Обычно проблема кроется в robots.txt, мета-теге noindex или технической ошибке сервера – все это сразу видно в отчете.

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

Для наглядности удобно составить мини-чеклист проверки:

• site – показывает наличие в индексе;
• cache – последняя сохранённая копия;
• info – общая информация (только Google);
• Яндекс.Вебмастер – точные причины исключения;
• Google Search Console – диагностика и переобход.

💡 Совет: чтобы понять, когда робот перечитал файл robots.txt или мета-теги, посмотрите дату последнего обхода в Яндекс.Вебмастере или отчетах логов. Если с этого времени прошло больше 3–5 дней, а изменения не вступили в силу, стоит отправить запрос на переобход вручную.

FAQ: ответы на частые вопросы

❓Почему поисковик все равно индексирует, хотя я все закрыл?

Потому что запрет в robots.txt не удаляет уже проиндексированные страницы. Он лишь препятствует новым попадать в поиск. Чтобы убрать старые, нужно добавить мета-тег noindex и дождаться переобхода в Яндекс.Вебмастере.

❓Можно ли закрыть часть контента без robots.txt?

Да, если нужно спрятать только отдельные страницы. Для этого достаточно мета-тега noindex, nofollow или атрибута rel=»nofollow» на ссылках. Robots.txt нужен для глобальных ограничений, а не точечных задач.

❓Когда использовать noindex вместо Disallow?

Когда страница уже в индексе. Disallow блокирует доступ, и робот просто не сможет ее удалить, а мета-тег позволяет корректно убрать документ при следующем обходе.

❓Как быстро удалить страницу из выдачи?

Используйте инструмент «Удалить URL» в Яндекс.Вебмастере или Google Search Console. Это временная мера, но помогает мгновенно скрыть страницу до тех пор, пока не обновится robots.txt или мета-тег.