Вересневий Spam Update завершився 8 жовтня після майже двох тижнів розгортання. Тим часом представник Google показав, скільки можуть тривати виявлення сторінок, індексація, перенесення сайту та відновлення після Core Update. Для вебмайстра це корисні орієнтири, але обіцяти клієнтові повернення трафіку за ними я б не став.
SEO-новини Google цього тижня також стосуються фільтрів Search Console, вигаданих авторів і доступності sitemap для AI-краулерів. Нижче — що змінилося та як читати ці повідомлення без поспішних висновків.
Spam Update тривав майже 14 днів
За офіційним журналом Google Search, September 2026 Spam Update розпочався 24 вересня й завершився 8 жовтня. Розгортання зайняло приблизно 13 днів і 16 годин — майже весь заявлений строк до двох тижнів. Оновлення застосовується глобально та для всіх мов.
Три попередні спам-апдейти 2026 року завершилися менш ніж за три дні кожен. Проте тривалість розгортання сама по собі не показує, наскільки сильно змінилися позиції конкретного сайту.
Є й окрема проблема з вимірюваннями. SEOmonitor повідомила, що з 26 вересня автоматизовані сервіси перевірки позицій отримували неповні або некоректні результати, які не збігалися з тим, що бачили звичайні користувачі Google. Це пояснення самого сервісу; воно не означає, що всі коливання були помилковими.
Падіння в трекері позицій ще не доводить, що сайт постраждав від Spam Update. Я б спочатку зіставив його з показами, кліками та органічними переходами за тими самими сторінками й ринками. Для порівняння тепер є визначений період розгортання — з 24 вересня до 8 жовтня. Дані до, під час і після нього варто оцінювати з урахуванням затримок звітності.
Сканування, перенесення та відновлення мають різні терміни
2 жовтня на Search Central Live Deep Dive Europe у Барселоні Gary Illyes представив часові діапазони для процесів Google Search. Учасник конференції John Campbell із ROAST опублікував переказ виступу з таблицями. За його словами, дані ґрунтуються на внутрішньому аналізі Google.
| Процес | Типовий строк у переказі | Найповільніші випадки |
|---|---|---|
| Виявлення нового URL | Близько 20 годин | Тижні або URL так і не буде виявлено |
| Обробка sitemap | Близько 24 годин | До 14 днів або без обробки через оцінку якості |
| Індексація, end-to-end | Близько 1,5 години | Місяці або без індексації через оцінку якості |
| Перенесення сайту | 1–3 місяці | Від 6 місяців до понад року |
| Відновлення після Core Update | 3–6 місяців | 6–12 місяців |
Це орієнтири з переказу учасника, а не гарантований графік Google. У ньому не наведено розміру вибірки, періоду вимірювань чи точного визначення «типового» випадку. Процеси також залежать один від одного: сторінку неможливо проіндексувати до сканування, тому затримки можуть накопичуватися.
Особливо обережно слід читати рядок про 1,5 години. Він не обіцяє, що нова публікація потрапить у пошук через 90 хвилин після натискання кнопки «Опублікувати». Виявлення адреси, сканування, індексація та повернення позицій — різні процеси, а частина сторінок може взагалі не потрапити до індексу.
Такі діапазони допомагають пояснити, чому перенесення або відновлення сайту не завжди видно за кілька днів. Але якщо проєкт вийшов за наведений строк, це привід перевірити причини затримки, а не просто призначити нову дату очікування.
Search Console об’єднує дані кількох країн і пристроїв
Google Search Central оголосив про оновлення фільтрів звіту Performance. В офіційній довідці Search Console тепер описано вибір кількох країн або типів пристроїв для перегляду їхніх спільних показників.
Наприклад, для сайту, який працює на кількох ринках, можна зібрати їхній пошуковий трафік в одному відфільтрованому звіті. Аналогічно можна об’єднати вибрані категорії пристроїв.
Важливо розрізняти об’єднання та порівняння. Функція Compare, як і раніше, зіставляє два значення вибраного параметра. А фільтрувати одночасно за кількома видами представлення результатів — Search appearances — не можна.
Вигаданий експерт із AI-портретом — це обман
У рекомендаціях щодо корисного й надійного контенту Google прямо застерігає від фальшивих авторських профілів. Йдеться про згенеровані портрети, вигадані імена та неправдиві відомості про кваліфікацію, які створюють враження, ніби матеріал написав справжній експерт.
Компанія називає таке введення в оману ознакою сторінки низької якості та причиною недовіри користувачів і автоматизованих систем оцінювання. Це стосується саме підробленого авторства: із формулювання не випливає загальна заборона на AI-ілюстрації чи використання AI під час підготовки тексту.
Для власника сайту практичний крок простий: перевірити підписи, сторінки авторів і заявлені досягнення. Реальна редакційна відповідальність важливіша за портрет «експерта», якого не існує. Ця вимога доповнює вже описану нами ручну перевірку AI-контенту. Окремого нового штрафу за будь-яке AI-зображення документація не оголошує.
Sitemap має бути доступною для виявлення, а Couldn’t fetch потребує діагностики
У випуску Search Off the Record від 1 жовтня John Mueller і Martin Splitt обговорили XML-карти, RSS та AI-краулери. Мюллер пояснив, що такі краулери зазвичай не мають аналога Search Console, куди власник сайту міг би подати карту. Передбачувана назва на кшталт sitemap.xml, запис у robots.txt або доступна RSS-стрічка допомагають їм знайти адреси.
Мюллер також розповів про звернення AI-краулерів до sitemap і RSS у журналах власного сервера. Це його спостереження, яке не доводить, що всі AI-системи працюють однаково. Отримання файла також не гарантує використання сторінок для навчання моделі чи цитування в її відповідях.
Окреме питання — статус Couldn’t fetch у Search Console. Він означає, що Google не отримав файл sitemap, але причина не обов’язково в синтаксисі XML. Довідка звіту Sitemaps серед можливих причин називає блокування в robots.txt, ручні заходи, неправильний URL, недоступність сервера та низький попит на сканування.
Тому я б почав із деталей останнього запиту й перевірки доступності файла для Google. Якщо файл коректний, варто дослідити навантаження сервера та пріоритет сканування. Саме повідомлення Couldn’t fetch не дозволяє оголосити сайт неякісним.
Не слід також плутати XML Sitemap із HTML-картою сайту: навігаційна сторінка допомагає людям і роботам знаходити розділи, але виконує іншу роль. Змінювати працюючу карту лише через червоний статус у звіті я б не поспішав — спочатку треба встановити, чому Google її не отримав.