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

Один запит користувача може породити кілька внутрішніх підзапитів. Google називає цей механізм query fan-out; далі я називатиму його розгортанням запиту. Офіційний приклад: для запиту про газон, зарослий бурʼянами, система може паралельно шукати найкращі гербіциди, способи видалення бурʼянів без хімії та методи профілактики. Кожен підзапит формує власний набір сторінок-кандидатів. Відповідь для користувача одна, але фактичний простір пошуку ширший за буквальний текст початкового запиту.[2]

Для SEO це означає, що логіка точного входження стає ще менш корисною як основний спосіб моделювання попиту. Сторінка може бути релевантною не до вихідної фрази, а до одного з підзапитів, окремого фрагмента тексту або звʼязку між сутностями, який система використала під час розгортання запиту. Це не доказ того, що «ключові слова померли». Це доказ того, що окреме ключове слово давно не дорівнює всьому простору можливих запитів.

Рис. 1.1. Від запиту користувача до посилання на джерело: ранжування, відбір документів, опора на джерела і цитування є різними етапами.

Авторська схема. Механіка узагальнена на основі Google Search Central: https://developers.google.com/search/docs/appearance/ai-features

Таблиця 1.1. У 2026 році видимість у пошуку складається з кількох різних форматів. Механіка між ними частково спільна, але метрики не взаємозамінні.

Тут важливо не впадати у дві крайності. Перша: «AI забрав увесь SEO-трафік». Це неправда. Друга: «нічого не змінилося, бо користувачі все одно клікають». Це теж погано узгоджується з даними. Станом на 2026 рік є щонайменше два незалежні набори даних, які показують один напрям: коли AI-відповідь закриває інформаційну потребу безпосередньо у видачі, частота переходів на зовнішні сайти падає.

Рис. 1.2. Оцінений вплив AI Overview на органічний CTR залежно від позиції.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код F7FBD559

Дані: Ahrefs, 300 000 ключових слів, 4 лютого 2026 року. https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/ Це модельна оцінка на основі спостережень, а не рандомізований причинний експеримент.

Таблиця 1.2. Оцінка Ahrefs для грудня 2025 року. Важливо: це модельна оцінка впливу, а не прямий причинний ефект, виміряний експериментом.[3]

Сама цифра -58% сильна, але її користь для Senior SEO не в тому, щоб вставити її в презентацію. Важливіша методологія. Ahrefs не просто порівняв поточний CTR запитів з AI Overview і без нього. Дослідники використали базовий рівень до масового поширення AI Overview та контрольну групу інформаційних запитів, щоб оцінити, яким міг би бути CTR запитів з AI Overview без цього фактора. Це все одно не усуває сторонні змінні: структуру запитів, склад SERP, зміни поведінки користувачів, відмінності між пристроями, сезонність та інші елементи видачі. Але така методологія сильніша за просте твердження «у запитів з AI Overview CTR нижчий».

Це інший тип дослідження. Pew не намагався оцінити CTR конкретної позиції. Дослідники дивилися на поведінку реальних користувачів після сторінки результатів Google. Напрям виявився тим самим: коли у видачі є AI-відповідь, частка сесій без переходу на зовнішній сайт зростає.

Ще одна корисна деталь із Pew: у їхній вибірці AI-відповідь зʼявлялася приблизно у 18% усіх пошукових сесій Google. Імовірність сильно залежала від форми запиту: лише 8% одно- або двослівних запитів мали AI-відповідь, тоді як серед запитів із 10 і більше словами частка становила 53%. Для запитів, що починалися з питальних слів на кшталт «хто», «що», «коли», «чому», частка сягала 60%.[4]

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

У старій звітності часто було достатньо побачити: позиція стабільна, покази ростуть, кліки падають. Далі починалися припущення про заголовок, фрагмент опису, сезонність або слабший попит. У 2026 році до цього списку треба додати зміну самого формату видачі.

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

У 2026 році Google описав механіку досить прямо, щоб прибрати частину ринкового шуму навколо «GEO-хаків». Генеративні функції пошуку Google спираються на основні системи ранжування й оцінки якості. Для отримання актуальної інформації вони використовують RAG: знаходять релевантні сторінки в індексі й використовують їх як фактичну основу для відповіді. Додатково система може розгортати початковий запит у кілька паралельних підзапитів.[2]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 5F5F5A2C

Щоб сторінка могла зʼявитися як посилання на джерело в AI Overviews або AI Mode, вона має бути проіндексована й придатна для звичайного показу в Google з фрагментом опису. Google прямо зазначає, що окремих технічних вимог лише для AI-функцій немає.[1] Це критично: якщо URL не проходить базовий ланцюжок пошуку, «оптимізація під AI» поверх цього не вирішує проблему.

Тут є важливий нюанс. «Немає спеціальної розмітки для AI» не означає, що структуровані дані не потрібні. Google окремо уточнює, що вони залишаються корисними для звичайних елементів пошуку та розширених результатів. Просто не треба продавати їх як магічний фактор GEO. Те саме із заголовками, таблицями чи FAQ: вони можуть покращувати читабельність, структуру інформації та її виділення, але немає офіційної вимоги дробити сторінку на спеціальні фрагменти «для LLM».

AI змінив не лише SERP, а й економіку контенту. Якщо відповідь складається із загальнодоступних фактів, які десятки сторінок переказують однаково, пошуковій системі дедалі простіше сформувати її без окремого переходу на ще одну схожу сторінку. У документації для AI-пошуку Google робить акцент на унікальній інформації, експертному внеску, власному досвіді та матеріалах, які не є простим переказом того, що вже є в мережі.[2]

Для SEO-команди це перекладається на операційну мову дуже просто. «Ще одна стаття на ту саму тему» перестає бути достатньою одиницею виробництва контенту. Сторінка повинна мати хоча б один власний інформаційний актив: дані, реальний тест, інструмент, набір даних, зріз цін, методику порівняння, скріншоти, власні спостереження, калькулятор, дані з API, регіональну специфіку або іншу практичну цінність, якої немає у взаємозамінних конкурентів.

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

Ще у 2025 році одна з головних проблем AI-пошуку полягала в тому, що SEO бачив кінцевий результат, але майже не мав даних про те, де й як сайт зʼявляється у генеративних відповідях. У 2026 році ситуація стала кращою.

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

Рис. 1.3. Search Console: окремий звіт про ефективність генеративних функцій AI у пошуку.

Схематичне відтворення офіційного скріншота Google, без доданих метрик. Оригінал: https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports

Bing дає ще глибший рівень діагностики. Якщо URL часто цитують, але набір запитів, за якими його знаходять, вузький, сторінка може мати сильну видимість лише в одному тематичному кластері. Якщо більшість цитувань припадає на кілька URL, можна порівняти ці сторінки з іншими й перевірити різницю в охопленні теми, чіткості сутностей, щільності фактів, актуальності, посилальній вазі та відповідності запиту. Але навіть тут кількість цитувань не можна називати «позицією в AI». Bing прямо пояснює, що активність цитування не дорівнює місцю, авторитетності чи ролі сторінки в конкретній відповіді.[6]

Рис. 1.4. Bing Webmaster Tools AI Performance: цитування, цитовані сторінки та запити, за якими система знаходила джерела.

Схематичне відтворення офіційного скріншота Microsoft Bing. Оригінал: https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview

Я б не будував окрему «GEO-панель», відірвану від SEO-аналітики. Корисніше розкласти видимість на чотири шари й дивитися, на якому саме етапі губиться цінність.

Таблиця 1.3. Мінімальна модель, яка не змішує технічну доступність, потрапляння у відбір, видимість і бізнес-результат.

Після цього можна рахувати власні похідні метрики. Вони не є метриками Google і їх не треба видавати за стандарт індустрії. Це робочі аналітичні коефіцієнти, які дозволяють порівнювати власні дані між періодами.

Рис. 1.5. Модель вимірювання: індексованість, потрапляння у відбір, видимість, трафік і бізнес-результат не можна зводити до одного показника.

Авторська схема. Метрики та джерела даних відповідають моделі вимірювання цієї глави.

Найважливіше: не змішувати різні знаменники. Генеративні покази в Google, цитування в Bing і переходи з ChatGPT описують різні події. Їх не можна просто скласти в один «показник AI-видимості» без нормалізації та чіткого визначення, що саме він означає. Інакше панель виглядає красиво, але перестає бути діагностичним інструментом.

Якщо органічні кліки впали на 20%, я не починаю з гіпотези «це AI». Я починаю з декомпозиції. Спочатку перевіряю попит: покази, Google Trends, динаміку рік до року, сезонність. Потім дивлюся розподіл позицій: чи справді вони не просіли всередині важливих груп сторінок і запитів. Далі перевіряю склад SERP: AI Overviews, локальні й товарні блоки, відео, новини та інші елементи. І лише після цього оцінюю, чи падіння віддачі в кліках збігається зі зростанням генеративних показів.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код B5986919

Для цього достатньо простої формули: віддача в кліках = кліки / покази для конкретного сегмента. Не для всього ресурсу одразу, а для однакового набору запитів, сторінок, країн і пристроїв. Якщо віддача падає за стабільних або кращих позицій, а генеративні покази одночасно ростуть, гіпотеза про вплив нового формату видачі стає сильнішою. Якщо одночасно змінилися структура запитів або розподіл позицій, причинність не доведена.

Перша зміна: SEO-план більше не можна будувати лише навколо задачі «підняти позицію». Для частини інформаційних кластерів позиція може рости, а додаткового трафіку майже не буде. Пріоритизація повинна враховувати потенціал кліків у конкретному форматі видачі, а не лише частотність запиту та поточну позицію.

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

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

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

Пʼята зміна: технічний SEO стає не менш, а більш важливим. Для посилань на джерела в AI Google використовує ту саму базову придатність сторінки до пошуку: вона має бути проіндексована й придатна для показу з фрагментом опису. Якщо на сайті хаос із канонічними версіями, проблеми з рендерингом, noindex, мʼякі 404, зламана внутрішня перелінковка або сторінки просто не потрапляють до індексу, «GEO-оптимізації» нема на що спиратися.[1]

Це не повний аудит. Це швидка діагностична перевірка, після якої вже зрозуміло, чи проблема взагалі варта глибшого дослідження.

Таблиця 1.5. Швидка діагностика, яка відділяє вплив формату видачі від падіння попиту або позицій.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A492704C

Ми точно знаємо, що Google використовує індекс пошуку, системи ранжування й оцінки якості, RAG та розгортання запиту у генеративних функціях пошуку.[1][2] Ми точно знаємо, що Google не вимагає llms.txt, спеціальної розмітки для AI або окремої schema.org-розмітки для появи в цих функціях.[2] Маємо сильні зовнішні дані, що AI-відповіді корелюють із нижчою частотою кліків в інформаційній видачі.[3][4] Також маємо власні звіти Google та Bing, які вже дозволяють бачити генеративні покази, цитування, цитовані сторінки й запити, за якими система знаходила джерела.[5][6]

Чого ми не знаємо з публічних джерел: точних ваг сигналів для потрапляння в AI-відповідь; універсальної формули ймовірності цитування; повної залежності між органічною позицією і цитуванням; повного набору внутрішніх сигналів відбору документів; стабільного «GEO-фактора ранжування», який можна оптимізувати одним технічним трюком. Якщо хтось продає це як встановлений факт, вимагайте докази, методологію та розмір вибірки.

Перевірено станом на 12 вересня 2026 року. Для динамічних продуктів та інтерфейсів перед фінальним друком потрібен повторний фактчек.

1. Google Search Central. AI features and your website.. https://developers.google.com/search/docs/appearance/ai-features Офіційна документація: умови появи в AI Overviews та AI Mode, відбір документів і розгортання запиту.

2. Google Search Central. Optimizing your website for generative AI features on Google Search.. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide Офіційна документація 2026 року: RAG, робота з джерелами, технічні вимоги та спростування поширених міфів про AI-оптимізацію.

3. Ahrefs. Update: AI Overviews Reduce Clicks by 58%.. https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/ 4 лютого 2026 року. Спостережне дослідження на 300 000 ключових слів із модельною оцінкою впливу AI Overview на CTR.

4. Pew Research Center. Google users are less likely to click on links when an AI summary appears in the results.. https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/ Дослідження поведінки 900 дорослих у США: 68 879 унікальних пошукових сесій Google.

5. Google Search Central Blog. Introducing Search Generative AI performance reports in Search Console.. https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports 3 червня 2026 року; примітка оновлена після глобального розгортання звіту 31 серпня 2026 року.

6. Bing Webmaster Blog. Introducing AI Performance in Bing Webmaster Tools Public Preview.. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview 10 лютого 2026 року. Цитування, цитовані сторінки, запити для пошуку джерел і активність на рівні URL.

7. OpenAI Help Center. Searching the web with ChatGPT.. https://help.openai.com/en/articles/9237897 Актуальна документація продукту: веб-пошук, цитування та джерела.

8. OpenAI Help Center. Publishers and Developers - FAQ.. https://help.openai.com/en/articles/12627856-publishers-and-developers-faq Актуальні рекомендації для видавців і пошукових роботів, зокрема щодо OAI-SearchBot та відстеження переходів.

ЧАСТИНА I / ПОШУК У 2026

ГЛАВА 2

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код D8DD80B1

На рівні продукту Google сам розділяє ці режими. AI Overview зʼявляється всередині звичайної сторінки результатів, коли системи Google вважають генеративну відповідь корисним доповненням до класичного пошуку. AI Mode створений для складніших запитів, порівнянь, дослідження теми й уточнювальних питань. Обидва формати можуть використовувати розгортання запиту, але Google прямо зазначає: вони можуть працювати на різних моделях і техніках, тому відповідь та набір посилань можуть відрізнятися.[1]

У січні 2026 року Google ще сильніше зблизив ці інтерфейси: користувач отримав можливість ставити уточнювальні питання прямо з AI Overview і переходити в продовження діалогу. На I/O 2026 Google вже описував це як безшовний перехід від сторінки результатів з AI Overview до розмови в AI Mode із збереженням контексту.[2] Для користувача межа між «SERP» і «чатом» стає менш помітною. Для SEO ця межа, навпаки, критична, бо різні формати можуть показати різні URL.

Станом на оновлення Google від 31 серпня 2026 року AI Overviews має понад 2,5 млрд активних користувачів на місяць, а AI Mode перевищив 1 млрд активних користувачів на місяць.[3] Це не частка всіх пошукових запитів і не показник кліків. Це показники аудиторії продуктів. Але вони достатні, щоб не розглядати генеративний пошук як лабораторний експеримент, який можна винести за межі основної SEO-стратегії.

Рис. 2.2. AI Mode як окремий пошуковий інтерфейс: відповідь, джерела і продовження діалогу знаходяться в одному сеансі.

Схематичне відтворення за офіційним описом Google. Оригінальний матеріал: https://blog.google/products-and-platforms/products/search/ai-mode-development/

Таблиця 2.1. Те, що AI Overview і AI Mode живуть усередині Google Search, не робить їх одним і тим самим форматом.[1][2]

Найкращий спосіб побачити різницю між AI Overview і AI Mode - не сперечатися про інтерфейс, а подивитися на перетин джерел. Ahrefs у дослідженні, опублікованому в грудні 2025 року, зіставив 540 тис. пар відповідей для аналізу цитувань і 730 тис. пар для аналізу тексту. Дані були зібрані в США у вересні 2025 року.[9]

Результат добре показує, чому модель «AI Mode просто розгортає AI Overview» слабка. Семантична схожість відповідей була високою: близько 86%. Тобто системи часто приходили до близького змістового висновку. Але перетин цитованих URL становив лише 13,7%, а перетин унікальних слів - близько 16%.[9] Інакше кажучи, висновок може бути схожим, а шлях до нього - зовсім іншим.

Рис. 2.3. AI Overview і AI Mode часто погоджуються по суті, але цитують різні URL.

Дані: Ahrefs, https://ahrefs.com/blog/ai-overviews-vs-ai-mode/ Вибірка: 540 тис. пар для URL та 730 тис. пар для аналізу відповідей, США, вересень 2025 року.

У тому самому дослідженні AI Mode у середньому формував приблизно у чотири рази довші відповіді й містив у 2,5 раза більше сутностей людей і брендів. Якщо бренд уже згадувався в AI Overview, імовірність його появи в AI Mode у цій вибірці становила 61%. Водночас 11% AI Overviews і 3% відповідей AI Mode не містили цитованих джерел.[9] Ці цифри не треба переносити як константу на 2026 рік: моделі й інтерфейси вже змінилися. Їхня цінність в іншому - вони показують сам факт розходження між системами на великій вибірці.

Для практичного SEO це означає, що навіть усередині Google треба розділяти щонайменше дві задачі: присутність у AI Overview та присутність в AI Mode. Якщо сайт добре цитують в одному форматі, це ще не доказ, що другий формат бачить його так само. І навпаки, відсутність у AI Overview не означає автоматичну відсутність у AI Mode.

У ChatGPT логіка входу інша. Користувач не обовʼязково вирішує, що зараз він «іде в пошук». ChatGPT може запустити веб-пошук автоматично, коли для відповіді потрібна актуальна інформація, або користувач може вибрати пошук вручну.[4] Це змінює не лише інтерфейс, а й те, що SEO вважає запитом.

OpenAI прямо описує механіку переписування: початкове питання може бути перетворене в один або кілька цільових пошукових запитів. Після перегляду перших результатів система може відправити додаткові, більш специфічні запити.[4] Тобто фраза, яку написав користувач, не обовʼязково збігається з фразою, за якою система шукала ваш документ.

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

Рис. 2.4. ChatGPT Search: веб-пошук є частиною формування відповіді, а не окремою сторінкою результатів.

Схематичне відтворення на основі офіційної довідки OpenAI: https://help.openai.com/en/articles/9237897

Для власника сайту OpenAI окремо розділяє пошукове виявлення і навчання моделей. Щоб контент міг потрапляти у зведення й фрагменти ChatGPT Search, не треба блокувати OAI-SearchBot. GPTBot - інший робот, який використовується для керування потенційним використанням контенту в навчанні.[5] Це принципова технічна різниця: заборона навчання не повинна автоматично перетворюватися на заборону пошукового виявлення, якщо бізнес хоче отримувати переходи та цитування з ChatGPT.

OpenAI також повідомляє, що переходи з ChatGPT Search автоматично містять utm_source=chatgpt.com.[5] Це одна з небагатьох ділянок AI-пошуку, де джерело переходу можна визначити без моделі або стороннього сервісу: трафік із ChatGPT реально відокремлюється в аналітиці. Але це вимірює тільки переходи. Бренд може бути згаданий або процитований без кліку, і GA4 цього не покаже.

Рис. 2.5. Початковий запит користувача може породити кілька пошукових підзапитів.

Авторська схема. Основа: Google Search Central описує розгортання запиту; OpenAI Help Center описує переписування питання в один або кілька цільових запитів.[1][4]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 2A8939AC

Perplexity від початку позиціонує себе як пошукову систему з генеративною відповіддю. В офіційній довідці сервіс описує процес досить просто: інтерпретація питання, пошук в інтернеті в реальному часі, узагальнення знайденої інформації та посилання на джерела.[6] Для SEO важливе не маркетингове формулювання, а факт: сторінка конкурує не лише за місце в списку результатів, а за включення в набір джерел, з яких формується відповідь.

У липні 2026 року Perplexity окремо оновив документацію щодо сканування. PerplexityBot використовується для індексації сторінок і появи сайтів у результатах Perplexity. Окремий Perplexity-User використовується для запитів, ініційованих користувачем. У документації Perplexity зазначає, що PerplexityBot дотримується robots.txt; для бота, який виконує запит користувача, діє інша логіка.[7] Це ще один приклад того, чому «дозволити всіх AI-ботів» або «заблокувати всіх AI-ботів» - поганий технічний підхід.

У Microsoft картина ще одна. Bing Webmaster Tools з лютого 2026 року показує AI Performance для Microsoft Copilot, генеративних підсумків Bing та окремих партнерських інтеграцій. Звіт містить загальну кількість цитувань, середню кількість цитованих сторінок, цитування на рівні URL, динаміку та вибірку запитів для пошуку джерел - пошукових фраз, через які AI отримував контент, використаний у відповіді.[8] Це дуже цінно саме тому, що Bing показує частину проміжного шару між запитом і цитуванням.

Таблиця 2.2. Пʼять форматів можуть відповідати на одну потребу, але дають SEO різні сигнали й різну прозорість.[1][4][6][8]

Теза «щоб цитуватися в AI, достатньо бути в топ-10» звучить привабливо, бо переносить стару модель SEO в новий інтерфейс. Дані не дають підстав так спрощувати. У березні 2026 року Ahrefs оновив дослідження AI Overview на 863 тис. SERP і приблизно 4 млн URL, показаних у AI Overview. За оновленою методологією 38% сторінок, процитованих у AI Overview, одночасно ранжувалися в топ-10 органічної видачі для того самого запиту.[10]

Це сильний перетин, але не тотожність. Якщо 38% цитованих сторінок є у топ-10, більшість цитованих URL у цій конкретній методології знаходилась поза топ-10 або в інших блоках. Ще важливіше: попередня версія дослідження Ahrefs 2025 року давала значно вищу оцінку перетину. Сам Ahrefs пояснив оновлення зміною парсингу й методології.[10] Для мене це корисний урок не про точну цифру, а про дисципліну роботи з дослідженнями: AI Search змінюється настільки швидко, що навіть відомий відсоток треба зберігати разом із датою, вибіркою і способом підрахунку.

Окреме дослідження Ahrefs на 15 тис. запитів для ChatGPT, Gemini, Copilot і Perplexity показало ще слабший звʼязок із топ-10 Google. У середньому лише близько 12% URL, процитованих ChatGPT, Gemini та Copilot, були присутні в топ-10 Google для початкового запиту; Perplexity був ближче до класичної видачі: майже третина цитованих URL збігалася з топ-10 Google.[11] Це не пряме порівняння з дослідженням AI Overview: інший продукт, інша вибірка, інший метод. Але напрям однаковий: шар цитувань не є копією шару органічного ранжування.

Класичне відстеження позицій привчив SEO до відносно стабільної одиниці спостереження: запит, позиція, дата, країна, пристрій. Генеративна відповідь додає ще один рівень випадковості. Ahrefs у листопаді 2025 року проаналізував понад 43 тис. запитів, для кожного з яких було щонайменше 16 записаних AI Overviews протягом місяця. Між сусідніми спостереженнями текст відповіді змінювався приблизно у 70% випадків, а середня тривалість одного стану відповіді становила 2,15 дня.[12]

Ще показовіші цитування: коли AI Overview оновлювався, в середньому 45,5% цитованих URL змінювалися. При цьому зміст залишався значно стабільнішим: середня семантична схожість між послідовними відповідями становила 0,95 з 1.[12] Це майже та сама картина, яку ми вже бачили при порівнянні AI Overview з AI Mode: відповідь може залишатися змістово близькою, а джерела - обертатися.

Рис. 2.6. AI Overview може зберігати змістовий консенсус, але міняти конкретні джерела.

Дані: Ahrefs, понад 43 тис. запитів, щонайменше 16 спостережень на запит протягом місяця. https://ahrefs.com/blog/ai-overview-change/

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 93ED0D9D

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

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

Рис. 2.7. Мінімальна одиниця спостереження для AI-видимості.

Авторська схема. Значення в рядках показують структуру запису, а не реальні результати тесту.

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

У класичному SEO ми звикли будувати семантику з того, що користувач набирає в пошуковому полі. У генеративному середовищі між фразою користувача і пошуком документів зʼявляється додатковий шар. Google називає цей механізм розгортанням запиту (query fan-out): система може виконувати кілька повʼязаних пошуків за підтемами й джерелами даних.[1] OpenAI описує схожу за функцією поведінку: ChatGPT Search переписує питання в один або кілька цільових запитів і після перших результатів може запускати додаткові уточнення.[4]

Це не означає, що збір і аналіз ключових слів став непотрібним. Навпаки, нам потрібні ключові слова, щоб бачити реальний попит, частотність, SERP, конкуренцію і мову користувача. Але ключове слово перестає бути єдиною одиницею, під яку система шукає документ. Для складного питання треба мислити простором підзадач: які факти потрібно знайти, які критерії порівняти, які обмеження перевірити, які сутності звʼязати між собою.

Практичний приклад. Запит «який ноутбук краще взяти для постійних перельотів, до 1200 доларів, щоб працювати з великими таблицями і не носити зарядку весь день» може вимагати окремих перевірок ваги, автономності, ціни, продуктивності процесора, обсягу памʼяті, доступності конкретної моделі й реальних тестів батареї. Сторінка не повинна буквально містити весь довгий запит. Вона повинна бути сильною відповіддю на одну або кілька інформаційних підзадач, які реально виникають у такому сценарії.

Технічна частина AI-пошук часто починається з robots.txt, і тут дуже легко зробити грубу помилку. У різних платформ є різні роботи для різних задач. OpenAI відділяє OAI-SearchBot, потрібний для пошукового виявлення і появи контенту в ChatGPT Search, від GPTBot, який використовується для керування потенційним використанням контенту в навчанні.[5] Perplexity відділяє PerplexityBot для побудови пошукового індексу від Perplexity-User для запитів, ініційованих користувачем.[7]

Google також відділяє пошук від інших способів використання контенту. Для AI Overviews і AI Mode базовим механізмом керування обходом залишається Googlebot. Якщо власник хоче обмежити текст, що може показуватися в пошуку, Google рекомендує стандартні налаштування фрагментів: nosnippet, data-nosnippet, max-snippet або noindex. Google-Extended стосується окремих інших AI-систем Google, а не є окремим індексаційним перемикачем для AI Overview чи AI Mode.[1]

Таблиця 2.3. Керування доступом треба робити за конкретною функцією робота, а не за ярликом «AI-бот».[1][5][7]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 8048FA8D

Після всього цього легко перейти в протилежну крайність: якщо джерела нестабільні й системи різні, начебто оптимізувати нічого не можна. Це теж неправильно. Ми не контролюємо конкретний список URL у відповіді, але контролюємо велику частину вхідних умов, за якими сторінка взагалі може бути кандидатом.

Для Google фундамент залишається класичним: сторінка має бути доступна Googlebot, проіндексована, придатна до показу з фрагментом, повʼязана внутрішніми посиланнями, містити важливу інформацію у текстовій формі й відповідати правилам пошуку Google.[1] Для ChatGPT треба не блокувати OAI-SearchBot, якщо ми хочемо появи у зведеннях і цитуваннях.[5] Для Perplexity треба дозволити PerplexityBot, якщо видимість у сервісі є бізнес-ціллю.[7]

Далі починається не «секретна GEO-оптимізація», а конкуренція за корисність конкретного документа. Чіткі факти, власні дані, первинні джерела, зрозумілі таблиці, актуальність, однозначні назви сутностей, реальні характеристики продукту, ціни, умови, дати, методологія дослідження - усе це дає системі інформацію, яку можна точно витягти й використати. Це не гарантує цитування. Але це створює набагато сильніший документ-кандидат, ніж загальний текст, який нічого не додає до наявного масиву вебдокументів.

Таблиця 2.4. У генеративному пошуку є великий контроль над вхідними умовами, але немає прямого контролю над кінцевим цитуванням.

Якщо задача - зрозуміти, де бренд або сайт реально присутній у генеративному пошуку, я не починаю з випадкового списку запитів, придуманого SEO-спеціалістом. Я починаю з реального простору попиту: GSC, внутрішнього пошуку сайту, даних продажів, запитів служби підтримки, People Also Ask, форумів, комерційних модифікаторів і питань, які реально виникають перед конверсією. Потім із цього формую контрольний набір задач користувача.

Другий принцип - не змішувати наміри. Інформаційне питання «як працює X», порівняння «X проти Y», рекомендація «що вибрати», локальна задача «де знайти», транзакційна задача «купити/забронювати» і навігаційна задача «офіційний сайт бренду» повинні аналізуватися окремо. Інакше середня частка цитувань просто змішає зовсім різну поведінку систем.

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

Четвертий принцип - зберігати не тільки факт згадки бренду. Я окремо записую: чи є бренд у тексті; чи є URL бренду серед джерел; який саме URL; скільки усього джерел у відповіді; чи є конкурент; чи є посилання клікабельним; який тип сторінки процитовано; чи це головна, категорія, стаття, відео, форум, профіль або стороння згадка.

Пʼятий принцип - повторювати. Через нестабільність джерел одна відповідь має низьку доказову цінність. Для великих наборів запитів я радше зменшу кількість платформ або частоту збору, ніж залишу по одному неповтореному спостереженню і назву його стабільною часткою видимості.

Таблиця 2.5. Мінімальна структура даних для відтворюваного відстеження AI-видимості.

AI-пошук уже породжує десятки власних показників: оцінку видимості, частку цитувань, частку відповідей, частку згадок, частку джерел, охоплення запитів. Проблема не в самих метриках. Проблема починається, коли похідний показник стороннього сервісу сприймають як прямий сигнал платформи. Це та сама помилка, яку SEO роками робило з DR або DA.

Будь-яка власна AI-метрика має починатися з чіткого знаменника. «Частка цитувань 22%» нічого не означає без відповіді: 22% від чого? Від усіх відповідей? Від відповідей, де взагалі були джерела? Від усіх цитованих URL? Від трьох найпомітніших цитувань? За один запуск чи за середнє з повторів? Який набір запитів? Яка країна? Яка платформа?

Для керування командою я використовую кілька простих показників. Охоплення: у скількох контрольних задачах бренд або сайт зʼявився хоча б раз за період. Частота цитувань: у скількох спостереженнях був процитований конкретний домен або URL. Концентрація джерел: яка частка всіх цитувань припадає на кілька сторінок. Розрив із конкурентами: у яких групах задач конкурент стабільно присутній, а ми ні. Нестабільність: як часто склад джерел змінюється між повторними спостереженнями. Це не стандарти Google чи OpenAI. Це робочі коефіцієнти для власної аналітики.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 51B6EDA9

Цей аудит не замінює постійне відстеження. Його задача - за півтори години зрозуміти, чи проблема взагалі існує і де її шукати.

Таблиця 2.6. Швидкий міжплатформний аудит. Це діагностика, а не доказ причинності.

Якщо результат показує, що сайт добре ранжується в Google, але майже не зʼявляється в ChatGPT і Perplexity, я не починаю з переписування всього контенту «під LLM». Спочатку перевіряю, чи взагалі доступні потрібні сторінки відповідним роботам. Потім дивлюся, які типи документів цитують конкуренти: первинні джерела, огляди, категорії, довідники, форуми, відео. Лише після цього ставлю контентну гіпотезу.

Якщо навпаки: сайт часто цитують у AI, але переходів майже немає, проблема може бути не в SEO. Можливо, сама відповідь закриває інформаційну потребу без кліку. Тоді треба оцінювати, чи є сенс зміщувати контент у бік задач, де користувачеві все одно потрібен сайт: калькулятор, персональна пропозиція, актуальна база даних, інструмент, бронювання, оформлення замовлення, детальне порівняння, власне дослідження. Саме тут видимість знову перетворюється на дію.

Ми точно знаємо з офіційної документації, що Google AI Overview та AI Mode можуть використовувати розгортання запиту і можуть показувати різні відповіді та джерела.[1] Ми знаємо, що для появи як посилання-джерела в Google AI Search сторінка має бути проіндексована й придатна для звичайного показу з фрагментом.[1] Ми знаємо, що ChatGPT Search може переписувати питання в один або кілька пошукових запитів і додавати уточнювальні пошуки.[4] Ми знаємо, що OAI-SearchBot і GPTBot мають різні функції.[5] Ми знаємо, що Perplexity має окремого пошукового бота і бота для запитів користувача.[7] Ми знаємо, що Bing уже показує цитування та запити для пошуку джерел у Webmaster Tools.[8]

Ми не знаємо з публічних джерел точних ваг сигналів відбору URL у Google AI Mode, ChatGPT Search, Perplexity або Copilot. Ми не знаємо універсального «фактора цитування». Ми не знаємо формули, яка перетворює органічну позицію в імовірність цитування. Ми не можемо з одного скріншота визначити стабільну частку видимості. І ми не маємо підстав називати будь-яку конкретну довжину абзацу, кількість списків або розмітку schema.org універсальним способом «потрапити в LLM».

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

1. Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features Офіційна документація Google про AI Overviews, AI Mode, розгортання запиту, технічну придатність та налаштування фрагментів.

2. Google. A new era for AI Search. I/O 2026. https://blog.google/products-and-platforms/products/search/search-io-2026/ Оновлення AI Mode, безшовний перехід з AI Overview, агенти та новий Search box.

3. Google. New opportunities, control and insights for website owners. https://blog.google/products-and-platforms/products/search/new-controls-website-owners/ Опубліковано 3 червня 2026, оновлено 31 серпня 2026; аудиторія AI Overviews і AI Mode.

4. OpenAI Help Center. Searching the web with ChatGPT. https://help.openai.com/en/articles/9237897 Опис веб-пошуку, citations і переписування запиту в один або кілька цільових пошуків.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код F5A5A6F6

5. OpenAI Help Center. Publishers and Developers - FAQ. https://help.openai.com/en/articles/12627856 OAI-SearchBot, GPTBot, noindex і utm_source=chatgpt.com.

6. Perplexity Help Center. How does Perplexity work?. https://www.perplexity.ai/help-center/en/articles/10352895-how-does-perplexity-work Офіційний опис real-time web search, узагальнення й citations.

7. Perplexity. Crawlers. https://docs.perplexity.ai/docs/resources/perplexity-crawlers PerplexityBot, Perplexity-User, robots.txt та IP ranges.

8. Microsoft Bing. Introducing AI Performance in Bing Webmaster Tools. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview Total Citations, Average Cited Pages, grounding queries та page-level citation activity.

9. Ahrefs. Are AI Mode and AI Overviews Just Different Versions of the Same Answer?. https://ahrefs.com/blog/ai-overviews-vs-ai-mode/ 730 тис. пар відповідей; citation overlap, semantic similarity та entity overlap.

10. Ahrefs. Update: 38% of AI Overview Citations Pull From the Top 10. https://ahrefs.com/blog/ai-overview-citations-top-10/ 863 тис. SERP і близько 4 млн AI Overview URLs, березень 2026.

11. Ahrefs. Only 12% of AI Cited URLs Rank in Google’s Top 10 for the Original Prompt. https://ahrefs.com/blog/ai-search-overlap/ 15 тис. запитів; ChatGPT, Gemini, Copilot і Perplexity, серпень 2025.

12. Ahrefs. AI Overviews Change Every 2 Days. https://ahrefs.com/blog/ai-overview-change/ Понад 43 тис. запитів; волатильність відповідей, citations та entities, листопад 2025.

ЧАСТИНА I / ПОШУК У 2026

ГЛАВА 3

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

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 6C85ACEE

Саме тому я не використовую формулу «AI забрав X% органічного трафіку», якщо немає контрольованого дизайну дослідження. У більшості реальних даних одночасно змінюються тип запиту, склад SERP, частота AI Overview, реклама, намір запиту, пристрій і поведінка користувачів. Ми можемо виміряти асоціацію і напрямок. Значно важче довести, яка частина втрати спричинена саме одним елементом.

Рис. 3.1. Частка пошуків без кліку зростала ще до масового запуску AI Overviews. Різні роки спираються на різні панелі поведінкових даних, тому графік не можна читати як ідеально зіставний часовий ряд.

У SEO zero-click часто вживають так, ніби це одна універсальна метрика. Насправді під цим словом можуть ховатися щонайменше пʼять різних подій. Якщо їх змішати, два дослідження з однаковою цифрою можуть вимірювати різні речі.

Таблиця 3.1. «Zero-click» треба визначати до того, як команда почне порівнювати цифри між джерелами.

SparkToro у 2026 році визначав zero-click як пошук, після якого не було жодного кліку по результатах. Сюди входять два сценарії: користувач завершує сесію або запускає новий пошук через стандартне поле Google. Клік по YouTube, Maps, рекламі або органічному URL уже виводить пошук із zero-click категорії.[1]

Pew Research Center використовував іншу поведінкову схему. Для кожної відвіданої сторінки Google вони дивилися наступну URL-подію: клік по звичайному результату, клік по AI-підсумку, новий пошук, перехід кудись іще або завершення браузерної сесії. Тому їхні 8%, 15% чи 26% не можна напряму підставляти в ту саму формулу, що й 68.01% SparkToro.[4]

Для США у січні-квітні 2026 року SparkToro та Similarweb отримали доволі наочну картину. Приблизно 32% пошуків завершилися хоча б одним кліком. Близько 39% завершили саму сесію, ще близько 29% привели до нового пошуку. Разом ці дві останні групи дають близько 68% пошуків без кліку.[1]

Рис. 3.2. Розподіл дій після Google-пошуку у США. Усередині групи кліків SparkToro окремо показує відкритий веб, ресурси Alphabet і рекламу.

Тут є важлива деталь, яку зазвичай пропускають у заголовках. «Є клік» не означає «є органічний клік на зовнішній сайт». За даними SparkToro, серед кліків у цій панелі 66.61% припадали на органічні результати відкритого вебу, 27.38% - на ресурси Alphabet, а 6.01% - на платну рекламу. У підсумку на 1 000 Google-пошуків у США дослідження оцінює близько 231-232 кліків до відкритого вебу залежно від округлення в окремих таблицях і візуалізаціях.[1][2]

Для SEO Lead це практично корисніше, ніж сама цифра 68%. Макроринок органічного кліку треба мислити не як «1000 пошуків = 1000 можливостей», а як послідовність втрат між попитом і зовнішнім переходом. Частина запитів закривається одразу. Частина веде у власні продукти Google. Частина монетизується рекламою. І тільки після цього починається конкуренція між органічними URL.

Ще одна причина не використовувати одну глобальну норму CTR - помітна різниця між країнами. У червні 2026 року SparkToro опублікував зіставний зріз Similarweb для шести ринків за той самий період. Частка пошуків без кліку коливалась від 62.1% у Німеччині до 69.5% у Великій Британії.[2]

Рис. 3.3. Частка Google-пошуків без кліку в шести країнах за даними однієї панелі Similarweb.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код BEB399D0

Таблиця 3.2. Один і той самий Google дає різну економіку кліку залежно від ринку. Джерело: SparkToro + Similarweb, січень-квітень 2026.

Різниця між Німеччиною та Великою Британією становить 7.4 процентного пункту zero-click. Ще важливіше, у Німеччині дослідження нараховує 287 кліків до відкритого вебу на 1 000 пошуків, а у США - 231. Це приблизно на 24% більше кліків до відкритого вебу на однаковий обсяг пошуків. Причину з цих даних довести не можна. SparkToro припускає вплив регуляції, культури, мови та відмінностей інтерфейсу, але прямо маркує це як можливі пояснення, а не встановлену причинність.[2]

Найсильніші незалежні дані тут дають два різні типи досліджень. Pew спостерігав реальну поведінку користувачів. Ahrefs порівнював CTR великої вибірки ключових слів з AI Overview та без нього. Обидва підходи показують той самий напрямок, але відповідають на різні питання.

Pew Research Center проаналізував браузерну активність 900 дорослих у США. У вибірці було 68 879 унікальних Google-пошуків у березні 2025 року; 12 593 з них мали AI-підсумок у результатах, коли Pew повторно збирав SERP у квітні. На сторінках з AI-підсумком користувачі переходили по звичайному результату у 8% відвідувань. Без AI-підсумку - у 15%. По посиланню всередині самого AI-підсумку клікали приблизно в 1% відвідувань. Завершення браузерної сесії після сторінки з AI-підсумком траплялося у 26% випадків проти 16% без нього.[4]

Рис. 3.4. Поведінка користувачів у дослідженні Pew. Це спостереження, а не рандомізований експеримент.

Ahrefs у лютому 2026 року повторив своє CTR-дослідження на 300 000 ключових словах: 150 000 із AI Overview та 150 000 інформаційних без нього. Вони використали агреговані дані Google Search Console і порівнювали грудень 2023 року з груднем 2025 року. Після нормалізації загального падіння CTR присутність AI Overview корелювала приблизно з 58% нижчим середнім CTR сторінки на позиції 1.[5]

Таблиця 3.3. Три джерела не суперечать одне одному автоматично: вони вимірюють різні рівні системи.

З цього не можна чесно зробити висновок «AI Overview забирає рівно 58% трафіку». Ahrefs вимірює середню асоціацію на конкретній вибірці, а не універсальний коефіцієнт для будь-якого запиту. Pew також не рандомізував AI-підсумок між однаковими пошуками. І це важливо: Google частіше показує AI-відповіді на довших, питальних та інформаційних запитах, які самі по собі можуть мати нижчу схильність до кліку.[4]

У серпні 2025 року Google публічно заявив, що загальний обсяг органічних кліків із Search на сайти був «відносно стабільним» рік до року, а кількість так званих якісних кліків трохи зросла. Під якісним кліком Google має на увазі перехід, після якого користувач не повертається одразу назад у видачу. Компанія також стверджує, що AI Overviews стимулюють більше пошуків і показують більше посилань.[6]

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

Google повідомляв, що у великих ринках AI Overviews підвищували використання Search більш ніж на 10% для типів запитів, на яких вони зʼявляються.[7] Це показник використання, а не зовнішніх кліків. Тому речення «користувачі шукають більше» і «окремий результат отримує менший CTR» можуть бути правдивими одночасно.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 34693B17

Для бізнесу клік сам по собі ніколи не був кінцевою метрикою. Важливий результат після кліку. Zero-click робить це особливо помітним: якщо перехід стає рідшим, треба дивитися не тільки на CTR, а й на конверсію, дохід на сесію, маржу, повторні візити й асоційовані конверсії.

Рис. 3.5. Авторська модель економіки органічного показу. Позиція впливає на один етап, але фінальна бізнес-цінність утворюється добутком кількох імовірностей.

Практично я дивлюся на органічний показ як на актив із очікуваною цінністю. У найпростішій формі: цінність одного показу = CTR × коефіцієнт конверсії × цінність однієї конверсії. Формула не є моделлю Google. Це модель бізнес-економіки. Якщо CTR падає на 30%, але конверсія переходу зростає на 50%, фінальний дохід може поводитися зовсім не так, як графік кліків.

Є перші дані, що частина переходів із AI-джерел справді має вищий намір. Adobe Digital Insights на даних роздрібної торгівлі США повідомляв, що переходи з AI-джерел у березні 2026 року конвертували на 42% краще за переходи з інших джерел, у травні - на 54% краще, у липні - на 60% краще. Це не органічний трафік Google і не доказ того, що будь-який AI-клік кращий. Але це сильний приклад того, чому обсяг і якість переходу треба вимірювати окремо.[9][10]

Рис. 3.6. За даними Adobe, переходи з AI-джерел на сайти роздрібної торгівлі США у 2026 році конвертували краще за інші переходи. Це окремий канал і його не можна напряму прирівнювати до Google AI Overview.

Similarweb оцінював середній обсяг переходів з AI-джерел приблизно у 770.7 млн візитів на місяць у світі за червень 2025 - травень 2026, +117.4% рік до року. При цьому для більшості сайтів переходи з AI-джерел усе ще лишалися низькою однозначною часткою загального трафіку.[8] Це хороша ілюстрація нової ситуації: канал може бути малим у абсолюті, швидко рости і водночас мати непропорційний вплив на рішення користувача.

На реальному сайті я не починаю діагностику з питання «чи зʼявився AI Overview». Починаю з базових сигналів. Кліки впали - що сталося з показами? Якщо покази теж впали, причина часто ближча до попиту, сезонності, втрати запитів або індексації. Якщо покази стабільні, дивлюся позиції. Якщо позиції погіршились, це вже задача ранжування. І тільки коли покази та позиції відносно стабільні, а CTR помітно просідає, я серйозно дивлюся на зміну SERP.

Рис. 3.7. Мінімальний порядок діагностики падіння кліків. Він не доводить причинність, але сильно зменшує ризик лікувати не ту проблему.

Таблиця 3.4. Падіння кліків не є діагнозом. Це симптом, який треба розкласти на попит, ранжування, SERP і якість трафіку.

У звичайному звіті «Ефективність» Google Search Console ми маємо кліки, покази, CTR і середню позицію. Google визначає CTR просто як кліки / покази, а середню позицію - як середню найвищу позицію результату сайту або URL залежно від агрегації.[12] Цього достатньо, щоб знайти сторінки й запити, де віддача кліків падає без явної втрати видимості.

З 31 серпня 2026 року Google розгорнув для всіх сайтів окремий звіт про ефективність генеративного AI. Він показує покази в AI Overviews та AI Mode, дозволяє групувати їх за сторінками, країнами, датами й пристроями. Але окремих кліків, CTR, позиції та виміру запитів у цьому звіті немає.[11] Тому ми можемо бачити, що сторінка отримує AI-видимість, але не можемо напряму з GSC порахувати «CTR AI Overview» або визначити точний запит.

Ще одне операційне обмеження: станом на вересень 2026 року звіт про генеративний AI експортується через кнопку «Експорт», але не входить у стандартний Search Console API або масовий експорт до BigQuery. Для звичайного звіту ефективності BigQuery доступний і залишається найзручнішим способом великого порівняння CTR, позицій і показів.[11][13]

Для великого сайту я починаю з URL, де покази не впали суттєво, середня позиція не погіршилась суттєво, але CTR і кліки просіли. Це не доводить вплив AI Overview. Це просто короткий список сторінок, де є сенс вручну перевірити SERP і звіт про генеративний AI.

БЕЗ КОДУ: ПРОМПТ ДЛЯ ШІ Я завантажу два CSV з Google Search Console за два сусідні 28-денні періоди на рівні сторінок. Перевір назви колонок і не вигадуй відсутні дані. Зістав URL між періодами, порахуй зміну показів, кліків, CTR і середньої позиції. Виведи URL, де в обох періодах щонайменше 1000 показів, покази змінились не більше ніж на 10%, позиція не більше ніж на 0,5, а CTR впав щонайменше на 20%. Відсортуй за найбільшим падінням кліків і поясни, що це лише кандидати на ручну перевірку SERP, а не доказ впливу AI. АЛЬТЕРНАТИВА БЕЗ ШІ У Google Sheets/Excel зведіть два експорти через XLOOKUP або Power Query, порахуйте відносну зміну показів, кліків і CTR та абсолютну зміну позиції, а потім застосуйте ті самі фільтри. Для повного масового експорту без ліміту рядків SQL лишається надійнішим.

QR: КОД Скануйте камерою: QR містить компактну виконувану версію коду без коментарів. Коментований код наведено нижче.

ДЛЯ АВТОМАТИЗАЦІЇ: SQL ДЛЯ BIGQUERY

КОД 3.1. Запит використовує офіційну схему масового експорту Search Console. Порогові значення 10%, 0.5 позиції та -20% CTR є робочими фільтрами для первинної діагностики, а не універсальними стандартами.

У цьому SQL принципово важливі дві речі. По-перше, середня позиція для URL рахується через SUM(sum_position) / SUM(impressions) + 1, як описує Google. По-друге, дані обовʼязково агрегуються через SUM, бо Google прямо попереджає, що рядки масового експорту не гарантовано консолідовані за датою, URL чи запитом.[13]

Далі я беру 20-50 URL із найбільшим падінням CTR і вже вручну дивлюся SERP, історію елементів SERP у сторонньому інструменті, AI-покази, розподіл за пристроями та структуру запитів. Сам SQL не каже «винен AI». Він прибирає тисячі сторінок, де причина очевидно інша.

Для видавця zero-click часто напряму бʼє по монетизації, бо бізнес заробляє на переглядах сторінок, рекламі або підписці після відвідування. Для інтернет-магазину ситуація інша: користувач може отримати коротке порівняння у пошуку Google, але для покупки все одно має перейти на сайт або маркетплейс. Для локального бізнесу частина цінної дії взагалі відбувається в Google: дзвінок, маршрут, бронювання. Для партнерського сайту цінність особливо залежить від типу сторінки: інформаційна відповідь може повністю закритися в SERP, а порівняльний або бонусний намір усе ще потребує переходу, якщо користувач хоче перевірити умови чи виконати транзакцію.

Таблиця 3.5. Однакова втрата органічних кліків має різну економічну вагу залежно від того, де фактично відбувається цінна дія.

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

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 90D63E16

Цей аудит потрібен не для фінального висновку, а для первинної діагностики. За годину я хочу зрозуміти, в який бік копати: попит, позиції, SERP або якість трафіку. Якщо команда після цього все ще не може сформулювати гіпотезу одним реченням, даних недостатньо.

Таблиця 3.6. Швидкий аудит zero-click / стискання CTR. Його мета - сформувати перевірювану гіпотезу, а не знайти винного за одну годину.

Ми точно знаємо, що пошуки без кліку становлять більшість Google-пошуків у великих дослідженнях поведінки користувачів 2024-2026 років, хоча точний відсоток залежить від панелі, країни й методології.[1][2][3] Ми точно знаємо, що в дослідженні Pew користувачі рідше клікали по звичайних результатах, коли на сторінці був AI-підсумок, і майже не клікали по джерелах усередині AI-підсумку.[4] Ми знаємо, що Ahrefs на великій вибірці отримав сильну негативну асоціацію між AI Overview та CTR сторінок на найвищих позиціях.[5]

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

Ми не знаємо універсального «штрафу CTR від AI» для будь-якого URL. Не знаємо, скільки втрачених прямих кліків повертається потім через бренд, прямий захід або інший канал. Не можемо з GSC напряму порахувати CTR AI Overview у 2026 році, бо окремий звіт про генеративний AI показує покази, але не дає окремих кліків і запитів.[11]

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

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

1. SparkToro. In 2026, Less than One Third of Google Searches Still Send a Click. https://sparktoro.com/blog/in-2026-less-than-one-third-of-google-searches-still-send-a-click/ Панель Similarweb для мобільних пристроїв і комп’ютерів, США, січень-квітень 2026; 68.01% пошуків без кліку; методологія та обмеження.

2. SparkToro. Zero-Click Searches: Highest in the UK, Lowest in Germany, and France has the Most Efficient Searchers. https://sparktoro.com/blog/zero-click-searches-highest-in-the-uk-lowest-in-germany-and-france-has-the-most-efficient-searchers/ Порівняння шести країн на даних Similarweb, включно з часткою пошуків без кліку та кліками до відкритого вебу на 1 000 пошуків.

3. SparkToro. 2024 Zero-Click Search Study. https://sparktoro.com/blog/2024-zero-click-search-study-for-every-1000-us-google-searches-only-374-clicks-go-to-the-open-web-in-the-eu-its-360/ Панель поведінкових даних Datos; США та ЄС; 2024. Використовується для історичного контексту із застереженням про різні панелі.

4. Pew Research Center. Google users are less likely to click on links when an AI summary appears in the results. https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/ 900 дорослих у США, 68 879 унікальних Google-пошуків; поведінка після SERP з AI-підсумком і без нього.

5. Ahrefs. Update: AI Overviews Reduce Clicks by 58%. https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/ 300 000 ключових слів; GSC; порівняння CTR для SERP з AI Overview та без нього.

6. Google. AI in Search is driving more queries and higher quality clicks. https://blog.google/products-and-platforms/products/search/ai-search-driving-more-queries-higher-quality-clicks/ Офіційна позиція Google щодо сукупних органічних кліків та їхньої якості. Внутрішні дані Google без опублікованого сирого набору даних.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 31D2DF1E

7. Google. AI in Search: Going beyond information to intelligence / AI Overviews expansion. https://blog.google/products-and-platforms/products/search/google-search-ai-mode-update/ Заява Google про понад 10% зростання використання для типів запитів, де показуються AI Overviews.

8. Similarweb. AI Referral Traffic by Industry: What 770 Million Monthly Visits Reveal. https://aisearch.similarweb.com/blog/ai-referral-traffic-by-industry/ 770.7 млн середніх щомісячних переходів з AI-джерел, червень 2025 - травень 2026; +117.4% рік до року.

9. Adobe. AI traffic grows but retail sites lag in AI search visibility. https://business.adobe.com/uk/blog/ai-traffic-surge-retail-sites-not-machine-readable Березень 2026: переходи з AI-джерел на роздрібні сайти США конвертували на 42% краще за інші переходи.

10. Adobe. How AI is reshaping travel planning / retail update. https://business.adobe.com/blog/us-consumers-are-embracing-llms-to-make-travel-plans Липень 2026: переходи з AI-джерел на роздрібні сайти США конвертували на 60% краще; показники взаємодії та відмов.

11. Google Search Console Help. Generative AI performance report (Search). https://support.google.com/webmasters/answer/16984139?hl=en Окремі покази генеративного AI для AI Overviews та AI Mode; виміри, обмеження, експорт.

12. Google Search Console Help. What are impressions, position, and clicks? https://support.google.com/webmasters/answer/7042828?hl=en Офіційні визначення показів, кліків, CTR та позиції.

13. Google Search Console Help. Query guidelines and sample queries / Table guidelines and reference. https://support.google.com/webmasters/answer/12917174?hl=en Офіційна схема масового експорту до BigQuery, агрегація, SUM(impressions), SUM(clicks), sum_position і приклади SQL.

ЧАСТИНА I / ПОШУК У 2026

ГЛАВА 4

Класична органічна аналітика була відносно зручною, бо основні події формували зрозумілий ланцюг: показ у SERP -> клік -> сесія -> конверсія. Навіть тут були проблеми з агрегацією, атрибуцією і різницею між Search Console та аналітикою сайту, але принаймні самі події були зрозумілими.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код D27AEECA

Генеративний пошук додає кілька подій до кліку. Сторінка може зʼявитися в AI Overview. Бренд може бути названий у тексті без посилання. URL може бути процитований як джерело. Документ може бути знайдений системою, але не отримати видиме цитування. Після відповіді користувач може не клікнути взагалі, а через день виконати брендовий запит. Усі ці сценарії мають різний економічний зміст.

Таблиця 4.1. Найпоширеніша помилка - надавати одній події значення іншої.

У 2026 році найбезпечніша архітектура вимірювання - не шукати один сервіс, який «міряє AI», а зшивати кілька шарів даних. Пошукова система бачить власні покази та частину взаємодій. Вебаналітика бачить реальні переходи після кліку. CRM бачить продаж або лід. Стороння система моніторингу бачить лише той набір промптів і відповідей, які сам перевірив.

Рис. 4.2. Джерела даних бачать різні частини воронки. Матриця показує нативну доступність сигналу, а не загальну «якість» інструмента.

Google: офіційна документація Search Console. Bing: офіційний опис звіту AI Performance. ChatGPT: офіційне UTM-маркування переходів. Стороння система моніторингу: вибіркова перевірка промптів, а не доступ до приватних сесій користувачів.

Це принципова межа. Сторонній інструмент не має доступу до всіх приватних діалогів ChatGPT, Gemini або Perplexity. Ahrefs прямо описує Brand Radar як вибірковий підхід: сервіс запускає великі набори промптів і записує відповіді, але не бачить кожну реальну згадку бренду в усіх користувацьких сесіях.[6] Саме тому «AI-видимість» стороннього сервісу - це індекс або структурована вибірка, а не перепис населення.

І навпаки, Google Search Console має дані самої платформи про Google, але не показує ChatGPT, Copilot чи Perplexity. Bing Webmaster Tools показує власну екосистему і частину партнерських інтеграцій, але не є глобальним AI-аналітичним центром. GA4 побачить клік із ChatGPT, але не побачить десять відповідей ChatGPT, у яких ваш бренд згадали без переходу.

3 червня 2026 року Google анонсував окремі звіти про генеративний AI у Пошуку, а 31 серпня повідомив про глобальне розгортання для всіх сайтів. Окремий звіт включає AI Overviews та AI Mode і показує саме покази - скільки разів посилання на сайт були показані користувачу в генеративній функції Пошуку Google.[1][2]

У звіті доступні сторінки, країни, дати та пристрої. Дані по сторінках переважно привʼязані до канонічного URL. Графік агрегується на рівні ресурсу, а таблиця змінює агрегацію залежно від вибраного виміру. На звіт також поширюється стандартне обмеження таблиці Search Console у 1 000 рядків.[2]

Рис. 4.3. Що дає окремий звіт Google Search Console про генеративний AI станом на 12.09.2026.

Схематичне відтворення. Джерело функціональності: Google Search Console Help, Generative AI performance report (Search).

Найважливіше тут не те, що Google нарешті показує AI-покази. Найважливіше - чого окремий звіт не показує. Станом на дату зрізу в ньому немає окремих кліків, CTR, середньої позиції та виміру запитів. Тобто ми можемо побачити, що /guide/seo-audit/ отримує генеративні покази, але не можемо з цього звіту відповісти, які саме запити дали ці покази і скільки переходів прийшло саме з AI Overview або AI Mode.[2]

При цьому AI Overviews та AI Mode входять у звичайний звіт «Ефективність». Google окремо описує, що клік по зовнішньому посиланню в AI Mode або AI Overview рахується як клік, а покази та позиція підпорядковуються стандартним правилам Search Console. Для AI Overview всі посилання в блоці отримують одну позицію самого блоку; уточнювальне питання в AI Mode рахується як новий запит.[3] Це важливо, бо загальні кліки й покази вже містять AI-події, але окремий генеративний звіт дає лише виділений зріз показів.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 8BEE2BD5

З окремого звіту Google вже можна побудувати просту операційну метрику: частку генеративних показів серед усіх показів вебпошуку для того самого ресурсу, періоду, країни і пристрою. Я називаю її часткою генеративної експозиції, а не «часткою AI-запитів».

Формула 4.1. Це відношення показів вашого ресурсу, а не оцінка частки всіх запитів Google.

Наприклад, якщо генеративні покази ростуть, а загальні покази стабільні, це означає, що більша частина вашої видимості відбувається всередині генеративних функцій Google. Це ще не говорить, добре це чи погано. Далі треба дивитися CTR у звичайному звіті «Ефективність», сторінки, країни, пристрої та бізнес-результат. Але вже можна побачити структурний зсув у типі видимості.

10 лютого 2026 року Microsoft відкрив публічну тестову версію звіту AI Performance у Bing Webmaster Tools. За офіційним описом звіт охоплює Microsoft Copilot, AI-підсумки у Bing та частину партнерських інтеграцій. На відміну від Google, Bing у цьому звіті концентрується не на показах, а на активності цитувань.[4]

Рис. 4.4. Набір даних Bing AI Performance принципово інший: цитування URL та запити, які використовувалися для пошуку джерел.

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

Показник «Загальні цитування» (Total Citations) показує кількість цитувань сайту як джерела в AI-відповідях. «Середня кількість цитованих сторінок» (Average Cited Pages) - середню кількість унікальних сторінок сайту, що цитувалися за день. «Активність цитувань на рівні сторінок» (Page-level citation activity) розкладає кількість цитувань по URL. «Запити для пошуку джерел» (Grounding queries) показують ключові фрази, які AI використовував при отриманні контенту, що потім був процитований.[4]

Остання метрика особливо корисна, але її легко переоцінити. Microsoft прямо пише, що дані «Запитів для пошуку джерел» у звіті є вибіркою загальної активності цитувань, тобто вибіркою, а не повним журналом усіх внутрішніх запитів системи. Так само Показник Total Citations не показує місце або спосіб показу цитування усередині конкретної відповіді, а Average Cited Pages не є оцінкою авторитету чи ранжування.[4]

Для ChatGPT ситуація дзеркальна. OpenAI не надає вебмайстру Search Console з усіма показами або згадками. Але для переходів є дуже чистий сигнал: OpenAI офіційно вказує, що ChatGPT автоматично додає до вихідних URL параметр utm_source=chatgpt.com. Видавець може відстежувати ці переходи у Google Analytics або іншій аналітиці.[5]

Це означає, що сесія з ChatGPT є значно твердішим фактом, ніж «оцінена видимість у ChatGPT» стороннього сервісу. Ми знаємо, що людина натиснула посилання і прийшла. Далі можна порівнювати посадкові сторінки, залучені сесії, CVR, дохід, якість лідів і повторні візити. Але й тут UTM не показує, скільки разів бренд був згаданий без кліку або скільки відповідей ChatGPT містили цитування, яку користувач не відкрив.

БЕЗ КОДУ: ПРОМПТ ДЛЯ ШІ Я завантажу CSV з GA4, де є дата, landing page + query string, sessions і, якщо доступно, key events або revenue. Перевір колонки. Відфільтруй посадкові URL, які містять utm_source=chatgpt.com, порахуй сесії за датою і посадковою сторінкою, а також конверсії та дохід, якщо ці поля є. Не прирівнюй цей трафік до всіх згадок бренду в ChatGPT: це лише зафіксовані переходи. АЛЬТЕРНАТИВА БЕЗ ШІ © 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код FA175FE9 У GA4 Explorations додайте вимір Landing page + query string, метрики Sessions та Key events і фільтр contains "utm_source=chatgpt.com". Для регулярної автоматизації використовуйте BigQuery-запит нижче.

QR: КОД Скануйте камерою: QR містить компактну виконувану версію коду без коментарів. Коментований код наведено нижче.

ДЛЯ АВТОМАТИЗАЦІЇ: SQL ДЛЯ GA4 BIGQUERY

Код 4.1. Мінімальний спосіб виділити переходи ChatGPT за офіційним UTM. Для робочого звіту я б далі дедуплікував першу подію на посадковій сторінці і приєднав конверсії та дохід на рівні ідентифікатора сесії.

На рівні стороннього моніторингу я завжди розділяю згадку і цитування. Згадка означає, що бренд присутній у тексті AI-відповіді. Цитування означає, що домен або конкретна сторінка показані як джерело. Ahrefs саме так розділяє свої метрики: одна згадка рахується, якщо бренд зʼявився хоча б раз у відповіді, а одне цитування - якщо сторінка або домен були процитовані хоча б раз.[7]

Це дає чотири практично різні сценарії. Бренд може бути згаданий і процитований. Може бути згаданий без цитування, наприклад як відомий продукт. Сайт може бути процитований без явної згадки бренду в основному тексті. А може не зʼявитися взагалі. Якщо звести все до одного індексу, ми втрачаємо діагноз.

Таблиця 4.2. Згадка і цитування відповідають на різні питання. Відсутність цитування не завжди означає відсутність брендової видимості.

Стороння система моніторингу потрібен там, де сама платформа не дає достатньо даних. Він може стабільно перевіряти однаковий набір промптів, фіксувати відповіді, цитування, згадки, конкурентів і джерела. Для аналізу динаміки це дуже корисно. Проблема починається, коли отриманий індекс називають «реальною часткою присутності серед усіх користувачів ChatGPT».

Ahrefs станом на серпень 2026 року заявляє 459+ млн промптів у шести AI-індексах. Найбільший сегмент - AI Overviews, 308.6 млн; окремі індекси Gemini, Perplexity, ChatGPT і Copilot мають близько 31 млн промптів, AI Mode - 25.3 млн.[8] Це дуже велика вибірка, але вона все одно є побудованим індексом, а не приватними журналами реального використання платформ.

Рис. 4.5. Кількість промптів у шести індексах Ahrefs AI Visibility Index станом на серпень 2026 року. Дані самого Ahrefs.

Ahrefs моделює промпти з реального пошукового попиту та People Also Ask. Великий розмір вибірки не перетворює її на повний лог усіх взаємодій користувачів із LLM.

Ще важливіше читати визначення метрик. Метрика Ahrefs Estimated Impressions («оцінені покази») - це не реальні покази самої платформи ChatGPT. Сервіс оцінює їх через частотність пошуку повʼязаних запитів Google / People Also Ask; частка голосу в AI - відносна частка цих оцінених показів серед відстежуваних брендів.[7] Semrush використовує іншу систему: AI Visibility як порівняльний індекс 0-100, згадки, оцінку місячної аудиторії, цитування та інші власні метрики.[9] Тому число 37 у одному сервісі не можна порівнювати з 37 в іншому.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 3415EDF7

Таблиця 4.3. Власні метрики мають бути відтворюваними. Назва без знаменника створює красиву, але слабку аналітику.

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

Тому для власного моніторингу я фіксую принаймні пʼять речей: точний текст промпту або його стабільний ідентифікатор, платформу і модель, країну або мову, дату перевірки та список конкурентів. Якщо сервіс дозволяє щоденний моніторинг власних промптів, історію не можна змішувати з готовий індекс без окремої мітки. Це різні вибірки.

Не всі дані однаково близькі до грошей. Якщо CRM показує 120 оплачуваних контрактів, це сильніший бізнес-факт, ніж 18 000 оцінених AI-показів стороннього сервісу. Це не означає, що покази не потрібні. Вони потрібні для ранньої діагностики. Але управляти бюджетом лише верхнім шаром небезпечно.

Рис. 4.6. Ієрархія доказової ваги для SEO-звітності. Верхні рівні ближчі до фактичного бізнес-результату; нижні корисні для напрямку та діагностики.

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

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

Рис. 4.7. Один із можливих шляхів впливу без кліку. Без додаткового дизайну вимірювання він правдоподібний, але не доведений.

Що можна зробити практично. Перше - дивитися попит на брендові запити у Search Console і тренд прямого та брендового органічного трафіку поруч зі змінами AI-видимістю, але трактувати це як кореляцію. Друге - використовувати контрольні ринки, GEO або часові вікна, якщо бізнес дозволяє природний експеримент. Третє - для генерації лідів питати джерело знайомства в CRM або формі, але не змушувати користувача вибирати лише один канал. Четверте - дивитися асоційовані конверсії і дані шляхів, розуміючи, що видимість без кліку до сайту там усе одно не зʼявиться.

Якщо після росту AI-згадок брендові запити виросли на 20%, це ще не доказ, що одне спричинило інше. Можливо, одночасно була PR-кампанія, реклама, сезонність або реліз продукту. У книзі я навмисно не перетворюю цю красиву історію на причинний факт без контролю.

Моя базова звітна панель тепер має не один графік «Органічний трафік», а щонайменше чотири шари. Перший - попит і класичний Пошук. Другий - генеративна видимість у джерелах самої платформи. Третій - вибіркова присутність у сторонніх AI-платформах. Четвертий - реальні сесії та бізнес-результат.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 14512BF5

Таблиця 4.4. Мінімальна система вимірювання. Не кожному бізнесу потрібні всі рядки, але кожен KPI має мати зрозуміле джерело і власника.

Ключове правило порівнянь: однакова гранулярність. Не порівнюйте щоденний моніторинг власних промптів із місячним індексом. Не порівнюйте генеративні покази на рівні URL з загальним показником на рівні ресурсу без перевірки агрегації. Не змішуйте США з глобальними даними. Не робіть висновок по одному дню, якщо платформа й модель мають високу варіативність відповіді.

Таблиця 4.5. Більшість помилок AI-аналітики - не в даних, а в неправильному знаменнику або змішуванні одиниць виміру.

Якщо я сам задаю набір промптів для моніторингу, я не починаю з питання «які фрази змусити AI сказати наш бренд». Це створює самопідтверджувальний орієнтир. Починаю з реального простору запитів: Search Console, розмов із відділом продажів, звернень у підтримку, People Also Ask, внутрішній пошук, запити до продукту, конкурентні порівняння. Далі групую промпти за задачею користувача, а не за тим, де бренд уже перемагає.

Таблиця 4.6. Основний набір промптів має представляти реальні задачі користувача, а не лише запити, зручні для бренду.

Я тримаю основний набір стабільним для тренду. Нові промпти йдуть у дослідницький набір і не впливають на основний часовий ряд, доки не зафіксована нова база. Це простий спосіб не намалювати ріст або падіння тільки тому, що змінилися питання.

Таблиця 4.7. Частота вимірювання має відповідати швидкості зміни сигналу. Щоденний шум не повинен керувати квартальним бюджетом.

Станом на 12 вересня 2026 року ми точно можемо виміряти окремі генеративні покази у Google Search Console для AI Overviews та AI Mode.[1][2] Ми можемо отримати дані про цитування і вибірку запитів для пошуку джерел у Bing Webmaster Tools.[4] Ми можемо надійно виділяти переходи з ChatGPT, оскільки OpenAI автоматично додає utm_source=chatgpt.com.[5] Ми можемо запускати стабільний набір промптів у сторонніх трекерах і рахувати згадки й цитування та конкурентну присутність, якщо памʼятаємо, що це вибірка.[6][7]

Ми не маємо універсального лічильника від самої платформи всіх згадок бренду в усіх приватних сесіях LLM. Не маємо одного стандарту частки голосу в AI між різними сервісами. Не можемо з окремого GSC звіту про генеративний AI порахувати точний CTR генеративних функцій, бо звіт не містить окремих кліків. Не можемо довести, що зростання брендового пошуку після росту AI-згадок спричинене саме AI, якщо немає контрольного дизайну.

Тому правильна звітність у 2026 році не намагається приховати прогалини. Вона показує їх. Для мене сильна звітна панель - це не той, де є одна магічна цифра. Це той, де видно, які події виміряні даними самої платформи, які відновлені через власну аналітику, які отримані на вибірці і де ми маємо лише робочу гіпотезу.

На цьому Частина I закінчується. Далі переходимо від інтерфейсів і вимірювання до механіки самої пошукової системи. Почнемо з найпершого питання, яке часто пропускають: звідки пошукова система взагалі дізнається, що URL існує.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 136E313A

1. Google Search Central Blog. Introducing Search Generative AI performance reports in Search Console. https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports Анонс 3 червня 2026 року; глобальне розгортання 31 серпня; покази, сторінки, країни, пристрої, дати.

2. Google Search Console Help. Generative AI performance report (Search). https://support.google.com/webmasters/answer/16984139?hl=en AI Overviews та AI Mode; окремі генеративні покази; сторінки, країни, дати, пристрої; агрегація, 1 000 рядків, кнопка експорту.

3. Google Search Console Help. What are impressions, position, and clicks? https://support.google.com/webmasters/answer/7042828?hl=en Правила для AI Mode та AI Overviews: click, impression, position, follow-up query.

4. Microsoft Bing Webmaster Blog. Introducing AI Performance in Bing Webmaster Tools Public Preview. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview Total Citations, Average Cited Pages, grounding queries sample, page-level citation activity, trends.

5. OpenAI Help Center. Publishers and Developers FAQ. https://help.openai.com/uk-ua/articles/12627856-publishers-and-developers-faq OpenAI підтверджує автоматичне utm_source=chatgpt.com для переходів із результатів пошуку ChatGPT.

6. Ahrefs FAQ. AI-видимістю & Brand Radar. https://ahrefs.com/faq Пряме застереження: AI-видимістю monitoring є sampling-based, не real-time і не має доступу до приватних розмов або внутрішніх даних OpenAI.

7. Ahrefs Help Center. AI Visibility Metrics. https://help.ahrefs.com/en/articles/15501968-ai-visibility-metrics Визначення Згадки, Цитування, Found in, Estimated Impressions та AI Share of Voice; метод оцінювання показів через частотність пошуку Google.

8. Ahrefs. AI Visibility Index. https://ahrefs.com/ai-visibility-index 459+ млн промптів у шести індексах; кількість промптів по AI Overviews, Gemini, Perplexity, ChatGPT, Copilot та AI Mode; серпень 2026.

9. Semrush Knowledge Base. AI Visibility Metrics. https://www.semrush.com/kb/1594-ai-seo-metrics AI Visibility 0-100, Mentions, Monthly Audience, Citations, Share of Voice та інші власні метрики. Використано для демонстрації відмінностей методологій.

10. Google Search Central Community. Generative AI report data / BigQuery export. https://support.google.com/webmasters/thread/464075295/google-search-console-data-under-the-generative-ai?hl=en Станом на 1 вересня 2026 року в спільноті підтверджувалося: окремого масового експорту цього звіту в BigQuery немає; доступний Export. Це джерело зі спільноти, а не формальна продуктова документація.

ЧАСТИНА II / ЯК ПОШУКОВА СИСТЕМА БАЧИТЬ ВЕБ

ГЛАВА 5

Офіційний опис Google формулює процес досить прямо: частина сторінок уже відома з попередніх відвідувань, інші URL знаходяться через посилання на відомих сторінках, а власник сайту може передати список адрес через sitemap.[1] Після виявлення URL Googlebot може відвідати його, але це окреме рішення системи. Сам Google також не гарантує, що сторінку буде проскановано, проіндексовано або показано в результатах, навіть якщо вона відповідає технічним вимогам.[1]

Це добре видно у Search Console. Статус «Discovered - currently not indexed» означає, що Google знайшов URL, але ще не просканував його. У такому стані відсутність час останнього сканування не є загадкою: контент сторінки ще не був отриманий. Тому я ніколи не починаю діагностику такого статусу з переписування title або додавання schema. Спочатку треба зрозуміти, як URL потрапив у систему і чому не отримує наступний крок - сканування.[7]

Для практичного аудиту я розділяю джерела на пʼять груп. Чотири з них універсальні для класичного вебу: внутрішні посилання, зовнішні посилання, sitemap і вже відомі пошуковій системі адреси. Пʼята група - активні механізми повідомлення, наприклад IndexNow у Bing. Вони не скасовують граф посилань, але скорочують шлях від зміни на сайті до сигналу пошуковій системі.[10][11]

Таблиця 5.1. Канал виявлення повідомляє про існування URL. Він не дорівнює рішенню про сканування або індексацію.

У SEO внутрішні посилання часто обговорюють через розподіл PageRank або тематичні звʼязки. Але їхня перша функція простіша: вони створюють шлях, по якому краулер знаходить інші URL. Google прямо пише, що використовує посилання, зокрема, для пошуку нових сторінок для сканування.[2]

Тому «сторінка є в меню користувача» і «у HTML існує доступне для краулера посилання» - не завжди одне й те саме. Інтерфейс може виглядати як посилання, але технічно бути кнопкою, span з JavaScript-обробником або елементом, у якого URL зʼявляється тільки після взаємодії. Для Google найбезпечніший базовий варіант - HTML-елемент <a> з атрибутом href.[2]

Рис. 5.2. Візуально однакові елементи можуть мати різну цінність для виявлення URL.

Приклади синтаксису адаптовані з Google Search Central, Link best practices.

Таблиця 5.2. Для виявлення URL важлива не візуальна форма елемента, а те, що реально бачить і може розібрати краулер.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код C3966B0E

Після переходу Google на сканування з пріоритетом мобільної версії особливо небезпечна різниця між навігацією на десктопною і мобільною версіями. В офіційній документації Google прямо радить давати на мобільній версії той самий набір посилань, що й на десктопній. Якщо це неможливо, URL варто принаймні підтримати через sitemap; обмежений набір мобільних посилань може сповільнити виявлення нових сторінок.[5]

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

Google визначає sitemap як спосіб повідомити про сторінки, які є новими або оновленими. Для добре повʼязаного невеликого сайту sitemap може бути не критичним для самого виявлення: Google пише, що якщо всі важливі сторінки доступні через навігацію й внутрішні посилання, більшість сайту зазвичай можна знайти без нього. Водночас sitemap особливо корисний для великих сайтів, нових сайтів з малою кількістю зовнішніх посилань та спеціалізованого медіаконтенту.[3]

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

Рис. 5.3. Технічні межі sitemap не є лімітом індексації.

Google Search Central: до 50 000 URL або 50 MB без стиснення в одному sitemap; sitemap index може містити до 50 000 loc.[4][12]

Таблиця 5.3. Sitemap має бути чистим джерелом URL, а не складом усіх адрес, які здатен згенерувати сайт.

Google окремо пише, що використовує значення <lastmod>, якщо воно стабільно й перевірно відображає суттєву зміну сторінки. Зміна основного контенту, структурованих даних або посилань може бути суттєвою. Зміна дати copyright - ні.[4]

Тому шаблон «щодня ставити поточну дату всім URL» не прискорює систему магічно. Він знижує інформаційну цінність сигналу. Для великих сайтів я краще мати 20% URL з чесним lastmod, ніж 100% з датою, яка змінюється кожну ніч без реальної зміни сторінки.

Термін «ізольована сторінка» часто використовують занадто впевнено. Краулер Screaming Frog або будь-який інший інструмент не знає всіх шляхів, якими Google міг колись знайти URL. Якщо сторінка не має внутрішніх вхідних посилань у вашому скануванні сайту, вона може бути в sitemap, мати зовнішнє посилання, бути відомою з минулої версії сайту або вже бути в індексі.

Тому я використовую точніші класи. «Немає внутрішніх вхідних посилань» - факт нашого crawl. «Є тільки в sitemap» - факт по двох джерелах. «Не знайдено внутрішніх посилань, sitemap і запитів Googlebot за обраний період» - сильніший сигнал, але теж не доказ, що Google ніколи не знав URL. Такі формулювання роблять аудит набагато чеснішим.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 09F89CB7

Рис. 5.4. Практична класифікація URL за внутрішнім графом, sitemap і серверними логами.

Це робоча модель аудиту, а не внутрішня класифікація Google.

Таблиця 5.4. Термін «ізольована сторінка» краще замінити конкретним описом того, в яких джерелах URL є або немає.

У Search Console блок Discovery може показати sitemap і Referring page. Referring page - це сторінка, яку Google, імовірно, використав для виявлення URL. Вона може посилатися прямо або бути вищою ланкою ланцюга. Якщо поле порожнє, це не означає, що сторінки-джерела не існує. Сам Google попереджає, що інформація може бути недоступна в інструменті й URL міг бути знайдений іншим способом.[8]

Те саме видно в API URL Inspection. Поле sitemap[] містить відомі Google sitemap, де присутній URL, але документація прямо каже, що список не гарантовано вичерпний. Поле referringUrls[] повертає URL, які посилаються на перевірену адресу прямо або опосередковано.[9] Це корисно для автоматизації, але не перетворює API на повний лог discovery.

Рис. 5.5. Search Console показує окремі сигнали виявлення, а не повну історію того, звідки Google коли-небудь знав URL.

Офіційні поля: Sitemaps і Referring page; URL Inspection API: sitemap[] та referringUrls[].[8][9]

robots.txt контролює доступ краулера, а не знання про адресу. Google прямо попереджає: якщо інші сторінки посилаються на URL, заблокований у robots.txt, Google все одно може знати адресу і навіть показати її в результатах без опису, не завантажуючи сам контент.[6]

Звідси випливає важлива технічна помилка: не можна одночасно блокувати сторінку в robots.txt і очікувати, що Google гарантовано прочитає meta robots noindex у її HTML. Щоб побачити noindex, сторінку треба отримати. Те саме стосується canonical у HTML: він стає доступним лише після завантаження й обробки документа.

Рис. 5.6. robots.txt, noindex і canonical вирішують різні задачі. Жоден із них не є універсальною кнопкою «не знати цей URL».

Схема спрощує механіку для діагностики. Детальні правила індексації та канонікалізації розбираються в окремих главах.

Таблиця 5.5. Різні директиви працюють на різних етапах. Змішування виявлення URL, сканування та керування індексацією створює більшість технічних помилок.

Якщо Googlebot запитує відомий URL і отримує 301, 308, 302 або інший підтримуваний редирект, він переходить до цільової адреси. Для постійних серверних редиректів Google також використовує ціль як сильний сигнал канонічної версії.[13]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 6D6AA9DF

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

Google у публічній документації робить акцент на посиланнях, sitemap і запиті на повторне сканування через URL Inspection для невеликої кількості URL.[1][8][14] Bing, крім класичних посилань і sitemap, підтримує IndexNow - протокол активного повідомлення про додані, змінені або видалені URL.[10][11]

Bing прямо показує в IndexNow Insights надіслані URL, час подання, джерело, а для вибірки - статус сканування, статус індексації та час першої індексації. При цьому Microsoft так само застерігає: подання URL через IndexNow не гарантує сканування або індексацію.[11]

Рис. 5.7. Класичне виявлення через граф і sitemap та активне повідомлення IndexNow вирішують одну задачу різними шляхами.

Google не вказаний у книзі як учасник IndexNow. Для Google використовуються його офіційно задокументовані механізми; IndexNow тут показаний як окремий механізм Bing.

Логи дуже сильні як факт того, що конкретний агент користувача зробив HTTP-запит до конкретного URL у конкретний час. Але лог нічого не каже про те, скільки часу URL уже був відомий системі до першого запиту. Якщо Googlebot уперше звернувся 12 вересня о 03:14, це не означає, що URL був виявлений саме о 03:14.

Тому в аудиті я не використовую «перший зафіксований запит Googlebot» як синонім «дата виявлення». Це перша зафіксована нами дата сканування в наявному періоді логів. Виявлення могло відбутися раніше через sitemap, посилання або інше джерело. Search Console також може показувати referring page або sitemap, але не гарантує повноту цієї історії.[8][9]

Google не публікує універсальну норму на кшталт «95% сторінок повинні бути знайдені через внутрішні посилання». Тому я не використовую вигадані галузеву норму. Замість цього рахую власні стабільні метрики по шаблонах і дивлюся на зміну в часі.

Формула 5.1. Покриття внутрішнім графом.

Мета - не досягти магічних 100%, а знайти шаблони, де важливі URL існують тільки поза внутрішньою архітектурою.

Формула 5.2. Частка URL, які тримає тільки sitemap.

Розраховуйте окремо за типами сторінок. Один загальний відсоток може приховати проблему в конкретному шаблоні.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 75DB6176

Формула 5.3. Покриття sitemap цільовими URL.

Таблиця 5.6. Метрика повинна мати чіткий знаменник і не претендувати на те, чого джерело даних не бачить.

Я починаю не з кнопки «Запит на індексування», а з вибірки URL одного типу. Наприклад, 500 нових товарів, 300 масово згенерованих посадкових сторінок або 2 000 нових профілів. Потім накладаю чотири джерела: внутрішній crawl, sitemap, Search Console URL Inspection для вибірки та серверні логи Googlebot. Це дає значно більше інформації, ніж ручна перевірка десяти випадкових сторінок.

Таблиця 5.7. Аудит виявлення URL має рухатися від архітектури до фактичного запиту Googlebot, а не навпаки.

Нижче - не “магічний SEO-скрипт”, а мінімальна модель злиття трьох джерел. На вході потрібні три CSV: список цільових URL з кількістю внутрішніх вхідних посилань, список URL із sitemap і список URL, які запитував підтверджений Googlebot за обраний період. Назви колонок легко адаптувати під ваш експорт.

БЕЗ КОДУ: ПРОМПТ ДЛЯ ШІ Я завантажу три CSV: internal.csv з колонками url та inlinks, sitemap.csv з url і googlebot.csv з url та first_seen. Спочатку перевір структуру файлів. Побудуй повний список URL з усіх трьох джерел і для кожного визнач: чи є внутрішнє вхідне посилання, чи є URL у sitemap, чи бачив його Googlebot. Класифікуй URL за цими трьома сигналами, порахуй кількість у кожному класі й покажи по 20 найважливіших проблемних URL. АЛЬТЕРНАТИВА БЕЗ ШІ У Sheets/Excel створіть master-список URL і три колонки-прапорці через XLOOKUP/COUNTIF: внутрішні посилання, sitemap, логи. Потім зробіть зведену таблицю за комбінаціями TRUE/FALSE. Python потрібен лише коли обсяг або регулярність уже незручні для таблиці.

QR: КОД Скануйте камерою: QR містить компактну виконувану версію коду без коментарів. Коментований код наведено нижче.

ДЛЯ АВТОМАТИЗАЦІЇ: PYTHON ДЛЯ ЗЛИТТЯ 3 ДЖЕРЕЛ

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 858B2868

Код 5.1. Мінімальна класифікація URL за внутрішніми посиланнями, sitemap і серверними логами.

У реальній системі я додаю тип сторінки, цільовий canonical, HTTP-статус, можливість індексації, дату публікації і кілька часових полів. Тоді можна відповісти не «скільки ізольованих сторінок», а «який відсоток нових товарів категорії X через 48 годин має внутрішнє вхідне посилання, присутній у sitemap і вже отримав перший запит Googlebot». Це вже операційна метрика, яку можна порівнювати між релізами.

Найгірша реакція - масово натискати «Запит на індексування». Для великої вибірки це не усуває системну причину. Сам Google радить URL Inspection для невеликої кількості URL, а для великих наборів - sitemap. Повторний запит одного й того самого URL не змусить його скануватися швидше.[14]

Я спочатку сегментую проблему. Якщо статус має 12 URL з 50 000 - це одна історія. Якщо 70% нового шаблону через два тижні лишаються у статусі «виявлено», це інша. Далі перевіряю, чи вони доступні через нормальні внутрішні посилання, чи sitemap містить саме канонічні 200 URL, чи не створено мільйони альтернативних адрес параметрами, чи сервер стабільно віддає відповіді, і чи Googlebot взагалі доходить до цього шаблону.

Важливо не видавати пояснення з довідковий матеріал спільноти за гарантовану причину конкретного сайту. Офіційне значення статусу просте: URL знайдено, але не проскановано. Чому саме конкретна адреса довго не отримує сканування - це вже діагностика системи, а не текст одного статусу.[7]

Ми точно знаємо, що Google відокремлює виявлення URL від сканування.[1] Знаємо, що нові URL можуть бути знайдені через посилання і sitemap.[1][2][3] Знаємо, що стандартне <a href> є базовою надійною конструкцією для посилань, які Google може розібрати.[2] Знаємо жорсткі межі sitemap: 50 000 URL або 50 MB без стиснення на файл, а sitemap index може містити до 50 000 записів loc.[4][12]

Ми також знаємо, що sitemap є підказкою, а не гарантією сканування чи індексації.[4] robots.txt не є механізмом приховування самого URL з Google, якщо адресу можна знайти з інших місць.[6] URL Inspection може показувати sitemap і сторінку-джерело, але ці дані не є повним журналом усіх шляхів виявлення.[8][9] Bing окремо підтримує IndexNow як активний канал повідомлення про змінені URL, не гарантуючи при цьому індексацію.[10][11]

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

Головний практичний висновок цієї глави простий. До того як аналізувати рендеринг, canonical або якість контенту, треба довести, що потрібний URL узагалі існує для пошукової системи як адреса і має нормальний шлях до черги сканування. Наступна глава починається саме там: URL уже відомий. Тепер питання - коли, як часто і з яким пріоритетом його скануватиме Googlebot.

1. Google Search Central. In-Depth Guide to How Google Search Works. https://developers.google.com/search/docs/fundamentals/how-search-works Офіційне розділення URL discovery, crawling та indexing; посилання й sitemap як джерела нових URL.

2. Google Search Central. Link best practices for Google. https://developers.google.com/search/docs/crawling-indexing/links-crawlable Google використовує посилання для пошуку нових сторінок; <a href> як базова доступна для краулера конструкція.

3. Google Search Central. What Is a Sitemap. https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview Коли sitemap особливо корисний; Google зазвичай може знайти добре повʼязані сторінки через внутрішні посилання.

4. Google Search Central. Build and Submit a Sitemap. https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap 50 000 URL / 50 MB; абсолютні URL; sitemap як підказка; точний lastmod; Google ігнорує priority та changefreq.

5. Google Search Central. Troubleshoot Google Search Crawling Errors. https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors Поради щодо доступних для краулера посилань, мобільної версії, sitemap і логів.

6. Google Search Central. Introduction to robots.txt. https://developers.google.com/search/docs/crawling-indexing/robots/intro robots.txt керує доступом краулера, але URL може лишатися відомим і навіть зʼявитися в результатах без контенту.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код E378C549

7. Google Search Console Help. Page indexing report / Discovered - currently not indexed. https://support.google.com/webmasters/answer/7440203?hl=en Статус означає, що сторінку знайдено, але ще не проскановано.

8. Google Search Console Help. URL Inspection tool. https://support.google.com/webmasters/answer/9012289?hl=en Discovery, Sitemaps, Referring page і застереження щодо неповноти цих полів.

9. Google Search Console API. UrlInspectionResult. https://developers.google.com/webmaster-tools/v1/urlInspection.index/UrlInspectionResult Поля sitemap[] і referringUrls[]; lastCrawlTime та інші дані індексної версії URL.

10. Bing Webmaster Guidelines. https://www.bing.com/webmasters/help/webmaster-guidelines-30fba23a Bing прямо називає IndexNow, XML sitemap, внутрішні та зовнішні посилання каналами discovery.

11. Bing Webmaster Tools. IndexNow. https://www.bing.com/webmasters/help/indexnow-0z209wby Активне повідомлення про нові, змінені або видалені URL; submission не гарантує indexing.

12. Google Search Central. Manage Your Sitemaps With Sitemap Index Files. https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps До 50 000 loc у sitemap index; до 500 sitemap index files на сайт у Search Console.

13. Google Search Central. Redirects and Google Search. https://developers.google.com/search/docs/crawling-indexing/301-redirects Googlebot переходить за редиректами; постійний редирект є сигналом канонічної цілі.

14. Google Search Central. Ask Google to Recrawl Your Website. https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl URL Inspection для кількох URL, sitemap для великих наборів; повторні запити не пришвидшують crawl гарантовано.

ЧАСТИНА II / ЯК ПОШУКОВА СИСТЕМА БАЧИТЬ ВЕБ

ГЛАВА 6

Для більшості невеликих сайтів бюджет сканування не є окремою SEO-проблемою. Google прямо пише: якщо сторінок небагато, вони не змінюються дуже швидко або нові матеріали скануються того ж дня, достатньо підтримувати sitemap і регулярно перевіряти звіт Page Indexing. Окремий розширений посібник Google орієнтує насамперед на великі та дуже динамічні сайти.[1]

Офіційні орієнтири приблизні, а не жорсткі пороги: 1 млн і більше унікальних URL із помірними змінами приблизно раз на тиждень; 10 тис. і більше унікальних URL із дуже швидкими щоденними змінами; або сайти, де значна частина URL у Search Console має статус «Виявлено, але наразі не проіндексовано».[1] Сам Google окремо попереджає, що ці числа потрібні для класифікації, а не для математичного рішення “9 999 URL - проблеми немає, 10 000 - є”.

Рис. 6.2. Орієнтири Google для сайтів, де оптимізація бюджету сканування стає окремою технічною задачею.

Джерело: Google Crawling Infrastructure, 2026. Обидва пороги Google називає приблизними.

Таблиця 6.1. Бюджет сканування - не універсальна причина повільної індексації. Спочатку визначаємо, чи масштаб і динаміка сайту взагалі роблять його релевантним.

Google визначає межу спроможності сканування через навантаження на хост. Враховується не лише кількість паралельних зʼєднань, а й те, скільки часу сервер тримає їх відкритими. Якщо час відповіді та затримка стабільні або покращуються, межа може зрости. Якщо затримка або TTFB погіршуються, зʼявляються 5xx чи 429, межа знижується.[1]

Це одна з причин, чому я не використовую “запитів за секунду” як самодостатній KPI. Два сервери можуть обробляти однакові 5 запитів на секунду зовсім по-різному. Один віддає HTML за 80 мс і майже не помічає Googlebot. Інший тримає зʼєднання 2 секунди, упирається в CPU або базу і починає деградувати. Для пошукового робота це різні хости, навіть якщо число запитів однакове.

Таблиця 6.2. HTTP-відповідь впливає не лише на індексацію, а й на економіку повторного сканування.

Другий бік моделі - попит на сканування. Для Googlebot він залежить від розміру сайту, частоти оновлення, якості та релевантності сторінок відносно інших сайтів. У поточній документації Google окремо виділяє відомий інвентар URL, популярність і застарівання. Найбільш керований фактор для власника - інвентар URL: якщо система знає мільйони дублів, варіантів сортування, застарілих адрес або інших URL, які не потрібні в пошуку, частина ресурсу йде на них.[1]

Популярність тут не треба перетворювати на примітив “більше зворотних посилань = більше сканування”. Google формулює обережніше: популярні URL в інтернеті мають тенденцію скануватися частіше, щоб зберігатися свіжими. Застарівання означає, що система намагається не тримати документи застарілими. Міграція сайту або інша подія масштабу всього сайту також може тимчасово підняти попит на повторне сканування.[1]

Таблиця 6.3. Попит на сканування - це не черга, яку можна вручну розставити по позиціях. Ми керуємо інвентарем і сигналами, а не внутрішнім планувальником Google.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A01ECB3E

Звіт Crawl Stats - найкраща перша точка для швидкого макроаналізу. Він показує загальну кількість запитів сканування, завантажений обсяг, середній час відповіді, стан хоста, розподіл за HTTP-відповідями, типами файлів, метою сканування і типом Googlebot.[2] Для властивості домену можна також дивитися хости, але інтерфейс показує тільки 20 дочірніх доменів, які отримували трафік сканування за останні 90 днів.[2]

Звіт має важливе обмеження: список прикладів URL не є повним логом. Відсутність конкретного URL у прикладах не доводить, що Google його не запитував. Сам Google описує ці URL як репрезентативну вибірку. Тому Crawl Stats добре відповідає на “що відбувається з хостом у цілому”, але слабше - на “що сталося з кожним URL”.[2]

Рис. 6.3. Які зрізи дає Crawl Stats у Search Console. Значення на схемі навмисно не вигадані.

Схематичне відтворення офіційного звіту. Search Console окремо показує мету сканування: виявлення URL, який Google раніше не сканував, та оновлення - повторне сканування відомого URL.

Таблиця 6.4. Search Console дає агрегований стан системи; серверний лог потрібен для подієвого рівня.

У Crawl Stats Google розділяє мету сканування на Discovery і Refresh. Discovery означає, що URL раніше не сканувався Google. Refresh - повторний запит уже відомої сторінки.[2] Це корисне розділення для релізів. Якщо ви щойно опублікували великий набір нових сторінок або подали sitemap, логічно очікувати підйом сканування нових URL. Якщо проблема в тому, що ціни, наявність товарів або новини застарівають у видачі, дивитися треба не лише на виявлення нових URL, а й на частоту повторного сканування.

Я не ставлю KPI “Discovery має бути X% від усіх запитів”. Такий відсоток без контексту безглуздий. Для новинного сайту, каталогу після великого імпорту й зрілого енциклопедичного сайту нормальний профіль буде різним. Правильне питання - чи відповідає частота сканування бізнесовій швидкості змін конкретного типу сторінок.

Як тільки питання переходить на рівень “які саме URL Googlebot сканує, як часто й з якими статусами”, я переходжу до серверних логів. У них є те, чого немає в Search Console: конкретний час, конкретний URL, HTTP-код, обсяг відповіді, User-Agent, IP і, якщо інфраструктура логгує, час відповіді. Це дозволяє групувати запити за шаблонами, параметрами, статусами та часом.

User-Agent недостатньо для верифікації. Google прямо попереджає, що його можна підробити. Для важливого аудиту потрібно перевіряти IP через зворотний DNS-запит або зіставляти з офіційними діапазонами Googlebot.[3] У книзі далі я використовую термін “Googlebot у логах” тільки для трафіку, який уже пройшов таку перевірку.

Рис. 6.4. Робочий шлях від сирого серверного логу до SEO-рішення.

Лог без класифікації дає мільйони рядків. Цінність зʼявляється після верифікації бота, нормалізації URL і привʼязки до типів сторінок.

Таблиця 6.5. Мінімальний набір полів для аналізу сканування з серверних логів.

Універсальної “правильної частоти сканування” немає, тому я не порівнюю сайт з абстрактним галузевим відсотком. Я будую базову лінію за типами сторінок, а потім дивлюся, як вона змінюється після релізів, міграцій, перебудови фасетів або оптимізації сервера.

Формула 6.1. Частка корисного сканування.

Це внутрішня операційна метрика. “Цільовий canonical” визначається вашим інвентарем, а не зовнішнім стандартом.

Формула 6.2. Частка небажаного сканування.

До нецільових можна віднести фасети, внутрішній пошук, застарілі параметри, нескінченні календарі та інші URL, які ви свідомо не хочете підтримувати як пошукові сторінки.

Формула 6.3. Затримка першого сканування.

Рахуйте медіану та перцентилі окремо за типами сторінок. Середнє легко спотворюють поодинокі дуже довгі хвости.

Формула 6.4. Інтервал повторного сканування.

Агрегуйте за типом сторінки, а не одним числом по всьому сайту.

Таблиця 6.6. Логові метрики повинні бути привʼязані до типу URL і конкретної технічної гіпотези.

Google прямо рекомендує підтримувати HTTP-кешування і 304 Not Modified. Якщо документ не змінився з попереднього сканування, 304 повідомляє пошуковому роботу, що можна використати кешовану версію без повторної передачі повного контенту. Це економить мережевий трафік і серверні ресурси.[1][5]

Водночас 304 не треба продавати як “фактор ранжування” або спосіб примусити Google сканувати більше. Коректний висновок скромніший: для великих сайтів із великою часткою незмінених повторних запитів перевірка актуальності може зробити повторне завантаження дешевшим. Чи перетвориться ця економія на більший обсяг сканування саме ваших важливих URL, залежить від попиту й спроможності, а не від одного заголовка.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код C1DD89EE

Google називає фасетну навігацію однією з найчастіших причин надмірного сканування, з якими власники сайтів звертаються до команди Search. Проблема не у фільтрах як таких, а в комбінаторному просторі URL: кожна властивість і кожен порядок параметрів можуть породжувати нову адресу, яку пошуковий робот не може оцінити до запиту.[4]

Якщо такі сторінки не потрібні в пошуку, Google рекомендує не давати їх сканувати, наприклад через robots.txt, або проектувати фільтри так, щоб вони не створювали URL, доступні для сканування. Якщо ж частина фасетів потрібна як посадкові сторінки, завдання складніше: треба чітко розділити комбінації, що мають індексуватися і технічний “довгий хвіст” параметрів, підтримувати стабільний порядок параметрів, віддавати 404 для порожніх комбінацій і не створювати нескінченні простори.[4]

Таблиця 6.7. Надмірне сканування майже завжди починається з неконтрольованого інвентарю URL, а не з “надто активного Googlebot”.

Google прямо застерігає не використовувати 401, 403 або 404 для обмеження частоти. Усі 4xx, крім 429, не є сигналом “сервер перевантажений”. 429 якраз означає Too Many Requests і враховується як сигнал перевантаження сервера. 5xx також знижують інтенсивність сканування.[5]

Для аварійної ситуації, коли потрібно на кілька годин або один-два дні різко зменшити трафік сканування, Google рекомендує повертати 500, 503 або 429. Це грубий інструмент: він впливає на весь хост, уповільнює виявлення нових URL і повторне сканування, а якщо помилки тримаються кілька днів, URL можуть почати випадати з індексу. Це не постійний механізм “оптимізації бюджету”.[5]

Рис. 6.5. Найважливіші HTTP-відповіді з точки зору сканування.

Схема узагальнює офіційну документацію Google. Для повної обробки кожного статусу дивіться джерело 5.

robots.txt сам теж треба сканувати. Google зазвичай кешує його до 24 годин, але може тримати кеш довше, якщо оновлення недоступне. Особливо небезпечний сценарій - 5xx на robots.txt. В офіційній специфікації поведінка описана по часу: перші 12 годин Google припиняє сканування сайту, але продовжує намагатися отримати robots.txt; далі до 30 днів може використовувати останню доступну версію, якщо вона є; після 30 днів поведінка залежить від загальної доступності сайту.[5]

Рис. 6.6. Спрощена шкала поведінки Google при 5xx на robots.txt.

Джерело: Google Crawling Infrastructure. Схема не замінює повну специфікацію для DNS, тайм-аутів та інших мережевих помилок.

Практичний висновок: доступність robots.txt треба контролювати як критичну для доступності адресу. Якщо CDN, WAF або розгортання випадково починає віддавати 5xx на /robots.txt, наслідок не обмежується самим файлом. Це може зупинити або суттєво змінити сканування всього хоста.

У березні 2026 року Google окремо пояснив обмеження інфраструктури завантаження. Для Googlebot загального веб-пошуку завантажується до 2 МБ одного підтримуваного ресурсу в незжатому вигляді, включно з HTTP-заголовками; для PDF - до 64 МБ. Коли межа досягнута, пошуковий робот припиняє завантаження і передає далі лише вже отриману частину. Кожен CSS або JavaScript ресурс, на який посилається HTML, запитується окремо і має власну межу.[5]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 02FB5A71

Рис. 6.7. Офіційні межі обсягу одного завантаження для Googlebot у 2026 році.

2 МБ для підтримуваних типів файлів загального веб-пошуку; 64 МБ для PDF. Інші пошукові роботи Google можуть мати інші межі.

Для більшості HTML-сторінок 2 МБ незжатого HTML - дуже великий обсяг. Але на масивних шаблонах масової генерації, довгих каталогах або сторінках із вбудованими даними це вже не теоретична межа. Я перевіряю не тільки переданий обсяг після gzip/brotli, а й фактичне незжате тіло відповіді, бо саме його обмеження описує Google.

Нижче я свідомо не намагаюся розбирати будь-який можливий формат nginx/Apache. У різних командах логи вже потрапляють у S3, BigQuery, ClickHouse або CSV з різними полями. Скрипт очікує нормалізований CSV після верифікації Googlebot з колонками timestamp, url, status, bytes, response_time. Далі задача SEO - перетворити запити на зрозумілі шаблони.

БЕЗ КОДУ: ПРОМПТ ДЛЯ ШІ Я завантажу verified_googlebot.csv з колонками timestamp, url, status, response_time і bytes. Перевір типи даних і пропуски. Сегментуй URL за правилами, які я дам для product/category/search/other, порахуй кількість запитів і унікальних URL, медіанний response time, обсяг переданих байтів, частки 2xx/3xx/4xx/5xx та медіанний інтервал повторного сканування. Покажи аномалії, але не роби причинних висновків без додаткових даних. АЛЬТЕРНАТИВА БЕЗ ШІ Якщо CSV уже нормалізований, те саме можна зробити у Excel/Sheets: додати колонку типу сторінки, сімейство статусу, потім Pivot Table. Для інтервалу повторного сканування відсортуйте URL + timestamp і порахуйте різницю з попереднім запитом; Power Query зручніший на великих файлах.

QR: КОД Скануйте камерою: QR містить компактну виконувану версію коду без коментарів. Коментований код наведено нижче.

ДЛЯ АВТОМАТИЗАЦІЇ: PYTHON ДЛЯ АНАЛІЗУ ЛОГІВ

Код 6.1. Базова сегментація підтверджених запитів Googlebot за типом сторінок, статусами й медіанним інтервалом повторного сканування.

Після цього я додаю бізнесові поля: цільовий canonical, можливість індексації, версію шаблону, час останньої зміни, дату публікації, стан інвентарю. Тоді лог перестає бути “технічним файлом” і перетворюється на систему, де можна відповісти, наприклад: скільки годин у медіані Googlebot потребує, щоб уперше просканувати новий товар; який відсоток його запитів до /search/; чи впала частка 5xx після зміни інфраструктури; чи скоротився інтервал повторного сканування для сторінок, де ціна змінюється щодня.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код C6209DF2

Таблиця 6.8. Симптом сканування не дорівнює причині. Для кожної гіпотези потрібне окреме джерело даних.

Я починаю з інвентарю, а не з логу. Якщо команда сама не знає, які типи URL мають існувати в пошуку, неможливо визначити, що в трафіку сканування є “марним”. Далі дивлюся Crawl Stats, щоб зрозуміти масштаб, стан хоста, профіль часу відповіді і співвідношення виявлення/повторного сканування. Тільки після цього йду в логи, бо без контексту мільйони рядків легко перетворити на красиві, але беззмістовні графіки.

Таблиця 6.9. Аудит сканування як послідовність перевірок, а не список із 100 технічних прапорців.

Не потрібно блокувати все підряд у robots.txt лише тому, що Googlebot часто туди ходить. Якщо URL треба спочатку прибрати з індексу через noindex, пошуковий робот має мати можливість отримати цю директиву. Не потрібно робити випадкові щоденні зміни robots.txt “щоб перерозподіляти бюджет”: Google прямо не рекомендує використовувати файл як тимчасовий механізм перерозподілу. Не потрібно відповідати 403 або 404, щоб “пригальмувати бота”. І не потрібно вимірювати успіх просто падінням загальної кількості запитів сканування - менше запитів може означати як кращу ефективність, так і втрату попиту.[1][5]

Таблиця 6.10. Бюджет сканування без міфології: що реально випливає з поточної документації Google.

Точно знаємо: Google визначає бюджет сканування через спроможність і попит; великий зайвий інвентар URL може зменшувати ефективність; час відповіді, 5xx і 429 впливають на спроможність сканування; популярність і застарівання впливають на попит; 304 може заощадити мережевий трафік; Search Console Crawl Stats є агрегованим, а приклади URL не є повним логом; фасетну навігацію може створювати практично нескінченний простір URL; Googlebot має документовані межі байтів на одне завантаження.[1][2][4][5]

Не знаємо публічно: точну формулу планувальника, ваги кожного сигналу, персональну “вартість” конкретного URL у черзі сканування, гарантований обсяг додаткового сканування після прискорення сервера або блокування фасетів. Якщо SEO-спеціаліст показує “Google виділив нам 187 432 умовних кредитів сканування на день” без внутрішніх даних Google, це не факт, а модель або вигадка.

Бюджет сканування має сенс лише тоді, коли ми перестаємо сприймати його як магічний ліміт. У великому сайті є інвентар URL, є серверна місткість, є попит пошукової системи, є історія змін і є конкретні HTTP-відповіді. SEO може дуже сильно впливати на перше, частково - на друге, опосередковано - на третє і напряму контролювати коректність четвертого та пʼятого.

Мій робочий критерій простий: важливі нові URL мають швидко отримувати перше сканування, важливі змінені URL - повторне сканування із частотою, що відповідає їхній бізнесовій динаміці, а сервер не повинен витрачати значну частину ресурсу на адреси, які продукт не збирається підтримувати в пошуку. Усе інше - засоби вимірювання цієї системи.

1. Google Crawling Infrastructure: Optimize your crawl budget. https://developers.google.com/crawling/docs/crawl-budget Оновлено 22.07.2026.

2. Google Search Console Help: Crawl Stats report. https://support.google.com/webmasters/answer/9679690?hl=en

3. Google Search Central: Googlebot. https://developers.google.com/search/docs/crawling-indexing/googlebot Оновлено 03.02.2026.

4. Google Crawling Infrastructure: Managing crawling of faceted navigation URLs. https://developers.google.com/crawling/docs/faceted-navigation

5. Google Search Central / Crawling Infrastructure: technical crawling references. https://developers.google.com/search/blog/2026/03/crawler-blog-post ; https://developers.google.com/crawling/docs/crawlers-fetchers/reduce-crawl-rate ; https://developers.google.com/crawling/docs/troubleshooting/http-status-codes ; https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec Межі завантаження Googlebot, аварійне зменшення частоти сканування, HTTP-коди та поведінка robots.txt.

ЧАСТИНА II / ЯК ПОШУКОВА СИСТЕМА БАЧИТЬ ВЕБ

ГЛАВА 7

Перший корисний поділ - мережевий і браузерний. Під час HTTP-запиту сервер повертає статус, заголовки та тіло відповіді. На класичній серверній сторінці основний текст, посилання й SEO-метадані вже є в цьому HTML. На клієнтському застосунку відповідь може містити лише оболонку, JavaScript-бандли та контейнер, у який контент буде вставлено пізніше.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A32E1057

Googlebot спочатку отримує саме HTTP-відповідь і вже з неї може витягнути доступні <a href> посилання. Далі сторінка з 200 може потрапити до Web Rendering Service, де Chromium без графічного інтерфейсу виконає JavaScript. Після цього Google отримує інше представлення документа - DOM після виконання сценаріїв - і ще раз шукає контент та посилання.[1]

Важлива деталь: не-200 відповідь може взагалі не пройти повний рендеринг.[1] Тому JavaScript не повинен бути способом “виправити” базову семантику HTTP. Якщо сторінки немає, краще повернути коректний 404/410; якщо вона переїхала - серверний редирект; якщо доступ закритий - відповідний 401/403. JavaScript-редиректи Google підтримує, але сам Google радить використовувати їх лише коли серверний або meta refresh варіант неможливий, бо JavaScript-редирект залежить від успішного рендерингу.[10]

Рис. 7.2. Для однієї URL треба розрізняти HTTP-відповідь, DOM після JavaScript і візуальний кадр.

Скриншот корисний для діагностики, але головний технічний доказ наявності тексту або посилання - відрендерений HTML/DOM, а не пікселі.

Таблиця 7.1. Чотири джерела доказів для одного URL не можна підміняти одне одним.

У поточній документації Google є формулювання, яке часто дивує навіть досвідчених SEO: усі сторінки з HTTP 200 ставляться в чергу рендерингу незалежно від того, чи є на них JavaScript.[1] Це не означає, що архітектура SSR і CSR для Search однакова. Різниця в тому, скільки корисної інформації Google має вже на першому етапі та скільки критичних елементів залежить від наступного виконання ресурсів.

Якщо основний текст, заголовок, навігація, canonical і JSON-LD є у первинному HTML, рендеринг радше доповнює документ. Якщо первинний HTML - порожня оболонка, успішний рендеринг стає умовою появи майже всього, що SEO хоче від сторінки. У другому випадку збільшується кількість точок відмови: JS-бандл, API, мережеві правила, блокування ресурсів, помилки виконання, стан клієнта, авторизація, експерименти та залежність від зовнішніх сервісів.

Я не оцінюю фреймворк за назвою. Next.js можна налаштувати так, що продуктова сторінка повертає повний HTML, а можна винести головний каталог у клієнтські запити. React сам по собі не робить сайт ні придатним для SEO, ні непридатним для SEO. Для аудиту важливіше відповісти: що є в HTTP HTML; що зʼявляється після JavaScript; що змінюється під час гідратації; що залежить від стану користувача.

web.dev у матеріалі, оновленому 5 січня 2026 року, визначає SSR як формування HTML на сервері, CSR - створення DOM у браузері JavaScript-ом, попередній рендеринг - підготовку статичного HTML під час збірки, а гідратацію - додавання клієнтського стану та інтерактивності до вже відрендереного HTML.[8] Для SEO ці визначення корисні не як рейтинг технологій, а як карта залежностей.

Рис. 7.3. Де формується основний контент у різних моделях рендерингу.

Динамічний рендеринг у схемі показаний окремо, бо Google вважає його тимчасовим обхідним рішенням, а не рекомендованою довгостроковою архітектурою.[4]

Таблиця 7.2. Архітектура сама по собі не є фактором ранжування; вона визначає точки технічної залежності.

Технічно Google може побачити багато речей, доданих JavaScript. Документація прямо дозволяє змінювати title і метаопис, інжектити JSON-LD і навіть canonical.[1] Але “може обробити” і “це найнадійніша архітектура для критичного сигналу” - різні питання.

Для шаблонів, де SEO є важливою частиною бізнесу, я намагаюся мати у первинному HTML щонайменше основний контент сторінки, логічний H1, доступні для сканування посилання, базові robots/canonical сигнали та ті структуровані дані, які описують уже видимий контент. Це не вимога Google “все має бути SSR”; це інженерна стратегія зменшення кількості залежностей.

Таблиця 7.3. “Google підтримує через JavaScript” не означає “варто робити критичний елемент залежним від JavaScript”.

Один із найнебезпечніших шаблонів - віддавати noindex у первинному HTML, а потім знімати його JavaScript-ом, коли API підтвердить, що сторінка валідна. Google прямо попереджає: коли він зустрічає noindex, рендеринг і виконання JavaScript можуть бути пропущені. Тому логіка “спочатку noindex, потім JavaScript зробить index” ненадійна.[1]

Зворотний сценарій допустиміший: сторінка стартує без noindex, а JavaScript додає noindex, якщо API повернув стан, який не повинен індексуватися. Але для масових шаблонів я все одно віддаю перевагу правильному HTTP-статусу або серверній логіці. Особливо для товарів, вакансій і сторінок сутностей, де “існує / не існує” бізнес уже знає на сервері.

Google Search не взаємодіє зі сторінкою як людина. В офіційній документації про відкладене завантаження прямо сказано: реалізація не повинна покладатися на дії користувача на кшталт прокручування або кліку.[3] У посібнику Google з усунення проблем окремо зауважує, що функції, які вимагають дозволів, можуть бути безглуздими для Googlebot: він не надасть сайту камеру лише для того, щоб отримати основний контент.[2]

Тому важливий розподіл не “JavaScript / без JavaScript”, а “автоматично формується під час рендерингу / зʼявляється лише після окремої взаємодії”. Якщо текст відкривається після обробника натискання, список підвантажується лише на подію прокручування, API вимагає cookie з попередньої сесії або контент сидить за API дозволів - звичайна перевірка користувачем у браузері може вводити SEO в оману.

Рис. 7.4. Основний SEO-контент не повинен залежати від обовʼязкової дії користувача.

Google Search не “проклікує” інтерфейс, щоб відкрити прихований основний контент. Для lazy-loading потрібна автоматична поява контенту, коли він стає видимим в області перегляду.[3]

Таблиця 7.4. Взаємодія користувача може бути UX-функцією, але не повинна бути єдиним шляхом до критичного SEO-контенту.

Відкладене завантаження саме по собі не є SEO-помилкою. Google рекомендує його для невидимих або некритичних ресурсів, але з умовою: релевантний контент має завантажуватися, коли входить в область перегляду, без ручного натискання або прокручування як обовʼязкового тригера.[3] Для зображень і iframe найпростіший варіант - вбудоване відкладене завантаження браузера; для інших сценаріїв Google наводить IntersectionObserver.

Нескінченна прокрутка має окрему умову. Кожен логічний сегмент повинен мати постійну унікальну URL, однаковий контент при повторному відкритті й послідовні доступні для сканування посилання між сторінками. Коли під час прокручування новий сегмент стає основним, URL можна оновлювати History API.[3] Це вже не косметична техніка: без самостійних URL і пагінації пошуковий робот отримує лише один нескінченний інтерфейс без стабільної адресації.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 03804CB8

Рис. 7.5. Що перевіряти у відкладеному завантаженні та нескінченній прокрутці.

Критерій не “чи бачить це людина після прокрутки”, а “чи потрапляє контент і його URL у відрендерений HTML без обовʼязкової ручної взаємодії”.

Коли сторінка повертає правильний 200 і достатній HTML, але жива перевірка показує неповний DOM, я дивлюся на ресурси. WRS може не отримати JavaScript-бандл через robots.txt, CDN/WAF, помилки хоста, відмінну поведінку для ідентифікатора бота або зовнішній API. Google також пише, що WRS аналізує ресурси й може не завантажувати ті, які не потрібні для основного контенту, наприклад частину аналітики або запитів звітування про помилки.[2]

Ще одна неочевидна проблема - кеш. Googlebot кешує ресурси агресивно, а WRS може ігнорувати заголовки кешування. Якщо файл main.js змінюється, але URL лишається тим самим, Google може певний час використати старішу версію. Google рекомендує версіювання імені файлу за вмістом: імʼя файлу змінюється разом із його вмістом, наприклад main.2bb85551.js.[1]

Таблиця 7.5. Проблема рендерингу часто знаходиться у ресурсному графі, а не в HTML документа.

Google підтримує JavaScript-зміни title та meta description, може прочитати JSON-LD, доданий через JavaScript і canonical.[1] Але canonical має окреме застереження: якщо canonical є в початковому HTML, JavaScript не повинен змінювати його на іншу URL. Якщо сервер не може поставити canonical, його можна додати JavaScript-ом, але не створювати конфлікт двох значень.[1]

У практичному аудиті я порівнюю не лише “canonical є / немає”, а три стани: HTTP HTML, DOM після JavaScript і те, що Search Console показує як canonical, заявлений сайтом / canonical, обраний Google. Якщо перші два вже конфліктують, немає сенсу шукати складну алгоритмічну причину, чому Google обрав не ту URL.

Таблиця 7.6. Порівняння до/після JavaScript швидше знаходить конфлікти, ніж перевірка одного стану.

Для веб-компонентів Google документує підтримку: під час рендерингу він “сплющує” light DOM і shadow DOM у HTML після рендерингу. Практичний критерій простий: якщо потрібний контент не видимий у HTML після рендерингу, Google не зможе його індексувати.[1] Тому перевіряти лише View Source для сайту з веб-компонентами недостатньо.

Це хороший приклад ширшої проблеми: View Source показує отриманий від сервера HTML, а Elements у DevTools - поточний DOM браузера. Для класичної сторінки вони схожі; для складного клієнтського застосунку можуть відрізнятися радикально. В аудиті треба знати, який саме шар ви дивитесь.

URL Inspection поєднує два джерела даних: інформацію з індексу Google і дані живої перевірки. Індексована версія показує, що Google знає про сторінку після свого циклу сканування та індексації. Жива перевірка генерується окремо в момент перевірки і корисна для діагностики поточного стану, але не передбачає, наприклад, який canonical Google реально обере при індексації.[5]

У живій перевірці можна подивитися скриншот, HTML, HTTP-заголовки та консоль JavaScript і завантажені ресурси.[5] Для аудиту рендерингу це сильний набір. Але я не роблю висновок “все добре” лише зі скриншота: скриншот - візуальний кадр. Текст може бути нижче, елемент може бути присутній у HTML і не потрапити у видимий кадр, або навпаки інтерфейс може виглядати схожим, але критичне посилання не мати доступного для сканування href.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код F1013B56

Рис. 7.6. Порядок перевірки рендерингу конкретної URL.

Жива перевірка та індексовані дані відповідають на різні питання. Результат живої перевірки Google не використовує як індексовану версію сторінки.[5]

Таблиця 7.7. Жоден інструмент окремо не дає повної картини рендерингу.

Я починаю не з фрази “сайт на React”. Спершу фіксую конкретний симптом: відсутній текст, посилання, canonical, структуровані дані, зображення, пагінація або весь шаблон. Далі йду від найнижчого шару до найвищого.

Спочатку дивлюся HTTP-статус та первинний HTML. Якщо елемент уже відсутній там - це ще не дефект, але я вже знаю, що він залежить від наступного етапу. Потім відкриваю DevTools: чи зʼявився елемент у DOM, які запити його створили, чи є помилки в консолі. Після цього запускаю живу перевірку в Search Console і перевіряю HTML після рендерингу, ресурси й скриншот. І лише потім порівнюю індексовану версію, щоб не плутати поточну версію сайту зі станом, який Google зберіг раніше.

Рис. 7.7. Діагностичне дерево для симптома “у браузері є, у Google немає”.

Починати треба з шару, на якому зникає елемент: HTTP HTML, DOM після JS, жива перевірка або вже індексована версія.

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

На рівні масового сканування корисно порівняти режими Text Only і JavaScript Rendering. Screaming Frog дозволяє запускати обидва режими й експортувати title, meta robots, canonical, H1, кількість посилань, структуровані дані та користувацьке вилучення. Тоді питання “у нас JavaScript проблема?” перетворюється на таблицю “які саме поля змінюються після рендерингу і на яких типах URL”.

Формула 7.1. Коефіцієнт залежності SEO-елементів від рендерингу.

Це внутрішній діагностичний показник автора, а не офіційна метрика Google. Її сенс - порівнювати шаблони та релізи, а не “оптимізувати число заради числа”.

Формула 7.2. Частка URL із критичною розбіжністю рендерингу.

Критичною розбіжністю може бути відсутній основний текст, href, canonical, robots, title або структуровані дані - набір треба зафіксувати до тесту.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 9DBAF190

Таблиця 7.8. Масштабний аудит рендерингу має бути шаблонним і порівняльним, а не ручним списком скриншотів.

Нижче - мінімальний локальний тест. Він не емулює Googlebot і не замінює URL Inspection. Його завдання простіше: показати, які базові SEO-елементи змінюються між HTTP-відповіддю та браузерним DOM після JavaScript. Для масового аудиту в робочому середовищі я б додавав список URL, контроль User-Agent, тайм-аути, логування помилок ресурсів, власні селектори та збереження різниці у CSV.

БЕЗ КОДУ: ПРОМПТ ДЛЯ ШІ Я надам два HTML-файли однієї URL: raw.html з HTTP-відповіді та rendered.html після JavaScript. Порівняй тільки факти у файлах. Витягни title, meta robots, canonical, H1, усі внутрішні <a href>, JSON-LD, довжину видимого тексту та вказані мною CSS-селектори. Побудуй таблицю: елемент, raw, rendered, тип зміни, SEO-ризик. Окремо виділи елементи, що зʼявляються лише після JavaScript, зникають після JavaScript або конфліктують. Не роби висновків про індексацію, яких ці два HTML не доводять.

QR: КОД Скануйте камерою. QR містить компактну виконувану версію коду.

Альтернатива без Python: зробіть два сканування одного набору URL у Screaming Frog - Text Only і JavaScript rendering - та зіставте експорти за URL. Для одиничної URL достатньо HTTP-відповіді + Chrome DevTools + живої перевірки в Search Console. Python потрібен, коли порівняння треба повторювати регулярно або на великій вибірці.

Код 7.1. Мінімальне порівняння HTTP HTML і браузерного DOM після JavaScript. Потрібні requests, beautifulsoup4 та playwright.

У старих JavaScript SEO-гайдах динамічний рендеринг часто виглядає як нормальний шлях: ботам віддаємо попередньо відрендерений HTML, користувачам - клієнтський застосунок. Поточна позиція Google інша: динамічний рендеринг - тимчасовий обхід, а не довгострокове рішення. Google рекомендує серверний рендеринг, статичний рендеринг або гідратацію.[4]

Причина не лише у політиці Google. Дві версії одного документа треба синхронізувати; зʼявляються різні кеші, різні помилки, різний результат canonical і контенту. Якщо команда вимушено використовує динамічний рендеринг для застарілої системи, я ставлю йому строк життя та контроль відповідності між версією для ботів і версією для користувачів, а не перетворюю його на постійну архітектуру.

Таблиця 7.9. JavaScript SEO без ритуалів: кожен висновок має привʼязуватися до конкретного шару обробки.

Точно знаємо: Google сканує, ставить 200-сторінки в чергу рендерингу, виконує JavaScript у сучасному Chromium, повторно аналізує HTML після рендерингу та витягує посилання; підтримує JavaScript-зміни title, метаопис, canonical і структуровані дані; Search не взаємодіє зі сторінкою як користувач для відкладеного завантаження; WRS не зберігає localStorage/sessionStorage між завантаженнями сторінок; динамічний рендеринг не є рекомендованим довгостроковим рішенням.[1][2][3][4]

Не знаємо публічно: точний пріоритет конкретної URL у черзі рендерингу, гарантований максимальний час очікування, точну внутрішню модель планування ресурсів WRS, які саме ресурси система вирішить пропустити на конкретному рендері, і повну формулу, за якою документ після рендерингу впливає на подальшу індексацію. Тому будь-які “ліміти рендерингу Google” у секундах або магічна допустима кількість JS, якщо вони не мають актуального офіційного джерела, я не використовую як факт.

JavaScript SEO у 2026 році - не окрема магічна дисципліна. Це контроль переходу документа між станами. Сервер повернув одну версію. Браузер після JavaScript сформував другу. Жива перевірка Google може показати третю поточну версію, а в індексі зберігатися попереднє сканування. Завдання SEO - знайти, на якому саме переході губиться критичний елемент.

Мій робочий стандарт простий: усе, що критично для змісту сторінки, навігації й базових індексаційних сигналів, має бути або в первинному HTML, або гарантовано зʼявлятися в HTML після рендерингу без кліку, прокрутки, логіну, дозволів та збереженого стану. Аудит починається з HTTP і DOM, а не з назви фреймворку. Якщо елемент є у первинному HTML - рендеринг не є його першою проблемою. Якщо його немає у первинному HTML, але є після JavaScript - далі перевіряємо живу перевірку Google. Якщо є й там - переходимо до canonical, індексації та якості, а не продовжуємо звинувачувати JavaScript.

1. Google Search Central. Understand JavaScript SEO Basics. https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics Основи crawling, черги рендерингу, WRS, canonical, noindex, кешування та веб-компонентів.

2. Google Search Central. Fix Search-Related JavaScript Problems. https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript Обмеження WRS, дозволи, localStorage/sessionStorage, ресурси та діагностика.

3. Google Search Central. Fix Lazy-Loaded Website Content. https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading Відкладене завантаження без ручної взаємодії та індексована нескінченна прокрутка.

4. Google Search Central. Dynamic Rendering as a workaround. https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering Динамічний рендеринг як тимчасовий обхід; рекомендовані серверний/статичний рендеринг або гідратація.

5. Google Search Console Help. URL Inspection tool. https://support.google.com/webmasters/answer/9012289?hl=en Жива перевірка, скриншот, HTML після рендерингу, ресурси та консоль JavaScript.

6. Google Search Central. Latest Google Search Documentation Updates. https://developers.google.com/search/updates 04.03.2026: Google прибрав застарілий блок, наголосивши, що Search рендерить JavaScript багато років.

7. Google Search Central. In-Depth Guide to How Google Search Works. https://developers.google.com/search/docs/fundamentals/how-search-works Рендеринг JavaScript під час сканування та наступна індексація.

8. web.dev. Rendering on the Web. https://web.dev/articles/rendering-on-the-web Оновлено 05.01.2026. SSR, CSR, попередній рендеринг, гідратація та продуктивність.

9. web.dev. Client-side rendering of HTML and interactivity. https://web.dev/articles/client-side-rendering-of-html-and-interactivity Вплив клієнтського рендерингу на DOM і головний потік браузера.

10. Google Search Central. Redirects and Google Search. https://developers.google.com/search/docs/crawling-indexing/301-redirects JavaScript-редиректи через WRS; пріоритет серверного редиректу.

11. Google Search Central. Get started with Search: a developer's guide. https://developers.google.com/search/docs/fundamentals/get-started-developers JavaScript, semantic HTML, текст у DOM та URL для SPA.

ЧАСТИНА II / ЯК ПОШУКОВА СИСТЕМА БАЧИТЬ ВЕБ

ГЛАВА 8

Дублікатність усередині сайту сама по собі не є спамом. Параметри сортування, UTM, HTTP/HTTPS, www/non-www, альтернативні регіональні URL, printer-friendly сторінки або CMS-варіанти можуть породжувати однаковий основний контент. Завдання системи - не “покарати дубль”, а не зберігати і не показувати десяток еквівалентних представників без потреби.[1]

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

Таблиця 8.1. Сигнали canonicalization і їх практичне значення.

Google окремо радить посилатися всередині сайту саме на canonical URL. Це не означає, що одна випадкова внутрішня ссылка “перепише” canonical; це означає, що граф сайту повинен бути узгодженим. Якщо CMS десятиліттями генерує параметричні URL, canonical не перетворює цю архітектуру на чисту - він лише допомагає системі зрозуміти ваш намір.

Self-referencing canonical я ставлю на основні HTML-сторінки за замовчуванням, якщо немає спеціальної причини робити інакше. Це робить намір явним і зменшує залежність від того, як CMS згенерує параметри або альтернативні URL. Але self-canonical не “закріплює” сторінку назавжди. Якщо система бачить сильніший набір суперечливих сигналів або вважає іншу URL кращим представником дубліката, вона може вибрати іншу canonical.[1][3]

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

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 72981973

Окремо небезпечні cross-domain canonical. Вони технічно підтримуються, але це сильне твердження: “основна версія цього матеріалу знаходиться на іншому домені”. Для синдикації це може бути доречно; для випадково скопійованого шаблону - катастрофа. Я завжди включаю зовнішні canonical у окремий звіт.

Для регіональних сторінок однією мовою Google рекомендує поєднувати canonical і hreflang. Практична модель: кожна локалізована URL має залишатися canonical у власному логічному кластері, а hreflang повʼязує альтернативи. Якщо es-ES canonical-иться на глобальну англійську URL, а hreflang одночасно оголошує es-ES як окремий варіант, система отримує конфлікт намірів.[4][5]

Коли URL Inspection показує, що user-declared canonical і Google-selected canonical не збігаються, це не діагноз. Це симптом. Далі треба порівняти контент, статуси, redirects, внутрішні посилання, sitemap, hreflang, мобільні/десктопні варіанти та історію URL. Я шукаю не “чому Google не слухає тег”, а “який інший набір сигналів виглядає для системи послідовнішим”.

Таблиця 8.2. Діагностика розбіжності declared і selected canonical.

На великому сайті canonical-аудит я зводжу до матриці “URL → final status → declared canonical → canonical final status → indexability → inlinks → sitemap → selected canonical”. Після цього проблеми групуються шаблонами. Якщо 80 тисяч URL одного facet template canonical-яться через redirect, це одна системна помилка, а не 80 тисяч задач.

Корисний показник - Canonical Agreement Rate: частка indexable URL, для яких declared canonical збігається з очікуваною основною URL за правилами бізнесу. Це внутрішня метрика, не Google metric. Її цінність у регресійному контролі: після релізу можна побачити, що частка узгоджених URL впала з 99,4% до 92,1%, ще до того, як зміна проявиться у видимості.

Google групує дублікати й обирає представника; redirects і rel="canonical" є сильними сигналами, sitemap - слабшим; сигнали можна комбінувати; canonical є підказкою, а не директивою; дублікати самі по собі не є спамом; регіональні варіанти однією мовою потребують узгодження canonical і hreflang.[1][2][4]

Не знаємо публічно: точну вагу кожного canonical-сигналу в конкретному кластері та формулу, за якою Google вирішує конфлікт. Тому “підсилити canonical ще трьома сигналами” - практична інженерна стратегія, а не відтворення закритого алгоритму.

1. Google Search Central. What is canonicalization. https://developers.google.com/search/docs/crawling-indexing/canonicalization

2. Google Search Central. How to specify a canonical URL with rel="canonical" and other methods. https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

3. Google Search Central. Fix canonicalization issues. https://developers.google.com/search/docs/crawling-indexing/canonicalization-troubleshooting

4. Google Search Central. Managing multi-regional and multilingual sites. https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 4DD594A0

5. Google Search Central. Localized versions. https://developers.google.com/search/docs/specialty/international/localized-versions

ЧАСТИНА II / ЯК ПОШУКОВА СИСТЕМА БАЧИТЬ ВЕБ

ГЛАВА 9

Пошуковій системі немає сенсу тримати в активному індексі кожну технічно доступну URL. Варіанти параметрів, дублікати, порожні фільтри, тестові сторінки, soft 404, малокорисні комбінації programmatic templates і безкінечні календарі можуть бути доступні для сканування, але не створювати окремої пошукової цінності. Тому “Crawled - currently not indexed” треба трактувати як клас стану, а не як один дефект із одним фіксом.

Google прямо вказує: noindex має бути доступний crawler. Якщо сторінку одночасно заборонено в robots.txt, Googlebot не отримує HTML і не бачить noindex; URL усе ще може бути відома з посилань та інколи зʼявлятися в результатах без нормального snippet.[2] Це класичний приклад конфлікту між керуванням crawl і керуванням index.

Таблиця 9.1. Чотири різні способи “прибрати URL” вирішують різні задачі.

Якщо URL у стані Discovered - currently not indexed, перше питання - чи отримував її Googlebot. Якщо ні, ми ще на етапі discovery/crawl scheduling: внутрішні посилання, sitemap, серверна спроможність, crawl demand, надмірний URL-space. Якщо URL у Crawled - currently not indexed, crawler уже дійшов до документа, і бездумно “підсилювати sitemap” менш логічно. Треба перевіряти canonical cluster, soft 404, дублікати, якість шаблону, унікальність фактичних даних і те, чи сторінка взагалі заслуговує на окремий індексований документ.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код EBF850F7

Soft 404 виникає, коли HTTP-відповідь формально успішна, але зміст виглядає як відсутній або непридатний ресурс. Типові приклади: порожня категорія з 200, товар, що назавжди недоступний і не має альтернативи, сторінка внутрішнього пошуку без результатів, шаблон із одним заголовком і нульовим основним контентом. Важлива причина проблеми - системі доводиться окремо інтерпретувати семантичний стан замість отримати коректний HTTP-статус.

В Indexing reports багато URL, які SEO називає “випали з індексу”, насправді є alternate pages або дублікати. Це не обовʼязково проблема. Якщо параметричні URL, print-версія і clean URL утворюють один canonical cluster, індексація одного представника є очікуваною поведінкою. Тут треба оцінювати кластер, а не добиватися індексації кожної URL окремо.

Google не публікує повну формулу індексаційного відбору. Тому я не пишу “сторінка не індексується через E-E-A-T” або “потрібно 800 слів”. Коректніше: Search Essentials прямо не гарантує index навіть для технічно валідної сторінки; Google оцінює контент і дублікати на етапах обробки; якщо цілі класи тонких або майже взаємозамінних сторінок системно не індексуються, це сильний сигнал переглянути саму цінність шаблону, а не шукати чарівний технічний прапорець.[1][3]

Таблиця 9.2. Які знаменники потрібні для нормального індексаційного звіту.

Я навмисно не ділю “indexed URLs” на “усі URLs, які знайшов crawler”. Якщо crawler знайшов 12 млн параметрів, а бізнес очікує 400 тисяч індексованих сторінок, такий знаменник нічого не говорить про якість індексації.

URL Inspection корисний для доказу стану конкретної сторінки, але 100 тисяч URL вручну не перевіряються. Я будую стратифіковану вибірку: шаблон, рівень внутрішніх посилань, нові/старі URL, sitemap/non-sitemap, canonical/non-canonical, країна/мова. Потім беру 50-200 URL із кожного значущого сегмента. Мета - не отримати “загальний % індексації”, а знайти клас, де ймовірність індексації різко відрізняється.

Ручний запит на індексацію я використовую для важливої нової URL або після виправлення конкретної технічної помилки, коли хочу швидше запустити наступний цикл. Це не масштабна стратегія. Google прямо пише, що crawl та indexing займають час і не гарантуються; sitemap і нормальний internal graph - системні канали, ручна кнопка - допоміжний інструмент.[4]

Мій порядок: 1) чи URL повинна існувати як окремий searchable document; 2) final HTTP status; 3) robots/noindex; 4) canonical і дублікати; 5) rendered content; 6) внутрішні посилання та sitemap; 7) URL Inspection; 8) серверний лог; 9) порівняння шаблону з індексованими аналогами. Це майже завжди швидше, ніж починати з “додамо більше тексту” або “купимо посилання, щоб Google захотів індексувати”.

Технічна доступність не гарантує index; noindex має бути доступний crawler; sitemap допомагає discovery, але не гарантує index або ranking; canonicalization може означати, що альтернативна URL не представлена окремо; Google не дає строків або гарантій для crawl/index.[1][2][4]

1. Google Search Central. Search Essentials. https://developers.google.com/search/docs/essentials

2. Google Search Central. Block Search indexing with noindex. https://developers.google.com/search/docs/crawling-indexing/block-indexing

3. Google Search Central. In-depth guide to how Google Search works. https://developers.google.com/search/docs/fundamentals/how-search-works

4. Google Search Central. Crawling and indexing FAQ. https://developers.google.com/search/help/crawling-index-faq

5. Google Search Central. Crawling and indexing overview. https://developers.google.com/search/docs/crawling-indexing

ЧАСТИНА II / ЯК ПОШУКОВА СИСТЕМА БАЧИТЬ ВЕБ

ГЛАВА 10

Фраза “ця сторінка має позицію 3” зручна, але неточна. Вона має позицію для конкретного query, country, device, search surface, часу й набору конкурентів. Змінився query interpretation - змінився candidate set. Зʼявився local pack, shopping block або AI Overview - змінилася геометрія SERP. Змінилася країна - змінився intent і набір джерел. Тому rank tracker дає спостереження, а не внутрішній score документа.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 7A69F3FC

Якщо документ не витягується для конкретної інформаційної потреби, говорити про “підвищення позиції” рано. Для класичного пошуку цей шар менш видимий зовні, але в AI Search Google уже прямо описує RAG та query fan-out: системи виконують повʼязані пошуки, отримують релевантні сторінки з індексу, а потім використовують їх як джерела.[2] Механіка generative Search зробила стару проблему очевиднішою: ranking і retrieval не тотожні.

Google пише про many factors and signals, але це не ліцензія перетворювати будь-яку кореляцію на “ranking factor”. Page speed, links, freshness, language, location, meaning of query, content relevance - різні системи можуть бути важливими в різних класах запитів. Практична робота Senior SEO не полягає в пошуку глобальної ваги сигналу X. Вона полягає у визначенні, який клас проблем обмежує конкретний набір сторінок у конкретній SERP.

Таблиця 10.1. Пʼять рівнів, які не варто зводити до одного слова “ranking”.

Одна й та сама фраза може мати кілька можливих задач. Google може інтерпретувати “jaguar” як авто, тварину або бренд залежно від контексту; у комерційній SERP “best X” може означати огляд, список, категорію або marketplace. Тому я не починаю оптимізацію з TF-IDF або “додамо exact match”. Спочатку фіксую склад SERP: типи сторінок, домінуючі intents, features, бренди, свіжість, локальність, комерційність і те, чи стабільний цей склад у часі.

У ranking systems guide Google прямо уточнює: системи працюють переважно на рівні сторінок, але є також site-wide signals і classifiers. Це важлива протиотрута від двох крайнощів: “Google ранжує домен, сторінка не важлива” і “кожна URL повністю незалежна”. Практично я аналізую обидва рівні: конкретний документ і властивості класу/сайту, але не приписую третім метрикам типу DR роль внутрішнього site score Google.[1]

Сторінка може бути “дуже якісною” за редакційними мірками, але відповідати не на той intent. І навпаки, exact-match сторінка може бути релевантною словесно, але не давати користувачу достатньої інформації, доказів або функціональності. У практичному конкурентному аналізі я розкладаю gap на дві осі: semantic/task fit і evidence/value. Це дає кращі рішення, ніж “конкурент має 2400 слів, у нас 1800”.

Класична position metric не вимірює площу екрана. Position 1 під AI Overview, двома ads, shopping carousel і local pack має іншу економіку, ніж position 1 у простій видачі. Саме тому в попередніх главах ми розділили visibility і click yield. На цьому етапі важливо додати ще один принцип: serving system визначає не тільки порядок blue links, а й форму відповіді.

Для міжнародного SEO я ніколи не зводжу позиції різних країн у одну середню. Google документує окремі механізми локалізації й hreflang, а mobile/desktop можуть мати різну видачу. Середня позиція 4,8 може складатися з position 2 в Іспанії й position 18 у Мексиці. Для бізнесу це дві різні задачі, а не одна “позиція 4,8”.

Таблиця 10.2. Конкурентний SERP-аудит на рівні документа.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код EC1321FF

Якщо top-3 pages у середньому мають більше links, швидші Core Web Vitals або довший текст, це не показує, що різниця в цій метриці спричинила ranking. Рейтингові вибірки за визначенням змішані з брендом, типом сайту, intent, віком URL і десятками інших змінних. Я використовую такі studies для генерації гіпотез, а рішення підтверджую своїми даними, контрольованими змінами або хоча б сегментацією.

Ця послідовність економить години. Якщо page excluded by noindex - не аналізуємо anchors. Якщо indexed, але ніде не зʼявляється навіть за вузьким task-fit query - перевіряємо retrieval/relevance. Якщо стабільно position 8-12 для правильного intent - дивимося competitive gap. Якщо position 2, але clicks падають - дивимося SERP composition і CTR. Одна цифра “organic traffic -30%” не містить діагнозу.

Google використовує автоматизовані ranking systems із багатьма signals; page-level і site-wide signals співіснують; Search Essentials не гарантує serving навіть для технічно валідної сторінки; у generative features retrieval і query fan-out описані публічно; Search results динамічні й залежать від запиту та контексту.[1][2][3]

Не знаємо: повну формулу rank score, ваги сигналів, точний candidate set і всі умови, за яких окрема система активується. Тому професійна модель - не “вивчити 200 ranking factors”, а відділити спостережувані стани системи й тестувати гіпотези на власних даних.

1. Google Search Central. A guide to Google Search ranking systems. https://developers.google.com/search/docs/appearance/ranking-systems-guide

2. Google Search Central. Optimizing for generative AI features on Google Search. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

3. Google Search Central. Search Essentials. https://developers.google.com/search/docs/essentials

4. Google Search Central. In-depth guide to how Google Search works. https://developers.google.com/search/docs/fundamentals/how-search-works

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 11

Я спочатку виписую типи документів, які бізнес реально повинен мати: category, product/service, comparison, review, how-to, research, legal/support, locale variants. Потім визначаю, як користувач переходить між ними. URL structure є реалізацією, але не первинною моделлю. Google окремо зазначає, що не покладається на структуру URL як на головний спосіб визначити структуру ecommerce-сайту, а аналізує links between pages.[1]

Google у link best practices прямо радить, щоб на кожну важливу URL посилалася принаймні одна інша сторінка сайту.[2] Для мене це мінімум, а не оптимум. Money page, яку можна знайти лише в sitemap, технічно існує, але архітектурно майже не інтегрована. На великому сайті я рахую не тільки orphan pages, а й кількість незалежних шляхів до важливого шаблону.

Таблиця 11.1. Архітектурні метрики, які мають сенс.

Порада “усе має бути не далі трьох кліків” зручна, але не універсальна. Для сайту на 500 URL це може бути природно; для каталогу на 5 млн SKU - ні. Я дивлюся на distribution: яка median depth у money pages, які URL формують довгий хвіст, чи збігаються deep pages із poor crawl/index performance, чи глибина виникла через бізнес-логіку або через поламану навігацію.

Хаб потрібен, коли він скорочує шлях між повʼязаними документами і дає користувачу зрозумілий огляд простору. Хороший hub може бути category, comparison landing, thematic guide або brand page. Поганий hub - сторінка, створена тільки щоб перелінкувати 100 статей без власної задачі. Якщо сторінка не допомагає навігації чи прийняттю рішення, вона додає URL-space, а не архітектуру.

Фільтри можуть створити корисні landing pages для стабільного попиту, але кожна додаткова dimension множить URL-space. Google називає faceted navigation найпоширенішим джерелом overcrawl-проблем і радить або блокувати непотрібні комбінації, або дуже дисципліновано керувати тими, які мають скануватися.[3] Тому рішення “index/noindex” повинно виходити з inventory попиту й бізнес-цінності, а не з того, що CMS може згенерувати URL.

У affiliate-проєктах типова крайність - 90% внутрішньої ваги спрямувати на review/bonus pages, а supporting content існує лише як трафіковий long-tail. Я будую двосторонні звʼязки: informational → commercial для переходу до рішення, commercial → explanatory для доказів і зняття заперечень, brand hub → конкретні products/offers, comparative pages → individual reviews. Це корисно користувачу й одночасно робить граф семантично зрозумілим.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A7BEFD06

Я беру crawl із inlinks/outlinks, sitemap inventory, GSC clicks/impressions і business value. Для кожної indexable URL додаю type, parent concept, click depth, internal inlinks, unique linking templates, traffic, conversions і status. Далі шукаю чотири класи: важливі URL без graph support; надмірно сильні utility pages; дубльовані хаби; глибокі класи URL із слабким crawl/index coverage. Це перетворює “покращити перелінковку” на конкретну чергу робіт.

Google використовує links для discovery і як сигнал релевантності; crawler нормально витягує стандартні <a href>; Google аналізує звʼязки сторінок і відносну важливість; для ecommerce рекомендує навігаційні шляхи category → subcategory → products; на кожну важливу URL має посилатися інша сторінка.[1][2] Точну внутрішню вагу кожного internal link Google не публікує.

1. Google Search Central. Help Google understand your ecommerce site structure. https://developers.google.com/search/docs/specialty/ecommerce/help-google-understand-your-ecommerce-site-structure

2. Google Search Central. Link best practices. https://developers.google.com/search/docs/crawling-indexing/links-crawlable

3. Google Search Central. Faceted navigation guidance. https://developers.google.com/search/blog/2024/12/crawling-december-faceted-nav

4. Google Search Central. URL structure best practices. https://developers.google.com/search/docs/crawling-indexing/url-structure

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 12

Таблиця 12.1. Джерело keyword data визначає, що ви взагалі здатні побачити.

Search Essentials прямо радить використовувати слова, якими люди шукають ваш контент, у помітних місцях сторінки.[1] Але це не означає “створити URL під кожну фразу”. Сучасні системи розуміють релевантність без exact-match для кожної варіації, а Google окремо попереджає не створювати сторінки під кожний fan-out query лише для маніпуляції Search.[2]

Для комерційного кластера я розкладаю запити на base entity і modifiers: brand, product class, location, price, bonus, promo, app, review, comparison, safety, payment method, withdrawal, registration, alternative, problem. Це дозволяє побачити, які dimension є системними, а які випадковими. Якщо “brand + review”, “brand + bonus” і “brand + app” мають різний SERP і різну задачу, це кандидати на окремі page types. Якщо SERP майже ідентичний і користувач очікує одну комплексну сторінку, розмноження URL створить cannibalization.

SERP-overlap clustering відповідає на практичне питання: чи Google зараз часто показує ті самі URL для двох queries. Але він залежить від country, device, date і нестабільності SERP. Я використовую overlap як evidence, а не як єдиний rule. Для high-value cluster перевіряю вручну: чи однакова задача, чи однаковий тип сторінки, чи є окремий conversion path.

Після AI Overviews і багатьох SERP features 10 000 monthly searches не дорівнюють 10 000 потенційних organic visits. Я додаю до keyword model SERP click opportunity: ads, local, shopping, featured snippet, AI, video, brand dominance. Це не точний CTR forecast, а корекція здорового глузду. Для affiliate query із volume 700 і сильним commercial intent реальна цінність може бути вищою, ніж для informational query на 20 000, який закривається у SERP.

CPC корисний як сторонній ринковий сигнал, але не замінює власну економіку. Я оцінюю conversion probability, revenue per conversion, approval rate, LTV або affiliate EPC, залежно від моделі. Потім пріоритизую не keywords, а clusters. Просте expected value: search opportunity × expected CTR band × conversion rate × value per conversion. У кожного множника має бути діапазон, а не псевдоточне число.

На новому проєкті я будую зовнішню карту попиту: конкуренти, tools, SERP, forums, product taxonomy. На діючому сайті пріоритет зміщується до first-party data: GSC queries/pages, internal search, landing conversions, lost impressions, pages із position 5-20, clusters із великою різницею між impressions і clicks. Діючий сайт уже має власний “датчик попиту”, ігнорувати його заради чужого volume - помилка.

Таблиця 12.2. Моя перевірка перед створенням нової SEO-сторінки.

Third-party KD - модель конкретного сервісу. Вона може недооцінювати brand SERP, regulatory vertical, fresh query або SERP з сильними доменами й малою кількістю links. Я ніколи не використовую KD як gate. На low-KD запитах дивлюся, чому SERP така: чи це справді слабкі сторінки, чи інструмент просто не вимірює фактор, який визначає конкуренцію.

Мій фінальний dataset має cluster_id, primary task, query examples, locale, page type, current URL, proposed URL, demand range, SERP features, top competitors, business value, evidence available, content gap, internal hub, priority і status. Це вже база для architecture, content operations і measurement. CSV “keyword-volume-KD” сам по собі не є SEO-стратегією.

1. Google Search Central. Search Essentials. https://developers.google.com/search/docs/essentials

2. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

3. Google Search Console. Performance data filtering and limits. https://developers.google.com/search/blog/2022/10/performance-data-deep-dive

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 13

“Commercial investigation” нічого не каже редактору, якщо не розкласти очікування. Для “best online casino Spain” користувач може очікувати список операторів, критерії безпеки, бонуси, платежі, legal context і швидкий шлях до сайту. Для “casino X review” очікування інші: конкретний бренд, trust, withdrawal, KYC, bonus terms, app, support. Обидва commercial, але content object різний.

Я фіксую dominant page types, repeated subtopics, brands/entities, features і те, що відсутнє. Але не копіюю SERP як технічне завдання. Поточний SERP може бути слабким, змішаним або сформованим через дефіцит хороших документів. Завдання Senior SEO - зрозуміти pattern і перевірити, де є opportunity дати кращу відповідь.

Якщо сторінка про iPhone 18 Pro, логічно коректно називати Apple, модель, chipset, camera system, iOS, storage variants, relevant predecessors. Але “entity optimization” не означає вставити 40 повʼязаних імен. Google structured data documentation описує entity-like markup як явні clues про значення сторінки, але не обіцяє ranking boost за кількість entities.[1]

Якщо про тему можна написати 200 статей, це не означає, що бізнес повинен мати 200 URL. Покриття я оцінюю за задачами: чи є відповідь на primary commercial tasks, support questions, comparison, trust, troubleshooting, post-purchase. Якщо 20 сторінок дають повне покриття, додаткові 180 можуть бути просто scaled sameness.

Таблиця 13.1. Як я розрізняю три семантичні шари.

Якщо SERP містить product pages, guides і videos, є кілька стратегій. Створити окремі сторінки під intents; зробити один сильний mixed page; або сфокусуватися на intent із найвищою business value. Я дивлюся на стабільність сегментів і conversion. Якщо Google роками тримає два типи результатів, це може бути реальний multi-intent, а не “канібалізація”.

У AI Search Google прямо описує query fan-out: модель запускає повʼязані queries для підтем.[2] Практичний висновок не “створимо сторінку під кожний fan-out query”. Навпаки: треба мати документи, які добре відповідають на логічні sub-tasks і містять достатньо конкретики, щоб бути retrieved як джерело. Це ще один аргумент мислити задачами, а не exact-match phrases.

Для бренду я прагну однакових базових facts на first-party sources: name, legal/brand relation, URL, logo, contacts, location, product naming. Organization structured data може давати Google явні clues про організацію і використовуватися в knowledge panels та attribution surfaces.[3] Але markup не виправить хаос, якщо на різних сторінках різні назви й контакти.

Таблиця 13.2. Brief без “вставити 27 keywords”.

Google використовує системи для розуміння meaning і relevance, structured data може давати явні clues про зміст, а generative Search використовує query fan-out. Не знаємо публічно: універсального “entity score”, необхідної кількості сутностей або формули topical authority. Тому такі терміни я використовую як робочі моделі, а не офіційні metrics Google.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код FD2CA76B

1. Google Search Central. Introduction to structured data. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

2. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

3. Google Search Central. Organization structured data. https://developers.google.com/search/blog/2023/11/introducing-organization-markup

4. Google Search Central. Ranking systems guide. https://developers.google.com/search/docs/appearance/ranking-systems-guide

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 14

Google helpful content guide прямо пропонує перевіряти, чи дає матеріал original information, reporting, research або analysis.[2] Для мене це практичний тест: якщо конкурент може скопіювати всю цінність сторінки, не маючи доступу до наших даних, процесів, експертів або продукту, moat низький. Не кожна сторінка повинна бути дослідженням, але найважливіші сторінки мають містити щось, крім переказу загальнодоступного.

Таблиця 14.1. Що створює non-commodity content на практиці.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 2CB6A84D

Сторінка на 5000 слів може мати нижчу корисність, ніж таблиця на 800 слів, якщо решта - повторення. Я оцінюю coverage через questions/tasks, а не word count. Якщо користувач хоче порівняти три продукти, найціннішим може бути decision table, test methodology і висновок з обмеженнями.

У brief я додаю поле “Evidence required”. Для review це можуть бути screenshots продукту, actual terms, payments, withdrawal test, support response. Для technical guide - code tested on sample, source documentation, before/after. Для research - sample, period, inclusion criteria, calculation. Це дисциплінує команду краще, ніж список “LSI keywords”.

Google spam policies прямо говорять, що scaled content abuse визначається primary purpose і low value, незалежно від того, створено контент AI, людиною чи автоматизацією.[3] Тому “AI content penalty” як загальна теза некоректна. Ризик - масове виробництво взаємозамінних сторінок, factual errors, outdated facts і відсутність added value.

Я розділяю factual freshness і cosmetic freshness. Якщо бонус, ціна, закон, API, product spec або supported feature змінилися, документ треба оновити. Якщо тема фундаментальна, дата “Updated today” без змін не додає інформації. Для large content inventory корисно мати freshness SLA за типом факту, а не за сторінкою в цілому.

Падіння сторінки може бути через demand shift, SERP composition, competitor improvement, outdated section, broken links, changed product або site-wide issue. Тому “оновити статтю” - не діагноз. Я порівнюю query mix, sections, competitors, links, conversion і freshness-sensitive facts. Іноді найкраще рішення - нічого не дописувати, а видалити 40% застарілого.

Коли 4 статті відповідають на один intent, мають слабкий traffic і повторюють одна одну, я частіше консолідую їх у один сильний document, переношу унікальні fragments, роблю redirects і оновлюю internal links. Це не універсальне правило: якщо intents різні, merger зашкодить. Рішення повинне виходити з SERP і task model.

Таблиця 14.2. Мінімальний QA для сторінки, де факти мають значення.

Google рекомендує helpful, reliable, people-first content і прямо запитує про original information/research/analysis; 2026 AI guide підкреслює valuable, unique, non-commodity content; scaled content abuse залежить від мети і value, а не від факту використання AI.[1][2][3] Не існує підтвердженого Google metric “information gain score”, який SEO може виміряти зовнішнім сервісом.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 4A8CCF49

1. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

2. Google Search Central. Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content

3. Google Search Central. Spam policies - scaled content abuse. https://developers.google.com/search/docs/essentials/spam-policies

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 15

Я спочатку описую правила: product → category, category → key products, guide → relevant commercial, brand hub → review/bonus/app, comparison → individual entities, article → deeper explainer. Після цього автоматизація може шукати відсутні edges. Якщо почати з “link every keyword mention”, сайт швидко перетвориться на сітку шуму.

Кнопка з onclick, div із router event або текстова URL не гарантовано є посиланням для crawler. Google документує стандартний <a href> як надійний формат.[1] На SPA я перевіряю DOM після render, але для критичної навігації не хочу залежати від нестандартного JS-handler.

Хороший anchor зменшує невизначеність: “умови бонусу Locowin” кращий за “детальніше”, якщо саме це destination. Але exact-match у кожному місці не потрібен. Я прагну природного variation, який відповідає контексту. Anchor - semantic hint і UX element, а не поле для stuffing.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 86419B8F

Таблиця 15.1. Не всі внутрішні посилання еквівалентні за функцією.

Класична модель PageRank показує важливу властивість: link graph перерозподіляє вагу між nodes. Внутрішній граф - частина цього web graph. Але SEO не бачить внутрішній Google PageRank. Тому власні “internal PR” у crawler - модель за певними припущеннями. Я використовую її порівняльно: які сторінки надмірно центральні, які майже відрізані, як змінюється distribution після нового меню.

Якщо сторінка не варта crawl або internal importance, правильніше переглянути сам link/URL, а не масово ставити nofollow для “збереження PageRank”. Nofollow є hint для qualifying links і має нормальні use cases для untrusted/sponsored зовнішніх links, але не є сучасним універсальним інструментом sculpting внутрішнього графа.

Я join-ю GSC pages із crawl graph. Найцікавіші групи: position 5-20 + high business value + low contextual inlinks; pages із clicks, але без hub links; pages, що канібалізують один cluster і лінкуються однаково; new pages без входів із authority hubs. Потім перевіряю, чи link корисний користувачу. Якщо ні - не додаю його лише заради метрики.

Таблиця 15.2. Що вимірювати після системної перелінковки.

Для великого сайту я генерую candidate links на основі entities/topics, але не публікую їх без правил. Фільтри: не link to same URL; не більше N links із блока; target indexable 200 canonical; relevance threshold; diversity targets; cap sitewide repetition. AI добре генерує candidates і anchors, але QA має перевіряти destination і context.

Google використовує links для discovery і relevancy; crawlable <a href> є рекомендованим форматом; на кожну важливу URL має посилатися хоча б одна сторінка; ecommerce guidance прямо повʼязує internal links із relative importance.[1][2] Точну величину PageRank, що передається конкретним внутрішнім посиланням, ми не бачимо.

1. Google Search Central. Link best practices. https://developers.google.com/search/docs/crawling-indexing/links-crawlable

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код B874AD8B

2. Google Search Central. Ecommerce site structure. https://developers.google.com/search/docs/specialty/ecommerce/help-google-understand-your-ecommerce-site-structure

3. Google Search Essentials. https://developers.google.com/search/docs/essentials

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 16

Якщо template генерує мільйон параметричних URL, downstream ви побачите overcrawl, canonical conflicts, index exclusions, noisy logs, GSC coverage clutter і rank dilution. Лікувати кожний symptom окремо - марно. Я шукаю найранішу точку, де система почала створювати зайвий URL-space.

Автоматичний audit tool не знає business value URL. 404 на старому test path може бути нульовою проблемою; 302 замість 301 на domain migration - великою. Я оцінюю: скільки valuable URL affected; який механізм Search порушено; наскільки впевнені в causality; що коштує fix; чи є risk rollout.

Таблиця 16.1. Моя проста модель пріоритету технічного дефекту.

Я не складаю ці числа у “науковий score”. Вони примушують команду явно проговорити припущення. Часто вже після цього “Critical SEO issue” падає на 30-й рядок roadmap.

У site with 2M pages майже кожна технічна проблема є template problem. Вибірка по 20-50 URL на template дає більше, ніж random crawl 500k URL без класифікації. Я завжди додаю page_type до crawl/GSC/log datasets. Тоді “canonical mismatch 7%” перетворюється на “product variant template 63%”.

Найкраща технічна SEO-система ловить regression у день релізу. Для критичних шаблонів я автоматизую smoke tests: HTTP, robots, canonical, hreflang, structured data, main content selector, links count, title, sitemap inclusion. Раз на квартал audit потрібен для системних речей, але не повинен бути єдиним контролем.

Таблиця 16.2. Мінімальний технічний monitoring layer.

Fix, який економить crawler resources, але не змінює discovery/index/serving valuable pages, може бути nice-to-have. Натомість повільне створення sitemap для 100k daily inventory може мати реальну opportunity cost. Я завжди формулюю issue через expected outcome: “зменшити 3 млн непотрібних fetch/day і скоротити discovery lag new products”, а не “прибрати parameters”.

Screaming Frog, Sitebulb, Ahrefs audit, Botify, Oncrawl бачать різні representations і застосовують власні rules. Я не імпортую їх severity у roadmap. Дані crawler + GSC + logs + server + browser + business inventory мають бути зведені в одну модель. Найважливіше питання: чи дефект існує для Googlebot і чи стосується цінної URL.

Мій deliverable - не PDF на 150 сторінок. Це таблиця системних issues: mechanism, affected template, affected URL count, evidence, business risk, reproduction steps, recommended fix, owner, effort, validation query, rollback risk. До неї можна додати appendix із raw findings. Команда розробки повинна мати змогу відтворити проблему без SEO-перекладача.

Search pipeline складається з discovery/crawl/render/index/serve; Search Essentials визначає мінімальні технічні вимоги; Google має окремі documented controls для robots, status codes, canonical, hreflang, structured data, migrations. Не існує офіційного Google “technical health score”. Будь-який 92/100 - метрика інструмента.

1. Google Search Central. Crawling and indexing overview. https://developers.google.com/search/docs/crawling-indexing

2. Google Search Central. Search Essentials. https://developers.google.com/search/docs/essentials

3. Google Search Central. Latest documentation updates. https://developers.google.com/search/updates

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 120BD0B3

ЧАСТИНА III / ПОБУДОВА SEO-СИСТЕМИ

ГЛАВА 17

Google розділяє multilingual site - контент кількома мовами - і multi-regional site - контент для різних країн/регіонів.[1] es-ES і es-MX можуть бути однією мовою, але різними commercial contexts, currency, regulation, offers. en-US і fr-CA - і різна мова, і locale. Архітектура повинна починатися з product/legal/business differences, а не з того, скільки subfolders хоче SEO.

Google рекомендує різні URL для різних мовних версій, а не одну URL, яка змінює контент через cookie або browser language.[1] Причина практична: crawler має стабільну адресу документа. Locale-adaptive content може бути знайдений не повністю, оскільки Googlebot часто crawls from US і без Accept-Language header.

Таблиця 17.1. Архітектурні варіанти GEO.

Я вибираю модель за операційною реальністю: чи є окремі teams, products, regulations, link acquisition, infrastructure. SEO не повинно змушувати бізнес заводити 20 ccTLD, якщо компанія не може їх якісно підтримувати.

Localized versions повинні посилатися одна на одну, а locale codes бути валідними. Для великого набору сторінок зручніше sitemap hreflang, але логіка та сама. x-default корисний для global selector або fallback, але не є “міткою англійської мови”.[2]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код B8834745

Canonical визначає representative у duplicate cluster; hreflang визначає locale alternatives. Для es-ES і es-MX зі схожим іспанським контентом я зазвичай хочу self-canonical на кожній locale URL плюс взаємний hreflang. Canonical es-MX → es-ES одночасно з hreflang es-MX створює суперечливе повідомлення: “це окрема локаль” і “це не основна версія документа”.[1][3]

Google прямо радить уникати automatic redirect між language versions, оскільки це може завадити користувачам і crawler побачити всі версії.[1] Краща модель: стабільна URL, банер/selector із пропозицією локалі й crawlable links між варіантами. Geo-personalization можна робити всередині локалі, але він не повинен приховувати самі документи.

Google визначає language за visible content, а не lang attribute або URL. Якщо перекладені menu/footer, а основний body лишився англійським, система може не сприймати сторінку як повноцінну локалізацію.[1] Це особливо важливо для UGC, marketplace і programmatic pages, де template перекладений, а value content - ні.

Переклад keyword list із ES у MX або US у UK пропускає local vocabulary, brands, regulation, payment methods і SERP composition. Я використовую translation тільки як seed. Далі окремі GSC properties/filters, local SERPs, native-language review і business data. Навіть той самий англійський query може мати інший commercial intent у різних країнах.

Таблиця 17.2. Що перевіряти автоматично.

Google рекомендує окремі URL для мовних версій, підтримує hreflang у HTML/headers/sitemaps, радить не робити примусові locale redirects і визначає мову за visible content. Для similar same-language regional pages рекомендує поєднувати canonical і hreflang.[1][2][3] Hreflang не є ranking boost; його задача - допомогти показати правильний locale variant.

1. Google Search Central. Managing multi-regional and multilingual sites. https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

2. Google Search Central. Tell Google about localized versions. https://developers.google.com/search/docs/specialty/international/localized-versions

3. Google Search Central. Canonicalization. https://developers.google.com/search/docs/crawling-indexing/canonicalization

4. Google Search Central. International and multilingual topics. https://developers.google.com/search/docs/specialty/international

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 5DA831BE

ЧАСТИНА IV / АВТОРИТЕТ І КОНКУРЕНЦІЯ

ГЛАВА 18

100 links із майже ізольованих сторінок не обовʼязково сильніші за одне посилання зі сторінки, на яку веде багато важливих шляхів. Саме рекурсивність відрізняє PageRank від простого indegree. У практиці це пояснює, чому sitewide junk links і meaningful editorial references не варто рахувати однією колонкою.

Оригінальна модель часто пояснюється random surfer: користувач переходить links і з певною ймовірністю “телепортується” на випадкову сторінку. Це хороша математика для розуміння steady-state importance. Але некоректно стверджувати, що сучасний Google ranking буквально використовує ту саму формулу з тим самим damping factor. Patent/paper ≠ current production weights.

Внутрішній граф ми можемо перепроєктувати. Зовнішній - лише частково впливати через PR, product, outreach, partnerships, citations. Це робить internal linking найконтрольованішим способом змінити topology навколо money pages. Але внутрішній link не створює зовнішню authority з нуля; він перерозподіляє те, що вже є в site graph.

Таблиця 18.1. Що PageRank-модель пояснює добре, а що не треба з неї виводити.

DR, DA, Authority Score, Trust Flow будуються на власних crawls, формулах і link indexes. Це не Google metrics. Я використовую їх як comparative features: фільтр донорів, trend, competitor gap. Але рішення про link acquisition ніколи не приймаю за одним score. Найважливіші питання - чи реальний сайт, чи індексується сторінка, чи має вона реальну аудиторію, чи релевантний context, чи link editorially plausible.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код F451B3B5

Google документує permanent redirects як сильний canonical signal.[3] Це підстава для нормальних міграцій і консолідації. Але точний “% PageRank transfer” Google не публікує. Тому заяви “301 передає 90/95/100% ваги” без джерела - псевдоточність. Практично оцінюємо outcome: canonical selection, indexed target, rankings, crawl і backlinks.

Зовнішній граф не статичний. Pages зникають, редиректяться, стають noindex, змінюють content, links випадають із templates. Тому важливі не тільки acquired links, а retained live links. Для великих проєктів я дивлюся lost referring pages, status distribution, redirect chains і те, чи залишився link у rendered HTML.

PageRank потрібен Senior SEO не як релігія про “juice”, а як дисципліна мислення про граф. Сильні pages повинні мати шляхи до тих документів, які бізнес вважає важливими. External links мають оцінюватися в контексті source page і web graph. Усе інше - моделі з обмеженнями, а не доступ до внутрішнього score Google.

1. Page, Brin, Motwani, Winograd. The PageRank Citation Ranking: Bringing Order to the Web. Stanford technical report. http://ilpubs.stanford.edu:8090/422/1/1999-66.pdf

2. Google Search Central. Link best practices. https://developers.google.com/search/docs/crawling-indexing/links-crawlable

3. Google Search Central. Redirects and Google Search. https://developers.google.com/search/docs/crawling-indexing/301-redirects

4. Brin, Page. The Anatomy of a Large-Scale Hypertextual Web Search Engine. https://infolab.stanford.edu/~backrub/google.html

ЧАСТИНА IV / АВТОРИТЕТ І КОНКУРЕНЦІЯ

ГЛАВА 19

Перед metrics я перевіряю: чи є органічний footprint, нормальна історія, реальні categories, authors, contact/brand, inbound traffic signals, indexed pages, consistency теми. “Сайт” із 300 paid guest posts, нульовою аудиторією і випадковими topics може мати високий DR завдяки старому link graph, але це не робить placement сильним.

Link існує на конкретній page. Я дивлюся indexability, traffic/query relevance, internal inlinks, outbound link density, placement, surrounding text, freshness. Link із тематичної статті, яка сама має visibility й internal support, відрізняється від link на orphan post у “blog” сильного domain.

Таблиця 19.1. Швидкий аудит донорської сторінки.

Я не ставлю задачу “купити 30% exact anchors”. Спершу дивлюся natural language навколо entity/brand. Для brand/review pages нормальні brand, URL, partial, generic, compound anchors. Exact commercial anchors можуть існувати, але якщо portfolio виглядає як шаблон SEO-закупівлі, це додатковий risk. Anchor distribution треба читати разом із source types і timeline.

100 нових referring domains за місяць можуть бути аномалією для маленького локального сайту і нормою для бренду після PR launch. Я нормалізую темп на historical baseline, content/PR events, competitor growth і domain age. Сам по собі “швидкий приріст” не є documented penalty trigger.

Google прямо класифікує buying/selling links for ranking purposes як link spam і рекомендує qualifying paid placements через rel="sponsored" або nofollow.[1][2] Це не заважає ринку paid links існувати. Але senior-level decision повинна включати probability × impact risk, а не тільки expected ranking upside.

PBN дає контроль над anchors, placements і timing, але одночасно створює common ownership / infrastructure / content / linking patterns і single-point-of-failure. Я оцінюю мережу як portfolio risk: footprint, cost to replace, deindex history, outbound saturation, host diversity, ownership leakage. “Немає footprint” - не факт, а гіпотеза, яку неможливо довести ззовні.

Expired domain може мати корисний history/link graph, але Google окремо має policy expired domain abuse: repurpose primarily to manipulate rankings with low-value content.[3] Redirect expired domain на unrelated money site - не “безкоштовний PageRank”, а risk strategy з невизначеним outcome. Перш ніж купувати drop, перевіряю topical history, anchors, snapshots, status continuity, spam, trademarks і чи можна створити legitimate user value.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 27DF42EC

Я розділяю assets: editorial PR, niche edits, guest posts, partnerships, directories/citations, UGC/community, paid placements, owned network. Для кожного type - cost, expected lifetime, traffic/referral value, policy risk, anchor control. Це дає портфель, де один channel не може знищити весь link profile.

1. Google Search Central. Spam policies - Link spam. https://developers.google.com/search/docs/essentials/spam-policies

2. Google Search Central. Qualify outbound links. https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links

3. Google Search Central. Spam policies - Expired domain abuse. https://developers.google.com/search/docs/essentials/spam-policies

4. Google Search Central. Link tagging and link spam update. https://developers.google.com/search/blog/2021/07/link-tagging-and-link-spam-update

ЧАСТИНА IV / АВТОРИТЕТ І КОНКУРЕНЦІЯ

ГЛАВА 20

У GSC я сегментую exact brand, brand+modifier і non-brand. Динаміка brand impressions показує не “authority”, а search demand і visibility власної сутності. Brand+review, brand+login, brand+bonus, brand+support показують окремі user tasks навколо entity. Для нових брендів це сильний health metric, бо його важко підробити внутрішньою перелінковкою.

Name, logo, official URL, contacts, legal company, product names, founders/owners where relevant, social profiles - мають бути узгоджені. Organization structured data може допомогти Google краще understand і disambiguate організацію, а деякі fields впливають на visual elements/knowledge panels.[1] Але markup не повинен описувати те, чого немає у видимому або реальному бізнесі.

Organization/LocalBusiness schema корисна як machine-readable layer, але Google general guidelines вимагають, щоб structured data відповідала visible content і не була misleading.[2] Я додаю лише факти, які можу підтримувати. SameAs не повинен бути списком випадкових профілів, а logo - різним на кожній сторінці.

Згадка бренду на своєму сайті нічого не доводить про зовнішнє існування. Reviews, publishers, business directories, app stores, social profiles, partners, regulators, datasets - створюють external references. Я не стверджую, що кожна mention без link є ranking signal. Я використовую їх як evidence entity footprint і джерело branded discovery.

Таблиця 20.1. Brand SEO без магії.

Для navigational query я інвентаризую top results, sitelinks, knowledge panel, social, reviews, news, autocomplete. Мета не “зайняти всі 10 позицій”, а щоб користувач швидко отримав правильні official destinations і не бачив суперечливих facts. Для regulated affiliate brands окремо важливі support, terms, license/regulatory information.

Generative systems синтезують кілька sources. Якщо official page каже одне, app store друге, partner третє, шанс помилкового synthesis зростає. Я створюю canonical fact sheet на first-party site і підтримую однакові facts на high-authority profiles. Це не “LLM hack”, а data hygiene.

SEO часто називає co-occurrence підтвердженим ranking factor. Публічних даних недостатньо для такої категоричності. Я розглядаю mention поруч із category/entity як спосіб external context і brand discovery, але не приписую йому невідому вагу. Якщо кампанія digital PR збільшує mentions, branded searches і referral traffic - це вже вимірюваний outcome.

Google підтримує Organization/LocalBusiness structured data, використовує її для explicit organization details і може відображати ці facts у knowledge panels/visual elements; structured data має відповідати реальному content.[1][2][3] Не знаємо: універсального “brand score” або формули, що перетворює mentions у ranking.

1. Google Search Central. Organization structured data. https://developers.google.com/search/docs/appearance/structured-data/organization

2. Google Search Central. General structured data guidelines. https://developers.google.com/search/docs/appearance/structured-data/sd-policies

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код BAA83CE9

3. Google Search Central. Establish your business details. https://developers.google.com/search/docs/appearance/establish-business-details

4. Google Search Central. LocalBusiness structured data. https://developers.google.com/search/docs/appearance/structured-data/local-business

ЧАСТИНА IV / АВТОРИТЕТ І КОНКУРЕНЦІЯ

ГЛАВА 21

Review, bonus, app, promo code, withdrawal, payment methods, alternatives - це не просто keyword-modifiers. Кожна page type має окрему decision task. Review допомагає оцінити продукт; bonus - зрозуміти value і terms; app - install/compatibility; withdrawal - time/methods/limits. Якщо всі сторінки мають 80% однакового тексту, структура створена під query variations, а не під користувача.

Google high-quality reviews guidance радить демонструвати knowledge, власний evidence, quantitative measurements, плюси/мінуси й порівняння.[2] Для affiliate це практична перевага: screenshots account, actual onboarding, payment test, terms date, support response, product changes. Не треба вигадувати “ми протестували”, якщо не тестували. У такому випадку чесно описуйте desk research і джерела.

Таблиця 21.1. Сильне порівняння - це decision model, а не список брендів.

Комерційні terms - time-sensitive data. Якщо welcome bonus змінився, стара сторінка може створювати factual error і compliance risk. Я зберігаю fields структуровано: amount, match %, wagering, min deposit, max bet, expiry, code, eligible countries, last verified, source. Це дозволяє QA і масові updates без переписування всього тексту.

Exact-match domain може бути зрозумілим для query і CTR, але Search не зобовʼязаний ранжувати його через слова в domain. У портфельних стратегіях EMD також підвищує ризик doorway-like footprint, якщо десятки domains ведуть до одного merchant/offer через дуже схожі pages. Google doorway policy прямо згадує multiple sites/URLs, створені для охоплення схожих queries і funnel users до одного destination.[3]

Google дає й позитивні приклади affiliate value: additional price information, original reviews, rigorous testing/ratings, navigation of products/categories, product comparisons.[1] Це корисніше за спробу вгадати “мінімальний % унікальності”. Унікальний текст без унікальної value може лишатися thin.

Paid/affiliate relationships потрібно правильно qualifying. Google outbound link guidance рекомендує rel="sponsored" для advertisements/paid placements.[4] Це не заважає tracking parameters чи redirectors, але треба контролювати status, destination, geo behavior і те, щоб crawler/user не потрапляли в різні deceptive flows.

Іспанія, Мексика й Аргентина можуть мати спільну мову, але різні operators, payments, regulation, currency і search behavior. Я не тиражую одну review page 1:1 через AI translation. Спільним може бути factual core продукту; локальними - offer, legal context, payment methods, terms, CTA, support availability і competitor set.

Окрім rankings/clicks: outbound CTR to merchant, click-to-registration, registration-to-FTD/lead approval, revenue/EPC by landing page, brand/non-brand query mix, freshness error rate, pages per merchant, time-to-update offer. SEO page, яка дає багато clicks і поганий downstream conversion, може бути неправильною answer, навіть якщо rank хороший.

1. Google Search Central. Spam policies - Thin affiliation. https://developers.google.com/search/docs/essentials/spam-policies

2. Google Search Central. Write high quality reviews. https://developers.google.com/search/docs/specialty/ecommerce/write-high-quality-reviews

3. Google Search Central. Spam policies - Doorway abuse. https://developers.google.com/search/docs/essentials/spam-policies

4. Google Search Central. Qualify outbound links. https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links

5. Google Search Central. Reviews system. https://developers.google.com/search/docs/appearance/reviews-system

ЧАСТИНА V / AI-ПОШУК

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 450A2D55

ГЛАВА 22

Один user prompt може породити кілька retrieval queries. Наприклад, “best phone for travel under $600” може розкладатися на camera, battery, roaming/eSIM, durability, current prices. Це означає, що одна сторінка може бути relevant не до surface prompt, а до конкретного subtask. SEO не бачить повний fan-out у Google, тому не треба вигадувати точні hidden queries. Bing уже показує sample grounding queries - це ближче до спостережуваних даних.[2]

Документ може потрапити у candidate set і не бути використаний. Інший може бути використаний для factual grounding, але не отримати видиму citation. Третій - отримати link як додаткове джерело. Саме тому “нас немає в AI answer” недостатньо: треба визначити, яку подію вимірює інструмент.

Generative systems можуть витягувати specific information із pages/passages, але Google не вимагає спеціально різати контент на маленькі chunks. 2026 AI guide прямо mythbust-ить ідею спеціального chunking як requirement.[1] Практичний висновок простіший: headings, tables, clear statements і локальна coherence допомагають і людям, і extraction, але не треба ламати нормальний текст заради псевдоформули.

RAG потрібен саме для того, щоб модель спиралася на external current sources. Для SEO це підвищує цінність pages із clear facts, dates, sources, structured product/local data. Але “додати citations” не є ranking hack. Важливіше, щоб page містила correct, specific, updateable information.

Таблиця 22.1. Що ми можемо оптимізувати на різних етапах.

Google прямо пише: щоб page була eligible supporting link у AI Overviews/AI Mode, вона має бути indexed і eligible for snippet у normal Search.[3] Це важлива межа проти “LLM SEO без SEO”: якщо crawler не може отримати page або вона noindex, спеціальна AI schema її не врятує.

Для AI features у Search Google використовує Googlebot controls: noindex, nosnippet, data-nosnippet, max-snippet для того, що можна показувати.[3] Google-Extended стосується інших training/grounding contexts і не є control для AI Overviews/AI Mode Search. Це треба чітко розділяти.

Не знаємо публічно: точний fan-out, кількість retrieval rounds, thresholds, passage scoring, prompt rewriting, weights organic ranking vs other systems. Тому будь-який сервіс, що продає “точний citation score Google AI”, фактично моделює поверхню, а не читає internal system.

1. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

2. Bing Webmaster Blog. AI Performance in Bing Webmaster Tools. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview

3. Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features

ЧАСТИНА V / AI-ПОШУК

ГЛАВА 23

Top-3 page має конкурентну перевагу relevance/authority, але AI answer може потребувати вузький fact із page, яка органічно нижче. Навпаки, top page може бути listicle без конкретного fact для grounding. Тому citation optimization - не “підняти позицію” і не “додати FAQ schema”, а зробити source technically eligible і information-dense для task.

Я не дроблю текст механічно, але прагну, щоб важливе твердження мало subject, value, unit, date/context і source. “Вивід швидкий” слабше, ніж “у нашій вибірці 50 withdrawals median time становив X годин, period Y”. Друге простіше перевірити, процитувати й оновити.

Stable canonical URL, author/byline where expected, publication/update dates, organization identity і links to primary sources допомагають читачу оцінити provenance. Google helpful content guidance окремо ставить питання Who/How і радить accurate authorship.[2] Це не “citation factor”, але правильна publishing hygiene.

2026 AI guide прямо каже, що special schema.org markup для generative AI Search не потрібна.[3] Використовуйте structured data, яка відповідає реальному content і supported Search features. Створювати вигаданий JSON-LD type “AIAnswer” немає сенсу.

Таблиця 23.1. Практичний source-readiness audit.

Відповідь може змінитися через model version, query wording, date, locale, conversation context. Тому один screenshot не доказ “ми цитуємось”. Я вимірюю repeated prompt set, кілька runs/period, platform, locale і фіксую source URLs. Metric - citation frequency у визначеній тестовій системі, а не абсолютна видимість усіх користувачів.

Bing Total Citations не каже placement або click; Google generative impressions не дають dedicated click metric; third-party trackers бачать свої prompts. Бізнесу потрібні окремі layers: citation → referral traffic → assisted conversion → branded demand. Інакше “+40% citations” може не мати жодного economic outcome.

Тести source inclusion мають бути змістовними: додали original dataset, чіткі comparison tables, primary sources, оновили stale facts, створили tool. Не тест “поставили 17 FAQ і 4 schema”. Вимірюємо citation frequency на fixed prompt set, organic performance і user metrics, бажано з control pages.

1. Bing Webmaster Blog. AI Performance. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview

2. Google Search Central. Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код E104DFE6

3. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

4. Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features

ЧАСТИНА V / AI-ПОШУК

ГЛАВА 24

Таблиця 24.1. Реальні нові задачі generative visibility.

Technical accessibility, indexability, useful content, clear entities, original evidence, link graph, brand, freshness, internal architecture не стали іншими механізмами через слово GEO. Якщо consultant продає “GEO” і не перевіряє canonical/index/robots, він оптимізує поверхню без фундаменту.

У AI optimization guide Google розбирає популярні міфи: llms.txt не потрібен для ranking/visibility у Google Search; немає special AI schema; не потрібно штучно chunk-ити content; не треба створювати сторінку під кожен fan-out query.[1] Це дуже корисна межа між measurable work і ritual.

ChatGPT Search використовує OAI-SearchBot для search discovery; OpenAI окремо описує GPTBot для training та інші agents.[2] Bing має IndexNow і AI Performance. Google Search використовує Googlebot controls для AI Overviews/Mode. Отже, platform-specific ops реальні, але це infrastructure, а не “новий content algorithm”.

Якщо агентство обіцяє “GEO visibility +300%”, перше питання: який denominator? Які prompts? Яка platform/model/date/locale? Mention чи citation? Які repetitions? Без protocol цифра не відтворювана. Власне measurement methodology важливіша за назву дисципліни.

Я залишаю SEO як umbrella. Усередині: Search SEO, AI Search visibility, entity/brand visibility, agent accessibility. GEO/AEO/LLMO можна використовувати для комунікації, але в roadmap task називається конкретно: “підняти citation frequency у Bing Copilot для 120 fixed prompts” або “дозволити OAI-SearchBot і перевірити referral traffic”.

1. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

2. OpenAI Help Center. Publishers and developers FAQ. https://help.openai.com/uk-ua/articles/12627856-publishers-and-developers-faq

3. Bing Webmaster Blog. AI Performance. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview

ЧАСТИНА V / AI-ПОШУК

ГЛАВА 25

Навіть невеликий dataset може бути сильним, якщо методологія зрозуміла. 2 млн GSC queries, 500 support tickets, 100 withdrawal tests, price history, crawl logs - це матеріал, який competitor не може чесно відтворити без власного збору. Не треба завжди “велике дослідження”: іноді достатньо 50 observations із чіткими limitations.

Experiment - не “ми змінили title і traffic виріс”. Потрібні hypothesis, sample, control/comparison, timeframe, confounders, result, limitation. Навіть якщо test imperfect, transparent methodology створює більшу value, ніж категорична порада без evidence.

Інструмент часто закриває task краще за статтю. Mortgage calculator, hreflang validator, odds converter, bonus wagering calculator, SERP diff, log parser. Такі pages можуть отримувати links, repeat visits і citations, бо мають functional value. LLM може пояснити формулу, але користувач усе одно цінує готовий tool.

Photos, screenshots, screen recordings, measurements, support transcripts, code repos, before/after, invoices/terms snapshots - роблять claims перевірюваними. Google review guidance прямо радить evidence of own experience і quantitative measurements.[1]

Таблиця 25.1. Шкала “комодитизації” контенту.

У regulated topics цінність часто не у “досвіді автора”, а в точному читанні законів, official docs, terms, APIs, regulator databases. Це теж non-commodity work: знайти current source, правильно інтерпретувати scope, зафіксувати cut-off і не вигадати те, чого документ не каже.

Senior audience цінує не “що таке canonical”, а “як за 30 хвилин відрізнити canonical conflict від index quality issue”. SOP, query, regex, spreadsheet model, decision tree - це executable knowledge. У цій книзі я навмисно додаю такі артефакти, бо їх відкривають під час роботи.

AI добре прискорює clustering, extraction, draft, SQL, code, QA suggestions. Але proprietary value має приходити з реальних inputs. Якщо input - ті самі 10 top results, output лишається derivative незалежно від стилю.

1. Google Search Central. Write high quality reviews. https://developers.google.com/search/docs/specialty/ecommerce/write-high-quality-reviews

2. Google Search Central. Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 3A450EDC

3. Google Search Central. Optimizing for generative AI features. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

ЧАСТИНА V / AI-ПОШУК

ГЛАВА 26

Google Search Console generative report показує impressions у generative features і dimensions pages/countries/dates/devices. Він не дає query dimension, dedicated clicks/CTR/position для generative view.[1] Тому з нього можна чесно сказати “URL отримує exposure”, але не “цей prompt дав 14 clicks”.

Bing AI Performance показує Total Citations, Average Cited Pages, page-level citation activity і sample grounding queries.[2] Це інша telemetry. Citation count не означає ranking або placement. Grounding queries - sample, не повний log. Але для content gap це унікальний first-party signal.

OpenAI описує OAI-SearchBot і можливість public websites зʼявлятися в ChatGPT Search.[3] На своїй стороні можна виміряти referrals sessions/conversions із known referrers. Але no-click brand mention усередині відповідей платформа не дає власнику сайту як повний analytics feed, тому third-party prompt monitoring лишається вибіркою.

Я будую набір prompts за tasks: discovery, comparison, brand, category, support. Фіксую exact wording, language, locale, model/platform, date, fresh/new session, repetition count. Metric називаю “citation frequency у нашому test set”, а не “частка ринку AI”.

Таблиця 26.1. Мінімальний AI measurement dashboard.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 090EC73A

Можна рахувати частку citations бренду серед competitor citations у фіксованому prompt set. Формула корисна для trend, але залежить від set composition. Якщо завтра додати 100 prompts, де конкурент сильний, metric зміниться без реальної зміни platform. Тому version prompt set - обовʼязкове поле.

Для кожного prompt я зберігаю не тільки current source, а history. Citation volatility = частка runs/періодів, де source set змінюється. High volatility означає, що один screenshot взагалі не репрезентативний; low volatility дає сильнішу основу для experiment.

Корисний research metric - overlap cited domains/URLs із top organic results. Але correlation не означає, що organic rank спричинив citation. Обидва можуть бути наслідком shared relevance/quality/authority systems. Google сам говорить, що AI features rooted in core ranking and quality systems.[4]

Якщо user бачить бренд у AI, потім через день робить branded search і конвертується, стандартний last-click не віддасть credit AI. Можна дивитися branded lift, geo/period experiments, post-view surveys, incrementality. Але без user-level exposure data причинність слабка. Я не записую весь ріст direct traffic в “AI-assisted”.

Google дає direct generative impressions; Bing дає direct citations і sample grounding queries; website може виміряти referral traffic; third-party trackers дають controlled samples. Повного cross-platform census prompts/answers/clicks не існує для site owner. Хороший dashboard показує цю межу, а не приховує її одним score.

1. Google Search Central. Search Generative AI performance reports. https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports

2. Bing Webmaster Blog. AI Performance in Bing Webmaster Tools. https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview

3. OpenAI Help Center. Publishers and developers FAQ. https://help.openai.com/uk-ua/articles/12627856-publishers-and-developers-faq

4. Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features

ЧАСТИНА VI / МАСШТАБ

ГЛАВА 27

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код B8549D30

Я використовую простий gate: URL створюється лише тоді, коли він має окрему комбінацію наміру, даних і корисної дії. “Casino X bonus”, “Casino X withdrawal time” і “Casino X app” можуть бути різними сторінками, якщо SERP, очікування користувача і фактичні дані різні. Але створити по сторінці для кожної перестановки “best casino + місто + payment method + device” без окремої цінності — це вже комбінаторний шум.

Практично gate можна формалізувати чотирма питаннями: чи існує окремий попит; чи відрізняється набір фактів; чи можна зробити сторінку кориснішою за загальну категорію; чи має сторінка окремий шлях до конверсії. Якщо дві або більше відповідей “ні”, я не генерую URL автоматично.

Таблиця 27.1. Рішення про створення програмної сторінки.

Найнебезпечніша властивість programmatic SEO — геометричне зростання можливих URL. 200 брендів × 40 способів оплати × 20 країн × 3 пристрої — це вже 480 000 комбінацій. Більшість із них може не мати окремого попиту, даних або сенсу. Саме тут потрібен eligibility layer до генератора сторінок.

Я спочатку рахую повний теоретичний простір комбінацій, а потім поетапно відсікаю: комбінації без даних, без попиту, без достатньої відмінності, із юридичними обмеженнями, дублікати наміру, комбінації з нульовим inventory. Те, що залишилося, — не “всі можливі URL”, а індексований продукт.

Шаблон може бути один і той самий для 50 000 сторінок, якщо фактичне наповнення різне й корисне. І навпаки, 50 000 “унікальних” AI-текстів можуть бути семантично взаємозамінними. У сильних програмних проєктах основний актив — dataset: ціни, наявність, правила, коефіцієнти, характеристики, географія, реальні відгуки, вимірювання або інші структуровані факти.

Текстовий шар повинен пояснювати дані, а не маскувати їхню відсутність. Якщо джерело даних має дату, версію або SLA оновлення, це варто зберігати в моделі даних. Тоді можна автоматично знаходити сторінки зі stale facts, а не чекати, поки помилку побачить користувач.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 58A8B013

Шаблон — це не “H1 + 800 слів”. Це набір компонентів із правилами появи: summary, ключові факти, таблиця, порівняння, FAQ, калькулятор, карта, availability, CTA, докази, джерела. Для кожного компонента потрібні умови: показувати лише коли дані достатні; не підставляти порожні заглушки; мати fallback, якщо зовнішнє API недоступне.

На великих сайтах я тестую шаблони на крайніх випадках: найкоротший dataset, найдовші назви, нульове inventory, одна одиниця inventory, відсутня ціна, змішана валюта, невідомий бренд, кілька мов. Саме крайні випадки створюють тисячі thin або broken pages після масштабування.

Programmatic SEO генерує дублікати не тільки на рівні тексту. Два URL можуть показувати той самий набір об’єктів через інший порядок фільтрів, різні параметри або альтернативні назви сутності. Перед запуском потрібен детермінований ключ сторінки: набір полів, який однозначно визначає інформаційну потребу.

Canonical не повинен бути методом приховування поганої URL-моделі. Якщо система може не створювати дубль, краще не створювати його. Canonical — сигнал для консолідації, але Google все одно обирає канонічну версію сам, використовуючи кілька сигналів. [2]

Програмні сторінки мають бути частиною графа сайту. Якщо десятки тисяч URL існують лише в sitemap, це ознака слабкої інформаційної архітектури. Google прямо пояснює для ecommerce, що зв’язки між сторінками й кількість переходів за посиланнями допомагають зрозуміти структуру і відносну важливість сторінок.[3]

Я будую hub pages за сутностями і атрибутами, а не випадкові “related pages”. Кожен URL повинен мати зрозуміле батьківське місце: країна → категорія → підкатегорія → об’єкт; бренд → продукт → варіант; ліга → команда → матч. Це одночасно полегшує навігацію, виявлення і контроль сиріт.

На великому програмному сайті sitemap — не просто спосіб “відправити URL Google”. Я використовую sitemap-файли як керовані сегменти inventory: за типом сторінки, країною, мовою, датою запуску або статусом. Це дозволяє зіставляти submitted URLs з indexed URLs і швидше локалізувати проблему.

У sitemap треба класти канонічні URL, які сайт реально хоче бачити в індексі. Якщо у файлі змішані 200, 301, noindex, canonical-to-other і 404, сам sitemap перестає бути корисним як діагностичний набір.

Коли генерується 100 000 URL за день, питання “чи можемо ми згенерувати?” стає менш важливим за “чи може пошукова система нормально обробити inventory?”. Google окремо попереджає, що фасетна навігація може створювати практично безмежну кількість URL, спричиняти зайве сканування й уповільнювати виявлення важливого контенту.[4]

Перед великим запуском я роблю ramp-up: невеликий сегмент, перевірка crawl/index/traffic, потім наступна партія. Масовий реліз без контрольної групи ускладнює діагностику: коли половина URL не індексується, незрозуміло, проблема в шаблоні, попиті, якості даних, внутрішніх посиланнях чи просто в темпі запуску.

AI корисний для перетворення структурованих даних у читабельні пояснення, генерації чернеток, перевірки пропущених полів, нормалізації назв, класифікації intent. Але AI не повинен вигадувати відсутні атрибути. Якщо поле `withdrawal_time` порожнє, модель не має “знати типове значення”. Порожнє поле має викликати fallback або блокування компонента.

На production-рівні я розділяю factual layer і linguistic layer. Факти приходять із контрольованого джерела й передаються моделі як immutable inputs. Модель може пояснити їх, але не змінювати. Після генерації автоматичний QA перевіряє числа, валюти, бренди, URL, дати й допустимі значення.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 8A203656

Програмний сайт не можна тільки нарощувати. Потрібна політика видалення або консолідації. Я відстежую сторінки без показів, без унікальних даних, з нульовим inventory, з постійним canonical conflict, дублікати intent, застарілі сутності. Але “0 кліків за 90 днів” не є автоматичною підставою видалити URL: сезонність, long-tail і роль сторінки в архітектурі можуть бути важливішими.

Pruning має бути сегментним експериментом. Видалити 50 000 URL і потім пояснювати загальну зміну трафіку — слабкий дизайн. Краще сформувати однорідну групу, чіткий критерій, контрольний сегмент і період спостереження.

Для programmatic SEO я не дивлюся тільки на загальний organic traffic. Мінімальний dashboard має показувати inventory, discoverability, crawl, indexation, impressions, clicks, conversions і freshness за типом сторінки. Тоді “50 000 сторінок дали +20% трафіку” можна розкласти: скільки реально проіндексовано, які шаблони дають результат, де є overcrawl і скільки URL не створили цінності.

Таблиця 27.2. Мінімальний контроль programmatic SEO.

1. Google Search Central. Spam policies for Google Web Search. https://developers.google.com/search/docs/essentials/spam-policies — Scaled content abuse і doorway abuse.

2. Google Search Central. Consolidate duplicate URLs. https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls — Canonicalization і консолідація дублів.

3. Google Search Central. Help Google understand your ecommerce site structure. https://developers.google.com/search/docs/specialty/ecommerce/help-google-understand-your-ecommerce-site-structure — Внутрішня структура та виявлення товарів.

4. Google Search Central Blog. Crawling December: Faceted navigation. https://developers.google.com/search/blog/2024/12/crawling-december-faceted-nav — Комбінаторний простір URL і overcrawl.

ЧАСТИНА VI / МАСШТАБ

ГЛАВА 28

Перший артефакт великого сайту — не crawl export, а URL inventory. Я збираю всі джерела: внутрішній crawl, sitemap, CMS/database, Search Console, server logs, analytics, redirects. Потім нормалізую URL і класифікую за page type та бізнес-статусом.

Це дає категорії, яких не видно з одного джерела: URL існує в базі, але не має внутрішніх посилань; URL відвідує Googlebot, але його вже немає в sitemap; сторінка отримує трафік, але CMS вважає її discontinued; редирект живе роками, хоча жодне внутрішнє посилання на нього вже не веде.

Для кожного шаблону я документую контракт: який HTTP status очікуємо; чи indexable; canonical; robots directives; sitemap inclusion; structured data; внутрішні link sources; expected content components; target country/language; primary conversion event. Це дозволяє автоматично тестувати не “сайт”, а правила.

Якщо product page раптом починає віддавати `noindex` через помилку release, 200 випадкових URL у QA можуть не зловити регресію. Контрактний тест на representative sample кожного template ловить її до масштабування.

Таблиця 28.1. Приклад контракту шаблону.

На великих ecommerce/marketplace сайтах найбільш типова причина URL explosion — фільтри. Google прямо називає faceted navigation найпоширенішим джерелом overcrawl-скарг, які бачить команда Search.[1] Проблема не у фільтрах як UX, а в тому, що кожна комбінація може стати crawlable URL.

Я ділю фасети на три групи: indexable landing pages з доведеним попитом; crawlable, але неindexable технічні стани, якщо вони потрібні продукту; і states, які взагалі не повинні створювати окремий URL для краулера. Головна помилка — дозволити frontend генерувати повний combinatorial graph, а потім намагатися “виправити SEO” canonical-тегами.

На великих сайтах sitemap треба використовувати як вимірювальні сегменти. Я розділяю файли за типом сторінки, країною, мовою, іноді за lifecycle. Тоді Page indexing / API / власні моніторинги можна зіставляти з конкретним inventory.

Sitemap-файли не повинні ставати архівом усіх URL, які колись існували. Вони мають описувати поточний канонічний набір URL, який команда хоче бачити в пошуку. Інакше submitted metric змішує активні сторінки з редиректами, noindex і 404.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 469DEC61

Search Console Crawl Stats дає корисний агрегат, але логи відповідають на питання на рівні URL: що саме запитував bot, коли, з яким статусом, скільки байтів і як довго відповідав сервер. На великому сайті це єдиний спосіб побачити, наприклад, що Googlebot витрачає 35% запитів на параметричні URL, які команда не вважає важливими.

Не можна сліпо довіряти User-Agent. Для серйозного аналізу bots треба верифікувати згідно з рекомендаціями Google, а потім уже рахувати crawl frequency. Інакше “Googlebot” у логах може бути стороннім scraper.

Мене цікавить не “у Google 2,3 млн сторінок”, а частка eligible URL за типом. 90% indexation для продуктів і 15% для category landing pages — зовсім інша проблема, ніж рівномірні 60% для всього сайту.

Я будую funnel: inventory → eligible → discovered → crawled → indexed → impressions. Якщо просідання між discovered і crawled, дивлюся crawl demand/architecture. Якщо crawled → indexed, дивлюся canonical/duplication/quality/soft 404. Якщо indexed → impressions, проблема вже в retrieval/relevance/competition, а не в “індексації”.

Великі сайти часто втрачають SEO не через “Google update”, а через реліз. React component прибрав `<a href>`, CMS додала noindex, canonical почав вести на staging domain, JSON-LD перестав містити price, hreflang генерує 404. Один deployment може торкнутися мільйонів URL.

Тому я тримаю synthetic SEO tests у CI/CD або хоча б щогодинному моніторингу representative URLs. Мінімум: status, robots, canonical, hreflang, title, H1, body presence, ключові structured-data properties, внутрішні посилання, render result. У production додаю alert тільки на зміни, які мають масштаб.

Великий сайт природно накопичує discontinued products, порожні categories, старі campaigns, профілі без контенту, query pages, duplicates. Але масове “pruning” без карти залежностей може знести сторінки, які передають внутрішню вагу, мають backlinks або сезонний попит.

Я приймаю рішення по класах. Якщо товар знято назавжди й немає еквівалента — 404/410 може бути правильним. Якщо є чіткий successor — redirect. Якщо category тимчасово порожня, рішення залежить від likelihood повернення inventory і користі сторінки. Якщо URL не має попиту, даних, links і ролі в навігації — часто краще не підтримувати його.

На великому сайті ручний SEO-аудит — це sampling. Він потрібен, але не є системою контролю. Я автоматизую те, що детерміноване: extraction, classification, comparisons, contract tests, anomalies. Людина залишається для діагностики, пріоритизації і рішень із неоднозначними trade-offs.

Ключова метрика SEO-команди на такому сайті — не кількість знайдених “issues”, а час від регресії до виявлення і від виявлення до виправлення. Incident, який 10 хвилин торкався 2 млн URL, майже завжди дешевший за “невеликий canonical bug”, що жив шість тижнів.

Після певного масштабу Excel перестає бути джерелом правди. Я зводжу Search Console bulk export, analytics, logs, inventory і crawler output у warehouse. Google прямо рекомендує BigQuery exports для детального спільного аналізу Search Console і GA, коли потрібна максимальна деталізація й мінімум розбіжностей.[2]

Не потрібно будувати data platform “бо це модно”. Поріг простий: якщо одна й та сама таблиця збирається вручну щотижня, якщо історія втрачається, якщо різні люди рахують metric по-різному — пора формалізувати pipeline.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код E190546C

1. Google Search Central Blog. Crawling December: Faceted navigation. https://developers.google.com/search/blog/2024/12/crawling-december-faceted-nav — Ризик combinatorial URL space і overcrawl.

2. Google Search Central. Using Search Console and Google Analytics data for SEO. https://developers.google.com/search/docs/monitor-debug/google-analytics-search-console — Спільний аналіз і BigQuery exports.

3. Google Search Central. Ecommerce site structure. https://developers.google.com/search/docs/specialty/ecommerce/help-google-understand-your-ecommerce-site-structure — Граф внутрішніх посилань.

4. Google Search Central. Ecommerce URL structure. https://developers.google.com/search/docs/specialty/ecommerce/designing-a-url-structure-for-ecommerce-sites — URL, canonical, filters, pagination.

ЧАСТИНА VI / МАСШТАБ

ГЛАВА 29

Сильні причини: юридично окремий бренд, окремий продукт, суттєво інший ринок із власною командою і контентом, різна регуляція, acquisition або продаж бізнесу, технічна ізоляція, яка має реальну ціну на користь незалежності. Слабка причина — “хочемо зайняти ще один результат”.

Для міжнародного SEO окремі ccTLD можуть бути логічними, але не є єдиним варіантом. Підкаталоги часто простіші для консолідації authority, deployment і measurement. Архітектура повинна виходити з бізнесу, а не з магії доменної зони.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код B465F824

Якщо у вас 20 доменів, зміна privacy page, schema, tracking або footer link — це не одна задача, а distribution problem. Я рахую не тільки domain/hosting cost, а engineering hours, content maintenance, link acquisition, monitoring, compliance і incident surface.

Саме тому маленькі affiliate portfolios часто мають технічний борг, який не видно в P&L: half-broken analytics, expired certificates, stale bonuses, noindex після redesign, різні canonical rules. Це не “дрібниці”, а множник ризику.

Таблиця 29.1. Прихована ціна додаткового домену.

Два домени можуть конкурувати за однакову query space. Це не завжди погано: різні бренди справді можуть бути конкурентами. Але якщо вони належать одній команді й мають однакову пропозицію, ви самі розподіляєте links, content і brand signals між копіями.

Я будую cross-domain query matrix: які domains отримують impressions за одні й ті самі query clusters, де ranking URLs змінюються, де один домен витісняє інший, чи є різниця conversion rate. Іноді другий домен дає incremental reach. Іноді це просто дорожчий спосіб отримати той самий трафік.

Multi-GEO не означає “перекласти шаблон”. Країни відрізняються валютою, payment methods, регуляцією, delivery, availability, terms, support, competitors, brand recognition. Сторінка для Іспанії й сторінка для Німеччини мають різнитися не мовою, а фактичним продуктом.

Якщо одна команда не може підтримувати локальні факти, hreflang не зробить сторінку локально корисною. Hreflang допомагає співвіднести локалізовані версії, але не створює релевантність сам по собі.

Купівля старого домену сама по собі не заборонена. Google визначає expired domain abuse через ціль: домен купують і перепрофільовують переважно для маніпуляції rankings, розміщуючи low-value content. В офіційних прикладах є casino content на колишньому сайті початкової школи.[1]

Тому в оцінці дропа мене цікавить не DR. Я дивлюся історію тематики, backlinks, redirects, власників, індексацію, spam anchors, legal/trademark risk і чи має новий продукт правдоподібний зв’язок із минулим. Навіть сильний link graph не перетворює нерелевантне перепрофілювання на довгостроковий asset.

Коли портфель консолідується, міграція повинна мати URL mapping, 1:1 redirects там, де є еквівалент, оновлені internal links, canonicals, hreflang, sitemaps, analytics і monitoring. Google попереджає, що під час site move rankings можуть коливатися, поки система recrawl/reindex URL; більші сайти можуть відновлюватися довше.[2]

Не варто редиректити тисячі нерелевантних сторінок на homepage лише “щоб передати вагу”. Redirect має вести до найближчого реального еквівалента. Якщо еквівалента немає, 404/410 може бути чистішим рішенням.

Портфель починає бути керованим, коли у всіх сайтів одна telemetry model: однакові event names, dashboard schema, uptime checks, canonical tests, content freshness fields, ownership. Не обов’язково один hosting або CMS; важлива однакова мова контролю.

Я зводжу domains у registry: owner, purpose, geo, brand, CMS, DNS provider, analytics property, Search Console, release channel, renewal date, regulatory scope, critical contacts. Це банально, але саме відсутність такого реєстру перетворює 50 доменів на хаос.

У affiliate бізнесі домен може бути активом із traffic, backlinks, brand demand і cash flow. Тому рішення “залишити / інвестувати / об’єднати / продати / закрити” краще приймати як portfolio management.

Я оцінюю contribution margin домену після реальних SEO-витрат, а не тільки gross revenue. Сайт із $2k revenue і $1.8k links/content/maintenance — не такий самий актив, як сайт із $1.5k revenue і $200 підтримки. Це важливо, коли бюджет обмежений.

Коли десятки майже однакових доменів створені лише для захоплення схожих SERP і ведуть до тієї самої пропозиції, ви наближаєтеся до doorway pattern, який Google прямо описує у spam policies.[1] Я не оцінюю це морально; це питання risk/reward. Але називати таку модель “безпечним white-hat multi-domain SEO” — неправильно.

Для кожної тактики в портфелі я фіксую: policy status, ймовірність detection/enforcement, blast radius, recoverability і бізнесову залежність. Risk management починається з чесного називання механіки.

1. Google Search Central. Spam policies. https://developers.google.com/search/docs/essentials/spam-policies — Doorway abuse, expired domain abuse, scaled content abuse.

2. Google Search Central. Site moves with URL changes. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes — Міграції між доменами.

3. Google Search Central. International sites. https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites — Варіанти міжнародної архітектури.

4. Google Search Central. Localized versions / hreflang. https://developers.google.com/search/docs/specialty/international/localized-versions — Зв’язування мовних і регіональних версій.

ЧАСТИНА VI / МАСШТАБ

ГЛАВА 30

Я починаю з задач, де найбільше людського копіювання: exports, URL normalization, регулярні comparisons, template checks, anomaly detection. Потім — класифікація page types, mapping queries, internal-link suggestions. І лише після цього — генеративні задачі.

Хороша автоматизація повинна економити senior time, а не створювати новий dashboard, який ніхто не читає. Перед розробкою я рахую minutes per run × runs per month × loaded cost. Якщо скрипт економить 40 хвилин раз на квартал, його підтримка може коштувати дорожче.

Search Console UI зручний для діагностики руками, API — для керованих запитів і інтеграцій, bulk export — для повної історичної аналітики в BigQuery. Google документує, що Search Analytics API має default 1 000 rows, `rowLimit` до 25 000 і pagination через `startRow`; верхня доступна межа даних для API описувалася як до 50 000 рядків на день на сайт і search type.[1][2]

Bulk export щодня вивантажує performance data в BigQuery без щоденного row limit, але anonymized queries вилучаються з міркувань privacy.[3] Це робить bulk export кращою базою для warehouse і довгих trend analysis, якщо обсяг виправдовує BigQuery.

GSC вимірює взаємодію з Google Search, GA4 — поведінку після завантаження вашого сайту. Через різні визначення, timezone, canonicalization, privacy і tracking coverage цифри не повинні збігатися 1:1. Google прямо рекомендує використовувати обидва джерела разом і, для максимальної деталізації, зводити bulk exports у BigQuery.[4]

Автоматизація повинна зберігати source semantics. Не можна створити “єдину правду”, просто склавши GSC clicks і GA sessions у одну колонку. Це різні події.

Поганий pipeline легко перенести з Excel у Python і отримати автоматизований хаос. Перед кодом я визначаю canonical dimensions: `date`, `site`, `url`, `page_type`, `country`, `device`, `query_cluster`, `channel`, `event`. Потім кожне джерело мапиться до цієї схеми.

URL normalization має бути детермінованою: protocol, host, trailing slash, parameters, case, fragments. Якщо crawler і GSC називають одну сторінку по-різному, joins даватимуть фальшиві “missing URLs”.

Не кожне -20% WoW — інцидент. Я порівнюю з day-of-week, seasonality, rolling baseline і update dates. На ранньому етапі прості правила часто кращі за складну ML-модель: якщо clicks падають >30% YoY у page type із >10k baseline і impressions теж падають, створити alert; якщо clicks падають, а impressions стабільні — перевірити CTR/SERP.

Alert повинен вести до action. Якщо команда отримує 200 повідомлень на день, система автоматично навчає людей їх ігнорувати.

QR: компактна версія коду для копіювання без передруковування.

КОД 30.1. Простий контроль аномалій між двома GSC-експортами.

Коли скриптів більше трьох, потрібен scheduler і журнал виконання. Це може бути GitHub Actions, Cloud Run/Functions, cron, Airflow, Make/n8n — інструмент залежить від масштабу. Важливі retries, timestamp, input version, output location і alert при failure.

Я зберігаю raw data окремо від transformed data. Якщо логіка розрахунку змінилася, raw дозволяє перебудувати історію. Якщо ви зберігаєте лише фінальний Excel, зміна формули робить попередні місяці непорівнюваними.

Regex, page-type rules, redirects, schema generators, prompt templates — це код або конфігурація, а значить, мають жити у version control. Git дає answer на питання “хто і коли змінив правило”, а не тільки latest file у Drive.

Для критичних змін я додаю test cases. Наприклад, page classifier має список 50 URL з очікуваними типами. Якщо нове regex правило раптом класифікує `/casino/brand/review/` як category, тест впаде до production.

LLM може генерувати SQL, пояснювати anomaly, перетворювати natural-language question у query. Але production pipeline не повинен залежати від того, що модель “пам’ятає” schema. Я передаю schema, дозволені таблиці, приклади й обмеження, а SQL проходить validation.

Для необоротних дій — зміна redirects, видалення URL, publishing — потрібен human approval. AI може підготувати diff, але не має автоматично “прибирати сміття”, якщо definition сміття не формальна.

API keys, service-account JSON, database passwords не повинні лежати в коді або prompt history. Використовуйте secret storage, environment variables, мінімальні permissions і ротацію. Особливо це важливо, коли LLM отримує доступ до файлів або репозиторіїв.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 56E533AB

SEO automation швидко стає частиною production infrastructure. Її потрібно захищати так само, як інші internal tools, а не як “невинний скриптик маркетолога”.

Мій пріоритет: data collection, monitoring, recurring audits, changelogs, anomaly detection, content inventory, link inventory, indexation segmentation, release QA. Не автоматизую фінальне рішення про intent, brand positioning, risk acceptance і бюджет лише тому, що це можливо.

Найкращий результат автоматизації — команда витрачає менше часу на добування цифр і більше на постановку гіпотез та перевірку рішень.

1. Google Search Console API. Query Search Analytics data. https://developers.google.com/webmaster-tools/v1/how-tos/search_analytics — Pagination і rowLimit.

2. Google Search Central Blog. Performance data deep dive. https://developers.google.com/search/blog/2022/10/performance-data-deep-dive — Ліміти API і природа даних.

3. Google Search Central Blog. Bulk data export. https://developers.google.com/search/blog/2023/02/bulk-data-export — Щоденний BigQuery export без daily row limit; anonymized queries вилучаються.

4. Google Search Central. Search Console + Analytics. https://developers.google.com/search/docs/monitor-debug/google-analytics-search-console — Спільний аналіз джерел.

ЧАСТИНА VI / МАСШТАБ

ГЛАВА 31

Keyword clustering через LLM корисний для semantic grouping, але без чіткої unit of clustering результат плаває. Одні й ті самі keywords можна кластеризувати за SERP overlap, intent, entity, page type або funnel stage. Це різні задачі.

Я задаю hierarchy: спочатку market/task, потім entity, потім intent, потім desired page type. Для high-value cluster перевіряю SERP руками або через дані. LLM не має доступу до фактичного SERP, якщо ви його не передали.

Модель добре класифікує вже зібрані SERP features: commercial/listicle/product/local/forum/video. Але prompt повинен отримувати title, URL, snippet, features, а не тільки keyword. Інакше це intent guessing за фразою.

На sample із 100–300 queries я роблю manual labels, потім рахую confusion matrix. Якщо “review” і “comparison” постійно плутаються, змінюю taxonomy, а не просто модель.

AI може швидко підсумувати конкурентні coverage, entities, questions і gaps. Але brief стає корисним лише після додавання власної позиції: first-party data, експеримент, product knowledge, constraints, source requirements. Інакше brief оптимізує автора на середнє арифметичне SERP.

Я прямо додаю секцію “що НЕ повторювати”, щоб commodity paragraphs не займали половину статті. Для factual topics додаю список primary sources, які мають бути перевірені до drafting.

Це один із найкращих AI use cases. З тисяч сторінок можна витягнути brand, country, payment methods, currencies, regulators, product attributes. Але output краще змусити відповідати JSON schema з enum, nullable fields і source snippets.

Після extraction я запускаю deterministic validation: unknown enum, invalid dates, impossible currency/country pair, missing source. Модель не має “виправляти” невідоме значення без позначки uncertainty.

LLM різко знижує поріг входу в технічний аналіз. SEO може описати задачу, отримати SQL і розібрати його з поясненням. Але код треба тестувати на sample. Найнебезпечніший формат помилки — синтаксично правильний SQL, який рахує не те.

Я прошу модель спочатку описати assumptions і grain таблиці, потім SQL, потім три sanity checks. Якщо query агрегує GSC, треба прямо уточнити dimensions, canonical URL behavior, date timezone і denominator. “Працює без error” не означає “правильно”.

LLM може допомогти написати parser, regex для bots, класифікувати URL patterns, пояснити anomaly. Але raw logs краще агрегувати детерміновано, а моделі передавати summaries. Це дешевше, приватніше і контрольованіше.

Наприклад, замість мільйона рядків передаємо top page types by Googlebot hits, status distribution, response-time percentiles, top parameters, day-over-day change. Модель допомагає сформувати hypotheses, а факт залишається в aggregate data.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 3FE16448

AI добре генерує candidate anchors і semantic matches, але не знає вашої graph strategy, якщо її не описати. Я передаю source URL, target URL, title/H1, page type, existing anchors, priority score і exclusions.

Автоматичне вставлення links без QA легко створює circular boilerplate, надлишкові anchors або links у нерелевантних місцях. Тому AI пропонує candidates, а deterministic layer перевіряє duplicates, max links, target status і canonical.

Модель корисна як перший шар перекладу й локалізації, але regulated verticals потребують local reviewer або primary-source checks. Currency, tax, legal age, bonus terms, licensing і payment methods не можна “перекласти” з іншого GEO.

Я відділяю language QA від market QA. Текст може бути ідеально іспанським і фактично неправильним для Іспанії.

Без eval set AI workflow перетворюється на смак. Я створюю невеликий набір реальних examples із expected output і edge cases. Для classification рахую accuracy/F1; для extraction — field-level precision/recall; для generation — factual error rate, citation coverage, style violations.

Коли змінюється модель або prompt, проганяю той самий set. Це єдиний спосіб зрозуміти, чи “новіша модель” реально краща саме для нашої задачі.

Таблиця 31.1. Приклад контролю AI-задач.

Фраза “AI іноді галюцинує” занадто абстрактна. Я задаю допустимий error budget. Для brainstorm 10% помилкових ідей не страшні. Для фінансового розрахунку 0,1% може бути неприйнятним. Це одразу визначає архітектуру QA.

У high-stakes factual content модель не повинна генерувати claim без source field. Якщо source відсутній, output має бути `SOURCE_REQUIRED`, а не правдоподібний текст.

Коли AI читає web pages, connected docs або user-generated text, вхід може містити інструкції, які конфліктують із нашою задачею. Тому external content треба трактувати як data, а не authority.

Не передавайте в модель secrets, приватні клієнтські дані й production credentials без відповідних enterprise controls. AI-інтеграція — це частина data governance, а не тільки productivity feature.

Якщо всі competitors можуть за 30 секунд отримати однаковий “SEO article”, саме використання моделі не є moat. Перевагу створюють inputs, workflow, data, testing, distribution і speed of iteration.

Тому я оцінюю AI не за кількістю створеного контенту, а за скороченням cycle time: від питання до перевіреної відповіді, від anomaly до діагнозу, від dataset до production page, від brief до published evidence.

1. Google Search Central. Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content — Вимоги до корисності й надійності output.

2. Google Search Central. AI optimization guide. https://developers.google.com/search/docs/fundamentals/ai-optimization-guide — Generative AI не створює окремої магічної SEO-дисципліни.

3. Google Search Central. Spam policies. https://developers.google.com/search/docs/essentials/spam-policies — Scaled content abuse оцінюється за метою і цінністю, а не самим фактом AI.

ЧАСТИНА VII / ВИМІРЮВАННЯ

ГЛАВА 32

Impression у Search Console — подія показу search result за правилами конкретної поверхні, а не pageview. Click — перехід із Google Search. CTR = clicks / impressions. Position — середня topmost position вашого результату в наборі, а не “позиція keyword” у класичному rank-tracker sense.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A757D309

У SERP з різними features одна average position може приховувати зовсім різний click opportunity. Тому я не прогнозую traffic лише з “position 3”. Дивлюся query type, device, country, search appearance і, де можливо, SERP composition.

Search Console приховує частину queries із privacy reasons. У bulk export anonymized queries вилучаються, а в агрегованих totals можуть бути дані, які не можна розкласти до конкретного query.[1] Це означає, що сума рядків query table може не дорівнювати total chart.

Висновок простий: “інші/невідомі queries” — не помилка Excel. Не треба штучно розподіляти їх пропорційно по відомих queries і видавати це за факт.

Page-level Search Console data зазвичай призначається canonical URL. Це особливо важливо під час міграцій, дублів, mobile/desktop alternates і canonical conflicts. Якщо ви шукаєте old URL і не бачите clicks, це не доказ, що він не мав visibility — дані могли бути attributed canonical.

Перед page-level аналізом я додаю crawler/GSC URL Inspection canonical mapping. Інакше “сторінки без clicks” можуть виявитися duplicate URLs, чия performance сидить на іншій адресі.

UI хороший для швидкого comparison: останні 28 днів vs попередні, country/device split, query/page filter, regex. Але table row limit означає, що export не є повним long-tail dataset. Google документує звичайне обмеження таблиць 1 000 rows, яке також поширюється на generative AI report.[2]

Тому “я вивантажив CSV із GSC” не означає “я маю всі queries”. Для великих сайтів це лише верхівка distribution.

API дозволяє автоматизувати запити й pagination. Офіційна документація показує `rowLimit` до 25 000 і `startRow` для наступної порції; у Search Central deep dive також описувалась доступність до 50 000 рядків на день на site/search type у цьому інтерфейсі.[3][4]

Я використовую API, коли потрібен сервісний запит: щодня top pages по country/device, автоматичне оновлення внутрішнього dashboard, невеликий monitoring. Для повного багаторічного long-tail analysis краще bulk export.

Bulk export щодня створює `searchdata_site_impression`, `searchdata_url_impression` та `ExportLog`. URL table дає детальний query × URL рівень і search appearance fields; site table — property aggregation. Експорт не обмежений daily row limit Search Analytics API, але anonymized queries вилучаються.[1]

Я зберігаю цей dataset як історичний факт. Не роблю щотижневі CSV snapshots, які втрачають long tail. Потім можу приєднати CMS inventory, page type, GA4 revenue, log data і content changes.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 39655E14

QR: компактна виконувана версія коду.

КОД 32.1. URL-level performance з Search Console bulk export.

Search Console tables partitioned by `data_date`, тому date filter треба ставити завжди. Google окремо рекомендує обмежувати partition range, фільтрувати рано, під час розробки використовувати sampling і, де допустимо, approximate functions.[5]

Я не підключаю Looker Studio прямо до сирого dataset для кожного графіка. Роблю pre-aggregated tables: daily site, daily page type, weekly query cluster. Це дешевше, швидше й стабільніше.

Станом на 31 серпня 2026 Google розгорнув Search Generative AI performance report worldwide.[2] Він показує generative AI impressions і дозволяє аналізувати Pages, Countries, Dates, Devices. Важливе обмеження: це не query report і не окремий click/CTR/position report.

У chart data aggregation property-level: якщо два results того самого site з’явилися в generative feature, це може рахуватися як одна property impression за описаними правилами. При URL filter aggregation змінюється. Тому метрику треба читати буквально, а не називати її “AI rank”.

Перед панікою через різкий провал я перевіряю Search Console Data Anomalies. У 2026 Google публікував, наприклад, logging issues для Generative AI report і Discover. Якщо anomaly в logging, “SEO recovery plan” не потрібен.

Це маленька звичка з великим ROI: спочатку перевірити, чи не змінився measurement layer, потім шукати проблему сайту.

Regex у GSC корисний не для “магічних keyword hacks”, а для швидкої сегментації: branded/non-brand, question patterns, page folders, product IDs. Я зберігаю основні regex у repository, щоб місячні звіти не залежали від того, як аналітик цього разу написав `brand|бренд|brand typo`.

Для важливих сегментів regex краще замінити на taxonomy у warehouse: query cluster або page type. Regex — хороший exploration layer, але слабке джерело довгострокової істини.

Search Console не дає conversion value, complete user journey, повний SERP layout, backlinks, competitor rankings, усі queries, causal explanation ranking changes. Генеративний report не показує exact user query. Усе це треба добирати іншими системами.

Саме тому GSC — ядро SEO measurement, але не повна SEO-аналітика. Сильний стек об’єднує Search Console з GA4/business data, logs, crawler і зовнішнім SERP measurement.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 7C3CCD23

Таблиця 32.1. Яке джерело Search Console коли використовувати.

1. Google Search Central Blog. Bulk data export. https://developers.google.com/search/blog/2023/02/bulk-data-export — Схема tables і privacy limits.

2. Search Console Help. Generative AI performance report. https://support.google.com/webmasters/answer/16984139?hl=en — Global rollout 31.08.2026, dimensions і limits.

3. Search Console API. Search Analytics. https://developers.google.com/webmaster-tools/v1/how-tos/search_analytics — rowLimit і pagination.

4. Google Search Central Blog. Performance data deep dive. https://developers.google.com/search/blog/2022/10/performance-data-deep-dive — UI/API limits і aggregation.

5. Google Search Central Blog. BigQuery efficiency tips. https://developers.google.com/search/blog/2023/06/bigquery-efficiency-tips — Partition filters і cost optimization.

6. Search Console Help. Data anomalies. https://support.google.com/webmasters/answer/6211453 — Known logging/processing anomalies.

ЧАСТИНА VII / ВИМІРЮВАННЯ

ГЛАВА 33

Google прямо попереджає, що User-Agent Googlebot часто імітують інші crawlers. Найнадійніші підходи — reverse DNS verification або зіставлення IP з опублікованими Googlebot IP ranges.[1]

Я не роблю висновок “Googlebot атакує параметри” на невіріфікованому user-agent. На high-traffic сайті це може повністю спотворити distribution.

Для SEO потрібні timestamp, client IP, HTTP method, host, URL/path+query, status, response bytes, response time, user-agent. Referrer корисний не завжди, але зберігаю, якщо є. Якщо CDN додає cache status або edge/origin latency — ще краще.

З access logs я формую derived fields: verified_bot, bot_family, normalized_url, page_type, parameter_flags, date/hour, status_class. Не змінюю raw — derived layer можна перебудувати.

Кількість hits сама по собі не є метрикою “важливості”. Частота залежить від freshness, demand, signals, server capacity і багатьох внутрішніх рішень. Але в рамках одного сайту distribution корисний: які templates отримують 60% requests, які нові URL не бачать bot, які старі 404 запитуються місяцями.

Я рахую median/percentile recrawl interval за page type, а не average по домену. Homepage і мільйон архівних сторінок в одному average роблять число беззмістовним.

200 говорить, що fetch succeeded, але не гарантує indexation. 301/302 показують redirect overhead; 404/410 — removed URLs; 429 і 5xx можуть сигналізувати перевантаження або incident. Google рекомендує 500/503/429 як тимчасовий emergency спосіб різко знизити crawling, але це грубий інструмент і тривалі помилки можуть призвести до випадання URL.[2]

У log dashboard я дивлюся status mix саме для verified Googlebot і сегментую по page type. 2% 5xx на overall traffic і 20% 5xx на Googlebot requests до product pages — різні ситуації.

Повільний сервер не є “ranking penalty” у простій формулі, але crawl capacity пов’язана зі здатністю host відповідати без перевантаження. Якщо latency росте й server errors з’являються, crawling може адаптуватися.

Я дивлюся p50/p95 latency bot requests, а не лише average. Один slow API endpoint у template може створювати довгий tail і робити рендер/response нестабільним.

Логи добре показують, чи crawling витрачається на sort, tracking, session IDs, faceted combos, internal search. Я виділяю top query parameters by hits і unique URLs. Потім перевіряю, звідки вони discoverable: internal links, old backlinks, sitemaps, JS.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код E1CD5A72

Не всі “зайві” requests треба блокувати robots.txt. Якщо параметричний URL уже має signals або дублює content, рішення може вимагати canonical, internal-link cleanup, redirects або removal. Robots просто не дає crawl content і може залишити URL відомим.

Умовно корисно розділяти first-seen URL і recrawl existing URL. Якщо launch має 50 000 new products, але за три дні Googlebot вперше побачив 5 000, проблема ближче до discovery/crawl demand. Якщо всі побачені, але не indexed — інший шар.

Для цього зберігаю `first_googlebot_hit`, `last_googlebot_hit`, `hit_count`. При міграції додаю old/new URL mapping і дивлюся, як швидко bot проходить redirect graph.

QR: компактна виконувана версія коду.

КОД 33.1. Базова агрегація verified Googlebot logs.

Після migration logs дають фактичний recrawl old URLs, переходи через redirects, requests до new URLs і errors. Я будую cohorts: top traffic old URLs, top backlinks, categories, deep pages.

Не потрібно чекати два тижні, щоб дізнатися, що Googlebot отримує redirect loop на 15% old inventory. Це видно в перші години.

Логи не показують, чи URL indexed, rank, citation у AI, user intent або “crawl budget score”. Request — лише request. Тому logs треба join із crawl inventory, Search Console і status/canonical data.

Найгірша аналітика — перетворити crawl frequency на причинний ranking factor: “Googlebot заходить частіше, отже треба змусити його заходити частіше”. Частота може бути наслідком важливості/freshness, а не причиною rankings.

Логи великого сайту можуть бути терабайтами. Я зберігаю raw у cheap storage, а для аналізу — partitioned table з потрібними fields. Для recurring dashboard достатні daily aggregates; raw потрібен для incident drill-down.

Privacy/security важливі: access logs можуть містити user IPs, query parameters, tokens. SEO не повинен отримувати більше персональних даних, ніж потрібно для bot analysis. Фільтруйте і мінімізуйте.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 7751C290

Таблиця 33.1. Питання, на які добре відповідають logs.

1. Google Search Central. Googlebot. https://developers.google.com/search/docs/crawling-indexing/googlebot — Верифікація через reverse DNS/IP ranges.

2. Google Search Central. Crawl budget management. https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget — Crawl capacity/demand і server responses.

3. Google Search Central. HTTP network errors. https://developers.google.com/search/docs/crawling-indexing/http-network-errors — HTTP status behavior.

4. Google Search Central. Debug traffic drops. https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops — Відокремлення technical issues від інших причин.

ЧАСТИНА VII / ВИМІРЮВАННЯ

ГЛАВА 34

GA4 має різні scopes traffic-source dimensions. `First user` описує джерело першого залучення користувача, `Session` — джерело конкретної сесії. Google пояснює, що user- і session-scoped dimensions використовують paid and organic last click, тоді як event-scoped attribution може використовувати вибрану attribution model.[1]

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A9D3A812

Це означає, що “organic users” і “organic sessions” не відповідають на одне питання. Для SEO performance я найчастіше починаю з Session source/medium, а для acquisition cohort — First user.

Organic Search у GA4 — rule-based channel grouping. Він корисний для dashboard, але source/medium треба зберігати. Новий AI referral може спочатку потрапити в Referral, доки classification rules не відповідають вашій аналітичній потребі.

OpenAI прямо зазначає, що ChatGPT search referrals додають `utm_source=chatgpt.com`, тож їх можна окремо відстежувати в analytics.[2] Я не змішую такий трафік з Organic Search автоматично; створюю власний reporting dimension “AI referral” поверх raw source/medium.

У GA4 доступні data-driven attribution, paid and organic last click та Google paid channels last click.[3] Data-driven використовує property data й оцінює внесок touchpoints; last click віддає credit останній відповідній взаємодії.

Якщо користувач побачив бренд в AI answer, через день зробив branded Google search і купив, стандартна web analytics може не мати observable touchpoint “AI mention”. Тому ніяка attribution model не може розподілити credit події, яку ви не виміряли.

Google сам документує відмінності Search Console і Analytics: різна точка вимірювання, canonical URL attribution, tracking, timezone та інші правила.[4] Click може статися, але GA не запуститься; session може мати кілька pageviews; користувач може повернутися direct.

Я використовую ratio GSC clicks → GA organic sessions як monitoring metric, а не “правильний коефіцієнт”. Якщо ratio різко змінюється після consent banner release, це сигнал tracking change, а не обов’язково SEO.

`scroll_90` і `time_on_page` можуть допомагати діагностиці, але KPI SEO повинні наближатися до грошей. Для ecommerce — purchase/revenue/margin. Для SaaS — signup, activated account, paid conversion. Для affiliate — outbound click плюс, якщо є, server-to-server postback із реєстрацією/депозитом.

Я документую event contract: назва, trigger, parameters, deduplication, source of truth. Якщо “lead” спрацьовує і при submit, і на thank-you page, конверсії подвояться незалежно від SEO.

У affiliate часто browser analytics бачить click to operator, але не бачить downstream registration/FTD через інший домен. Тоді потрібен postback або партнерський report, який можна join за click ID, sub ID, date/geo/landing у межах дозволеного tracking.

Без цього SEO-команда оптимізує CTR до оператора, а не якість трафіку. Два landing pages можуть мати однакові outbound clicks і втричі різний FTD rate.

ChatGPT, Perplexity, Copilot та інші можуть віддавати referral traffic. Це невеликий, але вимірюваний шматок AI visibility. Я створюю список known AI referrers і щотижня переглядаю new referral domains.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 18F84F29

Не називаю AI referrals “повним AI traffic”. No-click visibility, branded follow-up search і agent action можуть не мати прямого referral. Це тільки observable clicks.

QR: компактна виконувана версія коду.

КОД 34.1. Власна група AI referrals у GA4-export.

Для SEO я дивлюся не тільки channel aggregate, а landing page × page type × query cluster. Revenue per organic session і key-event rate показують різницю між informational traffic і money pages.

Низький conversion rate informational article не означає, що article непотрібний: він може створювати assisted conversion або brand demand. Але такі claims треба доводити path/cohort analysis, а не storytelling.

Чим суворіші privacy restrictions, тим більше browser analytics має gaps. Server-side measurement може підвищити reliability окремих business events, але не є способом “обійти згоду”. Legal/compliance layer має бути частиною design.

Я завжди зберігаю business source of truth окремо: CRM, orders, partner postback. Analytics — модель поведінки, а бухгалтерія/CRM — інший контур.

Навіть data-driven attribution не доводить, що SEO touchpoint спричинив conversion у causal sense. Це allocation model. Щоб оцінити causal lift, потрібні експерименти або квазіекспериментальні дизайни.

Тому в reporting я розділяю “attributed revenue” і “incremental effect”. Перше можна рахувати регулярно, друге — значно складніше і не для кожної задачі.

Таблиця 34.1. Що міряти після organic click.

1. Google Analytics Help. Traffic-source scopes. https://support.google.com/analytics/answer/11080067?hl=en — User/session/event scopes.

2. OpenAI Help Center. Publishers and Developers FAQ. https://help.openai.com/uk-ua/articles/12627856-publishers-and-developers-faq — ChatGPT referrals і utm_source=chatgpt.com.

3. Google Analytics Help. Attribution. https://support.google.com/analytics/answer/10596866 — Три доступні attribution models.

4. Google Search Central. Search Console and Analytics. https://developers.google.com/search/docs/monitor-debug/google-analytics-search-console — Чому дані не збігаються 1:1.

5. Google Analytics Help. Campaigns and traffic sources. https://support.google.com/analytics/answer/11242841?hl=uk — Traffic acquisition basics.

ЧАСТИНА VII / ВИМІРЮВАННЯ

ГЛАВА 35

Я записую hypothesis до запуску: change, target metric, expected direction, unit, period, exclusion rules, stop condition. Це зменшує HARKing — вигадування пояснення після того, як графік уже побачили.

Наприклад: “Додавання contextual links із hub pages на orphan-ish product pages збільшить impressions/eligible URL за 28 днів порівняно з matched control, без росту 404/redirect crawl”. Це значно краще за “тестуємо internal links”.

Page, template, category, domain, market — різні units. Якщо ви змінюєте global navigation, page-level control практично неможливий, бо treatment впливає на весь graph. Якщо змінюєте title 500 products, можна випадково розподілити comparable URLs.

Потрібно враховувати interference: treatment однієї сторінки може впливати на іншу через internal links або cannibalization. Класичний A/B assumption незалежності часто порушується.

Randomized controlled experiments вважаються gold standard причинності, бо random assignment балансує відомі й невідомі confounders у середньому. Microsoft описує controlled experiments як спосіб науково встановлювати причинність у web products.[1]

У SEO randomization можлива не завжди, але для великих наборів однотипних сторінок — іноді так. Головне не рандомізувати URL, які фундаментально різні за demand, age або category, якщо sample малий.

Коли randomization неможлива, я підбираю control за pre-period metrics: impressions, clicks, average position, page type, age, country, query class. Потім перевіряю parallel trends до treatment.

Control не повинен “виглядати схожим” лише за URL. Якщо treatment group сезонна, а control — ні, difference після запуску нічого не доведе.

Проста логіка: дивимося, наскільки treatment змінився до/після, і віднімаємо зміну control. Якщо treatment +20%, control +15%, estimated incremental change близький до +5%, а не +20%.

Це все одно залежить від assumptions, зокрема parallel trends. Але вже сильніше, ніж назвати весь +20% ефектом SEO-зміни.

Google Research опублікував підхід Bayesian structural time series для оцінки causal impact intervention, коли randomized experiment неможливий.[2] Модель будує counterfactual time series із control predictors і порівнює observed post-period із очікуваним.

Це не магічна кнопка. Якщо control variables самі зазнали treatment, якщо structural break збігається з Google update, якщо pre-period короткий — модель може бути переконливо неправильною.

Перед запуском фіксую Search Status Dashboard, known updates, holidays, promotions, product launches. Якщо core update почався посеред тесту, я не “коригую” data в Excel. Або продовжую test до стабілізації, або визнаю confounding.

Google рекомендує чекати щонайменше повний тиждень після завершення core update перед аналізом у Search Console.[3] Це корисна дисципліна і для експериментів: не робити причинний висновок під час rollout.

Малий sample може не відрізнити +5% від шуму. Я визначаю minimum effect, який взагалі має бізнес-сенс, і будую sample/period навколо нього. Якщо для +3% CTR потрібні мільйони impressions, а сайт має 20k, не треба обіцяти точність, якої дані не дадуть.

В SEO часто краще агрегувати homogeneous page cohort, ніж тестувати одну сторінку. Але агрегація не повинна змішувати intent і seasonality.

Якщо протестувати 100 змін із p<0.05 і вибрати лише “переможців”, частина буде випадковою. SEO-команди рідко коригують multiple comparisons, бо багато тестів неформальні. Мінімум — вести registry всіх тестів, включно з нульовими.

Я не використовую statistical significance як binary magic. Дивлюся effect size, confidence interval/credible interval, business value, consistency і mechanism plausibility.

Primary metric має відповідати hypothesis: indexed rate, clicks, conversions, revenue. Guardrails — те, що не повинно погіршитися: 404 rate, crawl errors, conversion rate, page speed, returns.

Наприклад, SEO title test може підняти CTR, але знизити conversion через overpromise. CTR winner не обов’язково business winner.

QR: компактна виконувана версія коду.

КОД 35.1. Базовий difference-in-differences.

Переможець на 10% pages не гарантує такий самий ефект на 100%. Інші categories, demand distributions і link graph можуть змінити результат. Я rollout роблю поетапно й залишаю holdout, якщо business дозволяє.

Після rollout моніторю durability: ефект через 7, 28, 90 днів. SEO system може переоцінити сторінки не одразу.

Якщо команда публікує тільки success cases, вона навчається неправильно. Я зберігаю failed/neutral tests із hypothesis і context. Це створює internal evidence base і знижує повторення тих самих ідей.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 48254337

Найцінніший результат іноді: “Ми думали, що X дає +15%, але контроль показав 0–2%; більше не витрачаємо на це sprint”.

Таблиця 35.1. Мінімальний паспорт SEO-експерименту.

1. Microsoft Research. Online Experimentation at Microsoft. https://www.microsoft.com/en-us/research/publication/online-experimentation-at-microsoft/ — Controlled experiments і причинність.

2. Google Research. Inferring causal impact using Bayesian structural time-series models. https://research.google/pubs/inferring-causal-impact-using-bayesian-structural-time-series-models/ — Квазіекспериментальна оцінка intervention.

3. Google Search Central. Core updates. https://developers.google.com/search/docs/appearance/core-updates — Час аналізу після rollout.

4. Microsoft Research. Benefits of Controlled Experimentation at Scale. https://www.microsoft.com/en-us/research/publication/the-benefits-of-controlled-experimentation-at-scale/ — Практична культура експериментів.

ЧАСТИНА VII / ВИМІРЮВАННЯ

ГЛАВА 36

Для content cluster я можу прогнозувати monthly clicks і conversions. Для technical fix — recovered indexable inventory або avoided loss. Для migration — risk range. Для link campaign — не “DR +10”, а expected contribution to target pages, але з великою uncertainty.

Модель повинна відповідати типу рішення. Не треба змушувати кожну SEO-задачу давати “traffic forecast”, якщо цінність — reliability або risk reduction.

Search volume із third-party tool — оцінка, не census. Я калібрую його власним GSC там, де сайт уже має impressions. Для нового market використовую ranges і сезонність. Google Trends допомагає зрозуміти direction, але не дає absolute volume.

Для programmatic set я не сумую volumes тисяч keywords без deduplication intent. Одна сторінка може ранжуватися за сотнями синонімів; сума keyword volumes завищує addressable demand.

Замість “вийдемо в top-3” я задаю distributions: low — page 2/top10 small share; base — частина clusters top5-10; high — сильний top3 share. Для кожної групи використовую власний observed CTR, якщо є.

Generic CTR curve з дослідження — старт, не істина. Brand/non-brand, device, rich results, AI Overviews і query intent різко змінюють CTR. Найкраща CTR model — власний historical GSC за схожими query classes.

У 2026 informational visibility може мати нижчий external CTR через AI Overviews та інші SERP answers. Я не вставляю один “AI penalty = 40%” у всю модель. Сегментую queries за surface/intent і використовую observed data або scenario range.

Може зрости search usage, але впасти click yield. Тому demand growth і traffic growth — різні параметри forecast.

Для 50 000 new URLs не припускаю, що всі indexed у день launch. Модель має ramp: generated → discovered → crawled → indexed → impressions. Коефіцієнти беру з pilot або historical template.

Якщо pilot показав 65% indexed after 28d і 80% after 90d, forecast повинен відображати це. Інакше revenue “з першого місяця” просто математично неможливий.

SEO traffic неоднорідний. Money pages і informational articles мають різний conversion rate. Я прогнозую на рівні page type / intent. Для ecommerce краще margin, а не gross revenue, якщо рішення стосується бюджету.

Для lead gen використовую qualified rate і close rate; для affiliate — EPC або registration→FTD, якщо дані є. Якщо downstream data немає, прямо показую, де модель обривається.

Таблиця 36.1. Приклад сценарної моделі.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 8BBE4E64

Проєкт може мати високий traffic upside і бути поганим рішенням через engineering/content cost. Я додаю required effort: developer days, editorial hours, data engineering, links, design, maintenance.

Це дозволяє порівняти “10k pages programmatic” з “fix canonical bug” не за excitement, а за expected value / cost / confidence / time-to-impact.

SEO changes мають лаг. Technical fix може бути помітний після recrawl; content — після index/re-evaluation; authority — ще менш детерміновано. Forecast із cumulative curve реалістичніший за рівну лінію.

Я показую month 1–3 ramp, 4–6 scale, 7–12 steady/decay, якщо це відповідає механіці. Якщо даних немає — range ширший, а не “середній лаг 47 днів”.

Confidence — не відчуття 8/10. Я розкладаю: demand evidence, implementation certainty, indexability, historical analog, conversion data, competitive gap. Потім пояснюю, чому scenario range такий широкий.

Forecast із low confidence може бути корисним, якщо upside великий і тест дешевий. Він просто не має продаватися CFO як committed revenue.

Кожний квартал я беру старі forecasts і порівнюю з фактом: де помилилися demand, index rate, CTR, conversion, timeline. Це найкращий спосіб покращувати модель.

Якщо forecasts ніколи не backtest-яться, команда не прогнозує — вона пише sales documents.

Коли forecast стає quota, команда починає підганяти assumptions або оптимізувати короткострокові vanity metrics. KPI — performance system, forecast — decision model. Вони пов’язані, але не тотожні.

Я фіксую assumptions version і змінюю forecast тільки коли з’явилися нові факти, а не щоб “повернути план у green”.

Для cohort сторінок базова модель може бути: `Eligible URLs × Index rate × Impressions per indexed URL × CTR × Conversion rate × Value`. Вона груба, зате прозора. Складніша модель має сенс тільки коли покращує рішення.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код A02E8DB7

Кожний множник треба мати можливість замінити actual data після launch. Тоді forecast поступово перетворюється на operating model.

1. Google Search Central. Debugging traffic drops. https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops — Seasonality, updates, technical issues і demand.

2. Google Search Central. Search Console Performance data. https://developers.google.com/search/blog/2022/10/performance-data-deep-dive — Власні impressions/clicks як calibration data.

3. Search Console Help. Generative AI performance report. https://support.google.com/webmasters/answer/16984139?hl=en — AI exposure як окремий measurement layer.

4. Google Analytics Help. Traffic source dimensions. https://support.google.com/analytics/answer/15612152?hl=uk — Conversion/value segmentation за джерелом і сесією.

ЧАСТИНА VIII / РИЗИК

ГЛАВА 37

Я розділяю три речі: широку переоцінку ранжування, автоматичне застосування систем боротьби зі спамом і ручну дію. Core update, за поясненням Google, не є санкцією проти конкретного сайту: це широка зміна того, як системи оцінюють контент і конкурентний набір.[1] Manual action, навпаки, виникає після рішення людини-перевіряльника і відображається в Search Console.[2]

Це не семантика. Від класифікації залежить план. При ручній дії є конкретний report і процедура reconsideration. При технічному інциденті потрібен rollback або fix. При broad re-ranking може не бути одного дефекту, який можна “видалити”.

Spam policies описують поведінку, яка може призвести до нижчого ранжування або виключення з результатів. Google прямо включає cloaking, doorway abuse, scaled content abuse, scraping, expired domain abuse, link spam і site reputation abuse.[3] У 2026 правила також прямо поширюються на спроби маніпулювати generative AI responses у Google Search.

Я не перетворюю цей документ на зворотну інструкцію “що саме ловить Google”. Він не розкриває thresholds, weights чи detection logic. Політика показує boundary condition: яку мету й поведінку Google вважає маніпулятивною.

Актуальна документація Google рекомендує спочатку дочекатися завершення rollout, а потім порівнювати коректні періоди. Для core update Google радить зачекати щонайменше повний тиждень після завершення, перш ніж робити висновки в Search Console.[1] Малий рух, наприклад 2→4, не потребує радикальних змін. Великий і стійкий рух типу 4→29 — привід для глибшої оцінки.

Найгірша реакція — масово переписати titles, видалити блоки, скоротити тексти або змінити internal links лише тому, що хтось у X/Telegram назвав один елемент “тригером апдейту”. Це руйнує baseline й унеможливлює causal reading наступних даних.

Search Console Manual Actions report показує, чи застосована ручна дія, її тип і охоплення. Google повідомляє про неї також через message center. Після виправлення можна подати Request review; якщо Google вважає порушення усуненим, manual action відкликається.[2]

Тут я працюю як з incident response: зберігаю snapshot сайту й доказів до змін, описую scope, видаляю першопричину, перевіряю весь клас схожих URL і тільки після цього подаю reconsideration. “Ми видалили одну сторінку” не допоможе, якщо проблема системна.

Site reputation abuse стосується third-party content, опублікованого переважно для використання ranking signals host-сайту.[3] У серпні 2026 Google окремо оновив enforcement у Європейській економічній зоні: з 30 серпня manual actions за цією політикою мають інший ефект для пошуку в EEA, ніж поза нею.[4]

Для міжнародних publishers це означає, що policy analysis не можна робити без GEO. Один і той самий host/content relationship може мати різні наслідки у різних search experiences. Це ще один аргумент зберігати country dimension у діагностиці.

Google розрізняє ranking systems і updates до цих систем. Історично Search Central окремо документує core updates і spam systems. Тому “апдейт був того дня” — тільки temporal correlation, а не доказ конкретного механізму.[5]

Я прив’язую timeline до Google Search Status / ranking update history, але далі дивлюся pattern: які templates, queries, countries і page types втратили. Якщо падає тільки один комерційний каталог, а editorial стабільний, sitewide історія вже менш імовірна.

Google прямо формулює scaled content abuse через мету і цінність, а не через інструмент створення. Генеративний AI наведений як один із можливих способів створити багато сторінок без доданої користі, але сама автоматизація не дорівнює порушенню.[3]

Це важливо для programmatic SEO: питання не “AI чи людина”, а “чому ця URL повинна існувати, яку унікальну функцію/дані/рішення вона дає, і чи створюємо ми тисячі сторінок головно заради покриття запитів”.

У core update guidance Google називає видалення контенту last resort: якщо контент неможливо врятувати і він створювався насамперед для search engines, тоді deletion може бути логічним.[1] Це не рекомендація “після апдейту видаліть 30% сайту”.

Я спочатку класифікую inventory: valuable, salvageable, redundant, obsolete, abusive. Для valuable — improvement; для redundant — consolidation; для obsolete — update або retirement; для abusive — removal/noindex depending on purpose. Масовий prune без класифікації — ще одна форма панічного SEO.

Перед будь-яким recovery sprint я заповнюю мінімальну матрицю: дата початку, тип сигналу, Search Console messages, security issues, change log, update timeline, affected countries, devices, page types, query classes, index coverage, crawl/log anomalies.

Це займає години, а не тижні, але різко знижує шанс почати дорогий контентний rewrite, коли причина — noindex release, неправильний canonical, зміна SERP або tracking bug.

Recovery — не “повернули стару позицію”. Конкурентний набір і сам SERP змінюються. Я задаю observable target: restored eligible inventory, recovered non-brand clicks, stabilized conversion value, removal of manual action, reduction of error class.

Якщо після policy fix manual action знята, але traffic не повернувся, це не означає, що reconsideration “не спрацював”. Зняття санкції повертає право конкурувати, а не гарантує колишній rank.

Таблиця. Практична матриця для цієї глави.

1. Google Search Central. Core updates. https://developers.google.com/search/docs/appearance/core-updates

2. Search Console Help. Manual actions report. https://support.google.com/webmasters/answer/9044175

3. Google Search Central. Spam policies. https://developers.google.com/search/docs/essentials/spam-policies

4. Google Search Central Blog. Update to the Site Reputation Policy, 2026-08-28. https://developers.google.com/search/blog/2026/08/update-site-reputation-policy

5. Google Search Central. Latest documentation updates. https://developers.google.com/search/updates

ЧАСТИНА VIII / РИЗИК

ГЛАВА 38

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 03D4A686

Для бізнесу grey/black tactics — це портфельний ризик. Я дивлюся на expected upside, probability of loss, blast radius, recoverability і replacement cost. Один PBN link на disposable affiliate site і site reputation deal на головному бренді — різні ризикові профілі, навіть якщо обидва суперечать policy.

Тому “працює/не працює” недостатньо. Тактика може працювати шість місяців і бути поганою інвестицією, якщо очікувана вартість втрати домену перевищує прибуток.

Google визначає expired domain abuse як купівлю й перепрофілювання expired domain головно для маніпуляції rankings контентом із малою або нульовою цінністю. У документації прямо наведено приклад casino content на домені колишньої школи.[1]

Це не означає, що кожна купівля expired domain заборонена. Критичні ознаки політики — primary purpose і value. Але з operational perspective старий link graph не є страховкою: історія тематики, spam anchors, redirects, index state і ownership transitions треба перевіряти окремо.

Google рекомендує permanent server-side redirects для реальних site moves і consolidation. При коректному переїзді redirects допомагають передавати signals на нові URL.[2] Це не тотожне тезі, що будь-який старий домен можна направити на money site і механічно “передати authority”.

Я оцінюю mapping relevance. Старий документ про topic A → новий еквівалент topic A має зрозумілу користувацьку й міграційну логіку. Сотні різнорідних expired URLs → homepage казино — вже інший клас поведінки і значно слабший semantic mapping.

Google радить вести redirect одразу до final destination і уникати chains; у site move guidance зазначено, що Googlebot може пройти до 10 hops, але практична рекомендація — тримати chain низьким, ideally не більше 3 і менше 5.[2]

Для SEO-портфеля це означає: якщо домени мігрували кілька разів, не залишайте legacy chain як “історію”. Flatten redirects, update internal links і перевіряйте final status. Кожний hop додає latency й точку відмови.

PBN приваблює контролем над placement, anchor, timing і destination. Але той самий контроль створює correlated footprint: ownership, hosting, templates, analytics IDs, link patterns, content quality, registration history. Я не описую способи приховування мережі — це гонка з системами detection, а не стійка SEO-модель.

Бізнесово важливіше інше: якщо 30% ranking dependency сидить на ресурсах, які можуть зникнути одночасно, це concentration risk. Його треба бачити в link inventory так само, як фіндиректор бачить залежність від одного постачальника.

Google link spam policy вважає купівлю або продаж links для ranking manipulation порушенням; для рекламних/paid placements Google рекомендує `rel=sponsored` або інші атрибути, що не передають ranking credit.[1] Факт, що ринок купує links, не змінює policy status.

У практичному бюджеті я розділяю distribution/PR value і очікуваний SEO effect. Link, який дає qualified referral traffic, brand mention і discovery, має value навіть без “передачі ваги”. Це корисніше, ніж зводити кожний placement до DR/price.

Site reputation abuse — third-party content, розміщений переважно для використання established ranking signals host-сайту.[1] Google у 2026 уточнив enforcement у EEA.[3] Отже, “орендувати піддиректорію сильного медіа” більше не можна оцінювати тільки через швидкість rank.

Я рахую dependency: чи маю контроль над URL, контентом, redirects, analytics, renewal terms, deletion risk. Parasite може бути швидким channel, але майже завжди має низьку asset ownership.

Spam policies прямо включають multiple domains/pages із невеликими варіаціями, створені для покриття схожих queries і funnel до однієї destination, у doorway abuse.[1] Для affiliate portfolios це важлива boundary condition.

Multi-domain strategy сама по собі не doorway. Сайти можуть мати окремі brands, audiences, data, offers і editorial value. Але якщо 20 доменів відрізняються логотипом і H1, а ведуть в один funnel, політичний ризик значно вищий.

Affiliate page не стає корисною від кількості слів. Її moat — власне порівняння, data, screenshots, testing, terms normalization, availability, UX, filters, editorial judgment. Якщо сторінка лише перепаковує merchant copy, вона commodity і легко замінюється SERP/AI answer.

Для iGaming я особливо дивлюся на jurisdiction, T&C timestamp, wagering, min deposit, payment/restriction data і відповідність фактичній пропозиції. Помилка в commercial fact знищує довіру швидше, ніж слабкий keyword coverage.

Я веду risk register по доменах і тактиках: policy exposure, dependency, owner, replacement plan, maximum acceptable loss. Disposable experiment не повинен мати доступ до core analytics, brand accounts чи shared infrastructure без потреби.

Суть не в тому, щоб зробити risk tactics “безпечними”. Безпечними вони не стають. Суть — знати, який актив ви ставите під ризик і чи можете пережити його втрату.

Таблиця. Практична матриця для цієї глави.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код E6246119

1. Google Search Central. Spam policies. https://developers.google.com/search/docs/essentials/spam-policies

2. Google Search Central. Site moves with URL changes. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

3. Google Search Central Blog. Update to the Site Reputation Policy. https://developers.google.com/search/blog/2026/08/update-site-reputation-policy

4. Google Search Central. Redirects and Google Search. https://developers.google.com/search/docs/crawling-indexing/301-redirects

ЧАСТИНА VIII / РИЗИК

ГЛАВА 39

Google у своїй інструкції радить починати з Performance report і дивитися, чи змінилися clicks, impressions і average position, а також порівнювати search types.[1] Я додаю ще page type, query class, country, device і brand/non-brand.

Раптовий cliff, повільний decay, сезонний спад і step-change після migration — різні форми. Графік не ставить діагноз, але відсікає частину причин.

Я перевіряю Search Console messages, Manual Actions, Security Issues, indexing anomalies, robots.txt, noindex, canonical, redirect rules, DNS/CDN status, server errors, deployment log і analytics release. Це cheap checks із великим expected value.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 46D7A026

Якщо сайт учора повертав 200, а сьогодні 503 через WAF rule, немає сенсу аналізувати E-E-A-T. Спочатку повертаємо систему в робочий стан.

Втрата 40% total clicks може бути одним template, який давав половину трафіку. Або 5% падіння на кожному типі сторінок. Я будую матрицю page type × country × device × query class і дивлюся contribution to loss.

Contribution важливіший за percentage change. URL з -90%, який давав 20 clicks, не повинен відволікати від категорії з -12%, що втратила 80 000 clicks.

Google прямо радить перевіряти Trends і demand changes, а також timeline ranking updates.[1] Якщо impressions падають разом у всіх доменів ніші, це інша задача, ніж втрата share при стабільному попиті.

Я порівнюю own impressions із market proxies, branded demand і competitor visibility. Seasonality не можна “виправити SEO”. Її можна врахувати у forecast і capacity.

Актуальний core update guide розрізняє малі й великі зміни позиції. Малий рух у top results не є приводом для drastic action; великий sitewide drop потребує глибшої оцінки.[2]

Це важливо психологічно. Команда, яка реагує на кожен -1.2 position, створює більше шуму, ніж покращень.

При URL migration Google рекомендує server-side permanent redirects, оновлення internal links, canonicals, sitemaps і достатню server capacity. Small/medium migrations можуть оброблятися кілька тижнів; великим сайтам потрібно більше часу.[3]

Recovery тут вимірюється не “старий домен ще ранжується чи ні”, а coverage mapping: old URL → final URL, redirect correctness, canonical alignment, discovered/indexed new URLs, traffic transfer by directory.

Після падіння бізнес тисне: перепишімо тексти, змінимо title, купимо links, видалимо 20k pages, оновимо design. Якщо зробити все, ви втратите ability to learn.

Я класифікую fixes: hard defect, policy remediation, evidence-backed improvement, speculative test. Hard defect можна виправляти одразу. Спекулятивні зміни — окремими cohorts.

У мене є журнал: hypothesis, evidence, change, owner, deploy date, affected scope, expected leading metric, expected lag, result. Це не бюрократія, а пам'ять системи.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 9943C756

Через три місяці без журналу команда пам'ятає тільки “ми щось робили з internal links”. З журналом можна backtest рішення й не повторювати невдалі fix-и.

Google прямо попереджає, що після meaningful improvements частина ефектів може проявитися за кілька днів, а частина — через місяці; гарантії recovery немає.[2] Це не виправдання бездіяльності, а reminder про lag.

Чекати має сенс тільки після того, як leading signals підтверджують, що fix live: bot отримує 200, canonical правильний, URLs discovered, content changed. “Чекаємо апдейту” без перевірки implementation — не стратегія.

Recovery закінчується, коли root cause контрольована або принаймні operational risk повернувся в норму. Далі сайт знову переходить у growth portfolio: experiments, content, authority, product work.

Якщо команда шість місяців живе в режимі “повернути старий трафік”, вона може пропустити новий query space. Іноді правильна мета — не повернути 2025, а побудувати кращу систему для 2026.

Таблиця. Практична матриця для цієї глави.

1. Google Search Central. Debugging Search traffic drops. https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops

2. Google Search Central. Core updates. https://developers.google.com/search/docs/appearance/core-updates

3. Google Search Central. Site moves. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

4. Google Search Central. Changing hosting. https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes

ЧАСТИНА IX / SEO-КОМАНДА У 2026

ГЛАВА 40

Audit описує стан системи. Roadmap описує, що команда робитиме, в якій послідовності й чому. 180 знайдених issues не створюють стратегію автоматично.

Я перетворюю findings на opportunities: recovered coverage, new query space, CTR gain, conversion gain, risk reduction, operational leverage. Тільки після цього tasks потрапляють у roadmap.

Я не використовую одну магічну оцінку ICE/RICE як істину. Базово дивлюся Impact × Confidence, а потім ділю на Effort і коригую Time-to-impact, dependency та reversibility.

Critical incident може мати невеликий upside, але максимальний priority через risk. Research spike може мати нуль прямого traffic impact, але дешево знімає невизначеність для великого проєкту.

“Покращити internal linking” — не impact. “Збільшити частку money pages із ≤3 clicks from hub до 90% і підняти discovery/index coverage” — уже operating target. Для revenue-facing задач — qualified conversions, margin, FTD, revenue.

Для risk задач impact може бути avoided loss: наприклад, прибрати accidental noindex risk перед migration.

Я даю вищу confidence first-party observational data й контрольованим тестам, нижчу — correlation studies, ще нижчу — professional hypothesis. Це не означає, що гіпотези не можна робити; просто вони мають дешевше перевірятися.

Roadmap без confidence перетворюється на політичний список того, хто голосніше говорить на meeting.

SEO може оцінити task у “2 години”, але якщо потрібен backend engineer, QA, security review і реліз через три спринти — real effort інший. Я рахую constrained resource, не тільки свої години.

Так само 100 articles — не “100 × writer cost”: потрібні research, brief, editorial QA, design/data, internal links, publishing, monitoring і maintenance.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код C1F26EDD

У нормальному roadmap є quick fixes, medium bets і long-term assets. Якщо все quick wins — через квартал немає moat. Якщо все platform work — бізнес не бачить feedback.

Я зазвичай тримаю окремі lanes: reliability/risk, growth, experiments, scale/automation, research. Частки залежать від стадії продукту.

SEO-бюджет — people + engineering + content/data + distribution/PR + tooling + infrastructure + experiments. У affiliate link acquisition може бути великою статтею, але без site production і measurement вона не створює системи.

Я показую CFO не “нам треба $20k на SEO”, а allocation: що купуємо, який expected range, які leading metrics і коли review gate.

Великі ініціативи розбиваю на discovery → pilot → validation → scale. Наприклад, programmatic SEO: 50 pages pilot, потім 500, потім 10k — тільки якщо indexation, impressions і economics підтверджуються.

Це захищає від класичної помилки: побудувати 100k URLs, а потім з'ясувати, що dataset не створює унікальної цінності.

Кожна ставка має dependency: tracking, data source, CMS capability, legal approval, template, canonical logic. Я показую їх у roadmap явно.

SEO часто “запізнюється” не через SEO, а через hidden dependency. Винос залежностей зменшує конфлікти з product/engineering.

Щомісяця я не просто питаю “task done?”. Я перевіряю assumptions: чи demand той самий, чи search surface змінився, чи pilot дав expected signal, чи capacity змінилася.

Roadmap — living decision model. Але зміни повинні бути версійовані, інакше команда щомісяця переписує історію заднім числом.

Таблиця. Практична матриця для цієї глави.

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

ЧАСТИНА IX / SEO-КОМАНДА У 2026

ГЛАВА 41

На малому сайті Senior SEO може робити research, technical, content і links. На великому — це окремі functions. Я проектую ownership від систем: crawling/indexing, architecture, content/product, authority, measurement, experimentation, international.

Назва “SEO Manager” не пояснює, хто відповідає за canonical incident. RACI/owner map пояснює.

Кількість published pages стимулює thin content. Кількість acquired links — дешеві links. Середня позиція — вибір “зручних” keywords. Я використовую outcome + guardrails.

Наприклад, content team може мати eligible indexed pages із qualified impressions і conversion contribution, але guardrail — factual QA, decay rate, policy incidents.

Revenue — lagging. Index coverage, crawl health, delivery SLA, experiment velocity — leading. Якщо дивитися тільки revenue, команда дізнається про проблему занадто пізно.

Але leading metric не можна перетворювати на самоціль. 99% index rate непотрібний, якщо ви індексуєте 200k безцінних URLs.

Я хочу бачити одну сторінку: business outcome, major changes, risks, bets, confidence, next decision. Не 40 charts GSC без питання.

До appendix йдуть деталізації: query/page type/GEO, technical health, AI visibility, experiments, links, delivery.

Щотижня: incidents, shipped changes, leading metrics, experiments, blockers, next releases. 30–45 хвилин достатньо, якщо data prepared асинхронно.

Meeting не має перетворюватися на live reading dashboard. Люди приходять із висновком і рішенням.

Раз на місяць дивлюся cohort performance, roadmap assumptions, budget burn, market/competitor changes і learnings. Тут можна reprioritize.

Місячний review — не “пояснити CEO, чому traffic -7%”. Це рішення, де наступний долар/спринт дасть найбільший expected value.

Lead відповідає за system output: roadmap quality, incident handling, delivery, measurement, team learning. Specialist — за owned domain і якість рішень, а не за vanity total traffic, який він не контролює.

Коли одна людина “відповідає за organic revenue”, але не контролює engineering, product, stock і CRO, KPI несправедливий і провокує політику.

У 2026 AI здешевлює analysis і implementation prototypes. Тому конкурентна перевага — не кількість generated ideas, а кількість якісно закритих learning loops.

Я рахую: hypotheses created → tests launched → interpretable results → scaled wins / killed ideas. Neutral result теж output, якщо зняв невизначеність.

Decision log, migration playbook, incident runbook, content schema, measurement dictionary — це assets. Вони зменшують dependence від пам'яті одного Senior.

Команда без документації кожен рік заново “винаходить”, чому не можна закривати staging через robots.txt тільки перед launch.

Head не повинен вручну перевіряти кожний title. Його контрольна система: business performance, technical risk, roadmap, capacity, budget, evidence quality, people, external dependencies.

Якщо Head весь день робить keyword research, організація втрачає роль, яка має з'єднати SEO з продуктом і P&L.

Таблиця. Практична матриця для цієї глави.

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

ЧАСТИНА X / АГЕНТНИЙ ВЕБ

ГЛАВА 42

Generative answer синтезує інформацію. Agent має ще й plan/action loop: отримати state, вибрати наступну дію, взаємодіяти з сайтом/API, перевірити результат. Google у Search I/O 2026 описав information agents і розширення agentic booking; OpenAI ChatGPT agent використовує visual browser, text browser, terminal, APIs і connectors.[1][2]

Це важливо: visibility може завершитися не click, а action. Для бізнесу це добре, якщо economics зберігається. Для analytics — складніше.

Агент може працювати через GUI, DOM, accessibility tree, structured data, API або feed. Чим стабільніша структура, тим менше ambiguity.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код CA4E62BA

Це не означає “створіть schema для AI”. Google прямо каже, що спеціальної AI schema для AI Search не потрібно. Але стандартизовані Product/Offer/Organization/LocalBusiness data допомагають машинам і пошуковим системам розуміти факти у supported contexts.[3][4]

Для transactional agent критичні price, availability, shipping, location, opening hours, refund/cancellation terms. Застарілий informational paragraph неприємний; застаріла availability може зламати дію.

Тому content ops поступово стає data ops: source of truth, freshness timestamp, validation, API/feed monitoring.

Google документує Product structured data і Merchant Center feeds як способи точніше передавати price, availability, shipping і returns; Merchant Center обов'язковий для деяких shopping surfaces.[4] Це вже модель “публікувати дані, а не тільки текст”.

Для інших вертикалей еквівалентом можуть бути booking feeds, inventory API, local business data, event feeds. Не все це є ranking factor; це infrastructure для accurate eligibility і actions.

Operator/ChatGPT agent показав, що модель може клікати, вводити текст і скролити через GUI.[2] Отже, “машиночитність” не закінчується API. Form labels, accessibility, predictable states і error messages стають machine usability.

Captcha, modal chaos, hidden controls, infinite spinners, нестабільний DOM — це вже не лише CRO/accessibility debt, а agent compatibility debt.

SEO давно думає crawler access. Agent layer додає інші user agents, browsers і authenticated flows. Політика доступу повинна бути свідомою: що дозволяємо crawl, що дозволяємо action, де потрібна login/consent/payment confirmation.

Security важливіша за “бути доступним AI”. Не треба відкривати приватні endpoints заради agent friendliness.

Agent може знайти merchant, перевірити умови і привести користувача на фінальний confirmation step. А може виконати більшу частину flow сам. Referral analytics не обов'язково побачить весь contribution.

Потрібні server-side order source, partner IDs, API attribution, assisted brand lift і експериментальні методи. Старий UTM-only worldview стає ще менш повним.

Я не створюю окрему “Agent SEO” checklist із 100 пунктів. Беру фундамент: reachable data, correct semantics, stable actions, evidence, brand/entity consistency, fast predictable UX.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 6B82AB2A

Якщо агент постійно бачить різну ціну в HTML і checkout, жоден llms.txt не вирішить проблему.

Я тестую critical flows автоматизованим browser: знайти product/service, відкрити detail, перевірити availability, start booking/cart, handle error. Це synthetic monitoring, а не ranking test.

Для public data перевіряю parity HTML/structured data/feed/API. Divergence — operational incident.

Сильний digital business у агентному вебі має не тільки pages. Він має чіткі entities, structured inventory, policies, APIs/feeds де доречно, stable transaction flow і source-of-truth data.

SEO тут стає interface discipline між business data і зовнішніми discovery/action systems. Це ближче до product/data engineering, ніж до keyword density.

Таблиця. Практична матриця для цієї глави.

1. Google. Search I/O 2026: AI agents and more. https://blog.google/products-and-platforms/products/search/search-io-2026/

2. OpenAI. Introducing ChatGPT agent. https://openai.com/index/introducing-chatgpt-agent/

3. Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features

4. Google Search Central. Merchant listing structured data. https://developers.google.com/search/docs/appearance/structured-data/merchant-listing

5. Google Search Central. Share product data with Google. https://developers.google.com/search/docs/specialty/ecommerce/share-your-product-data-with-google

ЧАСТИНА X / АГЕНТНИЙ ВЕБ

ГЛАВА 43

Десять синіх посилань ніколи не були самою дисципліною. SEO працює з discovery, crawl, index, retrieval, ranking/selection, presentation і conversion. AI Overview або agent змінює presentation/action layer, але фундамент не зникає.

Google у 2026 прямо пише, що best practices SEO залишаються релевантними для AI features і спеціальних вимог для appearance в AI Overviews/AI Mode немає.[1]

Сайт може отримати organic rank, citation, brand mention, product inclusion або agent action. Жодна метрика не є повною сама.

Тому сучасний measurement stack має працювати з multiple observable layers і чесно показувати blind spots.

LLM може швидко синтезувати generic explanation. Тому moat переходить у proprietary data, first-party experience, tools, fresh inventory, expert judgment, workflows і brand trust.

Це не означає, що пояснювальний текст непотрібний. Він потрібен як interface до унікального evidence, а не як копія top-10 SERP.

Коли Search і agents використовують render, structured data, feeds, browsers і APIs, межа між “SEO issue” і “product/data issue” стирається.

Senior SEO має розуміти HTTP, templates, logs, data contracts, experimentation. Не обов'язково писати production backend, але треба розуміти механіку достатньо, щоб поставити правильний acceptance test.

Бренд створює navigational demand, mentions, trusted first-party sources, reviews, link earning, repeat behavior. Це багато різних observable phenomena, а не один “brand score”.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код 79ED217E

У AI environments entity consistency і source quality можуть підсилювати ймовірність правильної інтерпретації. Але я не називаю кожен brand metric прямим ranking factor без evidence.

Головна робота Lead/Head — не знати відповідь на все. Це швидко зменшувати невизначеність: які дані потрібні, який тест дешевий, що reversible, де risk asymmetric.

AI збільшує кількість можливих дій. Значить, selection quality стає важливішою за generation speed.

Regex, SQL, clustering, briefs, anomaly detection, schema drafts і code prototypes автоматизуються дедалі краще. Але system owner все одно відповідає за definitions, data quality, risk і business decision.

Якщо AI швидко створив 50k pages, це не означає, що 50k pages треба публікувати.

У світі нескінченного generated advice дорожчає здатність показати sample, method, source, limitation і causal boundary. Це стосується і контенту, і внутрішньої SEO-аналітики.

Команда, яка знає різницю між correlation, experiment і hypothesis, повільніше впадає в хайп і швидше знаходить working mechanism.

Не “200 ranking factors”. Я б учив web mechanics, information retrieval concepts, data analysis, experiment design, business economics, content differentiation, links/graph thinking і communication.

Після цього конкретний інструмент — Ahrefs, GSC, LLM, crawler — просто interface до задачі.

Книга починалася з ланцюга від URL до AI-відповіді. Закінчується вона ще простіше: Understand the system → observe the data → form a hypothesis → test → measure → scale.

Коли Google змінить UI, назву AI Mode або спосіб показувати citations, ця модель не зламається. Саме тому я вважаю її кориснішою за будь-який список hacks.

Таблиця. Практична матриця для цієї глави.

© 2026 Михайло Оплаканець aka Werter · SEO 2026 · Публічна захищена копія · код B606D3E9

1. Google Search Central. AI features and your website. https://developers.google.com/search/docs/appearance/ai-features

2. Google Search Central Blog. A new resource for optimizing for generative AI in Google Search. https://developers.google.com/search/blog/2026/05/a-new-resource-for-optimizing

3. Google. Search I/O 2026. https://blog.google/products-and-platforms/products/search/search-io-2026/

4. OpenAI. Introducing ChatGPT agent. https://openai.com/index/introducing-chatgpt-agent/

5. Google Search Essentials. https://developers.google.com/search/docs/essentials

ПІСЛЯМОВА