Чи може середній час відповіді сторінки впливати на сторінки зі статусом «Проскановано — наразі не проіндексовано»?

2 Травня, 2026 (Оновлено: 2 Травня, 2026) Від Проскуряков Ілля

Так, середній час відповіді сторінки (Average Response Time) безпосередньо впливає на появу статусу «Проскановано – наразі не проіндексовано» (Crawled – currently not indexed) у Google Search Console.

Хоча цей статус технічно означає, що Google вже відвідав сторінку, він часто є сигналом того, що пошуковий робот зіткнувся з певними труднощами під час аналізу або просто вирішив, що сторінка «не варта» ресурсів на індексацію саме зараз. Ось як саме час відповіді впливає на цей процес:

1. Краулінговий бюджет (Crawl Budget)

Google виділяє кожному сайту певну кількість ресурсів на сканування. Якщо ваші сторінки відповідають повільно (наприклад, понад 1000 мс), Googlebot витрачає весь ліміт часу лише на кілька сторінок.

Результат: Робот може встигнути завантажити код сторінки, але у нього не залишиться «бюджету» на її повний рендеринг або додавання в основний індекс. У такому разі сторінка потрапляє у «чергу очікування» зі статусом «Проскановано – наразі не проіндексовано».

2. Пріоритетність та «Якість» сервера

Google прагне індексувати контент, який забезпечує гарний користувацький досвід (Core Web Vitals).

Логіка алгоритму: Якщо сервер працює нестабільно або повільно під час сканування, Google може знизити пріоритет цієї сторінки. Він вважає, що показувати такий повільний контент користувачам у пошуку — погана ідея.

3. Ефективність рендерингу

Багато сучасних сайтів використовують JavaScript для відображення контенту.

Якщо ваш сервер довго віддає основні ресурси, процес рендерингу (виконання JS) на боці Google може перерватися або завершитися з помилками.
Оскільки Googlebot побачив сторінку, але не зміг якісно її обробити через затримки, він маркує її як проскановану, але не поспішає додавати в індекс.

Як перевірити зв’язок?

Щоб зрозуміти, чи є швидкість причиною проблем, перегляньте звіт Статистика сканування (Crawl Stats) у Search Console:

Зайдіть у Налаштування -> Статистика сканування.
Зверніть увагу на графік «Середній час відповіді».
Якщо ви бачите кореляцію: сплеск часу відповіді збігається з ростом кількості сторінок у статусі «Проскановано – наразі не проіндексовано», то проблема саме в продуктивності сервера.

У розділі «Проскановано – наразі не проіндексовано» сторінки то з’являються, то зникають. Чи може на це впливати середній час відповіді сторінки?

Так, Середній час відповіді (Average Response Time) безпосередньо впливає на те, чому сторінки «мігрують» між індексом та списком «Проскановано – наразі не проіндексовано».

Коли сторінки то з’являються, то зникають із цього звіту (ефект «гойдалок»), це часто свідчить про нестабільність ресурсів сервера або динамічне керування краулінговим бюджетом з боку Google.

Ось детальні причини, як час відповіді провокує таку нестабільність:

1. Тимчасове перевантаження сервера

Якщо ваш сервер іноді відповідає швидко, а іноді — повільно (через пікові навантаження, резервне копіювання або важкі скрипти), Googlebot реагує відповідно:

Фаза «Успіх»: Коли сервер швидкий, Google встигає завантажити та проіндексувати сторінки. Вони виходять зі звіту «не проіндексовано».
Фаза «Затримка»: Коли середній час відповіді зростає (наприклад, понад 600-1000 мс), Googlebot економить ресурси. Він сканує сторінку, бачить, що вона «важка», і відкладає її індексацію «на потім». В цей момент вона знову з’являється у звіті як просканована, але не додана в індекс.

2. Захисна реакція Google (Crawl Delay)

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

Це призводить до того, що сторінки, які вже були в черзі на індексацію, «зависають» у статусі «Проскановано – наразі не проіндексовано», поки час відповіді не стабілізується.

3. Рендеринг та тайм-аути

Google індексує сторінку у два етапи: завантаження HTML та рендеринг (виконання JS/завантаження CSS).

Якщо сервер довго віддає додаткові ресурси, Google може «здатися» на етапі рендерингу.
Сторінка потрапляє у звіт «Проскановано…». Як тільки при наступній спробі сервер відповідає швидше, рендеринг проходить успішно, і сторінка зникає зі звіту, потрапляючи в індекс.

Як переконатися, що причина саме в цьому?

Порівняйте графіки: Відкрийте в Search Console «Налаштування» -> «Статистика сканування». Накладіть графік «Середній час відповіді» на кількість сторінок у статусі «Проскановано – наразі не проіндексовано». Якщо піки затримок збігаються з ростом кількості таких сторінок — проблема в сервері.
Перевірте статус 5xx: Високий час відповіді часто супроводжується випадковими помилками сервера (500, 503). Навіть якщо їх небагато, вони змушують Googlebot сумніватися в стабільності сторінки.
Хостинг: Можливо, ваш тарифний план має ліміти на процесорний час (CPU) або ввід/вивід (I/O). Коли ліміт вичерпується, час відповіді різко зростає.

Висновок: Якщо сторінки постійно «скачуть» у цей статус і назад, це класична ознака того, що вашому сайту не вистачає продуктивності для стабільної індексації. Оптимізація швидкості сервера (TTFB — Time to First Byte) зазвичай допомагає «закріпити» ці сторінки в індексі.

Чи допоможе Cloudflare у такому випадку

Так, Cloudflare може стати чудовим рішенням у цій ситуації, оскільки він діє як “щит” і “прискорювач” між Googlebot та вашим сервером.

Ось як саме він допоможе стабілізувати статус сторінок у Search Console:

1. Зменшення часу відповіді (TTFB) через кешування

Cloudflare зберігає копії ваших сторінок на своїх серверах по всьому світу.

Як це працює: Коли Googlebot звертається до сторінки, Cloudflare віддає її миттєво зі свого кешу, не звертаючись до вашого сервера.
Результат: Середній час відповіді в Search Console різко падає і стає стабільним (наприклад, з 800 мс до 50–100 мс). Google бачить “швидкий” сайт і охочіше переводить сторінки з “Проскановано” в основний індекс.

2. Зняття навантаження з сервера

Якщо ваш сервер “підвисав” саме через активність ботів, Cloudflare візьме цей удар на себе.

Ефект: Оскільки більшість запитів обробляє Cloudflare, ресурси вашого хостингу (CPU/RAM) звільняються. Це дозволяє серверу відповідати швидше в тих випадках, коли запит все ж таки доходить до нього.

3. Функція “Argo Smart Routing”

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

Важливі нюанси (Що потрібно налаштувати)

Просте підключення Cloudflare (“сіра хмарка” стала “помаранчевою”) дає базовий результат, але для вирішення проблеми з індексацією варто зробити наступне:

Налаштуйте “Cache Everything” (через Page Rules): За замовчуванням Cloudflare кешує лише картинки та скрипти, але не HTML-сторінки. Щоб максимально знизити час відповіді для Googlebot, потрібно налаштувати кешування всього HTML (якщо контент не персоналізований для кожного користувача).
Tiered Cache: Увімкніть цю безкоштовну опцію. Вона дозволяє різним дата-центрам Cloudflare обмінюватися кешем між собою, що ще більше зменшує кількість запитів безпосередньо до вашого хостингу.
Browser Insights: Слідкуйте за показником TTFB (Time to First Byte) у панелі Cloudflare. Саме на цей показник Google орієнтується при виділенні краулінгового бюджету.

Чи є ризики?

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

Резюме: Cloudflare — це, мабуть, найшвидший і найдешевший спосіб “заспокоїти” графік часу відповіді та прибрати ефект “гойдалок” у Search Console без переїзду на дорожчий хостинг.