Зачем сайтам всё ещё нужен robots.txt

У сайта может быть 20 страниц, а может быть 20 миллионов URL. И проблема большого сайта часто начинается именно с этих URL: часть адресов нужна людям и поиску, а часть появляется только потому, что каталог умеет фильтровать, сортировать и искать.

Возьмём интернет-магазин. Есть каталог, в нём несколько тысяч товаров. Пользователь выбирает производителя, цвет, размер, цену - и сайт собирает для него новый адрес. Добавил сортировку - получил ещё один. Поменял параметр - ещё один.

Самих товаров больше не стало. URL стало больше.

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

Файл при этом предельно простой. Это обычный текстовый документ по адресу /robots.txt в корне сайта. Внутри - правила для автоматических роботов.

И этой простой конструкции уже больше тридцати лет.

Откуда взялся robots.txt

В 1994 году веб был совсем небольшим по сегодняшним меркам. Сайтов становилось всё больше, поисковые роботы активно их обходили, а владельцам серверов хотелось иметь хотя бы какой-то способ сказать: этот каталог роботам трогать не нужно.

Мартейн Костер предложил для этого механизм, известный как Robots Exclusion Protocol. Идея была довольно прямой: сайт размещает специальный файл в корне, а робот перед обходом смотрит правила и учитывает их.

Никаких специальных панелей управления или API для этого не требовалось.

Интересно, что за десятилетия сам формат почти не изменился. В 2022 году Robots Exclusion Protocol был формализован в RFC 9309, а файл всё так же выглядит как обычный текст.

Открываешь /robots.txt сегодня - и перед глазами всё тот же набор строк.

Что находится внутри

Самый простой вариант выглядит так:

//text

User-agent: *
Disallow: /admin/
Disallow: /search/

User-agent выбирает робота, к которому относится следующий блок. * означает всех роботов.

Disallow задаёт путь, который соответствующий робот не должен запрашивать согласно этим правилам.

Можно сделать и более точное исключение:

//text

User-agent: *
Disallow: /private/
Allow: /private/public-page.html

Здесь правило касается всего /private/, но отдельный адрес разрешён.

Есть ещё Sitemap:

//text

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

Так сайт указывает расположение XML-карты сайта.

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

Где сайт начинает плодить URL

Вернёмся к интернет-магазину.

Исходный каталог:

//text

/catalog/

После выбора бренда:

//text

/catalog/?brand=sony

Добавили цвет:

//text

/catalog/?brand=sony&color=black

Добавили сортировку:

//text

/catalog/?brand=sony&color=black&sort=price

Для посетителя это один и тот же каталог, просто с разными настройками.

Для робота это уже разные URL.

А теперь представим магазин с десятками производителей, цветов, размеров, характеристик и вариантов сортировки. Комбинаций становится очень много. Внутренний поиск способен создавать ещё больше адресов: каждый запрос пользователя может формировать собственный URL.

Похожая история встречается у фильтров, календарей, каталогов недвижимости, архивов и некоторых CMS.

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

Но тут есть важная граница.

Запрет обхода и индексация - разные вещи

Допустим, сайт содержит:

//text

User-agent: *
Disallow: /search/

Роботу сообщают, что раздел /search/ обходить не нужно. Это правило касается именно доступа робота к URL.

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

Поэтому robots.txt не стоит использовать как способ убрать страницу из поисковой выдачи.

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

У этих инструментов разные задачи: robots.txt регулирует обход, noindex - индексацию.

Закрытый каталог всё равно останется доступным человеку

Представим, что в файле написано:

//text

User-agent: *
Disallow: /secret/

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

Если человек знает адрес, он может открыть его в браузере. А если речь идёт о действительно закрытой информации, URL вообще может оказаться случайно опубликованным где-нибудь ещё.

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

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

Стоит ли закрывать CSS и JavaScript

В старых конфигурациях сайтов иногда встречается:

//text

Disallow: /css/
Disallow: /js/

Выглядит логично: это технические файлы, значит поисковику они якобы не нужны.

Но современному поисковику ресурсы страницы могут понадобиться для её обработки. CSS и JavaScript влияют на то, как браузер и поисковые системы видят и интерпретируют страницу.

Поэтому закрывать целые каталоги только из-за их названия - плохая идея.

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

Один robots.txt может содержать разные правила

Правила можно задавать для конкретного робота.

Например:

//text

User-agent: Googlebot
Disallow: /private/

User-agent: *
Disallow: /tmp/

Первый блок относится к Googlebot. Второй - к роботам, для которых подходит *.

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

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

Иногда одна строка меняет всё

У небольшого сайта robots.txt может выглядеть совсем просто:

//text

User-agent: *
Disallow: /admin/
Disallow: /search/

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

А у крупного проекта файл способен разрастись до нескольких десятков правил.

Само по себе это не проблема. Гораздо важнее содержание.

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

Например:

//text

Disallow: /

Для соответствующего робота это означает запрет обхода всего сайта.

Ошибка здесь особенно неприятна именно своей простотой: одна строка способна закрыть от робота весь проект.

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

Почему файл всё ещё нужен

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

Изменился и сам интернет.

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

robots.txt остаётся простым способом сообщить роботам, какие участки сайта не стоит обходить.

На маленьком сайте разница может быть почти незаметна. На крупном проекте ситуация другая: когда URL становится очень много, контроль за тем, что именно робот запрашивает, приобретает вполне практический смысл.

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

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