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

Оптимізація краулінгового бюджету — це робота над тим, щоб Googlebot витрачав свій обмежений час на сканування тих URL, які ви справді хочете бачити в індексі. Для цього треба прибрати дублікати й малоцінні URL, забезпечити швидкий і стабільний сервер та давати чіткі сигнали через коди відповіді, sitemap і внутрішні посилання. Найбільше краулінговий бюджет важить для дуже великих або сайтів, що швидко змінюються.

Якщо на вашому сайті кілька тисяч сторінок, а нові сторінки з'являються в Google за день-два, найімовірніше, проблема не у вас. А от якщо у вас інтернет-магазин із фільтрами, маркетплейс, дошка оголошень чи медіа з мільйонами URL, саме краулінговий бюджет може визначати, скільки новий контент чекатиме, доки Google його побачить.

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

Краулінговий бюджет (crawl budget) — це кількість URL, які Google може і хоче просканувати на вашому сайті за певний час. У посібнику Google щодо бюджету сканування сказано, що він складається з двох чинників: ліміту пропускної здатності сканування (скільки сканування витримує ваш сервер) і попиту на сканування (скільки Google хоче сканувати).

• Ліміт пропускної здатності залежить від «здоров'я» сканування. Якщо сайт відповідає швидко й стабільно, ліміт зростає. Якщо відповіді сповільнюються або сервер повертає помилки, ліміт знижується. Верхню межу також задають власні ресурси Google для сканування.
• Попит на сканування залежить від того, скільки URL, на думку Google, у вас є, наскільки вони популярні та наскільки застаріла збережена копія. Google називає рушіями для Googlebot уявний обсяг сторінок, популярність і застарілість.

Тому бюджет — це не фіксоване число, яке можна десь подивитися. Це результат того, як поводиться ваш сервер і наскільки ваші URL виглядають вартими сканування.

Чи потрібна моєму сайту оптимізація краулінгового бюджету?

Більшості сайтів — ні. Google зазначає, що його посібник розрахований на сайти з 1 млн+ унікальних сторінок, контент яких змінюється приблизно раз на тиждень, сайти з 10 000+ унікальних сторінок, що змінюються щодня, а також сайти, де велика частка URL застрягла в статусі «Виявлено – наразі не проіндексовано» (Discovered – currently not indexed). Там же сказано: якщо ваші сторінки скануються в день публікації, цей посібник вам не потрібен.

Корисний індикатор: порівняйте, скільки URL знаходить краулер, і скільки сторінок ви насправді хочете бачити в індексі. Якщо магазин на 20 000 товарів через комбінації фільтрів генерує 600 000 доступних для сканування URL, у вас проблема з ефективністю сканування — незалежно від розміру сайту.

Як перевірити краулінговий бюджет у Search Console?

Відкрийте в Search Console Налаштування → Статистика сканування. Звіт «Статистика сканування» показує загальну кількість запитів на сканування, загальний обсяг завантажених даних, середній час відповіді та стан хоста. Також запити розбиваються за кодом відповіді, типом файлу, метою сканування (виявлення або оновлення) і типом Googlebot. Звіт доступний лише для ресурсів кореневого рівня.

На що звертати увагу:

• Стан хоста не зелений. Проблеми з отриманням robots.txt, DNS чи підключенням до сервера знижують обсяг сканування з боку Google.
• Середній час відповіді зростає. Повільніші відповіді знижують ліміт пропускної здатності, тож кількість запитів на сканування часто падає невдовзі після цього.
• Велика частка відповідей не 200. Багато 301, 404 чи 5xx означає, що Googlebot витрачає запити на URL, які не дають йому нічого для індексу.
• Виявлення vs оновлення. Якщо сайт публікує багато, дуже низька частка сканувань із метою виявлення може означати, що нові URL стоять у черзі.

Потім перегляньте звіт «Індексування сторінок». Довгий і зростаючий список у статусі «Виявлено – наразі не проіндексовано» — класичний симптом проблем із краулінговим бюджетом: Google знає про URL, але ще не завантажив їх. Цьому статусу присвячено окремий посібник — «Виявлено – наразі не проіндексовано».

Логи сервера показують те, чого не видно в Search Console

На великих сайтах першоджерелом правди є сирі логи доступу. Відфільтруйте запити верифікованого Googlebot (перевіряйте IP, бо багато ботів підробляють user agent) і згрупуйте звернення за шаблонами URL. Зазвичай картина буде приблизно така:

• 40% звернень Googlebot припадає на URL фільтрів ?sort= і ?color=
• 10% — на редиректи, що лишилися після давньої міграції
• товарні сторінки, додані минулого тижня, взагалі не запитувалися

Ці цифри — не бенчмарки. Вони ілюструють тип розподілу, який показує, де саме втрачається бюджет. Порівняйте звернення в логах зі списком URL, які ви хочете індексувати: важливі сторінки, яких Googlebot не відвідував 30 днів, — перші кандидати на виправлення.

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

Втрати бюджету сканування створюють URL, які коштують запиту, але нічого не додають до індексу. На великих сайтах типові причини — фасетна навігація, параметри URL, дублікати контенту, ланцюжки редиректів, soft 404 і нескінченні простори на кшталт безкінечних календарів чи сторінок результатів пошуку. Кожна з них множить кількість URL, які Google має обробити.

Найпоширеніші джерела:

1. Фасетна навігація та фільтри. Кожна комбінація кольору, розміру, бренду й ціни може стати окремим URL. Кілька фільтрів із кількома значеннями кожен легко дають сотні тисяч URL.
2. Параметри сортування, відстеження та сесій. ?sort=price, ?utm_source= та ідентифікатори сесій створюють копії тієї самої сторінки.
3. Дублікати шляхів. Та сама сторінка доступна через HTTP і HTTPS, з www і без, зі слешем у кінці й без нього, у верхньому й нижньому регістрі.
4. Ланцюжки редиректів. Старий URL → проміжний URL → кінцевий URL. Кожен крок — це ще один запит, а в документації Google щодо кодів статусу HTTP сказано, що за замовчуванням Googlebot проходить не більше 10 переходів.
5. Soft 404. Порожні категорії чи сторінки «нічого не знайдено», що повертають 200 OK, продовжують скануватися як повноцінні сторінки.
6. Нескінченні простори. Календарі з посиланням «наступний місяць», що ніколи не закінчується, результати внутрішнього пошуку з посиланнями на них зі сторінок, а також петлі відносних посилань, які щоразу додають нові сегменти шляху.

Як оптимізувати краулінговий бюджет: що реально працює

Посібник Google щодо бюджету сканування перелічує практики, які справді допомагають: консолідувати дублікати, закривати в robots.txt URL, які ви ніколи не хочете сканувати, повертати 404 або 410 для видалених сторінок, усувати soft 404, підтримувати актуальні sitemap, уникати довгих ланцюжків редиректів і забезпечувати швидке завантаження сторінок. Рухайтеся приблизно в такому порядку.

1. Візьміть під контроль фасетну навігацію

Визначте, які сторінки фільтрів заслуговують на ранжування (наприклад, «червоні кросівки для бігу»), і зробіть доступними для сканування лише їх — із чистими URL, що виглядають як статичні. Для решти посібник Google щодо фасетної навігації рекомендує:

• закрити параметри фільтрів у robots.txt, або
• використовувати для фільтрів фрагменти URL (#color=red), адже Google не сканує фрагменти.

Там також зазначено, що rel="canonical" і rel="nofollow" на посиланнях фільтрів у довгостроковій перспективі зазвичай менш ефективні, ніж robots.txt. Якщо ви все ж залишаєте фасети доступними для сканування, використовуйте стандартний роздільник &, тримайте фільтри в сталому порядку й повертайте 404 для порожніх або безглуздих комбінацій.

User-agent: Googlebot
Disallow: /*?*sort=
Disallow: /*?*sessionid=
Disallow: /*?*color=

Перед розгортанням протестуйте такі шаблони на реальних URL. Один неправильний wildcard може закрити цілі категорії. Синтаксис і найчастіші помилки розібрано в нашому посібнику з robots.txt, а посібник з SEO-аудиту інтернет-магазину детальніше розповідає про фільтри та варіанти товарів.

2. Консолідуйте дублікати

Оберіть одну версію кожного URL (протокол, хост, слеш у кінці, регістр) і налаштуйте 301-редирект з інших версій на неї. Додайте самопосилальні canonical і ставте внутрішні посилання лише на канонічну версію. Внутрішні посилання на URL з параметрами знову й знову запрошують туди Googlebot.

3. Повертайте правильні коди відповіді

• Сторінки, видалені назавжди: 404 або 410, а не редирект на головну.
• Порожні категорії та сторінки «нічого не знайдено»: справжній 404 або сторінка з реальним контентом і посиланнями, але ніколи не «тонка» сторінка з кодом 200.
• Редиректи: ведіть кожен старий URL одразу на кінцеву адресу й оновіть внутрішні посилання, щоб вони оминали редирект.

У документації Google щодо кодів статусу сказано, що відповіді 4xx (крім 429) не знижують швидкість сканування — Google просто з часом рідше сканує такі URL. А от помилки 5xx і 429 сповільнюють сканування всього сайту.

4. Зробіть сервер швидким і стабільним

Пропускна здатність сканування зростає, коли відповіді швидкі й стабільні. Кешуйте HTML для анонімних відвідувачів, оптимізуйте повільні запити до бази даних на сторінках категорій і підтримуйте If-Modified-Since / відповіді HTTP 304 — посібник Google щодо бюджету сканування називає це найкращою практикою. Після кожної зміни стежте за середнім часом відповіді у «Статистиці сканування».

5. Тримайте sitemap чистими й актуальними

У sitemap мають бути лише канонічні, індексовані URL, що повертають 200. Розділіть їх за розділами (товари, категорії, статті), щоб бачити індексування за кожним типом. Використовуйте <lastmod> лише для реальних змін контенту. Google каже, що не гарантує повторного сканування на його основі, але точна дата все одно є корисною підказкою.

6. Посильте внутрішню перелінковку важливих сторінок

Сторінки, заховані на глибині шести кліків або доступні лише з архівів пагінації, скануються рідше. Ставте посилання на нові й цінні сторінки з хабів категорій і блоків схожого контенту. Наш посібник із внутрішньої перелінковки показує, як знайти сторінки-сироти та надто глибокі сторінки.

Скільки таких проблем на вашому сайті (ланцюжки редиректів, дублікати з параметрами, soft 404, конфлікти canonical і сторінки без внутрішніх посилань), можна побачити за допомогою безкоштовного SEO-аудиту SEORecheck: він сканує сайт і показує приклади з ваших власних URL.

Що не працює для краулінгового бюджету?

Кілька поширених прийомів не допомагають або навіть шкодять. Посібник Google щодо бюджету сканування прямо їх називає, і їх варто знати, перш ніж змінювати robots.txt чи метатеги на великому сайті.

• Noindex для економії бюджету. Google усе одно мусить запросити сторінку, щоб побачити noindex, тож сканування однаково витрачається. Noindex керує індексуванням, а не скануванням.
• Перемикання robots.txt, щоб перерозподілити бюджет. Google радить не використовувати robots.txt для тимчасового перенаправлення бюджету на інші сторінки. Закривайте лише те, що ніколи не хочете бачити просканованим.
• Очікування, що <lastmod> змусить пересканувати сторінку. Це підказка, а не команда.
• Блокування CSS чи JavaScript. Googlebot потребує цих файлів, щоб відрендерити сторінки. Блокування майже нічого не заощаджує, зате може зламати розуміння сторінок.

Що робити, якщо Googlebot перевантажує сервер?

Це протилежна проблема. У посібнику Google щодо зниження швидкості сканування сказано, що можна ненадовго повертати 500, 503 або 429 — це знижує сканування всього хоста. Водночас Google застерігає робити це довше ніж 1–2 дні: якщо Googlebot кілька днів бачить ці коди на тих самих URL, такі URL можуть випасти з індексу.

Як зрозуміти, що оптимізація краулінгового бюджету спрацювала?

Порівнюйте стан «до» і «після» на проміжку 4–8 тижнів, бо Google змінює сканування поступово. Ознаки успіху:

• у логах сервера більша частка звернень Googlebot припадає на канонічні, індексовані URL
• у «Статистиці сканування» менше редиректів і 404, а середній час відповіді стабільний або нижчий
• у звіті «Індексування сторінок» зменшується кількість URL у статусі «Виявлено – наразі не проіндексовано»
• нові сторінки з'являються в Google швидше після публікації

Ведіть журнал змін із датами (правила robots.txt, редиректи, зміни sitemap), щоб пов'язати кожен ефект із його причиною. У прикладі звіту видно, як можна відстежувати знахідки та проблемні URL між аудитами.

Головне

• Краулінговий бюджет визначають пропускна здатність сканування («здоров'я» сервера) і попит на сканування (обсяг сторінок, популярність, застарілість).
• Посібник Google розрахований на сайти з 1M+ сторінок або 10k+ сторінок, що змінюються щодня. Більшості невеликих сайтів він не потрібен.
• «Статистика сканування» і логи сервера показують, на що Googlebot насправді витрачає запити.
• Фасетна навігація, параметри, дублікати, ланцюжки редиректів і soft 404 — найбільші джерела втрат.
• Використовуйте robots.txt для URL, які ви ніколи не хочете сканувати. Noindex не економить краулінговий бюджет.
• Використовуйте 503/429 лише як аварійне гальмо на 1–2 дні.