Вхід Реєстрація
Реклама
Ваше рекламне місце
Забронюйте цей слот без конкуренції на обраний період.
Купити рекламу →
Логотип телеграм спільноти - Sneex SEO 🇺🇦
Додано 14 лип 2024 🌐 UK

Sneex SEO 🇺🇦

@sneex_seo
Кількість підписників: 2 770
Фото: 695
Відео: 25
Посилання: 594
Опис:
Всім привіт, мене звати Олексій. Пишу новини про SEO, що знаходжу у X, Linkedin, тощо. Аналіз даних з нуля, Python та інших корисні інструменти для SEO. Реклама, питання писати сюди: @alexey_web https://oleksiimatuznyi.com/advertising_slots/ - реклама
Джерело

Sneex SEO 🇺🇦 | Google вперше показав, скільки реально займають crawling, indexing та ...

Логотип телеграм спільноти - Sneex SEO 🇺🇦 Sneex SEO 🇺🇦 @sneex_seo
975 Охват/переглядів 2026-10-09 10:23 Повідомлення №1203
Google вперше показав, скільки реально займають crawling, indexing та recovery

На 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 weeks

Spam 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