Файл robots.txt — это текстовый файл в корне сайта, который задаёт правила доступа для поисковых роботов к отдельным URL, папкам и типам страниц. Его главная задача — не «спрятать страницу от Google», а управлять crawling : подсказывать роботу, что стоит сканировать, а на что не нужно тратить ресурсы сервера и crawl budget.

Сканирование — это когда бот запрашивает страницу. Индексация — это когда страница после обработки может попасть в базу поисковой системы. Noindex — отдельная директива, которая говорит Google не добавлять документ в результаты поиска. Именно поэтому robots.txt не стоит подавать как универсальный способ убрать URL из выдачи: для Google это прежде всего инструмент управления обходом.

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

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

Материал опирается на официальную документацию Google о robots.txt , техническую спецификацию того, как Google интерпретирует robots.txt , рекомендации по noindex и данные WordPress Developer Resources .

Что такое robots txt и когда он действительно нужен

Robots txt — это файл правил для ботов, который находится по адресу /robots.txt и сообщает, какие части сайта можно или не стоит сканировать. Для небольшого сайта с несколькими десятками страниц он может быть очень простым. Для интернет-магазина, контентного проекта, сайта на WordPress, крупного корпоративного ресурса или мультиязычной структуры файл robots.txt уже становится частью технической основы сайта.

Больше всего пользы robots txt seo даёт там, где на сайте есть фильтры, страницы внутреннего поиска, сортировки, параметры в URL, служебные каталоги, тестовые разделы, технические скрипты или другие зоны без ценности для поиска. В магазинах это особенно заметно: если не контролировать crawling, бот может бесконечно ходить по комбинациям фильтров и параметров вместо того, чтобы быстрее доходить до категорий, карточек товаров и контентных страниц.

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

Сканирование, индексация и noindex — не одно и то же

Одна из самых частых ошибок в старых SEO-материалах — смешивать сканирование и индексацию. Если страница заблокирована в robots.txt, это означает, что Googlebot может не зайти на неё и не увидеть её содержимое. Но URL всё равно может появиться в поиске, если на него есть ссылки с других страниц или внешних источников.

С noindex логика другая. Чтобы Google увидел эту директиву, страница должна оставаться доступной для обхода. Типичная ошибка — одновременно поставить Disallow в robots.txt и ждать, что бот прочитает noindex внутри страницы. Не прочитает, потому что доступ уже закрыт.

Если нужно глубже разобраться в самой логике попадания страниц в поиск, отдельно посмотрите материал про индексацию сайта в поисковых системах . На практике здесь часто путают именно причину проблемы: кажется, что страница «не индексируется», хотя на самом деле её просто неправильно открыли или закрыли для обхода.

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

У robots txt есть несколько базовых требований, которые не стоит нарушать. Файл должен называться именно robots.txt , быть обычным текстовым документом в кодировке UTF-8 и лежать в корне того хоста, к которому применяются правила. Если положить файл в подпапку, поисковый робот не будет воспринимать его как robots.txt.

Есть и технический нюанс, который часто теряется в общих объяснениях. Robots.txt действует не «на весь сайт в целом», а в пределах конкретного протокола, хоста и порта. То есть правила для https://example.com/robots.txt не становятся автоматически правилами для https://www.example.com/ или для поддоменов. Если ресурс распределён по нескольким хостам, это нужно учитывать ещё на этапе разработки сайта и построения его структуры.

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

User-agent, Disallow, Allow и Sitemap — что означают основные директивы

User-agent показывает, для какого именно робота действует блок правил. С этой директивы начинается любая логика управления доступом в robots.txt. Если указать User-agent: * , правило распространяется на всех ботов, которые поддерживают Robots Exclusion Protocol.

Disallow — основная директива, которой ограничивают сканирование отдельных разделов, папок или типов URL. Ею часто закрывают внутренний поиск, корзину, технические каталоги, тестовые папки или страницы с низкой SEO-ценностью.

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

Sitemap не запрещает и не разрешает обход, а только подсказывает, где находится карта сайта. Именно поэтому добавлять sitemap в robots txt — нормальная практика: это не заменяет подачу карты в Search Console, но даёт ещё одну точку обнаружения sitemap.

Базовый пример может выглядеть так:

User-agent: *
Disallow: /search
Disallow: /cart/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xml

Такие правила robots txt лучше делать короткими и понятными. Чем сложнее файл, тем проще случайно закрыть не ту папку, не тот шаблон URL или даже важные для рендеринга ресурсы.

Какой синтаксис robots txt действительно важен

Синтаксис robots txt не выглядит сложным, но именно на мелочах возникает большинство ошибок. Пути задаются от корня сайта, файл чувствителен к структуре URL, а невалидные или лишние строки Google просто игнорирует. Из-за этого неправильный robots.txt не всегда «ломается полностью» — иногда он частично работает, а частично нет, и именно поэтому ошибки могут долго оставаться незамеченными.

Есть и важный практический момент: Google не поддерживает часть директив, которые до сих пор кочуют по старым статьям и шаблонам. В частности, noindex , nofollow и crawl-delay не относятся к поддерживаемым правилам robots.txt для Google. Поэтому если в файле до сих пор есть подобные записи, они не должны быть опорой для современной технической оптимизации.

Robots txt для WordPress — что проверить отдельно

Robots txt для WordPress — отдельная тема, потому что на этой платформе файл может отдаваться не только как физический документ на сервере, но и динамически. Кроме того, в WordPress уже есть встроенная поддержка XML-sitemap. Это удобно, но итоговый результат всё равно нужно проверять.

На WordPress проблема часто не в самом файле, а в том, что его поведение меняется плагинами, темой или кастомной логикой. Владелец сайта может быть уверен, что robots.txt настроен давно и правильно, но фактическое содержимое по адресу /robots.txt уже другое. Именно поэтому проверка robots.txt для WordPress — это не формальность, а нормальная часть технического аудита сайта .

Для интернет-магазинов на WordPress или WooCommerce это ещё важнее: там быстро накапливаются параметрические URL, фильтры, страницы сортировки, корзина, checkout и другие участки, которые не стоит бесконтрольно отдавать на crawling.

Как проверить robots txt в Google Search Console

Проверять robots.txt лучше не изолированно, а вместе с Search Console, URL Inspection, Page Indexing и Crawl Stats. Сам файл может быть формально корректным, но это ещё не означает, что он работает на пользу сайту.

Сам robots txt report в Search Console помогает увидеть текущую версию файла и быстрее обновить кеш после изменений. Для отдельных URL полезен Google Search Console с URL Inspection: так видно, не блокирует ли robots.txt страницу, которая на самом деле должна сканироваться. Для более широкой картины стоит смотреть Page Indexing и Crawl Stats — именно там видно, где сайт реально теряет обход.

Если страниц много, проверять robots.txt «на глаз» недостаточно. Когда файл меняется вместе со структурой каталога, миграцией, новыми языковыми версиями или редизайном, его нужно проверять в рамках SEO-аудита сайта , а не только по принципу «файл открывается — значит, всё хорошо».

Типичные ошибки в robots.txt

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

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

  • Блокируют страницы, которые должны сканироваться. Из-за этого поисковик не видит важный контент, а проблема потом выглядит как «медленная индексация».

  • Закрывают ресурсы, необходимые для рендеринга. Если случайно ограничить важные CSS или JavaScript, страница может открываться в браузере нормально, но для Google её рендер будет неполным.

  • Держат в файле устаревшие или неподдерживаемые правила. Пользы от них нет, но они создают ложное ощущение контроля.

  • Публикуют файл не там. Robots.txt в подпапке, в неправильной кодировке или с ошибкой в названии — это фактически отсутствующий robots.txt.

  • Полагаются на robots.txt как на защиту приватных разделов. Для закрытой информации нужен контроль доступа, а не только рекомендация для ботов.

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

Также стоит помнить и о доступности самого файла. Если robots.txt отдаётся с серверными ошибками, это тоже влияет на crawling. Поэтому при редизайне, переезде, смене CDN или серверных настроек robots.txt нужно проверять так же внимательно, как sitemap, редиректы и canonical.

Вывод

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

На практике всё сводится к простому разделению ролей. Robots.txt нужен для управления обходом. Если страницу нужно убрать из поиска, смотреть нужно уже в сторону noindex , X-Robots-Tag или серверных ограничений доступа. Когда эти задачи не подменяют друг друга, техническая SEO-логика сайта становится заметно чище.

Если же на сайте уже есть сомнения в том, какие URL следует закрывать, что нужно оставить для обхода, где конфликтуют robots.txt, meta robots, canonical и sitemap, такие вопросы лучше решать не точечными правками, а через полноценный технический разбор структуры сайта.