На каталоге в сотни тысяч адресов robots.txt перестаёт быть формальностью и превращается в инструмент управления бюджетом обхода. Идея "закрыть от роботов всё лишнее" спорит с идеей "пусть робот видит всё и сам разберётся", и на большом магазине побеждает не одна из них, а продуманная схема: пагинация открыта, фильтры закрыты по паттернам, рекламные метки отрезаны. Разберём рабочие правила, различия роботов Google и Яндекса и типичные ловушки, из-за которых магазин теряет карточки из индекса.
Robots.txt управляет обходом, а не индексацией, и это меняет логику правил
Первое и главное: файл управляет обходом, а не индексацией. Если адрес закрыт в robots.txt, робот страницу не скачивает, но поисковик всё равно может показать её в выдаче, когда на неё ссылаются: вместо заголовка и описания останется голая ссылка. Второе следствие: метатег noindex на закрытой странице робот не увидит, потому что страницу не читает. Отсюда классическая ошибка новичка: адрес закрыт правилом Disallow и одновременно снабжён noindex, и вторая инструкция просто не работает.
Технические детали тоже имеют значение. Поисковики кэшируют файл и обновляют его не чаще раза в сутки, поэтому изменения вступают в силу не мгновенно. Google ограничивает размер файла пятьюстами килобайтами, всё сверх границы обрезается. Сервер обязан отдавать файл с кодом 200: если он стабильно отвечает ошибкой 5xx, робот Google может расценить это как запрет на обход всего сайта, а при 404 любые запреты снимаются. И последнее: любое правило в файле это просьба к вежливым роботам, а не команда: сканеры-собиратели чужого контента её игнорируют, поэтому защиту от них ищут на уровне сервера, а не в тексте файла.
Файл делится на секции по роботам: общий блок со звёздочкой и отдельные секции для конкретных поисковиков. Робот ищет свою секцию и подчиняется только ей, поэтому Clean-param в общем блоке бесполезен, а правило из секции Яндекса не сработает для Google. Частая причина путаницы именно здесь: адрес вроде бы закрыт, а обходится, потому что правило лежит не в той секции.
Полная открытость для краулинга и когда она перестаёт помогать магазину
Аргумент за открытость звучит разумно: пусть робот сам решит, что стоит в индексе, ведь поисковики умеют склеивать дубли по каноническим адресам и умеют не залипать в бесконечных комбинациях. На небольших магазинах это работает. Проблема начинается с масштабом: каталог в двести тысяч страниц, у каждой категории десяток фильтров, у каждого фильтра от двух до тридцати значений, плюс сортировка, плюс разбивка по страницам. Математика даёт миллионы комбинаций, и робот тратит бюджет обхода не на карточки товаров, а на третий уровень вложенности фильтра "цвет плюс размер плюс бренд".
Ключевой вопрос звучит так: достаточно ли роботу бюджета. Google прямо пишет, что вопросы бюджета обхода актуальны в первую очередь для крупных площадок с огромным числом адресов и постоянным добавлением новых. Практические признаки дефицита видны в панели вебмастера: число скачанных за сутки страниц стоит на месте или падает, а свежие карточки попадают в выдачу с задержкой в недели. Если таких признаков нет, а фильтры дают уникальный контент с реальным спросом, открытость оправдана. Если карточки ждут обхода неделями, пора резать лишнее.
Наглядный расчёт показывает масштаб. Категория обуви содержит четыре тысячи карточек и разбита на сорок страниц. Фильтр по цвету даёт десять значений, по размеру двадцать, по бренду тридцать, и комбинаторное пространство фильтров измеряется миллионами сочетаний. Даже если робот обойдёт малую часть, это тысячи лишних запросов на каждую категорию, и решение об открытости принимают по логам, а не по принципам: у одних магазинов фильтры собирают трафик, у других только грузят сервер.
Мощность сервера тоже имеет значение. Открытый обход миллиона комбинаций означает тысячи запросов в час, и витрина на слабом железе начнёт отвечать медленно живым покупателям. Бюджет робота и производительность магазина связаны напрямую: медленный ответ для робота оборачивается медленным ответом для всех.
Паттерны Disallow для фильтров, которые не режут важные страницы
Правила для магазина пишутся паттернами с подстановочными символами: звёздочка означает любую последовательность символов, знак доллара фиксирует конец адреса. Типовой каркас выглядит так:
User-agent: *
Allow: /
Disallow: /*gclid=
Disallow: /*yclid=
Disallow: /*sort=
Disallow: /*view=
Disallow: /search/
Disallow: /*compare=
Sitemap: https://example.com/sitemap.xmlПервые два правила отрезают рекламные метки кликов, вторая пара убирает множители сортировки и вида списка, третье закрывает страницы внутреннего поиска, четвёртое закрывает сравнение товаров. Паттерн "/*sort=" ловит параметр и после вопросительного знака, и после амперсанда, потому что срабатывает на любую строку с фрагментом sort=. В этом же кроется ловушка: фрагмент sort= сидит и внутри параметров вроде "resort=", поэтому правила пишут с оглядкой на реальный набор параметров из логов, а не по памяти.
Рабочий процесс для правил похож на работу с кодом. Сначала таблица: в колонках параметр, живые примеры адресов из логов, решение, паттерн. Затем прогон паттернов по выгрузке адресов за неделю: счётчик совпадений покажет, сколько и каких страниц уйдёт из обхода. Затем ручная проверка десятка случайных совпадений глазами. Только после этого файл уезжает на сервер. Час дисциплины экономит недели разбора последствий.
Проверка обязательна: каждый паттерн прогоняют по списку реальных адресов в обе стороны, иначе вместе с фильтрами уходит что-то полезное. Отдельный блок правил держат для служебных разделов и поддоменов, если витрины разнесены. И не забывайте про Sitemap в конце файла: эту строку читают оба поисковика, и она экономит роботу время на поиск карты.
Отдельная ловушка с поддоменами: у каждой витрины свой robots.txt в корне собственного домена, и правило из основного файла на мобильный или региональный поддомен не действует. Если магазин живёт на поддоменах городов, файлы дублируют с поправками на местную специфику, и проверять надо каждый по отдельности.
Пагинация, которую опасно закрывать от обхода роботами
Классический просчёт звучит так: закрыть адреса со счётчиком страниц, чтобы "не плодить дубли". Результат: робот перестаёт доходить до карточек, которые доступны только с двадцатой страницы категории, и глубина каталога вымывается из выдачи. Пагинация это дорога к товарам, и перекрыть её значит перекрыть дорогу вместе с грузом.
Рабочая схема открытой пагинации выглядит скромно: каждый адрес разбивки каноничен сам себе, без ссылок каноническим тегом на первую страницу, а переходы на следующую страницу остаются обычными индексируемыми ссылками. Указатели prev и next Google официально перестал использовать в 2019 году, и вкладываться в них нет смысла. Страница "показать всё" полезна только для лёгких категорий: если в разделе пять тысяч товаров, тяжёлый список сам превратится в проблему обхода. После изменений проверьте глубину: если карточки с больших глубин начали пропадать из выдачи, где-то в правилах закрылось лишнее.
Мониторинг глубины карточек встроен в обычный аудит: раз в месяц берут случайную сотню карточек из новых поставок и проверяют, за сколько кликов они достижимы из меню. Карточка, до которой робот добирается неделю, обычно живёт на большой глубине с малым числом входящих ссылок, и решением будет не только открытая пагинация, но и перелинковка: блоки рекомендаций, ссылки на свежие поступления со страницы раздела. robots.txt здесь половина работы, вторая половина это структура ссылок.
Clean-param Яндекса и различия синтаксиса роботов Google и Яндекса
У Яндекса есть инструмент, которого нет у Google: директива Clean-param. Она не запрещает обход, а сообщает роботу, какие параметры не меняют содержание страницы, и тот склеивает варианты по основному адресу. Для магазина это удобно: метки рекламы и счётчики исчезают из индекса, при этом страницы остаются доступными для чтения роботом.
User-agent: Yandex
Clean-param: utm_source&utm_medium&utm_campaign /catalog/Директиву Host, которой раньше указывали главное зеркало, Яндекс перестал учитывать в 2018 году, сейчас зеркала настраивают переездом с 301-редиректом. При конфликте правил у Яндекса побеждает более длинное совпадение, поэтому точное Allow для конкретного раздела перебивает общий Disallow. Директиву Crawl-delay Яндекс учитывает, а Google игнорирует: нагрузку на сервер от его робота регулируют ответами с кодами 429 или 503 и заголовком Retry-After, а не строками в файле. Готовый файл проверяют анализатором в панели вебмастера Яндекса, а для Google точечную проверку даёт инспектирование адреса: в отчёте видно, разрешён ли обход и каким именно правилом.
Проверить результат у Яндекса несложно: в панели вебмастера есть запрос переобхода страницы, и после добавления Clean-param полезно отправить на переобход несколько живых адресов с параметрами. По их состоянию в отчёте видно, склеились ли варианты. У Google цикл длиннее: оценка честнее через две-три недели, когда в отчёте по индексации можно сравнить количество вариантов одного адреса до и после.
Порядок внедрения правил на живом магазине без потери трафика
Роботы не читают файл так, как читает его человек, и правило "сначала проверь, потом закрой" на большом проекте превращается в обязательный процесс, а не в культуру письма. Внедрение на живом магазине выглядит так:
1. собрать полный список параметров из логов сервера и краулинга за месяц;
2. разделить параметры на мусор и рабочие комбинации с реальным спросом;
3. написать паттерны и прогнать их по списку реальных адресов в обе стороны;
4. развернуть файл в начале недели и сравнить статистику обхода до и после;
5. через две недели вычистить ложные срабатывания по отчёту индексации.
Файл храните в системе контроля версий вместе с остальным кодом: откат должен занимать минуту, а не вечер у разработчиков. Мониторинг после внедрения держит два числа: среднее число скачанных страниц в сутки и динамика количества адресов в выдаче. Резкое падение первого говорит об избыточно строгих правилах, падение второго сообщает о том же с задержкой в неделю, поэтому смотрят оба показателя сразу.
Развертывание удобно назначать на утро вторника: впереди целая рабочая неделя наблюдений, а не выходные с минимальной дежурной командой. Каждое изменение фиксируют в журнале: дата, правка, автор, причина. Через месяц журнал превращается в лучшее объяснение для новых сотрудников, почему файл выглядит именно так, а не иначе.
Когда полная открытость всё же выигрывает и как за ней следить
Открытость оправдана, когда выполняются три условия: бюджет обхода не в дефиците, фильтры дают комбинации с уникальным содержанием и собственным спросом, а серверу хватает производительности. Проверяется это не догадками, а цифрами: статистика обхода в панели вебмастера, отчёт по параметрам в краулере, позиции и переходы по фильтрованным адресам. Если фильтр "красные кроссовки" приносит трафик и продажи, резать его жалко, и правильнее оставить комбинацию открытой с каноническим адресом на саму себя.
Практичный принцип напоследок: robots.txt на большом магазине это не список страхов, а карта бюджета. Раз в месяц сверяйте список параметров с логами, вычищайте новые мусорные источники, проверяйте, не появились ли служебные адреса в выдаче, и держите файл под контролем версий. Тогда спор между открытостью и запретами решается не идеологией, а таблицей: то, что приносит трафик, открыто, то, что не приносит, закрыто, а спорные случаи проверяются на живых цифрах.
Полезный ритм такой: раз в квартал полный аудит параметров со свежими логами, раз в месяц быстрая проверка на новые источники мусора, раз в неделю взгляд на статистику обхода. Такой ритм держит файл живым документом, а не памятником решениям трёхлетней давности. На выручку приходит и автоматизация: файл генерируют из реестра параметров, который ведут в таблице, и каждое изменение проходит через ревью, как обычный код. Ручная правка живого файла на сервере запрещается правилом процесса, потому что именно так в проектах появляются строки, о которых через год никто не помнит.