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

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

zoom_in

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

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

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

# Отфильтровать только запросы Googlebot за последние 7 дней
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

# Статус-коды, которые видит Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Топ URL с ответом 404
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 по шаблонам и строят графики crawl rate.

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

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

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

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

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

zoom_in

Параметры URL и дубли: меры

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

# robots.txt — блокировка параметрных URL
User-agent: *

# Параметры сортировки и фильтров
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?filter=
Disallow: /*?color=
Disallow: /*?size=

# Пагинация глубже 3-й страницы (пример через Allow/Disallow)
Disallow: /*?page=
Allow: /*?page=1
Allow: /*?page=2
Allow: /*?page=3

# Сессионные и tracking-параметры
Disallow: /*?sessionid=
Disallow: /*?token=
Disallow: /*?ref=
Disallow: /*?utm_

# Preview и черновики
Disallow: /*?preview=
Disallow: /*?draft=

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

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

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

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

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

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

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

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

# robots.txt — паттерны для временных страниц
User-agent: *

# Вебинары и события
Disallow: /webinars/
Disallow: /events/draft-
Disallow: /landing/test-

# Макеты и превью
Disallow: /_preview/
Disallow: /mockups/
Disallow: /demo/

# A/B-тесты и эксперименты
Disallow: /*?variant=
Disallow: /*?experiment=
Disallow: /*?ab_test=

# Preview-параметры шаблонов
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">
  <!-- Приоритетные разделы — сканируются первыми -->
  <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>
  <!-- Менее приоритетные разделы -->
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-05-10</lastmod>
  </sitemap>
  <!-- НЕ включать временные страницы и дубли! -->
</sitemapindex>

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

Настройки сервера и rate limiting

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

# Nginx: вернуть 429 при слишком частых запросах от любого краулера
limit_req_zone $http_user_agent zone=crawlers:10m rate=10r/s;

location / {
    limit_req zone=crawlers burst=20 nodelay;
    limit_req_status 429;
    # ... остальные настройки
}

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

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

• Еженедельно: сравнивайте crawl requests в 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+)
• Из Sitemap исключены страницы с noindex и Disallow
• Sitemap index разбит по разделам с актуальным lastmod
• Цепочки 301 сведены к одному редиректу
• 404 в логах Googlebot < 5% — мёртвые ссылки устранены
• Настроен еженедельный мониторинг в GSC

FAQ