Маленький файл robots.txt и большие последствия одной строки

Почти за каждым сайтом стоит человек, которому небезразлично, приходят ли туда люди. Для кого-то сайт — это бизнес, источник заказов и клиентов. Для кого-то — увлечение, личный блог или сообщество по интересам. Разница тут велика, и всё же владельцы в обоих случаях заинтересованы в одном и том же. Им нужно, чтобы на сайт заходили, и желательно именно те, кому его содержимое действительно нужно.

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

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

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

Забавно, что при всей серьёзности последствий к самому файлу многие относятся с юмором. Yelp когда-то вписал в свой robots.txt отсылку к законам робототехники Азимова, TripAdvisor зовёт через него разработчиков на работу, а Google в 2014 году завёл отдельный файл killer-robots.txt, который запрещал терминаторам T-800 и T-1000 трогать основателей компании. Шутку приурочили к двадцатилетию robots.txt, позже файл убрали. Сам robots.txt давно стал площадкой для маленьких пасхалок.

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

robots.txt и изменения в поиске

Ещё недавно robots.txt был интересен только специалистам по поисковой оптимизации (SEO). Сегодня круг тех, кого он касается, заметно шире, и причин тому несколько.

Первая связана с тем, как меняется сам поиск. В недавнем интервью The Verge глава Google рассуждал о том, что поисковик всё чаще отвечает на запрос прямо на странице выдачи, не отправляя человека на сайты. Крупные издатели в том же разговоре упоминались как те, кто уже перестраивает бизнес-модели, исходя из того, что трафик из поиска стремится к нулю. Сбудется ли это в полной мере, судить сложно.

Вторая причина появилась совсем недавно. Языковые модели учатся на текстах из открытого интернета, и владельцы сайтов всё чаще задумываются, готовы ли они отдавать свое содержимое на обучение. robots.txt оказался первым инструментом, которым такой доступ пытаются ограничивать. Выходит, файл, задуманный для управления индексацией, неожиданно стал ещё и рычагом, регулирующим доступ искусственного интеллекта (ИИ) к содержимому сайтов. Так что разобраться в нём есть смысл чуть глубже, чем «закрыл админку и забыл».

Что такое robots.txt на самом деле

Если коротко, это текстовый файл в корне сайта, который лежит по адресу /robots.txt и подсказывает поисковым роботам, какие разделы можно обходить, а какие лучше не трогать. Формально он описан в стандарте Robots Exclusion Protocol, который в сентябре 2022 года оформили как RFC 9309. До этого стандарт почти тридцать лет держался на честном слове. Официально его никто не утверждал, а крупные поисковики просто договорились ему следовать и по большей части следовали.

Ключевое слово здесь «подсказывает». robots.txt не запрещает доступ и ничего не защищает. Это не пароль, не межсетевой экран и не права доступа. Робот, который захочет, спокойно прочитает закрытый раздел. Воспитанные роботы крупных поисковиков правила соблюдают, потому что им это выгодно, а вот сканеры, собирающие почту для спама или ищущие уязвимости, на robots.txt смотрят разве что как на список интересных мест, куда стоит заглянуть в первую очередь.

На практике это значит, что закрывать в robots.txt пути вроде /admin или /wp-login можно, но рассчитывать на защиту не стоит. Всерьёз это никого не остановит, скорее наоборот. Публичный файл сам подсказывает, где у сайта искать вход в админку.

Почему robots.txt не убирает страницы из поиска

Самая частая путаница связана с директивой Disallow. Она означает не «убери страницу из поиска», а «не сканируй эту страницу». Разница тонкая, но из-за неё закрытая страница спокойно остается в поиске, а нужная иногда из него выпадает.

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

Здесь же кроется вторая ловушка. Чтобы действительно убрать страницу из индекса, используют метатег noindex или заголовок ответа X-Robots-Tag, и это же советует Google, прямо отмечая, что сам robots.txt создан для управления нагрузкой на сайт, а не для сокрытия страниц. С noindex есть своя тонкость. Робот увидит его только в том случае, если сможет зайти на страницу и прочитать её. Стоит закрыть ту же страницу в robots.txt, и робот туда уже не зайдёт, а значит, и noindex не увидит. Два инструмента начинают мешать друг другу. В той же документации Google отдельно предупреждает, что правила сканирования и индексирования при смешивании способны гасить одно другое.

Отсюда и привычная логика. Когда страницу нужно держать вне индекса, её оставляют открытой для сканирования и ставят noindex. Сам же robots.txt берегут для другого, например, чтобы не гонять робота по бесконечным фильтрам и не тратить впустую ресурс обхода.

Как устроен синтаксис robots.txt

Минимальный рабочий файл выглядит примерно так:

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml

Здесь звёздочка в строке User-agent означает «правила для всех роботов», пустой Disallow означает «ничего не запрещаем», а Sitemap указывает на карту сайта. По сути, «всё открыто, вот карта».

Тот самый файл, который уронил магазин из вступления, выглядит так:

User-agent: *
Disallow: /

Один слеш после Disallow закрывает от обхода вообще всё. Именно такой файл обычно лежит на тестовых окружениях, и именно он опаснее всего при переезде.

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

User-agent: *
Disallow:

User-agent: SomeBot
Disallow: /

В правилах есть два полезных спецсимвола. Звёздочка * заменяет любую последовательность символов, а доллар $ обозначает конец адреса. Допустим, нужно закрыть от обхода все ссылки с параметрами сортировки, а заодно все PDF-файлы:

User-agent: *
Disallow: /*?sort=
Disallow: /*.pdf$

Здесь * подменяет любую часть адреса, а $ требует, чтобы адрес заканчивался именно на .pdf.

Allow работает как исключение из Disallow. С его помощью закрывают целый раздел и оставляют внутри одну открытую папку:

User-agent: *
Disallow: /private/
Allow: /private/public/

Весь раздел /private/ закрыт, кроме вложенной /private/public/. При конфликте правил побеждает более длинное и точное совпадение пути, а при равной длине выбирается менее строгое правило Google. У Яндекса логика похожая, хотя детали лучше каждый раз сверять с актуальной документацией, потому что они менялись.

Самое коварное тут — это длина пути. Допустим, кто-то закрыл все PDF и заодно открыл папку с загрузками:

User-agent: *
Disallow: /*.pdf
Allow: /downloads/

По задумке PDF закрыты. На деле для /downloads/report.pdf срабатывает Allow: /downloads/, потому что его путь длиннее, чем /*.pdf, и эти PDF остаются открытыми вопреки запрету.

robots.txt в рунете и тонкости Яндекса

Заметнее всего Яндекс отличается директивой Clean-param. Она говорит роботу, что определенные параметры в адресе не меняют содержимое страницы и их можно игнорировать при обходе. Удобно для разных меток вроде utm или идентификаторов сессий:

User-agent: Yandex
Clean-param: utm_source&utm_medium /catalog/

Со второй директивой, Crawl-delay, стоит быть аккуратнее. Когда-то она задавала паузу между запросами робота, чтобы тот не клал сервер нагрузкой. Google перестал её учитывать давно, а Яндекс отказался от поддержки ещё в 2018 году и предложил вместо неё настройку скорости обхода в панели вебмастера. Так что строки Crawl-delay во многих старых файлах сегодня просто игнорируются.

Отдельная тонкость касается кириллицы в адресах. Сам файл может быть в кодировке UTF-8, и современные поисковики, включая Яндекс, её понимают. Сложности возникают с путями. Для кириллических адресов надёжнее процентное URL-кодирование, а для доменных имён Punycode, так поведение предсказуемее. Яндекс прямо рекомендует кодированные формы, поэтому путь вроде /корзина записывают как /%D0%BA%D0%BE....

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

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

Где robots.txt ломается чаще всего

Самая болезненная ошибка уже описана выше, и это случайный полный запрет через Disallow из тестового окружения. Хватает и других, менее заметных.

Закрытые стили и скрипты

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

Путаница Disallow и noindex.

Про неё уже сказано, но она настолько частая, что повторю. Закрытие в robots.txt не убирает из индекса.

Регистр

В путях он важен, поэтому /Catalog и /catalog для робота разные адреса. В названиях директив регистр роли не играет, Disallow и disallow понимаются одинаково. Имена роботов обычно сопоставляются без учёта регистра, googlebot и Googlebot для Google одно и то же, но писать их лучше в официальном виде. Само имя файла при этом должно быть строчным, robots.txt, и никаких Robots.txt.

Не тот адрес

Файл работает только в корне домена и только для своего адреса. robots.txt с основного домена не действует на поддомен, а версия для http не относится к https. Для каждого домена и поддомена нужен свой файл.

Размер

У Google есть ограничение, он читает примерно первые 500 килобайт файла, остальное игнорирует. На обычном сайте это не проблема, но автоматически сгенерированные гигантские robots.txt иногда упираются в этот предел.

Что закрывают через robots.txt, а что другими инструментами

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

Robots.txt подходит, чтобы не пускать робота в тяжёлые или бессмысленные для поиска разделы, например в бесконечные фильтры, корзину, результаты внутреннего поиска. Это экономия так называемого бюджета обхода.

Метатег noindex в коде страницы убирает конкретную страницу из индекса при условии, что страница открыта для сканирования.

Заголовок X-Robots-Tag делает то же, что noindex, но на уровне ответа сервера. Удобно для файлов без HTML, например для PDF-документов или картинок.

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

Готовый robots.txt для обычного сайта

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

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /search/
Disallow: /*?sort=
Disallow: /*?filter=

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

Закрыты здесь корзина, оформление заказа, внутренний поиск и страницы с сортировкой и фильтрами. Всё остальное робот обходит как обычно, поэтому отдельный `Allow` не нужен, а карта сайта просто стоит в конце. И всё же это не догма. Те же фильтры прячут далеко не всегда, ведь страница фильтра порой, наоборот, хорошо живёт в поиске, например под запрос вроде «ноутбук с rtx 4060» она отвечает точнее общего каталога. В жизни набор запретов у каждого сайта получается свой.

robots.txt и сканеры искусственного интеллекта

Кроме классических поисковых роботов, по сайтам теперь ходят сканеры, которые собирают тексты для обучения языковых моделей. GPT-Bot у OpenAI, ClaudeBot у Anthropic, PerplexityBot у одноименного ИИ поисковика, CCBot у проекта Common Crawl, на данные которого опираются многие. Управляют ими через тот же robots.txt. Причём у OpenAI и Anthropic ботов несколько. Кроме обучающих, у них есть боты для поиска и для ответов на запросы пользователей. В robots.txt их закрывают по отдельности, так что обучающего бота можно закрыть и при этом остаться в ответах ChatGPT и Claude.

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

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: PerplexityBot 
Disallow: / 

Чуть особняком держится Google-Extended. Через этот токен владелец сайта решает, пойдёт ли его содержимое на обучение моделей Google. На обычное сканирование для поиска этот запрет не влияет, так что закрыть Google-Extended можно, не выпав из выдачи. Появился токен в 2023 году, когда владельцы сайтов как раз начали просить такую возможность.

С другой стороны, пока одни вебмастера баррикадируются от нейросетей с помощью robots.txt, другие пытаются под них подстроиться. В сентябре 2024 года Джереми Ховард (сооснователь fast.ai) предложил новый формат разметки — файл llms.txt. Если robots.txt указывает, куда ходить нельзя, то llms.txt — это текстовое приветствие для ИИ-агентов. 

Этот файл пишется на простом языке Markdown и размещается в корне сайта (например, ://site.com). Внутри публикуется краткая и емкая выжимка о проекте, а также список ссылок на самые важные и качественные страницы — документацию, FAQ или главные статьи. 

Часто в паре с ним создают llms-full.txt, куда выгружают вообще весь текстовый контент сайта, но в «плоском» виде — полностью очищенным от тяжелого HTML-кода, рекламы, дизайна и навигационных меню.

Зачем это нужно? Современным ИИ-ассистентам вроде Claude или ChatGPT тяжело и дорого «продираться» сквозь верстку сайта в поисках сути. Компактная шпаргалка экономит им контекстное окно. Формат быстро набрал популярность: его используют для своей документации сами разработчики ИИ (Anthropic, OpenAI, Google), умные редакторы кода вроде Cursor, а популярные SEO-плагины для WordPress (Yoast, RankMath) уже научились генерировать такие файлы автоматически.

Впрочем, и robots.txt, и llms.txt работают только на добросовестных сканерах, которые сами согласились соблюдать эти правила. Крупные игроки говорят, что соблюдают, и похоже, что так и есть, но проверить каждого нельзя... По сути, эти файлы здесь не замок, а вежливые таблички. Кому нужен настоящий контроль, тот уходит на уровень сервера и режет ботов по имени или по адресам. Кроме того, любые правила влияют только на сбор новых данных: уже собранное они из моделей не удалят. robots.txt влияет только на сбор новых данных, но не на само обучение. Уже собранное он не удалит, да и гарантий, что содержимое не попадёт в обучающую выборку, не даёт.

Как проверить свой robots.txt

Проверять файл на глаз почти бесполезно, очевидная ошибка всё равно ускользает. Поэтому есть смысл пользоваться инструментами.

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

У Яндекса в Вебмастере есть анализатор robots.txt. В него можно ввести адрес и посмотреть, открыт он для обхода или закрыт, и каким именно правилом. Это выручает, когда правил много и непонятно, какое срабатывает.

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

Поэтому на стейдж robots.txt с Disallow: / лучше вообще не вешать. Тестовый контур аккуратнее закрыть HTTP-аутентификацией, без логина внутрь не попадёт ни робот, ни случайный человек, и подменять при выкатке нечего. Сам файл удобнее не перетаскивать между окружениями, а собирать на лету по тому, где запущено приложение, тогда боевая версия физически не подхватит тестовую. Ну и простая проверка на `Disallow: /` прямо в выкатке ловит ровно этот случай до того, как файл доедет до боевого сайта.

Что важно помнить про robots.txt

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

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

И мы сознательно оставили за рамками часть тонкостей, например нюансы с кешированием самого файла и поведение совсем экзотических сканеров. Это темы для отдельных разборов.

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

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