Короткий ответ
Краулинговый бюджет — это сколько URL вашего сайта Googlebot готов обойти за отрезок времени. Проблемой он становится редко: на сайтах до нескольких тысяч адресов причина непроиндексированных страниц почти всегда другая: слабый контент, дубли или отсутствие внутренних ссылок. Думать про бюджет стоит, когда сайт генерирует десятки тысяч URL: каталог с фильтрами, календарь бронирования, внутренний поиск, параметры сортировки.
Из чего складывается краулинговый бюджет
Google Search Central описывает его как сочетание двух ограничений.
| Составляющая | Что это | Кто на неё влияет |
|---|---|---|
| Предел частоты обхода | Сколько запросов сайт выдерживает без деградации | Ваша зона: время ответа сервера и коды 5xx |
| Спрос на обход | Насколько Google хочет обходить эти URL | Зона Google: популярность страниц, частота обновлений, устаревание данных |
Отсюда следует главное, и Google Search Central пишет об этом прямым текстом: «увеличить бюджет» напрямую нельзя. Можно сделать так, чтобы сайт отвечал быстрее и чтобы Googlebot тратил запросы на полезные адреса вместо мусорных. Всё остальное — фольклор.
Когда бюджет действительно ни при чём
Ко мне регулярно приходят с формулировкой «Google не индексирует сайт, наверное не хватает краулингового бюджета». Чаще всего сайт при этом на пару сотен страниц, и бюджет там ни при чём.
Признаки, что причина другая:
- в «Статистике сканирования» видно, что Googlebot обходит сайт регулярно, а страницы всё равно висят в статусе «Просканирована, но пока не проиндексирована»: это вопрос ценности контента, а не частоты обхода;
- непроиндексированные страницы не имеют ни одной внутренней ссылки, и тогда это страницы-сироты, и обходить их просто неоткуда;
- в индекс не попадают почти одинаковые карточки, и тогда разбираться нужно с дублями страниц, а не с бюджетом.
Полный разбор причин я собрал в отдельной статье про то, почему страницы не индексируются в Google. Краулинговый бюджет стоит там последним пунктом списка, и это правильный порядок проверки.
Что реально съедает бюджет
Почти всегда это не контент, а адреса, которые сайт порождает сам.
- Фасетная навигация. Фильтры, комбинирующиеся между собой, дают комбинаторный взрыв: три фильтра по десять значений дают тысячу адресов на одну категорию.
- Сортировки и пагинация с параметрами. Один и тот же товар доступен по десятку адресов с разными параметрами.
- Внутренний поиск. Каждый запрос — отдельная страница результатов, если её не закрыть.
- UTM-метки во внутренних ссылках. Классика: метки проставлены на баннерах внутри сайта, и каждая страница удвоилась.
- Календари бронирования. Бесконечная генерация дат вперёд превращается в ловушку, из которой краулер не выходит.
- Цепочки редиректов. Каждое звено стоит отдельного запроса: три вместо одного тратят бюджет втрое.
- Мягкие 404. Удалённые товары, отвечающие кодом 200 с пустой карточкой, продолжают обходиться. Как правильно закрывать такие адреса, я разбирал в статье про 404, 410 или редирект для удалённых страниц.
Как продиагностировать за час
Порядок, которым я иду сам на техническом аудите:
- Search Console → Настройки → Статистика сканирования. Смотрю три вещи: число запросов в сутки, среднее время ответа и разбивку по назначению (обнаружение против обновления) и по типу файла.
- Разбивка по коду ответа. Заметная доля 3xx и 4xx означает, что бюджет тратится на адреса, которых давно нет.
- Логи сервера. Единственный источник, где видно поимённо, какие URL обходит Googlebot и сколько раз. Выгружаю за 2–4 недели, фильтрую по user-agent с проверкой по обратному DNS, группирую по маске URL. Обычно несколько масок объясняют большую часть обходов.
- Собственный краул. Сравниваю, сколько URL находит краулер по ссылкам и сколько из них есть в sitemap. Расхождение в разы выдаёт генерацию мусора.
- Время ответа. Если среднее время ответа держится в районе секунды и выше, частота обхода будет низкой независимо от всего остального. Это смежная история со скоростью сайта и позициями, но здесь важен именно ответ сервера, а не Core Web Vitals.
Разовый всплеск обходов после релиза нормален: Googlebot переобходит изменившееся. Тревожный сигнал другой, и в «Статистике сканирования» он виден за 2–3 недели: устойчивое смещение обходов в сторону адресов с параметрами при падении обходов карточек.
Чем управляют бюджетом
| Инструмент | Что делает | Когда применять |
|---|---|---|
| robots.txt | Запрещает запрос URL | Внутренний поиск, календари, заведомо мусорные параметры |
| noindex | Убирает из индекса, обход остаётся | Страница нужна пользователю, но не выдаче |
| rel=canonical | Склеивает дубли | Сортировки и варианты одной карточки |
| Ссылки без параметров | Не создаёт лишних адресов | Внутренние баннеры и промо: метки только для внешних источников |
| Быстрый ответ сервера | Поднимает частоту обхода | Всегда |
| Актуальный lastmod в sitemap | Помогает выбрать, что перекраулить | Каталоги с частыми изменениями |
Настройку карты сайта и файла запретов я разбираю отдельно, в статье про sitemap.xml и robots.txt. Здесь важна одна оговорка: robots.txt — не способ убрать страницу из выдачи. Закрытый в нём адрес Google может показать в результатах без описания, потому что запретил себе его прочитать.
Что я вижу на своих проектах
На собственных сайтах Googlebot упирался в потолок обхода ровно один раз, и не из-за размера, а из-за архитектуры: генерация страниц сравнения по комбинациям параметров дала на порядок больше адресов, чем было полезного контента. Лечилось это не «оптимизацией краулинга», а решением о том, какие комбинации вообще имеют право существовать как отдельная страница.
Честная граница применимости: если у вас сайт услуг на 40 страниц или блог на 300 статей, вся эта глава вам не нужна. Ваш потолок — не бюджет обхода, а спрос и качество. Возвращаться к теме имеет смысл, когда число URL начинает измеряться десятками тысяч, а доля обходов важных страниц падает.
Что сделать на этой неделе
- Открыть «Статистику сканирования» и записать три числа: запросов в сутки, среднее время ответа, долю ответов не-200.
- Прогнать сайт краулером и сравнить число найденных URL с числом адресов в sitemap.
- Найти три самые массовые маски мусорных адресов и решить по каждой: robots.txt, canonical или убрать ссылки.
- Убрать UTM-метки из внутренних ссылок: самая дешёвая правка с заметным эффектом.
- Если ответ сервера медленнее секунды, заняться бэкендом: это влияет и на обход, и на пользователя. Такие правки обычно относятся к веб-разработке, а не к настройкам SEO, но без них технический аудит упрётся в потолок.
