ШІ-кліки в Google, індексація, редиректи та аналітика пошуку: головне в SEO за 2–8 листопада | Медіа Inweb

Упродовж 2–8 листопада 2026 року SEO-фахівці зафіксували аномальні стрибки кліків у Google Search Console, а Google уточнив підходи до індексації сторінок, використання редиректів і блокування JavaScript-ресурсів. Водночас компанія поки не планує запроваджувати окрему звітність щодо кліків з AI Overviews та AI Mode. Інші новини тижня стосуються оновлення фільтрів у Search Console, змін у Lighthouse, нерелевантних результатів пошукової видачі та застосування політики зловживання репутацією сайту в Європейській економічній зоні.

Я — Ярослава Чигрин, SEO-спеціалістка в Inweb. У цьому дайджесті розбираю головні SEO-новини за 2–8 листопада та пояснюю, що вони означають на практиці для SEO-спеціалістів і власників сайтів.

Допомагаємо бізнесу зростати завдяки просуванню в інтернеті — Inweb

Залишити контакт

Google поки не планує додавати окрему звітність щодо кліків з AI Overviews та AI Mode

2 листопада Search Engine Journal повідомив, що Google поки не має конкретних планів щодо запуску окремих показників кліків і пошукових запитів з AI Overviews та AI Mode у Search Console. Про це представник Google Гарі Ілліс розповів у відповідь на допис SEO-фахівця Раджива Лехвара в LinkedIn. За словами Ілліса, команда зацікавлена в наданні власникам сайтів більшої кількості корисних даних, однак наразі нічого не анонсує.

Звіт Generative AI Performance дає змогу аналізувати покази сторінок у ШІ-пошуку за сторінками, країнами, пристроями та датами, але не містить окремих показників кліків, CTR і пошукових запитів. Водночас кліки з AI Overviews та AI Mode враховуються у стандартному звіті Performance разом з іншими переходами з Google Search.

На мою думку, одна з головних проблем GEO зараз — недостатня прозорість аналітики. Ми можемо бачити, що сторінки сайту з’являються у відповідях ШІ, але оцінити реальний внесок такої видимості в трафік і конверсії значно складніше. Я рекомендую вже зараз окремо відстежувати переходи з ШІ-платформ у GA4, де це можливо, та аналізувати поведінку цих користувачів на сайті. Важливо розуміти, чи приводить така видимість цільову аудиторію, чи користувачі лише бачать бренд у відповідях ШІ. Також не варто оцінювати ефективність GEO лише за кількістю показів. Для бізнесу важливі не тільки згадки та цитування, а й переходи на сайт, звернення та продажі.

У Google Search Console помітили аномальні стрибки кліків

3 листопада Search Engine Land повідомив про незвично великі стрибки кліків у звітах Performance у Google Search Console. За спостереженнями SEO-фахівців, які зібрала Марі Гейнс, аномалії почали з’являтися наприкінці жовтня, а найбільші сплески припали на 1–2 листопада. У частини сайтів показники повернулися до звичного рівня вже 3 листопада.

Подібні стрибки фіксували не лише у вебінтерфейсі Search Console, а й через API. Водночас дані не завжди збігалися: в окремих випадках аномалії були помітні через API, але не відображалися в інтерфейсі. На момент публікації Google не підтвердив причину цих змін. Search Engine Land припустив, що йдеться про помилку звітності.

Такі ситуації показують, чому під час аналізу SEO-результатів важливо не обмежуватися одним звітом. Якщо Search Console показує різке зростання кліків, я насамперед порівняла б ці дані з GA4, кількістю органічних сеансів і конверсіями. Особливо важливо перевірити, чи відповідає зростання кліків реальній поведінці користувачів на сайті. Якщо кількість кліків збільшилася в кілька разів, а сеанси й конверсії залишилися на попередньому рівні, це привід додатково перевірити дані. У такій ситуації я не поспішала б змінювати сторінки або робити висновки про ефективність оптимізації. Натомість варто зафіксувати період аномалії в аналітиці, щоб під час порівняння періодів не сприймати його як реальне зростання органічного трафіку.

Google уточнив, як трактувати статус «Проскановано — наразі не проіндексовано»

3 листопада Search Engine Roundtable повідомив про оновлення довідки Google Search Console щодо статусу «Проскановано — наразі не проіндексовано».

У новому поясненні Google зазначає, що не всі сторінки в інтернеті потрапляють до індексу. Тому цей статус є поширеним і не обов’язково свідчить про проблему, яка потребує втручання. Для важливих сторінок Google рекомендує використовувати інструмент перевірки URL та інші засоби діагностики, щоб з’ясувати, чи немає технічних перешкод для індексації. Також із нового формулювання прибрали згадки про якість контенту. Однак це не означає, що якість більше не впливає на індексацію. Google лише уточнив, що цей статус не потрібно автоматично сприймати як ознаку низької якості сторінки.

На мою думку, це уточнення допоможе уникнути зайвої технічної роботи. Статус «Проскановано — наразі не проіндексовано» не варто автоматично сприймати як помилку, яку потрібно виправляти для кожної URL-адреси. Я рекомендую насамперед визначити пріоритетні сторінки: ті, що мають цінність для бізнесу, отримують внутрішні посилання або повинні залучати органічний трафік. Для них варто перевірити доступність для сканування, canonical, якість та унікальність контенту, а також його відповідність пошуковому наміру. Якщо Google не індексує багато важливих сторінок і очевидних технічних причин немає, варто проаналізувати якість контенту та загальну структуру сайту, а не намагатися механічно виправляти кожну URL-адресу окремо.

Google пояснив, як різні типи редиректів впливають на канонікалізацію

5 листопада Search Engine Journal опублікував пояснення представників Google Гарі Ілліса та Черрі Проммавін щодо постійних і тимчасових редиректів та їхнього впливу на вибір канонічної URL-адреси. Основна відмінність полягає в тому, чи є перенаправлення постійним. 301 сигналізує, що сторінка назавжди переїхала на нову адресу. Для Google це сигнал на користь вибору цільової URL як канонічної. 302 вказує на тимчасове перенаправлення. У такому разі Google може залишити початкову URL у результатах пошуку.

Google також уточнив різницю між дедуплікацією та канонікалізацією. Пошукова система може групувати схожі сторінки як за постійних, так і за тимчасових редиректів. Однак саме постійне перенаправлення передає сигнал на користь цільової URL як канонічної.

Окремо представники Google пояснили роботу кодів 307 і 308. Вони відповідають тимчасовому та постійному перенаправленню відповідно, але відрізняються від 302 і 301 особливостями збереження методу HTTP-запиту. Ці нюанси важливо враховувати під час міграції сайтів, зміни структури URL та перенесення контенту.

Я рекомендую не обирати тип редиректу за принципом «усі перенаправлення працюють однаково». Якщо сторінка переїхала назавжди, потрібно використовувати постійний редирект. Якщо зміна тимчасова — тимчасовий. Під час технічного аудиту також варто перевіряти ланцюжки перенаправлень, циклічні редиректи та відповідність кінцевої URL-адреси очікуваній сторінці. Це допоможе уникнути ситуацій, коли пошукова система отримує неоднозначні сигнали про те, яку адресу потрібно вважати основною.

Google пояснив, коли можна блокувати окремі JavaScript-ресурси через robots.txt

3 листопада Search Engine Journal розповів про пояснення представника Google Джона Мюллера щодо блокування окремих JavaScript-ресурсів від Googlebot. Питання виникло під час обговорення на Reddit. Власник сайту запитав, чи можна заборонити пошуковому роботу завантажувати скрипт вікового попапу, щоб він не відображався під час рендерингу сторінки. Мюллер пояснив, що такий підхід загалом може спрацювати. Якщо попап завантажується із зовнішнього домену, відповідні ресурси можна заблокувати через robots.txt цього домену. Якщо він працює через окремий JavaScript-файл на самому сайті, можна обмежити сканування саме цього файлу.

Водночас Мюллер застеріг від блокування скриптів, які відповідають за кілька функцій одночасно. Важливо переконатися, що без заблокованого ресурсу Googlebot зможе коректно відобразити основний контент сторінки. Ідеться про окремий технічний сценарій, а не загальну рекомендацію блокувати JavaScript для пошукових роботів.

На мою думку, це корисне уточнення для сайтів зі специфічними сценаріями відображення контенту. Але його не варто сприймати як загальний дозвіл блокувати JavaScript-ресурси від Googlebot. Під час технічного аудиту я спочатку з’ясувала б, який саме скрипт потрібно заблокувати для пошукового робота та чи не вплине це на відображення основного контенту. Якщо один файл відповідає і за попап, і за важливі елементи сторінки, його блокування може зашкодити тому, як Google бачить сайт.

У Google Search Console з’явилася можливість фільтрувати дані за кількома типами пристроїв

5 листопада Search Engine Watch повідомив про оновлення фільтрів у звіті Performance в Google Search Console. Тепер користувачі можуть одночасно вибирати кілька типів пристроїв: Desktop, Mobile і Tablet.

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

Я вважаю це невеликим, але практичним оновленням. Воно зменшує кількість ручної роботи під час аналізу сайтів, аудиторія яких по-різному поводиться на мобільних і десктопних пристроях. Рекомендую використовувати новий фільтр для регулярного аналізу кліків, показів, CTR і середньої позиції за типами пристроїв. Водночас, щоб зрозуміти причини змін, важливо не обмежуватися загальними показниками, а перевіряти дані за окремими сторінками та пошуковими запитами.

Оновлення Lighthouse змінює оцінки PageSpeed Insights навіть без змін на сайті

2 листопада Search Engine Journal повідомив про перехід PageSpeed Insights на Lighthouse 13.6.0, реліз якого відбувся 27 жовтня. Оновлення змінило методологію симуляції завантаження сторінок і вплинуло на розрахунок лабораторних показників First Contentful Paint (FCP) та Largest Contentful Paint (LCP).

За словами представника Chrome Web Performance Баррі Полларда, новий підхід має точніше оцінювати завантаження сторінок і загалом давати кращі результати. Найбільше зміни можуть вплинути на сайти з великою кількістю JavaScript. Зокрема, Lighthouse 13.6 змінив механізм симуляції Lantern. Тепер для визначення ресурсів, які блокують рендеринг, він використовує спеціальну позначку Chrome render-blocking, а пріоритет запиту враховує лише за її відсутності.

Також змінився розрахунок LCP у випадках, коли найбільшим елементом контенту є текст, який з’являється одночасно з першим контентом сторінки. Через це оцінки PageSpeed Insights можуть змінюватися навіть без технічних змін на сайті.

На мою думку, це важливий нюанс для SEO-фахівців, які регулярно проводять технічні аудити та відстежують Core Web Vitals. Якщо після оновлення Lighthouse оцінка швидкості сайту зросла, не варто одразу вважати це результатом технічної оптимізації. Спочатку потрібно перевірити версію інструмента, яка вказана у звіті PageSpeed Insights поряд з емульованим пристроєм, а потім порівняти лабораторні результати з польовими даними CrUX. Лабораторні показники відображають симульоване завантаження сторінки за визначених умов, тоді як польові дані базуються на реальному досвіді користувачів за останні 28 днів. Тому під час регулярних аудитів я рекомендую фіксувати версію Lighthouse та окремо відстежувати динаміку реальних Core Web Vitals. Це допоможе не плутати зміни методології вимірювання з фактичним покращенням швидкості сайту.

Сервіси моніторингу позицій зафіксували нерелевантні результати Google

3 листопада SE Ranking опублікував дослідження 10 000 десктопних пошукових запитів Google у США. Компанія виявила випадки, коли результати пошуку відповідали лише одному слову запиту, а не його повному змісту.

У 84% випадків, які SE Ranking визначила як проблемні, нерелевантні результати були пов’язані лише з одним словом. У решті випадків вони відповідали двом або більше словам запиту. Такі результати переважно з’являлися на нижчих позиціях. Жоден із виявлених блоків не починався в топ-5. У 3,5% випадків вони з’являлися на позиціях 6–8, а в 96,5% на дев’ятій позиції або нижче.

Дослідження також показало різке зростання частоти таких випадків у вибірці: з 0,09% 16 вересня до 57,3% 17 вересня та 67,2% 24 вересня. Ці показники стосуються лише дослідженої вибірки, а не всієї пошукової видачі Google.

Наприклад, за запитом business bank line of credit на другій сторінці видачі з’являлися музичні відео, месенджер LINE та готель The Line Hotel. Ці результати були пов’язані зі словом line, але не відповідали наміру користувача.

Схожі випадки досліджувала компанія Nozzle, яка також зафіксувала більше нерелевантних результатів на другій сторінці пошуку.

Для SEO-фахівців це означає, що падіння позицій у трекері не завжди свідчить про погіршення роботи сайту. Якщо на нижчих позиціях з’являються сторінки, релевантні лише одному слову пошукового запиту, інструмент може зафіксувати зміщення позиції або зникнення сторінки з вибірки. Я рекомендую уважніше перевіряти різкі зміни позицій, особливо якщо вони відбуваються нижче топ-5 або на другій сторінці пошукової видачі. Якщо інструмент показує, що сторінка втратила позиції, варто перевірити фактичну видачу Google, цільову URL-адресу та дані Search Console за відповідним запитом. Важливо аналізувати не лише власну позицію, а й те, які сторінки з’явилися поруч і наскільки вони відповідають повному пошуковому запиту.

Google повідомив про зміни в застосуванні політики зловживання репутацією сайту в ЄЕЗ

5 листопада Google почав надсилати власникам сайтів повідомлення про зміни в застосуванні ручних заходів за порушення політики зловживання репутацією сайту в Європейській економічній зоні (ЄЕЗ).

Зміну Google анонсував ще 28 серпня 2026 року, а новий порядок застосування ручних заходів почав діяти з 30 серпня. Відповідно до оновлених правил, вплив ручних заходів залежить від регіону користувача: за межами ЄЕЗ ручні заходи продовжують впливати на результати пошуку для відповідних частин сайту. У ЄЕЗ вплив цих ручних заходів на пошукову видачу не застосовується. Водночас Google може відокремити відповідний розділ сайту у своїх системах, щоб він ранжувався незалежно від основного домену.

Це не означає скасування політики проти зловживання репутацією сайту. Google змінив лише підхід до застосування ручних заходів у ЄЕЗ.

На мою думку, ця новина особливо важлива для міжнародних сайтів і проєктів, які публікують сторонній контент на власному домені. Одна й та сама сторінка може по-різному відображатися в пошуку залежно від регіону користувача. Я рекомендую власникам сайтів, які отримували ручні заходи за цією політикою, перевірити повідомлення в Search Console та проаналізувати видимість сторінок у різних регіонах. Водночас не варто сприймати зміну застосування санкцій у ЄЕЗ як дозвіл публікувати сторонній нерелевантний контент без контролю його якості.

Якщо відгукнувся наш досвід — обговорімо зростання вашого бізнесу