Краулінговий бюджет: що це, як перевірити й оптимізувати
Краулінговий бюджет — це кількість адрес сайту, яку пошуковий робот може й хоче просканувати за певний час. Google складає його з двох частин: ліміту навантаження на сервер (crawl capacity limit) і потреби в скануванні (crawl demand). Поняття практичне: що більший сайт і що повільніший сервер, то помітніше, що робот доходить не до всього; сайтам на кілька сотень сторінок зазвичай нема про що турбуватися.
Як Google визначає краулінговий бюджет
У документації Google Search Central краулінговий бюджет описано як набір адрес, які Google може й хоче просканувати. Він складається з двох величин:
- Ліміт навантаження (crawl capacity limit) — скільки одночасних з'єднань і з якими паузами Googlebot може тримати, не перевантажуючи сервер. Якщо сайт відповідає швидко, ліміт зростає; якщо сповільнюється, віддає помилки 5xx чи сигнали обмеження на кшталт HTTP 429 — знижується.
- Потреба в скануванні (crawl demand) — наскільки Google взагалі потрібно сканувати сайт. Вона залежить від розміру сайту, частоти оновлень, якості сторінок і їхньої затребуваності порівняно з іншими сайтами.
Звідси головний наслідок: навіть якщо сервер витримає більше, Google не скануватиме сайт частіше, ніж потребує попит. Швидкий сервер корисний, але малоцінні адреси й дублі знижують потребу в обході сильніше, ніж допомагає швидкість.
Від чого він залежить
- Швидкість і стабільність відповіді. Якщо сервер гальмує або віддає помилки, робот знижує темп, щоб не нашкодити сайту.
- Попит на обхід. Популярні і часто оновлювані сторінки обходяться частіше.
- Якість структури. Сміттєві адреси витрачають бюджет замість корисних сторінок.
Кому варто займатися краулінговим бюджетом
Google адресує свій посібник із краулінгового бюджету трьом типам сайтів:
- великі сайти — від мільйона унікальних сторінок, вміст яких змінюється приблизно раз на тиждень;
- середні й великі сайти — від 10 000 унікальних сторінок з дуже швидкою зміною вмісту (щодня);
- сайти, у яких велика частка адрес у Search Console має статус «Виявлено, не проіндексовано».
Якщо нові сторінки вашого сайту скануються в день публікації, за словами Google, займатися бюджетом не потрібно. Для типового сайту послуг чи блогу на сотні сторінок повільна індексація зазвичай пояснюється не бюджетом, а якістю, дублями або відсутністю внутрішніх посилань — див. сторінки-сироти.
Куди бюджет витікає
| Джерело витоку | Що робити |
|---|---|
| Безкінечні фільтри і сортування | Закрити параметри від обходу, залишити канонічні адреси |
| Внутрішній пошук по сайту | Закрити сторінки результатів |
| Цепочки редиректів | Скоротити до одного кроку — см. перевірку редиректів |
| Биті посилання | Виправити — як знайти |
| Дублікати і технічні копії | Звести канонічними адресами |
Що реально прискорює обхід
- Швидка відповідь сервера. Робот підстраює темп під навантаження: чим швидше відповідає сайт, тим більше сторінок він встигає обійти.
- Зрозуміла структура. Сторінка в трьох кліках від головної знаходиться швидше, ніж захована в глибині.
- Актуальна карта сайту і посилання на неї в robots.txt.
- Регулярні оновлення. Сайт, який змінюється, обходять частіше.
Звіт «Статистика сканування» в Search Console
Звіт розташований у розділі «Налаштування» → «Статистика сканування». Він показує, як Googlebot обходив сайт за останні 90 днів: загальну кількість запитів сканування, обсяг завантажених даних, середній час відповіді й статус хоста — чи були проблеми з отриманням robots.txt, DNS і підключенням до сервера. Під графіками — розбивки запитів за кодом відповіді, типом файлу, метою (виявлення нових адрес чи оновлення відомих) і типом Googlebot.
| Що дивитися | Тривожна ознака |
|---|---|
| Середній час відповіді | Зростає разом зі зменшенням кількості запитів — сервер обмежує обхід |
| Статус хоста | Помилки отримання robots.txt або підключення до сервера |
| За кодом відповіді | Помітна частка 3xx, 404 і 5xx замість 200 |
| За метою | Майже немає «виявлення», хоча нові сторінки виходять регулярно |
| За типом файлу | Ресурси (скрипти, зображення, JSON) займають більшість запитів |
Аналіз логів сервера: що видно лише там
Статистика сканування показує зведення й приклади, а логи сервера — кожен запит: які саме адреси Googlebot запитував, як часто і що отримував. Кілька команд для журналу nginx чи Apache у стандартному форматі:
# коди відповіді, які отримував Googlebot
grep -i "googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# адреси, які скануються найчастіше
grep -i "googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50User-agent легко підробити, тому перед висновками перевірте, що це справді Google: зворотний DNS-запит за IP має повернути ім'я в домені googlebot.com або google.com, а прямий запит за цим ім'ям — той самий IP. Докладніше — у статті про аналіз логів.
Як зрозуміти, що бюджет витрачається даремно
- Подивіться в Search Console статистику обходу: скільки сторінок на день і з якими кодами відповіді.
- Порівняйте число обійдених адрес з числом корисних сторінок сайту.
- Перевірте, яка частка обходу йде на редиректи і помилки.
- Якщо корисні сторінки обходяться раз на місяць, а сміттєві щодня — займіться структурою, а не посиланнями.
Як оптимізувати краулінговий бюджет: покроково
- Зведіть дублі. Канонічні адреси або редиректи для версій із параметрами, www/без www, скісною рискою — див. канонічна адреса.
- Закрийте в robots.txt те, що не треба сканувати взагалі: нескінченні фільтри, сортування, внутрішній пошук. Не використовуйте для цього noindex — Google однаково запитає сторінку. Як не закрити зайвого — у статті про перевірку robots.txt.
- Віддавайте 404 або 410 для видалених сторінок і позбудьтеся «м'яких» 404 — сторінок-заглушок із кодом 200: за словами Google, вони й далі скануються та витрачають бюджет.
- Приберіть довгі ланцюжки редиректів і посилання на адреси, що редиректять.
- Тримайте карту сайту актуальною: лише канонічні адреси з кодом 200 і тег
<lastmod>для оновлених сторінок. Перевірити можна аналізатором sitemap. - Підтримуйте відповідь 304 Not Modified на умовні запити: так Google розуміє, що сторінка не змінилася, і не завантажує її знову.
- Пришвидшіть сервер і стежте за помилками 5xx та 429 — вони напряму знижують ліміт навантаження.
- Порівняйте статистику сканування за кілька тижнів після змін: частка 200 і «виявлення» має зрости.
Міфи про краулінговий бюджет
- «noindex економить бюджет». Ні: Google запитує сторінку, бачить noindex і лише тоді її відкидає. Економить заборона в robots.txt — але тоді робот не побачить і сам noindex. Різниця інструкцій — у статті noindex, nofollow і robots.txt.
- «Crawl-delay у robots.txt сповільнить Googlebot». Google це правило не підтримує; швидкість він підлаштовує сам за відповідями сервера.
- «Що частіше сканують, то вищі позиції». Google писав, що зростання частоти сканування саме по собі не веде до кращих позицій. Сканування — умова потрапляння в індекс, а не фактор ранжування.
- «Маленькому сайту треба оптимізувати бюджет». На сайті із сотень сторінок робот і так обходить усе.
- «ШІ-боти витрачають бюджет Google». Бюджет рахується для роботів Google. Але будь-які боти навантажують сервер, а повільний сервер знижує ліміт для Googlebot. Якщо сторонні боти помітно вантажать сайт, ними керують у robots.txt — див. як закрити сайт від ШІ-ботів.