У каждого хоста в Google свой лимит внимания. Робот приходит на сайт с ограниченным запасом соединений и времени, и этот запас достаётся не самым полезным страницам, а самым доступным. В каталоге с фасетной навигацией доступнее всего как раз комбинации фильтров, а не карточки товаров: их миллионы, они легко находятся по ссылкам и выглядят для робота как новые URL. Краулинговый бюджет в таких проектах утекает тихо, без ошибок в отчётах, поэтому оптимизация начинается не с косметики, а с честного ответа на вопрос, куда именно робот тратит свои запросы. Разберём, из чего складывается бюджет, как направить Googlebot на коммерческие страницы через robots.txt и sitemap и какие метрики показывают, что настройка сработала.
Из чего складывается бюджет обхода и чем он отличается от скорости обхода
Google описывает бюджет обхода как результат двух слагаемых. Первое слагаемое - предел ёмкости обхода, hostload: сколько параллельных соединений и какого запаса времени робот может держать на хосте, не перегружая сервер. Стартовый лимит консервативный и одинаковый для всех, дальше система сама поднимает его, если сайт отвечает стабильно и быстро, и снижает, если растёт задержка, летят ошибки 5xx или ответы 429. Второе слагаемое - спрос: насколько часто роботу нужно возвращаться. Спрос зависит от воспринимаемого объёма URL, популярности страниц и скорости устаревания контента. Даже при свободной ёмкости робот не станет приходить чаще, если спрос низкий.
Официальный гайд по бюджету Google адресует крупным сайтам: от миллиона страниц с изменениями раз в неделю или от десяти тысяч страниц с ежедневными обновлениями. Магазин с фасетами попадает в эти категории раньше, чем кажется: три фильтра по пять значений уже дают тысячи комбинаций, а с сортировками и пагинацией пул URL растёт на порядки. Прямо назван и симптом, по которому стоит бить тревогу: массовый статус "Обнаружено, сейчас не индексируется" в Search Console. Робот узнал адреса, но не нашёл ресурсов или причин их обойти.
Фасетная навигация и календари как главные потребители ресурса робота
В рекомендациях Google перечислены типичные причины всплеска обхода: фасетная навигация и прочие механизмы сортировки и фильтрации, календари с отдельным URL под каждую дату и цели динамических рекламных кампаний. Механика везде одна - каждый фильтр умножает пул адресов, а робот не может заранее отличить полезную комбинацию от бесполезной: чтобы понять это, страницу нужно запросить и отрисовать. В итоге фасеты съедают ёмкость до того, как система разберётся, что перед ней дубликаты. Google называет это избыточным обходом и добавляет второе следствие: пока робот занят фильтрами, новые товары и свежие статьи он находит медленнее.
Отдельные пожиратели бюджета, о которых часто забывают. Внутренний поиск по каталогу: каждая фраза из строки поиска создаёт новый URL, и ссылки на них робот находит в связанных запросах блоков "с этим ищут". Страницы сравнения и избранного с десятками идентификаторов в параметрах. Хвосты utm-меток, попадающие в обход из писем и баннеров. И пустые комбинации фильтров: если по запросу "красные кроссовки 46 размера" товаров нет, страница не должна отдавать код 200 с пустой сеткой и тем более редиректить на общий каталог ошибок. Честный ответ для пустой выборки - 404, без пересылки на служебную страницу ошибки.
Если отдельные комбинации фильтров нужны в индексе как посадочные под запросы, им стоит дать структуру, которую робот в состоянии понять. Разделитель параметров - только стандартный амперсанд: запятые, точки с запятой и скобки поисковые системы распознают плохо. Если фильтры кодируются в путь адреса, логический порядок сегментов фиксируется раз и навсегда, а дубль фильтра исключается на уровне шаблонов. И на каждую такую страницу - собственный заголовок, внятный текст и ссылочная поддержка из статей и подборок, иначе бюджет уйдёт на страницы, которые всё равно не соберут трафик.
Настройка robots.txt для каталога с фильтрами без случайных блокировок
Базовая идея проста: разрешить обход товаров и базовых категорий, а генераторы мусора закрыть шаблонами URL. В примере по фасетам Google показывает такой набор директив:
user-agent: *
disallow: /*?*sort=
disallow: /*?*color=
disallow: /*?*size=
allow: /*?size=all$
sitemap: https://www.example.com/sitemap.xmlШаблон /?sort= перехватывает любой адрес с параметром сортировки, а строка allow: /*?size=all$ возвращает роботу специально оставленную полезную комбинацию. Закрывать директиву только для Googlebot нет смысла: универсальный вариант экономит ресурсы и для остальных систем обхода, включая Бинг и Яндекс. Несколько правил, которые обычно нарушают при внедрении. Первое - не блокируйте CSS и JavaScript: отрисовка фасетной страницы без стилей и скриптов ломается, и проверка URL в Search Console покажет страницу, которую пользователь никогда не увидит. Второе - фрагменты после # в адресе не обходятся в принципе, поэтому фильтр, посаженный в хеш, вообще не влияет на краулинг: иногда это самый дешёвый способ спрятать бесконечные комбинации. Третье - canonical и noindex на фасетах работают, но Google прямо называет их менее надёжными в долгой перспективе, чем запрет обхода. robots.txt не убирает адреса из индекса мгновенно, зато экономит запросы с первого дня.
Отдельная тонкость про порядок действий. Мету robots noindex робот видит, только если страницу можно обойти, поэтому убирать страницу из индекса закрытием в robots.txt нельзя: адрес может остаться в выдаче без сниппета, если на него ссылаются извне. Рабочая схема обратная - сначала поставить на страницу noindex, дождаться её выпадения из индекса и лишь потом блокировать обход, если она и вправду ничего не даёт ни людям, ни роботу.
Что Google игнорирует в XML sitemap и что реально работает
Тег priority из протокола sitemap Google игнорирует, changefreq тоже. Устойчивый миф, будто максимальный приоритет направит робота на важные страницы, не выдерживает проверки: в обработке поисковой системы этих значений нет, и никакие "1.0" на ключевых категориях ничего не меняют. Работает другое. Поле lastmod Google читает, если дата стабильно совпадает с реальным изменением страницы. Как только CMS начинает писать туда время каждой выгрузки, система перестаёт доверять полю, и вся экономия сходит на нет.
Ограничения формата жёсткие: один файл - не больше 50 000 URL и 50 МБ без сжатия, сверх этого собирается sitemap index. Хорошая новость для магазинов: RSS и Atom фиды принимаются как sitemap, поэтому лента новых товаров - уже половина работы. Минимальный рабочий файл выглядит так:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.example.com/catalog/running-shoes/</loc>
<lastmod>2026-04-18</lastmod>
</url>
</urlset>Для краулингового бюджета sitemap - это не список приоритетов, а список фактов: вот существующие URL, вот когда они реально менялись. Держите файл чистым: только страницы с кодом 200, без редиректов, без версий, канонизированных на другие адреса, без выгрузки всего подряд. Отдельная страховка для товарного каталога - фид Merchant Center: спрос роботов Google на страницы из товарных фидов формируется отдельно от обычного обхода, и новые карточки через фид обнаруживаются быстрее, чем через цепочки ссылок.
Управление спросом робота через свежесть внутренних ссылок и честные коды ответов
Второй рычаг - спрос. Воспринимаемый объём URL Google называет самым управляемым фактором: то, чего робот не знает, он и не станет обходить. Консолидация дублей, честные 404 и 410 для снятых с продажи товаров, вычистка софт-404 страниц - всё это уменьшает очередь и освобождает запросы. Ссылки внутри сайта подсказывают популярность: карточка, на которую ссылаются из шапки, категорий и подборок, получает визиты чаще, чем страница, забытая на пятой ступени пагинации. Свежесть работает через честный lastmod и реальную частоту обновлений, а не через красную дату в каждой строке.
Короткие цепочки редиректов экономят и ваши ресурсы, и время робота: каждый лишний прыжок - лишний запрос. Поддержка 304 с заголовком If-Modified-Since позволяет серверу вместо полного документа вернуть один ответ "не менялось". Скорость тоже часть формулы ёмкости: стабильное время до первого байта даёт Google возможность держать на хосте больше параллельных соединений. И наоборот: медленные ответы и ошибки снижают лимит по всему домену, включая те страницы, что работают нормально.
Диагностика по отчёту статистики обхода и логам сервера
Search Console показывает статистику обхода: запросы по дням, разбивку по назначению визитов и типу робота, распределение ответов по кодам, среднее время ответа и одновременные соединения. В статистике полезны разрезы по типу робота - смартфонный и десктопный обход идут с разной скоростью, и хромает обычно мобильный, по типу файлов - доля CSS и JavaScript в общем числе запросов подсказывает, сколько ресурсов съедает отрисовка, и по кодам ответов - рост ошибок 4xx и 5xx по дням сигнализирует о перегрузке в моменты пиковых визитов. К отчёту добавляется главный источник правды - логи сервера, отфильтрованные по user-agent Googlebot. Инструменты разбора логов вроде Screaming Frog Log File Analyzer или самописный скрипт на Python показывают, какая доля запросов уходит на фильтры, сортировки и пагинацию, а какая - на карточки и категории.
Маркеры утечки бюджета, которые видны без глубокого анализа, выглядят так:
- доля обходов страниц фильтров и сортировок превышает долю обходов карточек товаров;
- в отчёте индексирования массово растёт статус "Обнаружено, сейчас не индексируется";
- новые карточки ждут первого визита робота неделями при живом и чистом sitemap;
- в логах велика доля редиректов 301 и 302 на пути робота и повторных заходов в удалённые разделы;
- сервер отвечает роботу заметно медленнее, чем обычным посетителям, и соединения висят дольше нормы.
Каждый пункт - отдельный мини-проект: закрыть шаблон в robots.txt, вычистить цепочки редиректов, усилить ссылки на разделы, которые приносят выручку. Оценивать эффект стоит не раньше чем через месяц: лимиты ёмкости пересчитываются медленно, и резкие рывки тут не в чести.
Экстренное снижение нагрузки робота и честные пределы управления бюджетом
Если обход перегрузил инфраструктуру, быстрый способ притормозить робота - отвечать кодами 500, 503 или 429 вместо 200. Google снижает скорость на всём хосте и сам восстанавливает её, когда ошибки исчезнут. Заголовок Retry-After подсказывает срок возврата: задержка в секундах или абсолютная дата по стандарту RFC 9110.
HTTP/1.1 503 Service Unavailable
Retry-After: 120Встроенного механизма "выдайте больше бюджета" у Google нет. Заявки на увеличение скорости обхода не принимаются в принципе, а заявка на снижение рассматривается несколько дней и годится только для экстренных случаев. Поднять лимит можно косвенно: добавить серверных мощностей, если инструмент проверки URL показывает "Hostload exceeded", и повышать ценность контента. Спрос робота растёт к страницам, которые собирают поведение пользователей, внешние ссылки и поводы возвращаться. Переезд сайта - отдельная история: смена адресов сама по себе подстёгивает спрос, и на время переезда база под обход должна быть готова к всплеску.
Краулинговый бюджет не выжимается настройками - он освобождается. Запреты в robots.txt не ускоряют обход нужных страниц напрямую, они лишь убирают из очереди тысячи бесполезных URL, и на фоне чистого sitemap с честным lastmod робот перераспределяет запросы туда, где лежат деньги: в категории, карточки и свежие материалы. Проверить эффект просто: через месяц после настройки доля обходов карточек в логах растёт, а статус "Обнаружено, сейчас не индексируется" перестаёт размножаться. Если ничего не изменилось, ищите вторую проблему - перегруженный сервер, медленные ответы или слишком бледный спрос на контент, который роботу не за чем возвращаться смотреть.