Краулинговый бюджет: практическое руководство для крупных платформ

Краулинговый бюджет — это количество страниц, которые Googlebot готов просканировать на вашем сайте за определённый период. На небольших сайтах он практически не ограничен. На платформах с миллионами URL это стратегический ресурс: бот тратит его на фильтры, пагинацию, пустые шаблоны и тестовые страницы вместо того, чтобы сканировать приоритетный контент. В результате новые товары с задержкой проходят индексацию, каталог покрыт слабо, а позиции теряются.

zoom_in

Шаг 1: сбор и анализ логов краулера

Серверные логи — главный источник правды о том, что Googlebot на самом деле сканирует. Анализ логов показывает реальную частоту запросов, какие разделы бот игнорирует или на каких застревает, и какие HTTP-ответы отдаёт сервер. Без логов любая оптимизация — это догадки.

Извлечение запросов Googlebot из Nginx / Apache

# Filter only Googlebot requests from the last 7 days
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

# HTTP status codes seen by Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Top URLs returning 404 to Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '$9 == "404" {print $7}' \
  | sort | uniq -c | sort -rn | head -30

Для структурного анализа больших объёмов логов используйте специализированные инструменты: Screaming Frog Log File Analyser и Semrush Log Analyser, а также стек ELK (Elasticsearch + Kibana). Они сами группируют URL по шаблонам и строят график частоты сканирования во времени.

Шаг 2: Google Search Console и анализ ответов сервера

Google Search Console даёт агрегированные данные о сканировании без доступа к серверным логам. Главная точка входа — отчёт «Статистика сканирования» (Crawl Stats). Он показывает среднее число запросов в день, скорость загрузки страниц так, как её видит Googlebot, и распределение кодов ответа.

• GSC → Настройки → Статистика сканирования: график запросов сканирования, разбивка по типу файла и коду ответа. Ищите всплески 404/500 и провалы после деплоев.
• GSC → Индексирование → Страницы: число проиндексированных URL и причины, по которым страницы не попали в индекс. Статус «Обнаружено — не проиндексировано» — прямой сигнал краулингового бюджета.
• GSC → Проверка URL: ручная проверка статуса конкретной страницы — когда её сканировали в последний раз и что увидел Googlebot.
• GSC → Настройки → Скорость сканирования: можно ограничить частоту сканирования, если бот перегружает сервер. Обычно это не нужно — ограничивайте, только если есть измеримые проблемы с производительностью.

Источники потерь краулингового бюджета

На крупной платформе бот теряет бюджет по шести типовым источникам. Найдите каждый в логах и оцените объём — так появится порядок приоритетов для оптимизации.

zoom_in

Параметры URL и дубли: как исправить

Параметрные URL — главный источник потерь на e-commerce-платформах. Единого решения нет: выбор зависит от природы параметра.

# robots.txt — blocking parametric URLs
User-agent: *

# Sort and filter parameters
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?filter=
Disallow: /*?color=
Disallow: /*?size=

# Pagination deeper than page 3 (Allow/Disallow approach)
Disallow: /*?page=
Allow: /*?page=1
Allow: /*?page=2
Allow: /*?page=3

# Session and tracking parameters
Disallow: /*?sessionid=
Disallow: /*?token=
Disallow: /*?ref=
Disallow: /*?utm_

# Preview and drafts
Disallow: /*?preview=
Disallow: /*?draft=

Фильтры, фасеты и пагинация

Фасетная навигация — самый сложный случай. Она создаёт комбинаторный взрыв URL: 10 фильтров по 5 значений каждый потенциально дают больше миллиона комбинаций. Задача — сохранить ценные фасеты (бренд + категория) и закрыть бесполезные комбинации.

1. Выявите ценные фасеты: страницы с высоким органическим трафиком или уникальным SEO-контентом (например, /catalog/nike/ с текстом именно о бренде) — оставьте в индексе с canonical на саму себя.
2. Добавьте noindex + follow к малоценным комбинациям: страница рендерится, ссылки на ней учитываются, но в индекс она не попадает. Используйте <meta name="robots" content="noindex, follow"> в шаблоне, если активно больше одного фасета.
3. Закройте технические параметры через Disallow: сортировку, цвет, размер — если у них нет SEO-ценности — закройте в robots.txt.
4. AJAX-подгрузка фасетов: если фасеты подгружаются JavaScript и не отражаются в URL, бот не видит дополнительных URL. Так проблема решается на уровне архитектуры.

Пагинация: canonical или Disallow

Оптимальная стратегия пагинации зависит от масштаба: до 10 страниц — разрешите сканирование и поставьте canonical со страниц 2+ на страницу 1. Для сотен страниц пагинации — Disallow глубже 3–5-й страницы. Бесконечная прокрутка без URL-параметров бот воспринимает как одну страницу — это хорошо для бюджета.

Временные страницы: вебинары, макеты, демо

Временные страницы — скрытый расход бюджета на платформах с активными маркетинговыми командами. Лендинги вебинаров, демо-макеты, страницы предпросмотра для клиентов и варианты A/B-тестов появляются быстро и часто остаются навсегда, молча съедая краулинговый бюджет.

• meta robots noindex: добавьте <meta name="robots" content="noindex, nofollow"> в шаблон всех временных страниц. Бот зайдёт, прочитает директиву и исключит URL из индекса. Это самый простой способ, если есть доступ к шаблону.
• X-Robots-Tag в HTTP-заголовке: если у временных страниц нет собственного HTML-шаблона (например, это сгенерированные PDF или файлы), используйте заголовок ответа: X-Robots-Tag: noindex, nofollow.
• Disallow по префиксу пути: если временные страницы лежат под предсказуемыми префиксами, закройте их в robots.txt. Гарантии удаления уже проиндексированного URL нет, но новые URL сканироваться не будут.
• HTTP-авторизация: для staging и страниц предпросмотра это единственный надёжный способ полной изоляции. У Googlebot нет учётных данных, и он страницу не просканирует.

# robots.txt — patterns for temporary pages
User-agent: *

# Webinars and events
Disallow: /webinars/
Disallow: /events/draft-
Disallow: /landing/test-

# Mockups and previews
Disallow: /_preview/
Disallow: /mockups/
Disallow: /demo/

# A/B tests and experiments
Disallow: /*?variant=
Disallow: /*?experiment=
Disallow: /*?ab_test=

# Template preview parameters
Disallow: /*?preview=
Disallow: /*?draft=
Disallow: /*?revision=

Sitemap Index при больших объёмах

При миллионах URL один XML-сайтмап не работает: он ограничен 50 000 URL и 50 МБ. Sitemap Index — файл-оглавление, который ссылается на дочерние сайтмапы. Так можно расставлять приоритеты и направлять бюджет туда, где он нужнее всего.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- Priority sections — crawled first -->
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <!-- Lower-priority sections -->
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-05-10</lastmod>
  </sitemap>
  <!-- Do NOT include noindex pages or duplicates! -->
</sitemapindex>

• Разбивайте сайтмапы по типам контента: товары, категории, блог, статические страницы — каждый в отдельном файле. Так в GSC видна индексация по каждому разделу.
• Указывайте lastmod честно: lastmod сообщает боту, насколько контент свежий. Ставьте дату последнего реального изменения, а не сегодняшнюю — иначе бот перестанет доверять этому сигналу.
• Исключите заблокированные URL: страницы с noindex или Disallow не должны попадать в сайтмап — они дают боту противоречивые сигналы.
• Лимит дочернего сайтмапа: каждый дочерний файл — максимум 50 000 URL или 50 МБ (в сжатом виде). При превышении разбейте на части: sitemap-products-1.xml, sitemap-products-2.xml.

Настройки сервера и ограничение частоты запросов

Серверная часть влияет на краулинговый бюджет в обе стороны: медленные ответы заставляют Googlebot снижать интенсивность сканирования, а ошибки 5xx заставляют бот ждать и тратить время на повторные попытки. Оптимизация сервера напрямую повышает эффективность сканирования.

# Nginx: return 429 when any crawler sends too many requests
limit_req_zone $http_user_agent zone=crawlers:10m rate=10r/s;

location / {
    limit_req zone=crawlers burst=20 nodelay;
    limit_req_status 429;
    # ... other settings
}

KPI и мониторинг

Краулинговый бюджет нужно мониторить постоянно: любой деплой может случайно открыть тысячи новых параметрных URL. Настройте еженедельный дашборд и ежемесячный обзор следующих метрик.

• Еженедельно: сравнивайте запросы сканирования в GSC за текущую и прошлую неделю. Резкий скачок — признак новых дублей после деплоя.
• Ежемесячно: проверяйте в GSC → Страницы статус «Обнаружено — не проиндексировано». Рост этого числа при неизменном размере сайта — проблема краулингового бюджета.
• После каждого крупного деплоя: прогоните Screaming Frog по сайту и проверьте число уникальных URL. Сравните с предыдущим снимком.
• Раз в квартал: полный анализ логов за 30 дней. Ищите новые паттерны параметрных URL, которые появились после обновления кода.
• Алерты: настройте уведомление, если 5xx-ответы за день превышают 1% всех запросов Googlebot.

Быстрые победы и дорожная карта

Оптимизация краулингового бюджета — не разовая задача, а процесс. Разделите работу на быстрые победы (эффект через 1–2 недели) и системные изменения (1–3 месяца).

Чеклист быстрых побед

• noindex добавлен во все шаблоны временных страниц (вебинары, макеты, демо)
• Disallow для ?preview=, ?draft=, ?sessionid=, ?utm_ в robots.txt
• Canonical на чистые URL на всех параметрных страницах (сортировка, пагинация 2+)
• Страницы с noindex и Disallow удалены из Sitemap
• Sitemap Index разбит по разделам, lastmod указан честно
• Цепочки редиректов сведены к одному переходу
• 404 в логах Googlebot < 5% — битые ссылки убраны
• Настроен еженедельный мониторинг в GSC

FAQ