robots.txt: как он работает на современных сайтах
Одна строка в robots.txt может запретить краулеру запрашивать тысячи URL — или случайно закрыть ему доступ к страницам и ресурсам, которые вы хотели сделать доступными для обнаружения.
Именно поэтому значение robots.txt легко недооценить. Это небольшой конфигурационный файл, но он находится практически в самом начале взаимодействия поисковых систем, AI-краулеров, систем мониторинга и других автоматизированных клиентов с сайтом.
Самое важное различие: robots.txt управляет доступом к crawling. Это не средство управления indexing, не система аутентификации и не механизм безопасности. Google прямо указывает, что URL, закрытый от crawling, всё равно может появиться в результатах поиска, если Google обнаружит его другим способом. (developers.google.com)
Что такое robots.txt?
robots.txt — это обычный текстовый файл, который сообщает соблюдающим его правила автоматизированным краулерам, какие URL-пути им разрешено или запрещено запрашивать.
Протокол Robots Exclusion Protocol был стандартизирован в RFC 9309 в сентябре 2022 года, хотя сам механизм существует ещё с ранних лет веба. Стандарт определяет, как краулеры должны находить, разбирать, кэшировать и применять правила robots.txt. (rfc-editor.org)
Для HTTPS-сайтов файл обычно располагается здесь:
https://example.com/robots.txt
Он должен находиться в корне соответствующего хоста. Файл по адресу:
https://example.com/blog/robots.txt
не управляет crawling для example.com. Согласно RFC 9309, стандартный путь — /robots.txt, а имя файла записывается в нижнем регистре. (rfc-editor.org)
Чем на самом деле управляет robots.txt
Проще всего представить robots.txt как инструкции у входа на сайт:
«Краулер X может заходить по этим путям, но не должен заходить по тем.»
Базовый файл может выглядеть так:
User-agent: *
Disallow: /admin/
Disallow: /internal-search/
Sitemap: https://example.com/sitemap.xml
User-agent: * применяется к краулерам, соответствующим общей группе. Правила Disallow предписывают им не запрашивать URL, начинающиеся с указанных путей.
Строка Sitemap сообщает поддерживающим её краулерам местоположение XML sitemap. Google, Bing и другие крупные поисковые системы поддерживают указание sitemap в robots.txt, хотя Sitemap не относится к основным правилам протокола RFC 9309. (developers.google.com)
INTERNAL LINK: XML Sitemaps Explained
Crawling — не то же самое, что indexing
Это самое распространённое заблуждение о robots.txt.
Рассмотрим пример:
User-agent: Googlebot
Disallow: /private-offer/
Googlebot не должен выполнять crawling содержимого по этому пути. Но если другой сайт ссылается на:
https://example.com/private-offer/
Google всё равно может узнать о существовании этого URL. Google документирует, что заблокированный URL может появиться в результатах поиска без содержимого страницы или обычного сниппета. (developers.google.com)
Если ваша реальная задача звучит так:
«Эта страница не должна появляться в результатах поиска»,
используйте средство управления indexing, например:
<meta name="robots" content="noindex">
или HTTP-заголовок:
X-Robots-Tag: noindex
Но здесь есть важная зависимость: краулеру необходимо получить доступ к странице, чтобы увидеть директиву noindex. Поэтому блокировка того же URL через robots.txt может помешать Google обнаружить инструкцию noindex. (developers.google.com)
INTERNAL LINK: noindex vs robots.txt
robots.txt — не средство безопасности
Никогда не используйте robots.txt для защиты паролей, внутренних документов, данных клиентов, staging-систем, административных страниц или конфиденциальных файлов.
Этот файл публичный. Любой человек может открыть:
https://example.com/robots.txt
и увидеть перечисленные вами пути.
RFC 9309 прямо указывает, что robots.txt не является механизмом авторизации доступа и не должен заменять реальную защиту на уровне приложения. Конфиденциальные ресурсы необходимо защищать с помощью аутентификации, авторизации, сетевых ограничений или других подходящих механизмов безопасности. (rfc-editor.org)
Правило вроде:
Disallow: /secret-backups/
может, наоборот, показать всем, что путь /secret-backups/ существует.
Как сопоставляются правила
Файл robots.txt состоит из групп правил для разных краулеров.
Например:
User-agent: Googlebot
Disallow: /internal/
Allow: /internal/public/
User-agent: *
Disallow: /tmp/
Первая группа применяется к Googlebot. Вторая задаёт правила для других краулеров, соответствующих группе с wildcard.
В случае Google, если URL соответствует сразу нескольким правилам, обычно применяется правило с более специфичным путём. Если конфликтующие правила имеют одинаковую специфичность, Google применяет менее ограничивающее правило. (developers.google.com)
Например:
User-agent: *
Disallow: /
Allow: /blog/
Сайт в целом заблокирован, но URL, начинающиеся с /blog/, разрешены.
Google также поддерживает * для сопоставления шаблонов и $ для обозначения конца URL:
User-agent: Googlebot
Disallow: /*.pdf$
Это правило блокирует подходящие URL, заканчивающиеся на .pdf. (developers.google.com)
Реализации у разных краулеров могут отличаться, особенно в отношении нестандартных расширений протокола. Поэтому не стоит считать, что каждый краулер поддерживает все особенности поведения Google.
Современные JavaScript-сайты
Современные сайты часто зависят от JavaScript, CSS, API-запросов и других ресурсов, необходимых для формирования видимого содержимого страницы.
Если заблокировать ресурсы, необходимые для rendering страницы, краулеры, выполняющие JavaScript-rendering, могут получить её неполную версию. Google документирует, что если robots.txt запрещает Googlebot получать определённый URL, этот ресурс не запрашивается; Google Search не может выполнить rendering JavaScript из заблокированных страниц или файлов. (developers.google.com)
Поэтому правило вроде:
Disallow: /assets/
нужно внимательно проверять, если в /assets/ находятся JavaScript- или CSS-файлы, необходимые для публичных страниц.
Блокировать ненужные backend-пути может быть полезно. Но блокировка ресурсов, необходимых для понимания страницы, может вызвать проблемы с crawling или rendering.
INTERNAL LINK: JavaScript SEO Explained
robots.txt и эффективность crawling
robots.txt особенно полезен, когда сайт способен генерировать огромное количество доступных для crawling URL.
Типичные примеры:
- faceted navigation
- результаты внутреннего поиска
- URL календарей
- комбинации фильтров
- параметры сортировки
- URL с идентификаторами сессий
- динамически генерируемые пространства URL
Например, e-commerce-система может создавать такие URL:
/products?color=black&size=m&sort=price
/products?color=black&size=m&sort=newest
/products?color=black&size=l&sort=price
Тысячи или миллионы подобных вариантов могут расходовать ресурсы краулера и сервера, не создавая при этом полезных поисковых страниц.
Google отдельно рекомендует ограничивать ненужный crawling URL faceted navigation, если такие отфильтрованные страницы не требуется индексировать. (developers.google.com)
Для крупных или сильно динамических сайтов это значительно важнее, чем для простого сайта из нескольких десятков страниц.
robots.txt и AI-краулеры
Сегодня robots.txt относится уже не только к традиционным поисковым системам.
AI-компании также используют краулеры, причём разные crawler identity могут предназначаться для разных задач.
Например, OpenAI документирует OAI-SearchBot для контента, который может обнаруживаться и показываться в поисковых возможностях ChatGPT. OpenAI указывает, что издателям, желающим сделать свой контент доступным для summaries и snippets, не следует блокировать OAI-SearchBot. (help.openai.com)
Anthropic аналогичным образом документирует отдельные crawler identity для разных видов активности и указывает, что её боты соблюдают директивы robots.txt. (support.anthropic.com)
Это создаёт важный вопрос для современной конфигурации: каким автоматизированным системам вы действительно хотите предоставить доступ к своему контенту?
Сайт может устанавливать разные политики для поискового обнаружения, AI search retrieval, crawling для разработки моделей, рекламных систем и других автоматизированных клиентов.
INTERNAL LINK: AI Crawlers and robots.txt
Практический пример robots.txt
Для относительно простого публичного сайта можно использовать:
User-agent: *
Disallow: /admin/
Disallow: /internal-search/
Disallow: /api/private/
Sitemap: https://example.com/sitemap.xml
Такая конфигурация не позволяет обычным краулерам заходить в разделы, которые почти не имеют ценности для crawling, при этом оставляя публичный контент доступным.
Не копируйте этот пример вслепую. Конфигурация должна соответствовать реальной архитектуре сайта, требованиям к краулерам и стратегии indexing.
HTTP-ошибки имеют значение
Поведение краулеров также зависит от того, что происходит при запросе самого /robots.txt.
RFC 9309 различает ситуацию, когда файл robots.txt отсутствует, и ситуацию, когда до него невозможно добраться из-за серверной или сетевой ошибки.
Например, ответ 4xx может интерпретироваться как отсутствие файла, при котором crawling разрешён. Напротив, если robots.txt недоступен из-за проблемы на стороне сервера или сети, стандарт требует, чтобы краулеры первоначально считали всё полностью запрещённым. Краулеры также могут кэшировать robots.txt; RFC 9309 указывает, что кэшированные версии обычно не следует использовать более 24 часов, если файл доступен. (rfc-editor.org)
Это означает, что ошибка при развёртывании robots.txt может иметь совершенно другие последствия, чем полное отсутствие файла.
RFC 9309 также требует, чтобы реализации краулеров поддерживали разбор как минимум 500 KiB содержимого robots.txt. Google в настоящее время также применяет лимит robots.txt в 500 KiB и игнорирует всё содержимое после этого объёма. (rfc-editor.org)
Обычный файл robots.txt почти никогда не должен приближаться к такому размеру.
Как диагностировать проблемы
Если важные страницы перестали сканироваться или корректно рендериться, robots.txt стоит проверить на раннем этапе диагностики.
Полезный рабочий процесс выглядит так:
Симптом: страница или ресурс не сканируются.
Измерение: напрямую запросите /robots.txt и проверьте правило, применяемое к нужному краулеру.
Возможная причина: слишком широкое правило Disallow, wildcard-шаблон, отдельная группа для конкретного краулера или заблокированный ресурс для rendering.
Подтверждение: протестируйте проблемный URL с помощью диагностических инструментов соответствующего краулера. Для Google отчёты robots.txt и инструмент URL Inspection в Search Console могут помочь подтвердить доступность. (developers.google.com)
Исправление: сузьте или удалите неправильное правило.
Повторное измерение: убедитесь, что доступны как сам URL, так и необходимые ресурсы страницы.
Также проверьте CDN, WAF, firewall, слой аутентификации и систему управления ботами. Правила robots.txt могут разрешать доступ краулеру, тогда как другой инфраструктурный слой всё равно возвращает 403 Forbidden. OpenAI прямо указывает это как одну из возможных причин проблем с доступом краулеров. (help.openai.com)
Распространённые ошибки
Самые серьёзные ошибки обычно возникают тогда, когда robots.txt используют не по назначению.
Например:
User-agent: *
Disallow: /
на production-сайте запрещает всем обычным соблюдающим правила краулерам доступ ко всему сайту.
Среди других распространённых ошибок — блокировка страниц с noindex, блокировка JavaScript, необходимого для rendering, публикация имён приватных директорий, предположение о повсеместной поддержке crawl-delay или копирование правил с другого сайта без понимания его архитектуры. Google, например, не поддерживает поле crawl-delay в robots.txt. (developers.google.com)
robots.txt должен быть намеренно небольшим и понятным.
Рекомендация SeoNest
Относитесь к robots.txt как к части архитектуры crawling, а не как к второстепенному SEO-файлу.
Для большинства сайтов разумно начинать с разрешающей конфигурации и блокировать только те пространства URL, которые краулерам действительно не нужно запрашивать. Конфиденциальную информацию защищайте реальными механизмами контроля доступа, используйте noindex, если задача состоит в том, чтобы не допустить indexing доступной страницы поддерживающими эту директиву поисковыми системами, и периодически пересматривайте правила для отдельных краулеров по мере развития поисковых и AI-систем.
И самое главное — проверяйте фактическое поведение после настройки, а не предполагайте, что конфигурация работает именно так, как выглядит.
FAQ
Обязательно ли нужен файл robots.txt?
Не обязательно. Если краулерам можно предоставить доступ ко всему публичному сайту, отсутствие robots.txt допустимо. Google указывает, что пустой файл или отсутствие robots.txt фактически означает разрешение crawling по умолчанию. (developers.google.com)
Удаляет ли Disallow страницу из Google?
Нет. Disallow управляет crawling. Заблокированный URL всё равно может быть обнаружен и потенциально появиться в результатах поиска. Если необходимо предотвратить indexing, используйте подходящий механизм noindex. (developers.google.com)
Может ли robots.txt защищать приватные страницы?
Нет. robots.txt доступен публично и не является механизмом авторизации. Используйте аутентификацию и полноценный контроль доступа. (rfc-editor.org)
Стоит ли блокировать CSS и JavaScript?
Обычно нет, если эти ресурсы нужны краулерам для rendering и понимания публичных страниц. Google не может выполнить rendering JavaScript из ресурсов, доступ к которым запрещён через robots.txt. (developers.google.com)
Можно ли отдельно управлять AI-краулерами?
Да, если оператор краулера публикует отдельные имена user-agent и поддерживает управление через robots.txt. Например, OpenAI и Anthropic документируют отдельные средства управления своими краулерами. (help.openai.com)
Итог
robots.txt отвечает на узкий, но важный вопрос: какие URL разрешено запрашивать краулерам, соблюдающим его правила?
Он не определяет, является ли URL конфиденциальным, должна ли страница исчезнуть из результатов поиска и может ли неизвестный бот технически получить доступ к вашему серверу.
Если рассматривать crawling, indexing, rendering, безопасность и идентификацию краулеров как отдельные задачи, robots.txt становится гораздо проще правильно настроить — и гораздо сложнее использовать не по назначению.
Sources
- IETF / RFC Editor — RFC 9309: Robots Exclusion Protocol. September 2022. (rfc-editor.org) RFC 9309
- Google Search Central — Introduction to robots.txt. Google documentation. (developers.google.com) Introduction to robots.txt
- Google Crawling Infrastructure — How Google Interprets the robots.txt Specification. Google documentation. (developers.google.com) Google robots.txt specification
- Google Crawling Infrastructure — Create and Submit a robots.txt File. Google documentation. (developers.google.com) Create a robots.txt file
- Google Search Central — Block Search Indexing with noindex. Last updated December 10, 2025. (developers.google.com) Block indexing with noindex
- Google Search Central — Understand JavaScript SEO Basics. Google documentation. (developers.google.com) JavaScript SEO basics
- Google Crawling Infrastructure — Managing Crawling of Faceted Navigation URLs. Google documentation. (developers.google.com) Faceted navigation crawling guidance
- OpenAI — Publishers and Developers FAQ. OpenAI Help Center. (help.openai.com) OpenAI publisher crawler guidance
- Anthropic — Does Anthropic Crawl Data from the Web, and How Can Site Owners Block the Crawler? Anthropic Help Center. (support.anthropic.com) Anthropic crawler guidance
