Crawl budget (краулинговый бюджет) — это число страниц, которое поисковый робот готов обойти на сайте за единицу времени. На маленьком сайте бюджет неограничен, и эта тема не имеет практического значения. На сайте с десятками тысяч страниц краулинговый бюджет становится дефицитным ресурсом: робот не успевает обойти всё, новые и обновлённые страницы попадают в индекс с задержкой, часть URL вообще остаётся за пределами обхода. Управление бюджетом обхода — отдельная задача технического SEO на крупных проектах; от неё зависит скорость индексации, доля страниц в выдаче и общее индексирование сайта в его актуальной структуре.
Что такое crawl budget
Crawl budget — это лимит обращений поискового робота к сайту, заложенный в логику обхода. Робот не пытается переобойти весь сайт за один заход: он распределяет свои ресурсы между миллиардами доменов в интернете, и для каждого сайта рассчитывает индивидуальный объём обхода. Бюджет складывается из двух составляющих: crawl rate limit (технический лимит, который сайт выдержит без перегрузки) и crawl demand (потребность поисковика в обходе именно этого сайта).
Crawl rate limit отражает производительность сервера: насколько быстро сайт отвечает на запросы, как часто возвращает ошибки 5xx, сколько одновременных соединений принимает. Чем быстрее сервер, тем выше лимит. Crawl demand — это интерес алгоритма к содержимому: насколько часто на сайте появляется новое, насколько он популярен в выдаче, как часто пользователи переходят на его страницы.
Итоговое число обращений в день — произведение этих двух факторов. Сайт с быстрым сервером и редкими обновлениями получает средний бюджет: робот мог бы обходить больше, но нечего смотреть. Сайт со слабым сервером и активной редакцией — тоже средний бюджет: контент интересный, но сервер не выдержит увеличения частоты запросов. Высокий бюджет — у сайтов с быстрым сервером и активным обновлением.
Crawl budget — не настройка и не ресурс, который можно купить. Это поведенческое решение робота, основанное на сигналах сайта. Изменить бюджет можно только через изменение этих сигналов: ускорить сервер, очистить структуру, повысить ценность контента.
Для каких сайтов это важно
Тема crawl budget актуальна не для всех проектов. Для большинства сайтов услуг и блогов робот обходит весь сайт за день-два и проблема не возникает. Реальный лимит начинает влиять на индексирование больших сайтов.
| Размер сайта | Актуальность темы | Что делать |
|---|---|---|
| До 500 страниц | Неактуально | Стандартные настройки sitemap.xml, robots.txt, canonical — этого достаточно |
| 500–5 000 | Низкая | Проверить, что нет десятков тысяч URL с фильтрами и параметрами; закрыть их через canonical или Clean-param |
| 5 000–50 000 | Средняя | Регулярный аудит логов сервера, оптимизация sitemap-индекса, контроль обхода параметрических URL |
| 50 000+ | Критическая | Постоянный мониторинг crawl stats, log file analysis, дробление sitemap по типам, приоритизация обновляемых разделов |
| 500 000+ (агрегаторы, маркетплейсы) | Жизненно важная | Выделенная команда SEO с фокусом на crawl budget; технические решения уровня noindex для слабых разделов, динамические robots.txt, специализированные сервисы лог-анализа |
Для интернет-магазина с 10 000 товаров и развитой системой фильтров количество доступных URL может достигать миллиона комбинаций. Без управления бюджетом обхода робот расходует большую часть лимита на технические дубли, в то время как новые карточки товаров индексируются неделями.
Из чего складывается краулинговый бюджет
На размер бюджета влияет набор технических и контентных сигналов. Их понимание задаёт основу того, как управлять crawl budget без догадок и подбора по наитию.
Скорость и стабильность сервера. Главный технический фактор. Время ответа сервера на запрос Googlebot или YandexBot напрямую определяет crawl rate limit. Сервер с временем ответа 200–400 мс получает высокий лимит. Сервер с регулярными ответами 1–2 секунды или с частыми ошибками 5xx — низкий: робот снижает частоту обращений, чтобы не перегружать ресурс. Любая нестабильность инфраструктуры (медленные базы данных, перегруженные CMS) снижает бюджет.
Размер и активность сайта. Сайт с миллионом страниц требует физически большего бюджета, чем сайт со ста страницами. Активность обновлений (новые товары, новые статьи, изменения в каталоге) повышает crawl demand: робот понимает, что есть смысл возвращаться чаще.
Качество и популярность страниц. Страницы с высоким трафиком из выдачи обходятся чаще. Страницы, на которые есть внешние ссылки, — тоже. Малоценные страницы (старые статьи без трафика, дубли, технические разделы) обходятся реже или вообще исключаются из активного обхода.
Внутренняя перелинковка. Страницы, на которые ведёт много внутренних ссылок (из меню, перелинковки, фильтров), робот считает приоритетными и обходит чаще. Страницы на 5+ уровне без перелинковки попадают в категорию «низкий приоритет» — глубина обхода в таких случаях достигает нескольких недель или месяцев между визитами робота.
История сайта. Сайт с историей частых ошибок, удалений и нестабильности получает меньший бюджет даже после исправления. Восстановление доверия со стороны алгоритма занимает 2–6 месяцев. Новые домены работают с минимальным бюджетом первые несколько месяцев — это нормальное поведение.
Что расходует бюджет впустую
На большом сайте часть бюджета обхода уходит не на ценные страницы, а на технические URL, которые ничего не дают индексу. Это и есть главная зона оптимизации.
- Дубли с GET-параметрами. UTM-метки, идентификаторы сессий, параметры сортировки и фильтрации, параметры пагинации. Один товар может быть доступен по 50+ URL с разными параметрами — все обходятся, все засчитываются в бюджет.
- Цепочки редиректов. Каждый шаг 301 редиректа — отдельный запрос робота. Цепочка из 3–4 редиректов умножает расход бюджета на каждом URL.
- Битые ссылки и 404. Робот пробует обходить несуществующие URL, фиксирует ошибку, тратит запрос. На сайте с десятками тысяч 404 это десятки тысяч потерянных обращений.
- Тонкие и устаревшие страницы. Страницы без трафика, дублирующие, пустые карточки с надписью «нет в наличии», старые статьи блога без обновлений — обходятся, но не дают ценности.
- Фильтры с большой матрицей комбинаций. На каталоге с 5 фильтрами по 10 значений теоретическое число комбинаций — 100 000+. Без закрытия от индексации робот пытается обойти их все.
- Дубли через слеш и регистр.
/category/и/category,/Category/и/category/— четыре URL для одной страницы без редиректа или canonical. - Глубокая пагинация. Страницы пагинации
?page=50, ?page=100на большом каталоге обходятся, но фактически содержат старые товары без коммерческой ценности для нового трафика.
На крупном интернет-магазине доля обращений робота к малоценным URL нередко превышает 70%. Освобождение этой части бюджета — главная задача оптимизации.
Как мониторить crawl budget
Без мониторинга работа с бюджетом обхода ведётся вслепую. Контроль строится на трёх уровнях. Параллельно полезно понимать понятие crawl frontier — это очередь URL, которую робот выстраивает для обхода: какие URL уже посещены, какие на очереди, какие отложены до следующего цикла. Сигналы из консолей и логов как раз показывают срез этой очереди.
Google Search Console → Crawl Stats. В Search Console раздел «Настройки → Статистика сканирования» (Crawl Stats) показывает: число запросов Googlebot в день, общий объём загруженных байт, среднее время ответа сервера, распределение по типам ответов (2xx, 3xx, 4xx, 5xx), распределение по типам файлов (HTML, CSS, JS, изображения). На графике видны провалы и пики обхода, по которым можно оценить эффект изменений.
Яндекс.Вебмастер → Статистика обхода. В Яндекс.Вебмастере раздел «Индексирование → Статистика обхода» показывает аналогичные данные для YandexBot: число обращений, коды ответов, распределение по дням. Дополнительный отчёт «Страницы в поиске» с фильтром «Исключённые» — список URL, которые робот видел, но не включил в индекс.
Анализ логов сервера
Самый точный метод — log file analysis. Из логов сервера (Apache access.log, nginx access.log) фильтруются записи о визитах Googlebot, YandexBot, Bingbot, и анализируется: какие URL обходились, сколько раз, какой код ответа возвращался, какой User-Agent использовался. Инструменты: Screaming Frog Log File Analyser, Botify, OnCrawl, JetOctopus.
Лог-анализ даёт детализацию, которой нет в Search Console и Вебмастере: точные URL и время обращений, частоту обхода каждой конкретной страницы, поведение робота по часам и дням недели. Это основной инструмент технического SEO на больших проектах.
Как оптимизировать crawl budget
Оптимизация crawl budget — это перенаправление обхода с малоценных URL на приоритетные. Несколько направлений работы, которые применяются последовательно.
Закрытие через robots.txt. Технические разделы (личный кабинет, корзина, страницы благодарности, динамические URL с GET-параметрами) закрываются от обхода через Disallow в robots.txt. Робот не тратит запросы на закрытые URL. Для Яндекса дополнительно используется директива Clean-param, которая склеивает URL с разными значениями параметра в один.
User-agent: *
Disallow: /cart/
Disallow: /account/
Disallow: /search/
Disallow: /*?utm_
User-agent: Yandex
Clean-param: utm_source&utm_campaign&sort&filter /Управление через canonical. Дубли с параметрами и вариантами товаров закрываются через rel="canonical" на основную версию. Робот по-прежнему обходит дубли, но в меньшем объёме — алгоритм понимает их вторичность и снижает частоту переобхода.
Noindex для слабых разделов. Страницы пагинации после 5–10 страниц, фильтры без коммерческого спроса, технические листинги закрываются через meta noindex. Робот сначала обходит их, но со временем переходит на низкую частоту обхода — алгоритм понимает, что эти URL не нужны в индексе.
Структурированный sitemap-индекс
Вместо одного монолитного sitemap.xml на миллион URL делается sitemap-индекс с разбивкой по типам: sitemap-products.xml, sitemap-categories.xml, sitemap-articles.xml. Каждая карта с обновлённой датой <lastmod> сигнализирует, какие группы страниц обновились. Робот может сосредоточиться на свежем контенте.
Поле <lastmod> в каждой записи sitemap — отдельный приоритизирующий сигнал: робот видит, что страница обновилась с прошлого обхода, и ставит её выше в очередь. Регулярное обновление lastmod при реальных правках контента (не имитация для всех URL) — рабочий инструмент управления частотой переобхода приоритетных страниц.
Точечная внутренняя перелинковка. Приоритетные страницы (новые товары, обновлённые статьи) получают ссылки из часто обходимых разделов: главная, каталог-листинги, верх блога. Это поднимает их частоту обхода до 1–3 дней против 1–2 недель для страниц без перелинковки.
Ускорение сервера. Снижение времени ответа сервера до целевого диапазона (см. H3 «Скорость и стабильность сервера» выше) расширяет crawl rate limit. Кэширование, оптимизация запросов к базе, переход на более мощный хостинг, использование CDN — стандартные шаги. На сайтах с быстрым сервером общий объём обхода может вырасти в 2–3 раза.
Особенности в Google и Яндексе
| Параметр | Яндекс | |
|---|---|---|
| Имя робота | Googlebot (и подвиды: Googlebot-Image, Googlebot-Video, Googlebot-News) | YandexBot (и YandexImages, YandexMedia, YandexNews) |
| Документация по теме | Развёрнутая, отдельный гайд «Large site owner’s guide to managing your crawl budget» | Краткая, в разделе «Помощь Вебмастера» |
| Управление параметрами | URL Parameters в Search Console — устарел и отключён в 2022 году. Сейчас — только canonical и noindex | Директива Clean-param в robots.txt — рабочий инструмент |
| Чувствительность к качеству сервера | Высокая, быстрая реакция: при росте 5xx обход снижается в течение часов | Высокая, реакция в течение 1–3 дней |
| Сигналы из Search Console / Вебмастера | Crawl Stats с детализацией по типам файлов и ответов | Статистика обхода в Вебмастере; «Переобход страниц» как ручной инструмент |
| Обработка noindex | Сначала продолжает обходить, постепенно снижает частоту до раз в несколько месяцев | Снижение частоты обхода быстрее, но noindex-страницы периодически переобходятся |
Для проектов под белорусский рынок (Google 65–75%, Яндекс 25–30%) технические настройки строятся под Google как более строгого индексатора. Для Яндекса в robots.txt прописываются отдельные директивы (Clean-param, Host исторически, хотя сейчас её роль минимальна).
Типичные ошибки
| Ошибка | Последствие | Решение |
|---|---|---|
| Все фильтры открыты для индексации | Десятки тысяч малоценных URL расходуют бюджет; приоритетные страницы обходятся редко | Закрытие неприоритетных комбинаций через canonical на основную категорию или meta noindex для пагинации после 10 страниц |
| Один монолитный sitemap.xml на 500 000+ URL без разбиения по типам | Робот теряет приоритеты; новые товары и обновления не выделяются на фоне старых страниц | Sitemap-индекс с раздельными картами для категорий, товаров, статей; на крупных каталогах — дополнительное дробление по разделам |
| Медленный сервер с регулярными 5xx | Crawl rate limit падает; общий объём обхода уменьшается на 30–60% | Аудит производительности: кэширование, оптимизация базы данных, CDN, переход на более мощный тариф хостинга |
| Сотни цепочек редиректов после миграции | Каждая цепочка из 3+ шагов умножает расход бюджета на одну страницу | Переписать карту редиректов: старый URL → актуальный URL напрямую, без промежуточных шагов |
| Тысячи 404 в индексе после удалений | Робот регулярно проверяет несуществующие URL; на сайте с 10 000 битых ссылок это десятки тысяч потерянных обращений в месяц | Точечный аудит через Screaming Frog и Search Console; 301 редиректы для удалённых страниц с аналогами, 410 для удалённых без замены |
| Параметры сортировки и фильтрации без обработки | На сайте генерируются миллионы URL-комбинаций; робот пробует обойти большинство | Disallow в robots.txt для критичных параметров; Clean-param для Яндекса; canonical на основную версию |
| Глубокая пагинация без noindex | Старые страницы пагинации (page=50, page=100) обходятся, но не приносят трафик | Meta noindex на страницы пагинации после 5–10 страниц; внутренние ссылки только на первые 3–5 страниц |
| Игнорирование лог-анализа | Решения по бюджету принимаются вслепую; невозможно проверить эффект изменений | Регулярный лог-анализ через Screaming Frog Log File Analyser или специализированные сервисы; еженедельный отчёт по структуре обхода |
Часто задаваемые вопросы
Какой размер crawl budget у моего сайта?
Точное число — в Search Console (Crawl Stats) для Google и в Яндекс.Вебмастере (Статистика обхода) для Яндекса. На графике видно среднее число запросов в день за последние 90 дней. Для оценки достаточности — сравнить общий объём обхода с числом ценных URL на сайте: если 70%+ запросов уходит на дубли и технические страницы, бюджет требует оптимизации.
Можно ли увеличить crawl budget искусственно?
Прямо — нет, это не настройка. Косвенно — да, через изменение сигналов: ускорить сервер (расширяется crawl rate limit), повысить актуальность и популярность контента (растёт crawl demand), очистить структуру от мусорных URL. Эффект на полную мощность раскрывается за 2–6 месяцев работы.
Что делать, если новые страницы не индексируются неделями?
Признак того, что бюджет уходит на нецелевые URL. Шаги: лог-анализ для понимания, куда тратится обход, точечная перелинковка с главной и обходимых разделов на новые страницы, ручная подача через «Проверка URL» в Search Console и «Переобход страниц» в Яндекс.Вебмастере, оптимизация sitemap.xml с актуальными датами <lastmod>.
Влияет ли количество страниц на сайте на индексирование больших сайтов?
Влияет напрямую. На сайте с 10 000 страниц робот успевает обойти всё за 1–2 недели. На сайте с 1 000 000 страниц — за несколько месяцев, и часть URL может вообще не попасть в активный обход. Удаление или закрытие через noindex малоценных страниц освобождает бюджет для приоритетных и ускоряет переобход важных разделов.
Что приоритетнее: robots.txt или noindex для закрытия от индексации?
Это разные инструменты. Disallow в robots.txt запрещает обход URL — робот не заходит туда вообще, бюджет экономится сразу. meta noindex разрешает обход, но запрещает индексацию: робот заходит, видит запрет, не индексирует. Для экономии бюджета — robots.txt; для управления именно индексом (когда страница должна быть доступна пользователю, но не быть в выдаче) — noindex.
Как часто пересматривать настройки crawl budget?
Для больших сайтов — еженедельный мониторинг через Search Console и Вебмастер, ежемесячный лог-анализ, ежеквартальный полный аудит. После крупных изменений (миграция, релиз новой версии каталога, изменение фильтрации) — внеплановая проверка через 2–4 недели.
Зависит ли crawl budget от уровня контента?
Косвенно — да. Сильный контент с поведенческими сигналами и внешними ссылками повышает crawl demand: робот понимает, что сайт нужно обходить чаще. Сайт с тонким контентом и низким трафиком получает минимальный бюджет даже при отличном сервере.
Стоит ли крупному магазину покупать дорогой хостинг ради бюджета обхода?
Если сервер медленный — да, ускорение даёт прямой эффект на crawl rate limit. Если сервер уже отвечает за 200–400 мс — дополнительные инвестиции в инфраструктуру дадут меньше эффекта, чем работа с архитектурой и закрытие дублей через robots.txt и canonical.
Сколько стоит работа с crawl budget в РБ?
Разовый технический аудит с лог-анализом и подготовкой технического задания для разработчиков — от 1500 до 3500 BYN в зависимости от размера сайта. Для каталогов 100 000+ страниц — от 3000 до 6000 BYN с привлечением специализированных инструментов лог-анализа. В составе SEO-абонемента для крупных интернет-магазинов работа с обходом — постоянная задача месячного ведения.
