На
Search Central Live Deep Dive Europe 2026 у Барселоні Gary Illyes показав внутрішні дані Google про те, скільки часу в середньому займають різні процеси Search.І тут є цифри, які дуже корисно показувати клієнтам, коли вони питають: «ми внесли зміни вчора — чому Google їх ще не бачить?»
1. Discovery нового URL — близько 20 годин
Типовий час:
~20 hoursАле у складних випадках:
weeks → neverТобто Google може досить швидко знайти нову сторінку, але discovery ще не означає indexing.
2. Повторний crawl відомої сторінки — близько 30 днів
Це одна з найцікавіших цифр.
Для URL, який Google уже знає, типовий
refresh:~30 daysТому ситуація, коли ви оновили контент два тижні тому, а Google досі бачить стару версію, може бути абсолютно нормальною.
3. Sitemap processing — приблизно 24 години
Типово:
~24 hoursУ повільному сценарії — до
14 days або навіть never, якщо виникають quality issues.Тобто sitemap допомагає discovery, але не гарантує crawl або indexing.
4. Rendering — секунди, але черга може зайняти години
Сам процес rendering сторінки Google зазвичай виконує за секунди.
Але URL може провести:
hours in rendering queueУ найгірших випадках —
days to weeks.Особливо важливо для JavaScript-heavy сайтів.
До речі, на тому ж Search Central Google підтвердив: Googlebot не скролить і не клікає сторінку. Контент, який з'являється тільки після interaction, може залишитися невидимим.
5. End-to-end indexing — близько 1.5 години
Ця цифра звучить сенсаційно, але її легко неправильно зрозуміти.
~1.5 hours — це не:Publish → через 90 хвилин у GoogleЦе час самого indexing pipeline після того, як необхідні попередні процеси вже відбулися успішно.
Google окремо підкреслив, що етапи залежать один від одного:
Discovery → Crawl → Rendering → Indexingі затримки накопичуються.
6. Canonical changes — 1–3 тижні
Змінили canonical і через три дні нічого не сталося?
Типовий діапазон Google:
1–3 weeksЯкщо сигнали конфліктують — можуть знадобитися місяці.
7. Site migration — 1–3 місяці
Для переїзду сайту типовий термін:
1–3 monthsПовільний сценарій:
6 months → 1 year+Тому оцінювати результат великої міграції через два тижні — майже безглуздо.
8. Recovery після Core Update — 3–6 місяців
Одна з найважливіших цифр:
3–6 months to recoverА у повільному випадку:
6 months → 1 yearФактично сайт може чекати наступного Core Update, щоб зміни повністю переоцінилися.
9. Core Update та Spam Update працюють із різною швидкістю
Rollout:
Core Update → 2–4 weeksSpam Update → 1–2 daysПри цьому відновлення після spam-related змін може займати значно довше самого rollout.
Не всі SEO-зміни можна оцінювати через 7 або 14 днів.
Google фактично дав нам орієнтири для різних типів задач:
новий URL → години / дніоновлення сторінки → тижніcanonical → 1–3 тижніmigration → місяціCore Update recovery → 3–6+ місяцівІ ще важливіше: у таблицях Google слово
never зустрічається багато разів — переважно там, де процес залежить від quality.Технічно правильна сторінка не отримує автоматичної гарантії crawling та indexing.
Важливий нюанс: ці цифри були показані Gary Illyes на Search Central Live 2 жовтня 2026 року та записані учасником події John Campbell. Google поки не опублікував самі слайди, тому це reference ranges, а не SLA або гарантовані строки.
Джерела:
- ROAST — Google Search Central Live Deep Dive Barcelona, Day 3 Recap
- ROAST — Day 2: Indexing & JavaScript
- Google Search Central — Search Central Live Deep Dive Europe 2026
