Від факапу до виправлення: як ШІ допомагає розв’язувати SEO-проблеми за години, а не тижні

Більшість розмов про ШІ в SEO зводиться до генерації контенту, написання коду й автоматизації повторюваних завдань. У моїй роботі все трохи інакше. Як консультант я постійно стикаюся з різними сайтами, ринками, мовами й дуже вузькими завданнями, які можуть більше ніколи не повторитися. Тому для мене важливіше автоматизувати не конкретну операцію, а сам процес мислення: як ухвалити рішення, не пропустити ризик, швидко розібратися в падінні трафіку й вчасно помітити технічну проблему.

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

Матеріал підготовлено за мотивами мого виступу на конференції AI SEO Day від WebPromo Experts 18 лютого 2026 року.

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

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

Що я називаю SEO-факапом

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

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

Тому моє правило №1 дуже просте:

Якщо із сайтом щось не так, найімовірніше, винні ми.

Спочатку потрібно перевірити власні релізи, зміни шаблонів, контенту й перелінкування. І лише потім пояснювати падіння черговим оновленням Google.

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

Не один великий ШІ, а кілька вузьких ролей

Я щодня використовую різні інструменти: Perplexity для пошуку інформації, Google Gemini, Claude Code, Atlassian Rovo для роботи з Jira й Confluence. Але самі назви сервісів не настільки важливі. Важливіше розуміти, яку функцію виконує кожен із них і який контекст отримує.

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

Генератор альтернатив

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

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

Хранитель фактів і збирач артефактів

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

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

Ці відомості потім стають контекстом для інших агентів. У результаті ШІ відповідає не абстрактно «як SEO-фахівець», а з урахуванням історії та особливостей конкретного сайту.

Аналітик ризиків і наслідків другого порядку

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

Один із прикладів із моєї практики: на сайті були неправильно налаштовані канонічні теги. Водночас маркетингова команда працювала з Merchant Center і запустила велику кількість фідів із різними GET-параметрами в URL товарів і категорій. Google виявив мільйони таких адрес, проіндексував їх, і сайт отримав величезний обсяг тонкого дубльованого контенту. У результаті трафік упав.

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

Як ухвалювати рішення за допомогою ШІ

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

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

Наприклад, мета редизайну не повинна звучати як «зробити сайт сучаснішим». Можна зафіксувати, що після запуску ми очікуємо зростання продажів, зниження показника відмов або поліпшення Core Web Vitals. Потім потрібно заздалегідь визначити, які дані підтвердять результат, що робитимемо в разі погіршення метрик і наскільки швидко зможемо відкотити зміну.

ШІ корисний на кожному з цих етапів, якщо не просити його «оцінити редизайн», а дати конкретну роль, правила й контекст.

Negotiator Gem для співробітників поза SEO-командою

Один із моїх варіантів - Negotiator Gem у Google Gemini. У NotebookLM я збираю джерела: внутрішні правила проєкту, накопичену інформацію про продукт і важливі рекомендації Google. Потім підключаю ці матеріали до Gem із системним промптом, який перевіряє запропоновані завдання.

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

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

Такий Gem не замінює фінальний SEO-перевірку. Він допомагає спіймати ризик раніше - ще тоді, коли завдання лише формулюють.

Claude.md і навички для повторюваних процесів

Гнучкіший варіант - невеликі агенти й навички у Claude Code. Інструмент працює з папками, у яких можуть лежати код, документація, правила розробки, описи завдань і вивантаження даних.

Наприклад, для старого інтернет-магазину можна створити навичку, який допомагає вирішувати, які товари варто видалити. У ньому фіксуються правила: товар не має зображення або не відповідає іншим заздалегідь заданим вимогам. До навички можна додати невеликі скрипти, які отримують дані з MySQL або BigQuery. У підсумку на комп’ютері з’являється не одноразовий промпт, а відтворюваний процес із правилами, даними й очікуваним результатом.

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

Контекст - головна частина будь-якої системи з ШІ

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

Корисний контекст зазвичай складається з двох частин:

1. Знання про проєкт. Документація з Confluence або Obsidian, історія рішень, правила продукту, транскрипції зустрічей, вимоги до розробки.
2. Дані. Наприклад, вивантаження Google Search Console у BigQuery, продуктові таблиці, аналітика й технічні сигнали.

Рішення мають ґрунтуватися на даних, але самих таблиць теж недостатньо. Цифри без пояснення релізів, інцидентів і особливостей сайту легко призводять до хибних висновків. Тому я спочатку накопичую контекст, а вже потім будую навколо нього точкові процеси з ШІ.

Як аналізувати трафік після релізу

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

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

Зберіть дані в одному місці

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

Цього вже достатньо, щоб зробити в Gemini окремий Gem, який пам’ятає структуру даних і допомагає генерувати SQL-запити. Я знаю SQL, але не хочу щоразу писати все вручну. Помічник, який знає таблиці конкретного проєкту, щодня заощаджує мені час.

Після релізу можна швидко підготувати запити й перевірити:

• зміну трафіку рік до року;
• динаміку позицій і показів;
• зміну показника відмов;
• відмінності між типами сторінок;
• зрушення за країнами та іншими сегментами.

Використовуйте Jupyter Notebook для відтворюваного аналізу

Коли SQL-запиту замало й потрібна візуалізація, я використовую Jupyter Notebook. Із ним можна працювати локально у VS Code або Antigravity, а можна відкрити Google Colab і підключитися до BigQuery чи файлів.

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

Згодом накопичуються два корисні типи шаблонів:

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

Не аналізуйте дати у вакуумі

Дата релізу - лише одна точка на часовій шкалі. Поруч могли статися інші події:

• Google Update;
• ще один продуктовий реліз;
• технічний інцидент;
• період, коли сайт був недоступний.

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

Де шукати приховані технічні факапи

Для технічного аналізу потрібні три різні погляди на сайт:

1. Серверні логи - що насправді запитував Googlebot.
2. Краул - що знайшов Screaming Frog, Netpeak Spider або інший краулер.
3. Код, який бачить Google - підсумковий HTML типових сторінок.

Не можна замінити одне джерело іншим. Краулер показує доступну йому модель сайту, але не говорить, куди Googlebot насправді витрачає ресурси. Вихідний код у браузері теж не завжди збігається з тим, що отримує пошуковий робот, особливо на сайтах, де поєднуються SSR і клієнтський рендеринг.

Порівняння змін типових сторінок

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

Якщо є версія тижневої давності й поточна, значно простіше помітити, що хтось:

• змінив canonical;
• додав noindex;
• видалив частину контенту;
• змінив посилання;
• переніс важливий блок у клієнтський рендеринг.

Такі помилки здаються надто очевидними, але продовжують траплятися. Людині складно щоразу уважно порівнювати весь HTML, а LLM добре працює, коли отримує не дві величезні сторінки, а вже виділені зміни.

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

Що можна дізнатися із серверних логів

Раніше аналіз серверних логів вимагав значно більше ручної роботи. Тепер можна попросити розробників вивантажити окремий файл із запитами Googlebot, а потім розібрати його в Claude Code або Jupyter Notebook.

Ось кілька корисних запитань до логів:

• які типи сторінок Googlebot обходить найчастіше;
• які URL відсутні в карти сайту;
• який відсоток адрес не відповідає Friendly URL;
• які групи URL мають підозріло малий розмір відповіді;
• які розділи Googlebot відвідує регулярно, а до яких перестав повертатися;
• чи не зросла різко кількість URL із GET-параметрами.

В одному проєкті за розміром відповіді в логах я помітив, що Googlebot надто часто відвідує категорії з однією-двома картками товару. Звичайний краул не обов’язково підсвітив би пріоритет проблеми: важливо було побачити саме поведінку робота.

Логи допомагають відповісти ще на одне запитання після релізу: чи побачив Google наші зміни. Якщо ми оновили великий набір сторінок, недостатньо просто почекати тиждень. Спочатку варто переконатися, що Googlebot повторно обійшов значну частину змінених URL - наприклад, щонайменше 80%. І лише потім оцінювати вплив релізу на пошук.

Як спробувати передбачити проблему до падіння

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

Спочатку визначте категорії ризиків, актуальні для вашого сайту. Наприклад:

• виснаження бюджет сканування;
• зростання тонкого або дубльованого контенту;
• погіршення Core Web Vitals;
• поступове зниження позицій у «хвості».

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

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

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

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

Практична схема: від ідеї до моніторингу

Якщо зібрати весь підхід в один процес, вийде така послідовність:

1. Сформулювати мету зміни й критерії успіху.
2. Зібрати факти, обмеження та історію проєкту.
3. Згенерувати альтернативи, а не приймати перший варіант автоматично.
4. Перевірити прямі ризики й наслідки для сусідніх систем.
5. Зафіксувати дати релізів та інцидентів.
6. Після запуску перевірити трафік, технічний стан і фактичний обхід Googlebot.
7. Зберегти результати аналізу й використати їх як контекст для наступної ітерації.

У цій схемі ШІ може допомагати на кожному кроці, але він не повинен ставати єдиним джерелом істини. Істина міститься в даних, документації, коді й реальній поведінці Googlebot. Модель пов’язує ці джерела та прискорює роботу фахівця.

Висновок

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

Є два принципи, які я залишив би як підсумок.

Перший: ШІ не завжди має рацію. Що більше достовірного й актуального контексту ми йому передаємо, то корисніші його висновки.

Другий: починати варто з простого. Не обов’язково одразу будувати складну систему агентів. Якщо ШІ може автоматично виписати важливі факти з дзвінка, підготувати SQL-запит, порівняти дві версії HTML або підсвітити забутий ризик - цього вже достатньо, щоб заощадити час і не допустити чергового факапу.

Наступний крок - поєднати такі точкові процеси в стійку систему.

Фінальний слайд навмисно простий: після інструментів, кейсів і процесів відповідальність знову повертається до фахівця, який відповідає на запитання, перевіряє результат і вирішує, що робити далі.