Краулінговий бюджет Google: повний посібник з оптимізації Crawl Budget

Краулінговий бюджет — ліміт сторінок, які Googlebot обходить на вашому сайті за добу. Для магазинів і порталів від 10 000 сторінок його нестача напряму блокує індексацію нових товарів і статей. Нижче — кейс, інструменти і конкретні дії для управління.

Що таке краулінговий бюджет і з чого він складається

Googlebot не обходить весь інтернет рівномірно. Кожен сайт отримує певну «квоту» — кількість HTTP-запитів, яку бот готовий зробити за день. Офіційно Google називає це crawl budget.

Він складається з двох компонентів:

• Crawl rate limit — максимальна швидкість краулінгу без ризику перевантажити сервер. Google підвищує або знижує її залежно від часу відповіді вашого сервера. Якщо сайт відповідає за 200 мс — бот краулить агресивніше; якщо за 2 секунди — гальмує.
• Crawl demand — попит на краулінг, який визначається популярністю сторінок у пошуку та частотою оновлення контенту. Нова сторінка з беклінками буде проіндексована раніше, ніж стара порожня.

Реальний бюджет = мінімум з цих двох значень. Якщо сервер повільний — бот обходить менше сторінок, навіть якщо попит великий. Якщо контент рідко оновлюється — попит низький, і бот приходить рідко.

Google офіційно підтвердив концепцію crawl budget у документації для Search Central. Джерело: developers.google.com.

Для кого це критично: розмір сайту і пріоритети

Google прямо зазначає: для невеликих сайтів (до 1 000 якісних сторінок) краулінговий бюджет не є проблемою — бот встигає обійти все. Але ситуація кардинально змінюється, щойно сайт переходить певний поріг.

З нашої практики просування e-commerce проєктів, проблема стає відчутною при таких масштабах:

• 10 000–50 000 сторінок — бюджет уже обмежений, фільтри і пагінація «крадуть» частину ресурсу
• 50 000–200 000 сторінок — без управління бюджетом нові товари можуть чекати на індексацію тижнями
• 200 000+ сторінок — необхідна системна стратегія: пріоритизація, закриття дублів, моніторинг

Особливо вразливі: інтернет-магазини з URL-фільтрами (колір, розмір, бренд), новинні портали з архівними сторінками, агрегатори з параметричними URL.

Кейс: інтернет-магазин 15 000 SKU — бюджет х3 за 90 днів

До нас звернувся клієнт з інтернет-магазином побутової техніки: 15 000 активних SKU, ще стільки ж архівних товарів і генерований URL для кожної комбінації фільтрів. GSC показував 48 000+ сканованих URL на місяць, але в індексі знаходилося лише близько 9 000 товарних сторінок.

Діагностика через лог-файли показала: 58–62% запитів Googlebot витрачалося на URL виду /catalog/televisions/?brand=Samsung&color=black&diagonal=55. Реальні сторінки товарів, блог і категорії отримували менше 40% бюджету.

Ми провели роботи у три етапи:

1. Аудит URL-простору — зібрали всі патерни URL з лог-файлів і розбили на групи: товари, категорії, фільтри, пагінація, UTM-параметри.
2. Закриття сміттєвих URL — у robots.txt додали Disallow для патернів фільтрів (Disallow: /*?*color=, Disallow: /*?*brand= тощо), пагінацію категорій закрили canonical на першу сторінку.
3. Прискорення сервера — перейшли на Redis-кешування, час відповіді знизився з 1,8 с до 380 мс.

Результат через 90 днів: кількість проіндексованих товарних сторінок зросла з 9 000 до 28 500 — у 3,2 раза. Органічний трафік на товарні сторінки +74% порівняно з базовим місяцем.

Що з'їдає краулінговий бюджет

Більшість сайтів витрачають значну частину бюджету на URL, які не мають жодної цінності для пошукової видачі. З нашого аудиту 50+ e-commerce проєктів, типові «пожирачі» розподіляються так:

• URL-параметри фільтрів і сортування — ?sort=price_asc&page=3&color=red. Одна категорія може генерувати тисячі унікальних URL, кожен з яких Googlebot намагається обійти.
• Пагінація без canonical — сторінки /catalog/?page=47 без посилання на першу сторінку. Бот краулить усі 200 сторінок пагінації замість того, щоб зосередитися на товарах.
• Дублі контенту — сторінки з www і без, HTTP і HTTPS версії, версії з trailing slash і без. Кожен дубль з'їдає бюджет.
• Тонкий контент — порожні категорії, сторінки тегів з 1–2 товарами, архівні URL видалених товарів, що повертають 200 OK замість 404.
• Session ID і UTM-параметри в URL — ?session_id=abc123 або ?utm_source=google доступні для сканування.
• Нескінченний скрол без пагінації — якщо JS генерує нові URL при скролі, а сервер їх доступний напряму.

Як аналізувати: GSC Crawl Stats і лог-файли

Є два рівні аналізу краулінгового бюджету: базовий (через GSC) і детальний (через лог-файли сервера).

Google Search Console — Crawl Stats

Шлях: GSC → Налаштування (шестерня в лівому нижньому куті) → Статистика сканування. Тут ви побачите:

• Кількість запитів на день — скільки URL обходить Googlebot. Якщо цифра значно менша за кількість ваших сторінок — є проблема.
• Середній розмір відповіді в байтах — підозрілі сплески можуть означати важкі сторінки.
• Середній час відповіді — понад 500 мс регулярно знижує crawl rate limit.

GSC також показує краулінг за типом відповіді (2xx, 3xx, 4xx, 5xx). Велика кількість 3xx редиректів або 4xx сторінок у щоденному краулінгу — пряма втрата бюджету.

Як налаштувати і читати всі звіти GSC для SEO-аналізу — у нашому повному гайді по Google Search Console.

Аналіз лог-файлів сервера

Це детальніший рівень, недоступний через інтерфейс GSC. Лог-файл Apache або Nginx містить кожен запит із User-Agent. Алгоритм аналізу:

1. Вивантажте логи за останні 30 днів (зазвичай через cPanel, Plesk або SSH).
2. Відфільтруйте рядки з Googlebot в User-Agent: grep "Googlebot" access.log
3. Підрахуйте запити за URL-патернами — скільки запитів на фільтри, товари, категорії, статичні ресурси.
4. Знайдіть аномалії — URL, які Googlebot обходить по 50+ разів на місяць (ознака постійного переіндексування або м'яких 404).

Зручні інструменти для парсингу логів: Screaming Frog Log File Analyser (Windows), GoAccess (Linux/CLI), або спеціалізований Semrush Log File Analyzer.

Robots.txt — перший інструмент економії

Robots.txt — найшвидший спосіб звільнити бюджет. Googlebot читає його при кожному візиті і не витрачає запити на заборонені URL. Але є нюанс: закриті в robots.txt URL все одно можуть потрапити в індекс через зовнішні посилання — без noindex вони просто не матимуть контенту, але залишаться в індексі як «заблоковані роботом».

Типові блоки для e-commerce у robots.txt:

User-agent: *
# Параметри фільтрації
Disallow: /*?*sort=
Disallow: /*?*color=
Disallow: /*?*brand=
Disallow: /*?*size=
# Сесійні параметри
Disallow: /*?*session_id=
Disallow: /*?*PHPSESSID=
# UTM і реклама
Disallow: /*?*utm_
# Адмінка і кабінет
Disallow: /admin/
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/

Для перевірки коректності robots.txt використовуйте інструмент Google Search Console: GSC → Налаштування → robots.txt тестер. Він показує, які URL блокуються для Googlebot і яких — для інших ботів.

Canonical і noindex: тонке налаштування

Robots.txt діє на рівні сканування — бот навіть не заходить на сторінку. Canonical і noindex — інструменти наступного рівня: бот заходить, але розуміє, що сторінку не потрібно індексувати або що це дубль основного URL.

Детальніше про правила налаштування canonical і типові помилки — у нашій статті про канонічні теги.

Canonical — для дублів і параметрів

Додайте canonical на всі сторінки з параметрами, що вказує на «чисту» версію URL:

<!-- На сторінці /catalog/phones/?sort=price -->
<link rel="canonical" href="https://example.com/catalog/phones/" />

Canonical підходить, коли сторінка з параметрами має реальну цінність для користувача (наприклад, повноцінна категорія за брендом), але ви не хочете, щоб вона конкурувала з основною.

Noindex — для тонкого контенту і службових сторінок

Мета-тег <meta name="robots" content="noindex, follow"> вказує Google не включати сторінку в індекс, але дозволяє переходити за посиланнями. Це важливо для:

• Сторінок пошуку по сайту (/search/?q=телефон)
• Порожніх категорій і тегів
• Сторінок подяки після форми (/thank-you/)
• Архівних сторінок видалених товарів, де 404 не можна поставити з технічних причин

Різниця між canonical і noindex: canonical каже «це дубль, основний там», noindex каже «не індексуй взагалі». Для фільтрів без беклінків — robots.txt або noindex. Для дублів із беклінками — canonical.

Таблиця: розмір сайту vs рекомендований підхід

Якщо ваш сайт потребує технічного SEO-аудиту, аналіз краулінгового бюджету — обов'язковий його елемент. Ми перевіряємо лог-файли, robots.txt, дублі та пагінацію як частину комплексної SEO-стратегії просування.

На практиці

Українська дошка оголошень про роботу — 2,4 млн активних вакансій, нові з'являються щогодини — звернулася з критичним симптомом: Googlebot обходив близько 12 000 сторінок на добу. Для бази у 2,4 млн оголошень це означало, що переважна більшість контенту залишалася поза увагою пошуковика місяцями.

GSC Crawl Stats підтверджував: середній час відповіді сервера тримався на рівні 2,3 секунди, а в індексі перебувало лише близько 180 000 сторінок вакансій — менше 8% реального каталогу.

Аналіз лог-файлів через Screaming Frog Log File Analyser виявив першопричину: бот застрявав на 800 000 параметричних URL фільтрів — /jobs?city=kyiv&salary=30000&type=part-time та десятки тисяч схожих комбінацій. Після закриття всіх паттернів фільтрів у robots.txt бюджет перерозподілився на реальні сторінки вакансій.

GSC зафіксував зростання щоденних запитів з 12 000 до 74 000. Кількість проіндексованих вакансій зросла з 180 000 до 940 000 за 8 тижнів — без жодного нового беклінка і без змін у контенті.

Ключовий висновок для агрегаторів із швидким оновленням: якщо вакансія живе 3–5 днів, а бот приходить до неї через три тижні — вона вже не актуальна в момент індексації. Закриття фільтрів тут важливіше за будь-яку посилальну роботу.

Часті запитання

Що таке краулінговий бюджет Google?

Краулінговий бюджет — кількість сторінок, які Googlebot готовий проіндексувати на вашому сайті за добу. Він складається з crawl rate limit (максимальна швидкість без перевантаження сервера) і crawl demand (попит на основі популярності та оновлень контенту).

Для яких сайтів краулінговий бюджет є критичним?

Краулінговий бюджет критично важливий для сайтів від 10 000 сторінок: інтернет-магазини з великим каталогом, новинні портали, агрегатори. Для малих сайтів (до 1 000 сторінок) Google зазвичай індексує все без обмежень.

Як закрити URL-параметри від краулінгу?

Використовуйте Disallow в robots.txt для типових патернів (наприклад, Disallow: /*?sort=). Для більш точного контролю — тег noindex або canonical на сторінки з параметрами. Налаштування параметрів у старому GSC більше недоступне.

Де подивитися статистику краулінгу сайту?

В Google Search Console: Налаштування → Статистика сканування (Crawl Stats). Там видно кількість запитів на день, середній розмір відповіді та час відповіді. Для детального аналізу — лог-файли сервера, де фільтруємо запити від Googlebot.