Crawl budget — это не абстрактная метрика для отчётов, а конкретный факт: у Googlebot и у бота Яндекса есть лимит запросов к вашему серверу в сутки, и они его тратят не туда, куда вам хочется. Для сайта на 500 страниц это почти никогда не проблема — бот успевает обойти всё за один заход. А вот на каталоге из 20-40 тысяч SKU, агрегаторе или новостном архиве с историей за несколько лет это уже конкретная причина, почему часть страниц месяцами висит в статусе «Обнаружено, но пока не проиндексировано».
Дальше — не теория, а что смотреть и что чинить по шагам.
Из чего реально складывается лимит
Google официально делит crawl budget на два компонента, и путать их нельзя — чинятся они по-разному.
Crawl rate limit — сколько запросов сервер физически выдерживает без деградации. Проверяется просто:
curl -o /dev/null -s -w "time_total: %{time_total}s, code: %{http_code}\n" https://ваш-сайт.ru/catalog/tovar-123/
Если time_total стабильно выше 1-1,5 секунды или periodически вылезают коды 502/503 — бот сам снижает частоту визитов, вы не сможете «выпросить» больше обхода никакими sitemap-манипуляциями, пока не почините бэкенд.
Crawl demand — спрос бота на конкретные URL: сколько на них ссылаются изнутри сайта, как часто они меняются, есть ли внешние ссылки, упомянуты ли в sitemap. Если сервер быстрый, а страницы всё равно не переобходятся — проблема тут, а не в «лимите».
Практический пример: интернет-магазин на 40 000 карточек товара. В Search Console «проиндексировано» держится на уровне 24 000 три месяца подряд, новые карточки не попадают в выдачу неделями. Сервер отвечает за 300 мс, 5xx нет. Значит дело не в rate limit — бот просто не считает новые карточки достаточно приоритетными на фоне остального URL-пространства сайта. Дальше смотрим, куда уходит спрос.
Почему Google не индексирует сайт: причины и способы решения в 2025→Где на практике утекает бюджет — конкретные паттерны
- Фильтры каталога.
/catalog/?color=red&size=42&sort=price. На 10 параметрах фильтра легко получить миллионы комбинаций URL. Если они открыты для обхода и без единого canonical — бот физически тратит визиты на них вместо новых товаров. - Внутренний поиск.
/search/?q=...— почти всегда открыт по умолчанию в движке, генерирует тысячи мусорных URL с нулевой ценностью для индекса. - Бесконечная пагинация листингов. Страница 400 архива блога, которую никто не откроет руками, но бот честно обходит.
- Дубли по протоколу/домену.
http://иhttps://, сwwwи без, старые региональные поддомены без жёстких 301 — бот тратит визит на каждую копию отдельно. - Цепочки редиректов во внутренних ссылках. Если меню или карточка товара линкует на
/old-cat/который 301-ит на/new-cat/, это два запроса бота вместо одного. Проверить массово: выгрузить внутренние ссылки краулером и прогнать черезcurl -IL— где больше одногоLocation:в цепочке, чинить сразу. - 404 и битые внутренние ссылки. Каждый съедает такой же слот обхода, как рабочая страница.
Что делать по шагам (в этом порядке)
1. Закрыть мусор от обхода в robots.txt. Не через noindex — именно через Disallow, чтобы бот вообще не тратил визит:
Disallow: /search
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?utm_
Важно: то, что уже проиндексировано и нужно убрать из выдачи — закрывается meta noindex, а не robots.txt. Через robots.txt страница просто перестаёт обходиться, но может остаться в индексе с обрывками старых данных.
2. Проставить canonical на всех параметрических страницах. Каждая версия с фильтром/сортировкой должна ссылаться на чистый URL категории:
<link rel="canonical" href="https://ваш-сайт.ru/catalog/tovar-123/" />
3. Убрать редиректы из внутренней перелинковки. Все ссылки в меню, хлебных крошках, карточках — должны вести на финальный URL напрямую, без промежуточных 301.
4. Починить 4xx/5xx. На крупном сайте даже 0,5 % ошибок 5xx в логах заметно давит crawl rate limit — бот интерпретирует это как перегрузку сервера и снижает частоту визитов на недели вперёд, даже после того как вы всё почините.
5. Разбить sitemap по типам контента. Отдельно карта товаров, отдельно карта статей, отдельно — категорий. Так в Search Console видно, по какому именно разделу обход проседает, а не «в среднем по больнице». Это также поможет подготовить Чек-лист перед индексацией сайта: что реально проверяют Google, Яндекс и Bing .
Когда список приоритетных URL расчищен от мусора, есть смысл прогнать его массовой проверкой — не гадать по логам, а получить готовый отчёт по статусу каждого адреса. Для этого подходит Rush Analytics: загружаете список URL из финального sitemap и получаете, какие реально в индексе, какие нет и почему.
Как замерить ситуацию у себя, а не гадать
Самый честный источник — серверные логи , отфильтрованные по user-agent бота:
grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50
Так видно топ‑50 URL, которые бот реально запрашивал за период, и сразу понятно, если 60‑70 % визитов уходит в /search/ и параметры фильтров вместо карточек товара — это прямое подтверждение проблемы со спросом, а не с лимитом.
Без доступа к логам — косвенные, но рабочие источники:
- Google Search Console → «Настройки» → «Статистика сканирования» (Crawl Stats) → «Что просканировано». Там разбивка по кодам ответа и по типам файлов — если большая доля запросов уходит на JS/CSS или на страницы с 404, это видно сразу.
- Яндекс.Вебмастер → «Индексирование» → «Статистика обхода» — отдельно показывает распределение обойдённых страниц по HTTP‑статусам.
- Bing Webmaster Tools → «Crawl Information» — менее детально, но ловит грубые проблемы вроде массовых 5xx.
Разбор конкретной ситуации: страница висит 3 недели в «Crawled — currently not indexed»
Это один из самых частых запросов в поддержку, и почти всегда причина не в crawl budget. Если сайт меньше нескольких тысяч страниц, а часть всё равно не индексируется — бот приходил, страницу увидел, решил, что она недостаточно ценна на фоне остального контента. Это про качество страницы (тонкий контент, дубль по смыслу с уже проиндексированной), а не про обход. Проверка через URL Inspection в Search Console покажет именно этот статус — если он есть, оптимизация robots.txt и sitemap ничего не даст, нужно дорабатывать сам текст.
Второй частый ложный диагноз: «бот вообще не заходил». В логах и в Search Console почти всегда видно обратное — бот зашёл, увидел Disallow в robots.txt или noindex в мета‑теге и корректно отступил. Это не баг обхода, это сайт сам попросил бота уйти.
Когда после чистки мусора остаются конкретные важные страницы, которые долго не переобходятся, есть смысл точечно ускорить их индексацию через индексатор — например, SpeedyIndex, который отправляет приоритетные URL на ускоренный обход, не дожидаясь естественного цикла бота. А если нужно быстро понять состояние одной конкретной проблемной страницы — коды ответа, canonical, noindex — не поднимая логи целиком, удобнее экспресс‑проверкой вроде PR‑CY.
Связанные термины
- robots.txt — инструмент управления обходом, ключевой для экономии crawl budget.
- canonical URL — сигнал, какой адрес считать основным при дублях.
- Crawled, currently not indexed — статус, где бот зашёл, но не посчитал страницу достаточно ценной.
- IndexNow — push‑уведомления для Яндекса и Bing об изменённых страницах, снижают нагрузку на их crawl budget.
- Терминология индексации : Submitted, Crawled, Indexed, Stable
- Почему Google не индексирует сайт: причины и решения