Як Spilno Agency робить On-page оптимізацію сайта за допомогою Claude

Spilno Agency проводить on-page SEO оптимізацію сторінок клієнтів разом з AI-агентом Claude — за єдиним стандартом документа, що охоплює аудит GSC, технічну Schema-розмітку, контентні правки та live-перевірку кожної зміни на живому сайті. У статті — що входить у цей стандарт і сам майстер-шаблон документа для завантаження.

Чому “оновити мета-теги” — це ще не on-page оптимізація

Коли клієнти чують “on-page SEO оптимізація”, часто уявляють щось на кшталт: переписати Title, додати кілька ключових слів у текст — і чекати результату. На практиці це рідко працює, бо сторінка ранжується не за окремими елементами, а за сукупністю сигналів: технічною коректністю (canonical, hreflang, Schema), відповідністю контенту реальному пошуковому інтенту та довірою (E-E-A-T).

У Spilno Agency ми формалізували цей процес у єдиний документ-стандарт, який використовуємо для кожної сторінки — незалежно від того, це сторінка послуги, кейс чи гайд. Документ веде AI-агент Claude, а команда агентства контролює кожен крок і затверджує будь-які зміни на живому сайті.

Що входить у стандарт документа on-page оптимізації

Стандарт виріс до дев’яти обов’язкових кроків (Крок 0 – Крок 8). Жоден не пропускається — якщо якийсь блок не релевантний для конкретної сторінки, ми фіксуємо це явно, а не просто прибираємо пункт.

1. Крок 0. Підготовка — WP ID усіх мовних версій, перевірка на редирект чи паралельний дубль тієї самої сторінки (перш ніж аналізувати щось інше), доступів до Google Search Console і WP Admin.
2. Крок 1. Цільовий кластер запитів — реальні дані Search Console за 90–180 днів (покази, кліки, CTR, позиція), звірені з незалежним інструментом реального пошукового попиту, плюс перевірка, чи не конкурує ця сторінка за ті самі запити з іншою сторінкою сайту (канібалізація).
3. Крок 2. Технічний аудит — Schema markup, Title/Meta, H1/H2-структура, hreflang reciprocal, alt-тексти, internal linking, контраст і доступність (WCAG AA).
4. Крок 2б. Контентний аудит — окреме від Кроку 1 питання: чи сам текст сторінки достатньо покриває ці запити. Бенчмарк топ-3 конкурентів у видачі, обсяг тексту по блоках, карта входжень ключових слів, чого не вистачає порівняно з конкурентами (content gaps).
5. Крок 3. План змін — конкретні “до/після” для Title, Meta, H1, нових контентних блоків і Schema — без розпливчастих рекомендацій, і лише на основі даних Кроків 1 і 2б.
6. Крок 4. Зведена таблиця змін — пріоритет, тип (баг/фіча/інше) і статус кожної правки.
7. Крок 5. Мовні версії — окремий чекліст на кожну локаль (UA/EN/PL/RU), бо контент і запити для кожної мови різні.
8. Крок 6. Очікувані результати — прогноз по кожній конкретній зміні з термінами (2–4 і 6–8 тижнів) і ризиками, які можуть завадити прогнозу справдитись.

Цикл завершують два кроки, які й тримають стандарт чесним. Крок 7 — чекліст після впровадження: перевірка Title/Meta/Schema напряму на живому сайті (не в адмінці), запит на переіндексацію в Google Search Console і фіксація дати для звірки прогнозу з фактом. Крок 8 — журнал впровадження: якщо сторінку перевіряють повторно, це не новий документ, а нумероване впровадження в тому самому файлі — з коротким ідентифікатором ітерації і позначкою на графіку трафіку в аналітиці, написаною людською мовою, без SEO-жаргону, щоб власник бізнесу міг сам побачити, що і коли змінилось.

Головний принцип: не довіряти статусу “✅”

Під час одного з аудитів ми зробили важливе відкриття: попередній документ оптимізації для однієї зі сторінок клієнта містив статус “✅ впроваджено” на Title, Meta і Schema markup. Технічно запит на запис даних повертав код відповіді сервера 200 — начебто все успішно.

Але при прямій перевірці коду живої сторінки (без проміжних кешів чи адмінки) виявилось, що жодна зі змін насправді не потрапила на сайт. Причина — окремі системи (WordPress REST API та Yoast SEO) не завжди синхронізують дані так, як очікується: сервер підтверджує прийом запиту, але фактичний запис у “живі” поля може не відбутись.

Відтоді кожен крок нашого стандарту супроводжується обов’язковою live-перевіркою: після будь-якого запису ми напряму завантажуємо HTML сторінки і перевіряємо, чи змінилися Title, Meta, чи валідна Schema markup (через парсинг JSON-LD), а не покладаємось на код відповіді сервера. Це правило зараз є частиною стандарту для кожної сторінки, яку ми оптимізуємо.

Той самий принцип “не довіряти власній оцінці” ми застосували і до самого документа оптимізації. Раніше повноту документа перевіряв рукописний чекліст — і саме він одного разу виявився неповним, бо складався по пам’яті. Тепер завершеність документа звіряє окремий механічний скрипт, що порівнює структуру заповненого документа зі структурою еталонного шаблону: якщо якийсь крок пропущено — скрипт покаже це явно, а не покладається на те, що людина чи AI-агент самі це помітять.

Як це виглядає на практиці

Приклад із реального аудиту сторінки послуги для СТО та автосервісів. Дані Google Search Console показали: одна з мовних версій отримувала понад 5 000 показів за 180 днів, і по ключовому запиту сторінка вже трималась у топ-10 (позиція 6.9) — але клікала лише 0.19% користувачів. Причина виявилась простою: заголовок і опис у видачі не відповідали тому, що людина шукала.

Паралельно технічний аудит показав відсутність Schema markup (розмітки, яка допомагає Google показувати розширені результати — наприклад, блок “Часті питання” прямо у видачі) на всіх мовних версіях, хоча видимий FAQ-контент на сторінках уже був. А в одній із локалей знайшлась мовна помилка — запитання були однією мовою, а відповіді іншою.

Результат після виправлення: оновлений заголовок і опис під реальний запит користувачів, додана Schema-розмітка на основі вже наявного контенту (без вигаданих даних), виправлений переклад і видалений блок з цінами, який не мав там бути за внутрішньою політикою агентства. Кожна зміна — з прогнозом очікуваного ефекту і датою, коли ми звіримо факт.

Завантажте майстер-шаблон

Ми підготували публічну версію майстер-шаблону — чиста методологія і структура з дев’яти кроків, якою ми користуємось для кожної нової оптимізації, без даних конкретного клієнта. Це та сама версія, за якою працює Claude, коли Spilno Agency бере в роботу чергову сторінку.

Часті питання

Чи AI повністю замінює SEO-фахівця в цьому процесі?
Ні. Claude виконує аудит, аналіз даних GSC і технічні правки за затвердженим стандартом, але кожна зміна на живому сайті клієнта — під контролем команди агентства, а рішення про контент чи публікацію завжди підтверджує людина.

Чому так важливо перевіряти зміни “наживо”, а не довіряти відповіді сервера?
Бо код відповіді 200 означає лише, що сервер прийняв запит — а не що дані реально записались у потрібне поле. Ми на практиці зіткнулись із ситуацією, коли попередня оптимізація виглядала “виконаною” в документації, але на сайті нічого не змінилось.

Чи Schema markup гарантує вищі позиції в Google?
Ні, Schema не є прямим ranking-фактором, але допомагає Google краще розуміти контент сторінки і може відкрити розширені формати видачі (rich snippets) — а це підвищує CTR навіть без зміни позиції.

Через скільки часу видно результат оптимізації?
Перші технічні зміни (Schema, оновлений сніппет) Google переіндексовує за 1–3 тижні. Помітний вплив на позиції та трафік зазвичай оцінюємо через 2–8 тижнів залежно від конкуренції в ніші.

Чи можна застосувати такий стандарт до мого сайту?
Так, документ універсальний для будь-якої сторінки з мовними версіями чи без — структура (аудит запитів, технічний аудит, план, прогноз) не залежить від ніші.

Хочете подібний аудит для вашого сайту? Залиште заявку — і ми покажемо, які сторінки вашого сайту мають найбільший потенціал для зростання.