Публічної ціни у цього методу немає: перед вами гайд, а не послуга. Скіл Marketing від Anthropic дає структурований аудит технічної частини, контенту й позиціонування на ваших власних даних. Він не замінить краулер сайту, базу зворотних посилань і польові Core Web Vitals. Далі — порядок дій від збору даних до черги правок.
Стаття розрахована на власника сайту, який уміє відкрити термінал, вивантажити CSV і знайти поле title у своїй CMS. SEO-освіта не потрібна: кожен термін пояснюється при першій згадці.
Аудит через Claude — це прогін ваших власних даних сайту через скіл Marketing, що йде в комплекті з Claude Desktop: качати й ставити нічого не треба, запуск робиться командою
/seo-audit. На вхід ідуть sitemap.xml, robots.txt, сирий HTML головних сторінок, експорт Search Console і знеособлений експорт GA4. На виході ви отримуєте текстовий звіт із проблемами й рекомендаціями, який самі розкладаєте на три черги: правлю в CMS, робить Claude Code у репозиторії, потрібен розробник. Публічної ціни тут немає, бо це редакційний гайд. Головна умова: кожну рекомендацію перед впровадженням перевіряють другим джерелом.
Короткий словник
- Скіл — багаторазова інструкція для Claude, яку модель підвантажує сама, коли бачить відповідну задачу.
- Краулер — програма, що обходить сайт за посиланнями і збирає технічні дані кожної сторінки.
- Канонікал — тег
rel="canonical"у коді сторінки; каже пошуковику, яку адресу вважати основною серед дублів. - hreflang — тег, який показує пошуковику мовні версії однієї сторінки та зв'язок між ними.
- Core Web Vitals — показники швидкості й стабільності сторінки, які Google міряє у справжніх браузерах відвідувачів.
Що дає і чого не дає аудит через Claude
Чесна відповідь у перших рядках: це гайд, а не послуга
Тут немає чого купувати. Потрібні ваш акаунт Claude, доступ до Search Console і GA4 плюс кілька годин на перший прогін. Виконавців і підрядників у цій схемі не передбачено: ви робите аудит самі й самі відповідаєте за те, що впроваджуєте.
Друга половина чесної відповіді неприємніша. Claude не ходить по вашому сайту сам, не знає, скільки у вас сторінок, і не бачить, як сайт вантажиться у відвідувача з Кривого Рогу на мобільному інтернеті. Модель працює рівно з тим, що ви поклали в чат.
Маршрут аудиту: від збору даних до черги правок
- Збір даних: Search Console, GA4, sitemap, ключові URL
- Знеособлення експортів
- SEO Skill: технічка і контент
- Marketing Skills: позиціонування і меседжі
- Звіт: що болить, чому і на яких сторінках
- Верифікація кожної рекомендації
- Верифікація кожної рекомендації
- підтвердиласьУ чергу правок
- Пріоритезація і розподіл на три доріжки
- Верифікація кожної рекомендації
- не підтвердиласьПрибираємо або перепитуємо з точнішими даними
Де метод сильний, а де він просто мовчить
Сильна сторона одна, зате велика: модель швидко читає багато тексту і знаходить у ньому невідповідності. Запити, за якими сторінка вже отримує покази, проти того, що на цій сторінці реально написано. Однакові description по всьому каталогу. Обіцянка на головній, яку жодна внутрішня сторінка не підтверджує.
Мовчить метод там, куди ви його не пустили.
Якщо сторінки немає у вхідних файлах, для аудиту її не існує, і звіт про це не попередить. Гірше: коли модель не знає відповіді, вона рідко зупиняється. Вона впевнено допише правдоподібну деталь, і саме через це нижче є цілий розділ про перевірку. Плануйте час не тільки на прогін, а й на звіряння висновків.
Скіл, промпт чи Project-інструкція: у чому різниця простими словами
Скіл як багаторазова інструкція, яку модель підвантажує сама
Промпт живе одне повідомлення. Скіл написаний один раз і вмикається сам, коли задача підходить під його опис. Різниця відчувається на другому прогоні: промпт ви щоразу формулюєте трохи інакше, і два звіти вже не порівняти між собою, бо в них різна структура.
Якщо ви ще не ставили скілів руками, подивіться, як поставити перший скіл Claude. Для Marketing цього робити не доведеться, і причина — у наступному розділі.
Коли вистачає звичайного промпта, а коли треба скіл
Для одного питання про одну сторінку скіл зайвий. Напишіть у чат: ось HTML, ось запити, скажи, чого не вистачає. Скіл потрібен тоді, коли ви збираєтеся повторювати аудит: раз на квартал, після редизайну, перед сезоном.
| Що порівнюємо | Промпт у чаті | Інструкція Project | Скіл Marketing |
|---|---|---|---|
| Коли працює | тільки в цьому повідомленні | у всіх чатах одного проєкту | коли модель бачить відповідну задачу |
| Хто тримає структуру звіту | ви | ви | скіл |
| Для чого зручно | разове питання про сторінку | постійний контекст бізнесу | повторюваний аудит за однією схемою |
| Слабке місце | звіти не порівняти між собою | не задає формат звіту | нічого не знає про ваш бізнес, поки ви не дали дані |
Третій варіант — інструкція проєкту. Вона тримає постійний фон: чим ви займаєтесь, для кого, якою мовою пишете, які у бізнесу межі. Як це налаштувати, розібрано в гайді про Claude Desktop і Projects. Скіл і Project не конфліктують: інструкція дає фон, скіл дає формат.
Звідки береться скіл Marketing від Anthropic і що зробити, щоб ним користуватися
Качати нічого не треба: скіл уже в Claude Desktop
Скіл Marketing іде в комплекті з Claude Desktop. Окремої папки зі скілом не існує, файл інструкцій шукати й кудись класти не потрібно. Викликається він командами, які пишуть з першого символу повідомлення:
/seo-audit. Технічний і контентний розбір того, що ви подали на вхід./performance-report. Звіт за вивантаженими метриками./competitive-brief. Розбір конкурента за матеріалами, які ви дали./brand-review. Перевірка того, наскільки ваші тексти тримають один голос./content-creation,/draft-content,/campaign-plan,/email-sequence. Решта набору: матеріали, план кампанії, серія листів.
Як перевірити, що скіл справді підхопився
Наберіть у полі вводу скісну риску і подивіться список команд: /seo-audit має бути серед них. Другий спосіб надійніший. Запустіть команду на одній сторінці й подивіться на форму відповіді: скіл дає розділений звіт із категоріями проблем, а звичайний чат відповідає суцільним роздумом.
Що робити, якщо скіл не бачиться
Перевірте, що ви в застосунку Claude Desktop, а не у браузері. Оновіть застосунок і перезапустіть його. Почніть новий чат: у довгій розмові команда іноді читається як звичайний текст. Пишіть її без пробілу на початку і без лапок.
Зібрати вхідні дані
- sitemap.xml і robots.txt
- сирий HTML головних сторінок
- експорти Search Console
Знеособити експорти
- прибрати email і телефони
- замінити ідентифікатори на псевдо-ID
Запустити /seo-audit
- прикріпити файли
- описати нішу, регіон і мову сайту
Перевірити висновки
- URL Inspection
- curl -I
- view-source
Розкласти на черги
- правлю в CMS
- робить Claude Code
- потрібен розробник
Що подати на вхід, бо Claude не краулер
sitemap.xml, robots.txt і сирий HTML головних сторінок
Почніть із файлів, які лежать у вас під рукою.
- sitemap.xml. Карта сайту: список адрес, які ви самі віддаєте пошуковику.
- robots.txt. Правила обходу: які розділи закриті від пошукових роботів.
- Сирий HTML. Код сторінки до виконання скриптів, відкривається через view-source. Тут видно title, description, канонікал і те, чи є основний текст у коді взагалі.
Беріть по одній сторінці кожного типу: головна, категорія, картка товару чи послуги, стаття. Цього вистачає, щоб знайти проблему шаблону, а шаблонна проблема повторюється на всіх сторінках такого типу.
Експорти зі Screaming Frog або Sitebulb
Краулер обходить сайт за посиланнями і віддає таблицю: адреса, код відповіді, title, description, заголовки, глибина вкладеності. Ця таблиця перетворює аудит кількох сторінок на аудит сайту. Без неї модель бачить зріз, з нею — картину.
Search Console: Performance і Pages
З Performance вивантажте запити й сторінки з показами, кліками й позиціями за квартал. Зі звіту Pages візьміть перелік адрес, які не потрапили в індекс, разом із причинами. Саме зіставлення цих двох файлів дає найцікавіші висновки: сторінка отримує покази за запитом, якого немає в її тексті.
GA4: дивимось на конверсії
Експортуйте події конверсій у розрізі сторінок входу. Загальний графік трафіку в аудиті майже нічого не дає, бо він не пояснює, які сторінки приносять заявки. Перед завантаженням файл треба знеособити, і про це є окремий розділ.
Заведіть окрему теку на кожен прогін і назвіть її датою. Файли всередині називайте однаково від разу до разу: gsc-performance.csv, gsc-pages.csv, ga4-conversions.csv. Коли через квартал ви робитимете другий аудит, порівнювати доведеться саме ці файли, і однакові імена зекономлять вечір.
Онлайн чи офлайн: режим із web-доступом у Claude Code проти аудиту на завантажених файлах
Claude Code — це той самий Claude у терміналі, з доступом до файлів у теці й, з вашого дозволу, до мережі. Якщо формат для вас новий, почніть із пояснення, що таке Claude Code простими словами.
| Що порівнюємо | Claude Code з доступом до мережі | Аудит на завантажених файлах |
|---|---|---|
| Що бачить | живі сторінки, заголовки відповіді, редиректи | тільки те, що ви поклали в чат |
| Свіжість даних | стан на момент запуску | стан на момент експорту |
| Головний ризик | модель відкриє не ту адресу і опише не ту сторінку | сліпа пляма: чого немає у файлах, того не існує |
| Коли зручно | точкова перевірка кількох адрес | великі експорти й дані, які не хочеться віддавати наосліп |
Робочий компроміс простий. Великий розбір робіть на файлах, які ви самі підготували, а живий режим лишіть для перевірки конкретних адрес, коли треба побачити редирект або заголовок відповіді власними очима.
Сліпі зони методу, про які краще знати заздалегідь
Беклінки, обсяги пошуку і дані конкурентів
Модель не має бази зворотних посилань. Вона не знає, скільки разів на місяць люди шукають ваш запит. Про конкурента вона скаже рівно те, що є у вашому чаті. Питання «яка частотність цього запиту» дає відповідь, схожу на правду, і це найнебезпечніший тип помилки в усьому процесі.
Польові Core Web Vitals із CrUX, логи сервера, історія індексації
CrUX — це набір даних про швидкість, зібраних із браузерів справжніх відвідувачів. Модель до нього не має доступу, тому будь-яка оцінка швидкості зі звіту є припущенням за кодом сторінки. Логи сервера вона теж не бачить. Історія індексації живе в Search Console, і дивитися її треба там.
Чим це не замінює звичні інструменти
- Ahrefs і Semrush. Зворотні посилання й частотність запитів.
- PageSpeed Insights. Швидкість, разом із польовими даними.
- Search Console. Те, що Google справді бачить на вашому сайті.
- Краулер. Повний обхід усіх сторінок і коди відповідей.
Claude склеює вивантаження цих інструментів в одну картину і пропонує порядок дій. Саме склейка й пріоритезація тут є цінністю, а не самі дані.
Перевірка звіту на галюцинації
Вибіркова верифікація кількох тверджень через URL Inspection
URL Inspection — інструмент у Search Console, який показує, що Google знає про конкретну адресу: чи вона в індексі, який канонікал обрано, коли був останній обхід. Візьміть зі звіту твердження, найдорожчі за наслідками, і перевірте кожне поштучно. Найдорожчі — це ті, після яких ви щось видаляєте, закриваєте або масово переписуєте.
curl -I і view-source: канонікал, hreflang, заголовки відповіді
curl -sSI ваш-сайт.ua/storinka
curl -s ваш-сайт.ua/storinka | grep -iE "canonical|hreflang|noindex|<title"
Перша команда показує код відповіді й ланцюжок редиректів. Друга витягує з коду сторінки рядки з канонікалом, мовними версіями, забороною індексації і заголовком. Схему curl підставить сам, тож ви ще й побачите, чи є перехід на захищену версію.
Звіт пише, що на сторінці послуги стоїть канонікал на головну. Ви запускаєте другу команду і бачите в коді канонікал на саму себе. Висновок: рекомендація не підтвердилась, у чергу правок вона не йде. Такі розбіжності трапляються найчастіше там, де модель добудовувала картину за схожими сторінками.
Правило другого джерела: не впроваджую те, чого не підтвердив
Правило звучить нудно і рятує сайт. Жодна правка не потрапляє в чергу, поки ви не побачили проблему самі: в Search Console, у відповіді сервера або в коді сторінки. Виняток один, і він теж перевірний: якщо рекомендація стосується формулювань у тексті, суддею є ваш здоровий глузд і знання свого бізнесу.
Приватність: що саме потрапляє в модель із ваших експортів
Як знеособити GA4- і CRM-вивантаження: user_id, email, IP
Технічні файли сайту персональних даних зазвичай не містять. Експорти GA4 і CRM містять їх майже завжди: адреси електронної пошти, телефони, ідентифікатори користувачів, IP-адреси, імена клієнтів, а ще адреси сторінок із параметрами, у яких інколи лежить пошта прямо в рядку.
Перед завантаженням пройдіться по стовпцях і приберіть усе, що вказує на конкретну людину. Ідентифікатори, потрібні для зв'язку рядків між собою, замініть на псевдо-значення. Для аудиту немає жодної різниці, як звати клієнта; має значення, з якої сторінки він прийшов і що зробив далі.
Знеособлення робиться до завантаження файлу, а не в промпті. Прохання «не звертай уваги на колонку з поштою» персональні дані нікуди не дівають: вони вже у файлі, який ви надіслали. Прибирайте стовпці в редакторі таблиць і зберігайте окрему очищену копію.
Чому для клієнтського сайту потрібна згода замовника
Якщо сайт не ваш, дані теж не ваші. Домовленість про передачу вивантажень стороннім сервісам має бути зафіксована письмово, хоча б листом із підтвердженням. Це захищає і замовника, і вас, коли постане питання, звідки в аудиті взялися цифри з чужої аналітики.
Межі одного прогону: скільки сторінок реально влазить у контекст
Рахуйте не сторінки, а обсяг тексту. Сирий HTML важкий: у ньому купа розмітки, скриптів і стилів, які з'їдають місце і нічого не додають до аналізу. Табличні експорти влазять значно краще, бо в них немає коду.
Ознака перевищення межі помітна одразу: відповідь стає загальною, перестає посилатися на конкретні адреси й починає радити «оптимізувати структуру». Побачили таке — ріжте вхідні дані на менші частини.
Як бити великий сайт на пакети за шаблонами сторінок
Беріть по одному типу сторінок за прогін: спершу картки товарів, потім категорії, потім статті. У межах типу достатньо вибірки з кількох адрес, бо шаблонна проблема повторюється однаково. Окремим прогоном ідуть головна й сторінки послуг, які завжди унікальні.
Українська специфіка: аудит uk-UA контенту
hreflang для uk- і ru-версій та ситуація «дві мовні версії з дублями»
Найчастіша знахідка на українських сайтах така: дві мовні версії існують, а hreflang між ними не прописаний або вказує сам на себе. Пошуковик у такому разі сам вирішує, яку версію показувати, і рішення вам не сподобається. Друга типова знахідка: російська версія технічно є, але половина сторінок у ній порожня або дублює українську слово в слово.
Модель добре ловить обидва випадки, якщо ви подали HTML обох версій однієї сторінки поруч. Подавайте їх парою, інакше порівнювати нема з чим.
Локальний SEO і NAP у Google Business Profile
NAP — це назва, адреса й телефон компанії. Правило просте: у Google Business Profile, на сайті у футері та на сторінці контактів вони мають збігатися до символу, разом із форматом запису телефону. Скопіюйте всі три варіанти в чат і попросіть знайти розбіжності; це рівно та задача, у якій модель не помиляється.
Графік роботи й опис компанії теж варто звірити. Профіль, у якому вказано роботу до вісімнадцятої, а на сайті до двадцятої, псує довіру швидше за будь-який технічний недолік.
Від звіту до впровадження: три черги правок
Звіт сам по собі не покращує сайт. Робить це черга, розкладена за виконавцем.
Правлю сам у CMS: WordPress, Tilda, Webflow
Сюди йде все, що редагується через адмінку: title, description, заголовок H1, текст на сторінці, alt-описи картинок, внутрішні посилання, налаштування редиректу в плагіні. Тут не потрібен ніхто, крім вас і півгодини часу.
Робить Claude Code у репозиторії
Сюди йде те, що лежить у коді сайту: шаблон title, розмітка структурованих даних, атрибути hreflang, файл robots.txt, генерація sitemap. Claude Code читає теку проєкту й вносить правки, а ви дивитесь зміни перед публікацією. Умова одна: сайт має бути в репозиторії, і ви маєте вміти відкотити зміни.
Потрібен розробник
Сюди йде все, що чіпає сервер і швидкість: налаштування кешування, стиснення зображень на льоту, зміна логіки редиректів на рівні сервера, перебудова навігації. Не тому, що це складно вам, а тому, що ціна помилки на бойовому сайті висока.
Підтверджена правка зі звіту: куди її вести?
- Це текст, метадані або поле з адмінки CMSДоріжка 1: правлю сам у CMS
- Правка у файлах репозиторію: шаблон, редиректи, конфігЄ доступ до репозиторію і безпечний спосіб перевірити зміну?
- ТакДоріжка 2 — робить Claude Code у репозиторії
- НіДоріжка 3 — потрібен розробник
- Потрібні сервер, CDN, база даних або міграція структуриДоріжка 3: потрібен розробник
Як пріоритезувати чергу за впливом і складністю
Перше — усе, що ламає індексацію: помилковий noindex, закриті від обходу потрібні розділи, канонікал на чужу адресу, ланцюжки редиректів. Друге — сторінки, які вже мають покази, але слабкий заголовок: там ефект видно найшвидше. Косметика тексту йде останньою, хоч і виглядає найприємнішою для роботи.
Baseline перед правками: що фіксуємо ДО
Набір метрик, які знімаємо на старті
Зніміть і збережіть у файл: кількість сторінок в індексі, покази й кліки за квартал у розрізі сторінок, середні позиції за основними запитами, конверсії за сторінками входу. Це база порівняння. Без неї через квартал ви будете сперечатися самі з собою, стало краще чи ні.
Як не сплутати сезонність з ефектом правок
Порівнюйте не з попереднім місяцем, а з тим самим періодом торік. Якщо історії за рік немає, дивіться на сторінки, яких ви не чіпали: вони працюють контрольною групою. Сезонний спад видно по всьому сайту одразу, а результат правок помітний лише в тій групі адрес, яку ви змінювали.
Аудит як повторюваний процес
Звіт у git і diff між прогонами
Зберігайте кожен звіт текстовим файлом у репозиторії. Наступний прогін кладете поруч і дивитесь різницю: які проблеми зникли, які лишились, які з'явилися. Це найдешевший спосіб побачити рух, і він не потребує жодного окремого інструменту.
Що робити з рекомендацією, яку Claude повторює втретє
Варіантів два. Або ви її досі не впровадили, і тоді питання закрите. Або ви впровадили, а модель усе одно бачить проблему: тоді перевірте, чи правка справді доїхала до бойового сайту, бо кеш, чернетка в CMS і невикладена гілка перехоплюють такі зміни регулярно.
Антипатерни, які активно шкодять сайту
Масова перегенерація title і description
Ви просите модель переписати title і description для всього сайту, вивантажуєте результат у CMS і публікуєте. Через місяць частина сторінок втрачає покази, і зрозуміти, які саме тексти в цьому винні, вже неможливо, бо змінилося все одночасно.
Ви берете один шаблон сторінок, зберігаєте старі title і description у файл, міняєте їх у межах цієї партії й записуєте дату. Наступний прогін порівнює покази до і після саме по цій групі адрес, а решта сайту лишається контрольною групою.
Видалення «слабких» сторінок наосліп
Сторінка без кліків не завжди марна. Вона може отримувати покази за важливим запитом, бути частиною ланцюжка внутрішніх посилань або збирати переходи із соцмереж, яких немає у звіті Search Console. Перед видаленням подивіться на неї в аналітиці за рік і перевірте, що на неї не ведуть посилання зсередини сайту.
Купа правок одночасно, коли вже не зрозуміти, що спрацювало
Спокуса зробити все за вихідні велика, наслідок передбачуваний: показники змінилися, а причина невідома. Робіть правки партіями, між ними тримайте паузу хоча б у кілька тижнів. Дату кожної партії записуйте в той самий файл зі звітом; через квартал це буде єдиний спосіб пов'язати зміну цифр із конкретною дією.