Інструменти AI в SEO: мій набір і тести, які його сформували

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

Що AI робить у SEO добре, а чого не вміє?

Мовна модель добре читає, впорядковує й пише, але погано рахує з пам'яті й не бачить даних, яких ви їй не надасте. 26 і 27 вересня 2026 року я перевірив мовні моделі на 17 типах завдань SEO, кожен на легкому й важкому рівні. Частину типів я збудував на основі 103 вакансій для SEO-спеціалістів. Вакансії найчастіше називали технічний аудит, звітність і аналіз даних. З інструментів найчастіше називали Search Console, Google Analytics 4 (GA4), Ahrefs, Semrush і Screaming Frog.

Найсильніші моделі мали майже 100% майже в кожному типі завдань, тож відмінності проявилися лише на слабших моделях. До лідерів належали, зокрема, Claude Opus 5.5, Fable 5.1, Codex і Gemini 3.1 Pro. У підрахунках із файлу на важкому рівні Claude Haiku 4.5 отримав 2 бали з 10. Gemini 3.8 Flash із низьким рівнем міркування отримав 1 з 10, а локальна Gemma 4 12B - 0 з 10. У завданнях, де модель могла порахувати дані скриптом на Python, усі досліджені хмарні моделі отримали всі можливі бали. Навіть найслабші з них отримали всі можливі бали. Дані в цих завданнях - це експорти зі Screaming Frog, 45 тис. подій GA4 і лог сервера зі 160 тис. рядків. Тому цифри в моїй роботі рахує скрипт, який модель пише й запускає.

Текст польською наосліп оцінювали дві моделі, і тут відмінності були значні. Оцінювачі не знали, яка модель написала текст. Шкала мала 5 ступенів, а 5 означало текст, готовий до надсилання клієнтові без правок. Лише Claude Opus 5.5 і Claude Sonnet 5 отримали 5 на важкому письмовому завданні. Gemini 3.1 Pro отримав 2, бо вигадав «вчорашню розмову» з адресатом. Оцінювач Claude Opus був суворішим за оцінювача Gemini, і щодо відповідей Claude, і щодо решти моделей.

Та сама модель може дати інший результат при наступному запуску того самого тесту. Claude Haiku 4.5 отримав у двох прогонах 62 і 39 балів зі 102. У тексті про SEO-аудит описав, чому модель AI не зробить повного аудиту сайту сама.

Мій набір: які інструменти AI я використовую і для чого?

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

Якими мовними моделями я користуюся і для чого?

Головну роботу роблю в Claude Code, тобто в Claude, що працює в терміналі з доступом до файлів, скриптів і даних. Claude пише й запускає скрипти, читає експорти та готує чернетки звітів. Codex (OpenAI) і Gemini (Google) отримують ті самі матеріали для повторної перевірки.

Тексти й звіти перевіряю другою моделлю іншого виробника, у два раунди. У першому раунді шукаю фактичні помилки й прогалини. Другий раунд перевіряє лише правки, бо при виправленні виникають нові помилки. У жовтні 2026 року в одному проєкті другий раунд знайшов у посібнику хибну кількість усіх посилань, від якої рахували відсоток: 79 замість 76. Ця помилка виникла лише при правках. Мій контрольний скрипт її не знайшов.

Модель як суддя якості може вимірювати щось інше, ніж людина, тому перевіряю її на текстах, які вже оцінив. 7 жовтня 2026 року я дав двом моделям оцінити 87 описів патентів Google. Серед них було 8 описів, які раніше сам визнав готовими, а судді про це не знали. Fable, модель компанії Anthropic, визнала готовими 5 із цих 8. Codex із високим рівнем міркування визнав 1 з 8.

Ці два результати кажуть лише про тексти, які я сам визнав готовими. Решти 79 описів я не оцінював, тож не знаю, скільки відхилень було слушних. Codex відхилив загалом 51 з 87 описів, бо кожне речення опису порівнював із формулою винаходу, яка визначає обсяг правової охорони. Узгодженість суддів між собою була близькою до випадкової. Каппа Коена склала 0,06, де 0 означає випадкову узгодженість, а 1 - повну.

Локальні моделі на власному комп'ютері з відеокартою використовую для масового маркування даних, бо не плачу за кожну одиницю. 1 жовтня 2026 року я перевірив локальні моделі на чотирьох простих діях. Даними були сторінки трьох польських інтернет-магазинів. Gemma 4 31B розпізнала тип сторінки у 98,5% із 403 сторінок. Типи сторінок - це продукт, список продуктів, стаття або інше. Скрипт із правилами влучав у 84% цих сторінок.

Gemma майже без помилок зчитала ціни й оцінила узгодженість чисел, але частина еталонів у цьому тесті походила з моделі, а не від людини. Еталоном типу сторінки були мітки зі скрипта, виправлені моделлю Claude Opus. Gemma правильно зчитала ціну з усіх 177 карток продукту. Еталоном була ціна зі структурованих даних, узгоджена з текстом сторінки. У 99,3% зі 134 випадків Gemma правильно оцінила, чи число в реченні збігається з даними. Половина цих речень мала навмисно змінене число. Gemma розпізнала також тип попиту в ключовому слові (пропозиція, поза пропозицією чи порада) у 97,7% з 218 ключових слів. Еталоном були тут мітки моделі Claude Opus.

Та сама родина моделей підвела при порівнянні чисел між двома файлами в справжній пропозиції. 12 жовтня 2026 року дві версії Gemma 4, 26B і 31B, порівняли 63 рядки й повідомили лише про хибні суперечності. Визнали, наприклад, що «-34%» і «одна третина» - це суперечливі значення. Єдина справжня проблема в цьому тексті стосувалася не чисел, а перебільшеного слова біля результату з таблиці. Тож не належала до завдання Gemma. Тепер скрипт перевіряє, чи кожне число з одного файлу є в другому. Це контроль наявності чисел, а їхній зміст перевіряє людина або друга модель.

Якими інструментами користуюся для даних про позиції та попит?

Дані про результати Google беру з DataForSEO, Search Console та Ahrefs, і кожне з цих джерел має іншу пастку. DataForSEO продає завантаження результатів Google і дані про попит з оплатою за кожен запит. Від 17 вересня до 14 жовтня 2026 року я замовив там 17 076 завдань за 99,89 USD. Серед них було 13 085 завантажень результатів Google.

Одного завантаження результатів не вистачає для вимірювання позиції, бо наступні завантаження того самого ключового слова виглядають інакше. 7 жовтня 2026 року я завантажив результати для 94 ключових слів тричі з інтервалом в одну годину і двічі в ту саму хвилину, за 1,57 USD. Потім порівняв домени з першої десятки у двох завантаженнях того самого ключового слова. Спільні домени становили в медіані близько 15% усіх різних доменів з обох завантажень. У завантаженнях з тієї самої хвилини було близько 8%. Одне ключове слово мало в медіані 4 варіанти результатів. Тому замість позиції рахую частку завантажень, у яких домен є в першій десятці. Завантажень близько 10, і надсилаю їх одночасно.

Це вимірювання скасувало мій попередній тест, у якому я порівняв позицію з одного завантаження з цитуваннями з п'яти завантажень. Результат тесту «пройдено» виявився хибним, тож тест зупинив. AI Overview, тобто відповідь AI над результатами Google, був у цьому вимірюванні стабільним: з'являвся у 97-99% завантажень, а список цитованих сторінок не змінювався.

Search Console показує кліки, виміряні самим Google, але експорт із панелі обрізає таблицю до 1 000 рядків. Тисяча запитів, відсортованих за кліками, - це частина даних із найбільшою кількістю кліків. 20 вересня 2026 року для одного сайту експорт із панелі показав CTR 4,28% для позицій 1-3 у США. CTR - це частка показів, які закінчилися кліком. Дані за 16 місяців, отримані без ліміту 1 000 рядків, тобто 123 498 запитів, дали 1,40%. Такі дані отримую через API Search Console, тобто інтерфейс для програм. Другий спосіб - звіт у Looker Studio, безплатному інструменті Google для звітів, із конектором Search Console.

Ahrefs використовую для посилань, ключових слів і конкуренції, але його оцінки трафіку перевіряю в Search Console. Колонка трафіку в Rank Tracker від Ahrefs - це оцінка: оцінений попит, помножений на прийняту частку кліків. Для одного сайту ця оцінка була в 10-50 разів вищою за кількість кліків в Search Console, а в іншому приблизно в 3 рази нижчою. Rank Tracker рахує також блоки на сторінці результатів як позиції. В одному випадку падіння з 1-го на 13-те місце означало лише те, що над результатами з'явився AI Overview.

Якими інструментами користуюся для технічного аудиту?

Для аудиту використовую Screaming Frog і браузер Chrome без вікна, а модель AI читає результати, але не замінює сканування сайту. Screaming Frog проходить сайт так, як робот пошуковика. Chrome, запущений без вікна, показує сторінку після виконання JavaScript, тож порівнюю обидві версії сторінки. В одному аудиті сканування з JavaScript і без нього, запущені паралельно, дали хибний сигнал про рендеринг. Відтоді запускаю їх по черзі.

Коли файрвол сайту, який аудитую, блокує мою програму для сканування, окремі адреси завантажую через сервіс Apify Web Fetch. У тесті з 12 жовтня 2026 року сервіс зчитав 8 із 8 сторінок, яких я не міг завантажити зі своєї IP-адреси. Дві з них належали сайтам клієнтів, а шість - публічним сайтам із відгуками, порівнювачам і інтернет-магазинам. Це коштувало 0,00155 USD за адресу. Сервіс іноді повідомляв, однак, про вдале завантаження з кодом 200, хоча завантажив лише сторінку перевірки. Дуже короткий текст або текст про перевірку вважаю тому блокуванням і повторюю завантаження.

Цей сервіс не показує, що бачить справжній робот Google чи робот AI. Він підключається з іншої IP-адреси, а навіть коли я вказую назву робота, інші заголовки видають звичайний браузер Chrome. Тому блокування роботів перевіряю в Search Console і власним скриптом, який порівнює відповіді сервера для різних роботів. У тексті про файл llms.txt описав, як за IP-адресою перевіряю, чи запит надіслав справжній робот.

Асистента технічних аудитів я створив на аудитах моєї агенції з 2020-2026 років і вимірюю його на аудитах, які раніше зробила людина. Асистент - це агент AI, який збирає дані про сайт і перевіряє їх за каталогом правил, записаних з цих аудитів. Обсяг аудиту й пріоритети затверджую сам, на початку роботи й перед надсиланням аудиту. Результат вимірювання допишу тут після другого вимірювання на новому сайті.

Якими інструментами користуюся для контенту та семантики?

Ключове слово прив'язую до сторінки за допомогою гібридного пошуку, бо попередня версія мого інструмента правильно добирала сторінку лише для третини ключових слів. 14 жовтня 2026 року я взяв ключові слова з Search Console двох сайтів, без ключових слів з назвою марки. Для кожного ключового слова еталоном була сторінка, яка отримала щонайменше 60% кліків за цим ключовим словом і була серед відсканованих сторінок сайту. Попередня версія інструмента використовувала модель MiniLM для ембедінгів, тобто перетворення тексту на вектор чисел. Вона вказала еталонну сторінку першою у 34% ключових слів.

Гібридний пошук поєднує три списки сторінок і влучав в еталонну сторінку у 80,5% і 77,1% ключових слів. Перший список походить із моделі e5-large. Другий - це пошук за словами в тексті, а третій - за словами в title, заголовку H1 і адресі. Списки поєдную методом RRF, який винагороджує сторінки, що високо стоять одразу на кількох списках. Найкраща окрема модель для ембедінгів була різною на кожному з сайтів, а гібрид переміг в обох.

Під час цього тесту я знайшов помилку у власному інструменті: модель не бачила кінця більшості фрагментів тексту. Скрипт ділив текст на фрагменти по 80 слів, а модель приймає 128 токенів, тобто шматків слів. Польські слова діляться на більше токенів, ніж англійські, тож 89-98% фрагментів обрізали. Результат 34% стосується, отже, попередньої версії інструмента разом із цією помилкою, а не самої моделі MiniLM. Тест вимірює узгодженість із кліками в Google, а не те, яка сторінка найкраще відповідає на запит.

Сутності, тобто назви компаній, продуктів, осіб і понять, витягую з текстів локальною моделлю GLiNER2. У моєму тесті з липня 2026 року модель мала на польських текстах F1 0,94, стільки ж, як на англійських. F1 поєднує влучність і повноту, а 1 означає ідеальний результат. Цей результат стосується міток, які не перекриваються. Коли в одному запиті були одночасно мітки «фірма» і «марка», F1 падав до 0,85. Модель працює на звичайному процесорі, близько 20 абзаців на секунду, без плати за сторінку.

Не використовую GLiNER2 для розпізнавання інтенції ключових слів, бо в моєму тесті вона влучала лише в 33-42% випадків. Часто помилялася з упевненістю 0,99, тобто з майже найвищою упевненістю, яку сама повідомляє.

Мапу тем цієї серії текстів я зробив із сутностей на 71 сторінці конкурентів з Польщі та США. Скрипт витягнув 110 сутностей і 1 764 трійки, тобто записи у формі сутність, ознака й значення. Дані коштували 0,072 USD. Мапа показала ролі текстів, пари текстів для з'єднання посиланнями й теми, яких бракує на цьому сайті.

Якими інструментами користуюся для лінкбілдингу?

Для аналізу посилань використовую Ahrefs, але посилання, позначені як втрачені, перевіряю наживо, перш ніж вони потраплять у висновки. У жовтні 2026 року в одному проєкті Ahrefs показував 360 польських доменів як втрачені. 140 із них і далі посилалися тією самою адресою. Близько 70 адрес відповідали помилкою 403 на завантаження звичайною програмою, тож я перевірив їх у браузері, яким керує скрипт (Playwright).

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

Якими інструментами користуюся для вимірювання видимості в AI?

Інструменти для вимірювання видимості марки в AI описав в окремому тексті, тож тут наводжу лише принцип. Згадку марки у відповіді та цитування її сторінки рахую окремо. Кожне запитання ставлю кілька разів, бо відповіді асистентів змінюються. У тексті про видимість марки в AI описав вимірювання, кількість повторів і пастки інструментів. У тексті про AI SEO і GEO описав, що роблю на сайті, щоб асистенти AI могли його цитувати.

Які інструменти SEO ми створили самі?

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

У VerticalSEO ми готуємо 16 інструментів SEO, які будуть доступні через сайт і через API, також для агентів AI. Інструменти ще не опубліковані. Тести з 8 жовтня 2026 року перевіряли, чи інструменти працюють відповідно до специфікації. Пройшли 610 із 610 тестів API і 325 з 325 тестів інструментів для агентів у браузері. Ці інструменти працюють за стандартом WebMCP, який надає функції сайту агентам AI. Тести ще не вимірюють, чи інструменти дають влучні висновки SEO.

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

LemmeGSC, мою панель для даних із Search Console, готую до випуску як відкрите програмне забезпечення. Панель завантажує дані з Search Console без ліміту 1 000 рядків. Показує, зокрема, канібалізацію ключових слів, тобто кілька сторінок одного сайту на те саме ключове слово.

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

На початок вистачить Search Console, Looker Studio, безплатної версії асистента AI та безплатної версії Screaming Frog. Кожен із цих інструментів має іншу роль:

• Search Console показує кліки, покази й запити з Google;
• Looker Studio з конектором Search Console завантажує ці дані без ліміту 1 000 рядків;
• безплатна версія асистента AI групує ключові слова, пише чернетки й скрипти, якщо надасте їй дані;
• безплатна версія Screaming Frog сканує до 500 адрес, чого вистачає для малого сайту.

Платні інструменти для ключових слів і посилань варто додати лише тоді, коли знаєте, на яке запитання вони мають вам відповісти. Безплатний асистент AI не знає ваших даних із Search Console. Найбільше дає тоді, коли отримує від вас експорт і прохання про скрипт, який порахує результат.

Як я тестую інструмент AI, перш ніж йому довіряти?

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

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

Дані для тестів коштували мені небагато, а найбільше роботи вимагає еталонний набір. Тест завантажень результатів коштував 1,57 USD, а дані для мапи тем серії - 0,072 USD. Еталонний набір вимагає попередньої оцінки людини. Наведені витрати не охоплюють цієї праці.

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

Найпоширеніші запитання про інструменти AI в SEO

З чого почати?

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