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

> Краулінговий бюджет: коли він справді важливий, як оцінити його у звіті «Статистика сканування» та логах і які виправлення радить Google для великих сайтів.

URL: https://seorecheck.com/ua/blog/crawl-budget-optimization-large-websites · Опубліковано: 2026-10-29 · [English](https://seorecheck.com/blog/crawl-budget-optimization-large-websites.md), [Español](https://seorecheck.com/es/blog/crawl-budget-optimization-large-websites.md)

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

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

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

Краулінговий бюджет (crawl budget) — це кількість URL, які Google може і хоче просканувати на вашому сайті за певний час. У [посібнику Google щодо бюджету сканування](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget) сказано, що він складається з двох чинників: **ліміту пропускної здатності сканування** (скільки сканування витримує ваш сервер) і **попиту на сканування** (скільки Google хоче сканувати).

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

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

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

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

| Тип сайту | Чи ймовірна проблема з краулінговим бюджетом? | На чому зосередитися натомість |
|---|---|---|
| Сайт-візитка або сайт локального бізнесу (до ~1 000 URL) | Майже ніколи | Контент, внутрішні посилання, базове індексування |
| Блог або SaaS-сайт на кілька тисяч URL | Рідко | Sitemap, дублікати, якість сторінок |
| Магазин із фасетними фільтрами та сортуванням | Часто, бо фільтри множать URL | Фасетна навігація, параметри, canonical |
| Маркетплейс, дошка оголошень або новини (10k+ URL, що змінюються щодня) | Так | Ефективність сканування, швидкість сервера, свіжість |
| Сайт з 1M+ сторінок | Так | Усе з цієї статті плюс аналіз логів |

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

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

Відкрийте в Search Console **Налаштування → Статистика сканування**. [Звіт «Статистика сканування»](https://support.google.com/webmasters/answer/9679690) показує загальну кількість запитів на сканування, загальний обсяг завантажених даних, середній час відповіді та стан хоста. Також запити розбиваються за кодом відповіді, типом файлу, метою сканування (виявлення або оновлення) і типом Googlebot. Звіт доступний лише для ресурсів кореневого рівня.

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

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

Потім перегляньте звіт «Індексування сторінок». Довгий і зростаючий список у статусі «Виявлено – наразі не проіндексовано» — класичний симптом проблем із краулінговим бюджетом: Google знає про URL, але ще не завантажив їх. Цьому статусу присвячено окремий посібник — [«Виявлено – наразі не проіндексовано»](https://seorecheck.com/ua/blog/discovered-currently-not-indexed-fix).

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

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

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

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

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

Втрати бюджету сканування створюють URL, які коштують запиту, але нічого не додають до індексу. На великих сайтах типові причини — фасетна навігація, параметри URL, дублікати контенту, [ланцюжки редиректів](https://seorecheck.com/ua/blog/301-vs-302-redirects-seo), [soft 404](https://seorecheck.com/ua/blog/404-errors-seo-impact) і нескінченні простори на кшталт безкінечних календарів чи сторінок результатів пошуку. Кожна з них множить кількість URL, які Google має обробити.

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

1. **Фасетна навігація та фільтри.** Кожна комбінація кольору, розміру, бренду й ціни може стати окремим URL. Кілька фільтрів із кількома значеннями кожен легко дають сотні тисяч URL.
2. **Параметри сортування, відстеження та сесій.** `?sort=price`, `?utm_source=` та ідентифікатори сесій створюють копії тієї самої сторінки.
3. **Дублікати шляхів.** Та сама сторінка доступна через HTTP і HTTPS, з `www` і без, зі слешем у кінці й без нього, у верхньому й нижньому регістрі.
4. **Ланцюжки редиректів.** Старий URL → проміжний URL → кінцевий URL. Кожен крок — це ще один запит, а в [документації Google щодо кодів статусу HTTP](https://developers.google.com/search/docs/crawling-indexing/http-network-errors) сказано, що за замовчуванням Googlebot проходить не більше 10 переходів.
5. **Soft 404.** Порожні категорії чи сторінки «нічого не знайдено», що повертають 200 OK, продовжують скануватися як повноцінні сторінки.
6. **Нескінченні простори.** Календарі з посиланням «наступний місяць», що ніколи не закінчується, результати внутрішнього пошуку з посиланнями на них зі сторінок, а також петлі відносних посилань, які щоразу додають нові сегменти шляху.

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

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

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

Визначте, які сторінки фільтрів заслуговують на ранжування (наприклад, «червоні кросівки для бігу»), і зробіть доступними для сканування лише їх — із чистими URL, що виглядають як статичні. Для решти [посібник Google щодо фасетної навігації](https://developers.google.com/search/docs/crawling-indexing/crawling-managing-faceted-navigation) рекомендує:

- закрити параметри фільтрів у 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](https://seorecheck.com/ua/blog/robots-txt-seo-guide), а [посібник з SEO-аудиту інтернет-магазину](https://seorecheck.com/ua/blog/ecommerce-seo-audit-guide) детальніше розповідає про фільтри та варіанти товарів.

### 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. Посильте внутрішню перелінковку важливих сторінок

Сторінки, заховані на глибині шести кліків або доступні лише з архівів пагінації, скануються рідше. Ставте посилання на нові й цінні сторінки з хабів категорій і блоків схожого контенту. Наш [посібник із внутрішньої перелінковки](https://seorecheck.com/ua/blog/internal-linking-seo-guide) показує, як знайти сторінки-сироти та надто глибокі сторінки.

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

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

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

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

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

Це протилежна проблема. У [посібнику Google щодо зниження швидкості сканування](https://developers.google.com/search/docs/crawling-indexing/reduce-crawl-rate) сказано, що можна ненадовго повертати 500, 503 або 429 — це знижує сканування всього хоста. Водночас Google застерігає робити це довше ніж 1–2 дні: якщо Googlebot кілька днів бачить ці коди на тих самих URL, такі URL можуть випасти з індексу.

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

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

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

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

## Головне

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

---

## Хочете знати, що виправити на своєму сайті?

Отримайте безкоштовне превʼю SEO-аудиту: оцінку й реальні проблеми з доказами з ваших сторінок.

- [Отримати безкоштовне превʼю аудиту](https://seorecheck.com/ua/request)
- [Переглянути приклад звіту](https://seorecheck.com/ua/sample)