Google оновив вимоги до crawl budget: 304 та ліміти

Google оновив офіційну документацію про crawl budget – додав пряму рекомендацію повертати Googlebot код 304 (Not Modified) для сторінок, які не змінилися, і вперше явно пояснив, що ліміт сканування спільний для всіх краулерів Google. Це не новий алгоритм і не разова подія, а уточнення правил, за якими вже давно живе технічне SEO, – але тепер воно зафіксоване офіційно, а не лише як усталена практика галузі.

Що сталося

22-23 липня 2026 року Google оновив розділ «Optimize your crawl budget» у документації Search Central (частина розділу Crawling infrastructure). Документація описує три уточнення.

По-перше, кожен сайт стартує з однаковим консервативним лімітом crawl capacity. Google прямо пише: якщо є попит сканувати більше, а сайт стабільно й швидко відповідає на запити, система автоматично піднімає цей ліміт із часом. Тобто ліміт не фіксований назавжди – він «заробляється» надійною роботою сервера.

По-друге, цей ліміт спільний для всіх краулерів Google одночасно. У кожного краулера (звичайний Googlebot, Googlebot-Image, AdsBot та інші) свій попит на сканування, але верхня межа потужності одна на весь сайт. Якщо один краулер активно навантажує сервер, це залишає менше ресурсу іншим.

По-третє, у документації з’явилася пряма порада: підтримувати HTTP-код 304 (Not Modified). Якщо сторінка не змінилася з моменту останнього сканування, сервер може повернути 304 замість повного вмісту – Google повторно використає закешовану версію, а сервер економить трафік і ресурси. Практичний ефект – Googlebot витрачає вивільнений crawl budget на сторінки, які справді оновилися, а не на повторне завантаження того, що й так не змінилося.

Ці рекомендації стосуються не всіх сайтів без розбору. Google явно вказує аудиторію: великі сайти з понад мільйоном сторінок і сайти середнього розміру з понад 10 000 сторінок, які часто оновлюються.

Чому це важливо

Для сайтів, які підпадають під ці пороги, – маркетплейси, великі каталоги, новинні ресурси – crawl budget напряму впливає на те, як швидко нові чи оновлені сторінки взагалі потрапляють у видачу. Якщо Googlebot витрачає ресурс на повторне сканування тисяч незмінних карток товарів замість нових позицій чи оновлених цін, індексація нового контенту гальмується непомітно – без жодної помилки чи попередження в Search Console.

Раніше 304-кешування було загальновідомою практикою веб-продуктивності, яку радили радше з погляду швидкості сайту, ніж SEO. Тепер це офіційна рекомендація саме в контексті crawl budget – аргумент, який простіше показати команді розробки, коли потрібно обґрунтувати пріоритет технічної задачі, що не дає видимого результату за один спринт.

Як це працює

Було	Стало	Що робити
Crawl capacity limit описувався загально, без деталей про спільне використання між краулерами	Ліміт тепер прямо описаний як спільний для всіх краулерів Google одночасно	Перевірити в Search Console → Статистика сканування, які типи краулерів і яку частку ліміту використовують
304-кешування було загальною порадою з веб-продуктивності	Пряма рекомендація Google саме для економії crawl budget	Перевірити через заголовки відповіді сервера (curl -I з If-Modified-Since), чи сервер взагалі підтримує 304
Було незрозуміло, чому нові великі сайти скануються повільніше, ніж очікувалося	Пояснено: кожен сайт стартує з консервативного ліміту, який зростає з часом при стабільній роботі сервера	Не форсувати ліміт штучно – слідкувати за стабільністю відповіді сервера, а не намагатися «обійти» консервативний старт

Технічно нічого не ламається і не вимикається автоматично – це не примусовий перехід, як буває з деякими іншими оновленнями Google. Це документація, яка формалізує те, що частина технічних SEO-фахівців і так впроваджувала, і дає чіткіший орієнтир, куди саме дивитися, якщо великий сайт сканується повільніше, ніж хотілося б.

Кому це підходить

Прямий поріг застосовності Google назвав сам: сайти з понад мільйоном сторінок і сайти середнього розміру з понад 10 000 сторінок, що часто змінюються. Це маркетплейси, великі e-commerce каталоги, дошки оголошень, новинні портали й агрегатори.

Для типового бізнес-сайту з кількома десятками чи сотнями сторінок – лендінг, сайт послуг, невеликий інтернет-магазин – це оновлення практично нічого не змінює: у таких обсягах Google і без спеціальних заходів встигає сканувати весь сайт з великим запасом. Витрачати ресурс розробки на 304-кешування заради crawl budget тут немає сенсу – пріоритетнішими залишаються базові речі: швидкість завантаження, коректна індексація, відсутність дублів.

Окрема категорія – сайти, що масштабуються: якщо каталог зараз кілька тисяч товарів, а за півроку планується вихід за 10 000, варто закласти підтримку 304 в архітектуру заздалегідь, а не переробляти постфактум.

Аналіз редакції

Ми ще не проводили окремого виміру, наскільки саме зростає швидкість переіндексації після впровадження 304 конкретно після цього оновлення документації – воно занадто свіже, щоб зібрати статистику по клієнтських акаунтах. Але сама перевірка коду відповіді сервера – це вже стандартний пункт технічного SEO-аудиту, який ми проводимо для будь-якого сайту з великим каталогом, задовго до цього уточнення від Google. Ця новина не змінює методику роботи – вона дає офіційне підтвердження того, що напрямок обраний правильно, і аргумент, який легше показати клієнту чи команді розробки.

Практичний приклад

Уявімо каталог з 40 000 товарних карток, з яких реально оновлюється (ціна, наявність, опис) приблизно 5% на тиждень. Якщо сервер повертає код 200 з повним вмістом на кожну сторінку незалежно від того, змінилася вона чи ні, Googlebot витрачає однакову кількість ресурсу і на 2 000 карток, що реально оновилися, і на 38 000 карток, які лишилися без змін. Якщо ж сервер коректно повертає 304 для тих 38 000 незмінних сторінок, вивільнений ресурс краулер спрямовує на швидше повторне сканування саме тих 2 000, які змінилися, – і оновлена ціна чи статус наявності швидше з’являються у видачі.

Що робити вже зараз

• Перевірити розмір і темп оновлення каталогу: чи підпадає сайт під пороги Google (1 млн+ сторінок або 10 000+ сторінок, що часто змінюються).
• Якщо підпадає – перевірити разом з розробником, чи сервер взагалі повертає 304 для незмінних сторінок, чи завжди віддає повний код 200.
• Подивитися в Search Console → Статистика сканування розподіл кодів відповіді й типів краулерів.
• Для сайтів, що активно ростуть, – закласти підтримку 304 в технічне завдання заздалегідь, а не після того, як обсяг сторінок вже створює проблему.
• Для невеликих сайтів – не братися за це в першу чергу; спершу перевірити базові речі: швидкість завантаження, дублі сторінок, коректність robots.txt і sitemap.

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

На що звернути увагу. 304 працює тільки тоді, коли сервер точно визначає, що сторінка не змінилася. Якщо кешувальний шар (CDN, проксі) налаштований неправильно й повертає 304 навіть для сторінки з оновленою ціною чи описом, Google просто не побачить зміни – переіндексація реального оновлення затримається. Перевіряйте логіку визначення «сторінка не змінилася» окремо від самого факту, що код 304 технічно повертається.

FAQ

Що таке crawl budget? Це обсяг ресурсу, який Google готовий витратити на сканування конкретного сайту за певний період: скільки сторінок і як часто Googlebot встигає їх відвідати з урахуванням попиту на сканування й спроможності сервера.

Чи потрібно щось терміново міняти на сайті через це оновлення? Ні, для більшості сайтів – ні. Рекомендація прямо стосується великих каталогів і сайтів з понад 10 000 сторінок, що часто оновлюються; для типового бізнес-сайту з десятками чи сотнями сторінок crawl budget зазвичай не є вузьким місцем.

Що таке код 304 Not Modified і чим він відрізняється від 200? Код 200 означає, що сервер повернув повний вміст сторінки. Код 304 означає, що сторінка не змінилася з моменту останнього запиту, і клієнт (у цьому випадку Googlebot) може використати вже наявну закешовану версію – без повторного завантаження вмісту.

Чи впливає це оновлення на позиції сайту у видачі напряму? Ні, це не фактор ранжування. Ефект непрямий: коректна робота з 304 і crawl budget пришвидшує, наскільки швидко Google помічає й переіндексовує зміни на сайті, а не впливає на саму позицію сторінки.

Як перевірити, чи мій сервер підтримує 304? Можна надіслати запит з заголовком If-Modified-Since чи If-None-Match на конкретну сторінку (наприклад через curl -I) і подивитися код відповіді. Якщо сторінка не змінювалася після вказаної дати, а сервер все одно повертає 200 з повним вмістом, підтримки 304 немає.

Чи це стосується Google Merchant Center і товарних фідів окремо? Документація йдеться про сканування сторінок сайту Googlebot, а не про товарний фід Merchant Center – це різні механізми оновлення даних. Пряма рекомендація 304 стосується саме HTML-сторінок сайту.

Де в Search Console подивитися поточну статистику сканування? У розділі «Налаштування → Статистика сканування» (Crawl Stats) для конкретного ресурсу – там видно розподіл за кодами відповіді, типами файлів і краулерами Google за останні 90 днів.

Висновок

Це оновлення документації не змінює правила гри для більшості сайтів – воно формалізує те, що технічні SEO-фахівці великих проєктів і так знали з практики, і дає чіткіший орієнтир для тих, хто працює з великими каталогами чи сайтами, що масштабуються. Головний практичний висновок простий: якщо сайт великий і часто оновлюється, перевірте, чи сервер коректно повертає 304 для незмінного контенту – і чи не робить це помилково для контенту, що змінився.

Якщо хочете перевірити, чи crawl budget взагалі є вузьким місцем для вашого сайту, і що саме варто виправити першим – обговоримо на технічному аудиті. Такі перевірки – частина нашого SEO-просування, а якщо сайт ще тільки будується або переробляється, підтримку 304 й інші технічні вимоги можна закласти одразу на етапі розробки.