SEO-аудит сайту: як я роблю аудит крок за кроком

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

Аудит роблю у вісім кроків:

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

Що таке SEO-аудит і чим відрізняється технічний аудит?

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

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

Як зробити SEO-аудит сайту крок за кроком?

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

Крок 1. Мета й ситуація сайту, перш ніж запущу краулер

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

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

Цей етап треба пройти самостійно, хоча багато фахівців віддають його сьогодні мовній моделі. Мовна модель буває корисна, але не зрозуміє бізнесу клієнта. Не внесе вона й творчого, унікального погляду, який має досвідчений SEO-фахівець.

Крок 2. Чи роботи взагалі отримують сторінку

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

1. Сайт «втрачав» понад 2 200 посилань, бо сторінки, з яких вони вели, стояли за файрволом, що відбивав робота інструмента аналізу посилань.
2. Магазин мав в інструменті оцінку здоров'я сайту 0 за майже 42 тис. помилок, бо замість сторінок робот інструмента отримував відповіді файрвола Cloudflare.
3. На третьому сайті блокування зупиняло краулер на першій адресі, і три тижні ніхто цього не помітив.

Ту саму адресу завантажую як звичайний браузер і як роботи Google, Bing, OpenAI, Perplexity і Anthropic, а потім порівнюю коди відповідей і розмір сторінки. Різниця між браузером і роботом - перше, що треба з'ясувати, перш ніж щось рахувати. Такий тест надсилає запити з моєї IP-адреси під назвою робота, а файрволи розпізнають справжніх роботів Google і Bing за адресою, з якої вони приходять. Тож блокування «Googlebot» у тесті не доводить блокування справжнього Googlebot. Search Console, безплатна панель Google для власників сайтів, показує, як сайт бачить справжній Googlebot.

Файл robots.txt читаю до кінця парсером, тобто програмою, що застосовує правила так, як робот, а не очима. Робот Google застосовує лише одну групу правил, ту з найточніше підібраною назвою робота, а решту пропускає. Правило Disallow: без шляху нічого не блокує (Google Search Central). У серпні 2026 з фрагмента robots.txt одного із сайтів випливало, що він блокує Google. Парсер показав, що Googlebot мав повний доступ, а заблоковані були роботи Bing і AI-асистентів. Діагноз був інший: проблема стосувалася Bing і роботів AI, а не Google.

Відсутність файлу robots.txt не блокує Google, але після кожного впровадження перевіряю, чи файл не зник. Google трактує помилку 4xx для robots.txt (крім 429) так, ніби файлу немає, тобто без обмежень (Google Search Central). Мій сайт у серпні 2026 повертав помилку 404 для robots.txt, доки я цього не виправив.

Крок 3. Дані з кількох джерел і те, чого кожне не бачить

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

Дані з Search Console беру через API, тобто інтерфейс автоматичного отримання даних, бо експорт з панелі обрізає список до 1 000 рядків. API віддає до 50 тис. рядків на день для кожного типу результатів, наприклад окремо для результатів сторінок, зображень і відео (Google, Довідка Search Console). У тексті про інструменти AI в SEO показав, як обрізаний експорт завищив CTR в одному сайті.

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

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

Крок 4. Ключові слова й результати Google перед технікою

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

Відсутність сторінки під важливе ключове слово - одна з частіших проблем у моїх аудитах: 15 із 63 аудитів, у 14 із 50 сайтів. Краулер сам цього не повідомить, бо завантажує лише сторінки, які існують. Це стає видно лише тоді, коли зіставлю попит зі списком адрес і з тим, які сторінки конкурентів з'являються в результатах.

Крок 5. Перегляд за каталогом з умовами пріоритету

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

Кожен тип проблеми в каталозі має правило виявлення, умову повідомлення, потрібний доказ, пріоритет з умовами та спосіб перевірки після впровадження. З 256 типів 86 починають правило пріоритету зі слова «високий», але майже завжди з умовою: коли ключове слово має попит, коли сторінка має трафік, коли помилка в шаблоні.

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

Крок 6. Доказ до кожного питання

Питання без доказу залишається в аудиті як «до перевірки», а не як рекомендація. Доказом є знімок місця в коді або HTML із сервера поруч із версією після виконання JavaScript. Ним може бути й графік із Search Console або вимірювання швидкості з назвою елемента, який її псує. Елемент, що погіршує завантаження або зміщує макет сторінки, називаю так, як показує вимірювання, а не так, як пасує до моєї гіпотези.

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

Ось у скороченні одне повідомлення про посилання на редиректи:

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

Крок 7. Черговість, обсяг роботи й варіанти

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

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

Крок 8. Перехресна перевірка й перевірка після впровадження

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

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

Що перевіряю в технічному аудиті?

У технічному аудиті проходжу понад десяток областей, а проблеми найчастіше повідомляю в редиректах, архітектурі сайту й контенті. В останньому стовпчику видно, у скількох із 63 аудитів архіву автор повідомив принаймні одну проблему з цієї області. Стовпчик «Що перевіряю» подає приклади, а не повний обсяг області. Таблиця показує вибрані області, а каталог ділить проблеми на 22.

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

Як перевіряю індексацію сайту?

Індексацію перевіряю за трьома списками: що є в мапі сайту, що Google проіндексував і що краулер знаходить через посилання. Розбіжність між цими трьома списками показує проблему краще, ніж кожен окремо. Мапа сайту з адресами, що повертають редирект, помилку або виключені з індексу, була в 20 із 63 аудитів, у 18 із 50 сайтів. Для окремих адрес користуюся інспекцією адреси в Search Console, яка показує також сторінку після виконання JavaScript.

Чи впливають показники Core Web Vitals на позиції?

Core Web Vitals є частиною систем ранжування Google, але не важливіші за релевантність контенту. Google прямо пише, що системи ранжування використовують Core Web Vitals. Пише також, що завжди намагається показати найрелевантніший контент, навіть коли користуватися сторінкою незручно (Google Search Central). В аудиті користуюся даними від справжніх користувачів зі звіту CrUX, а не з одного тесту в лабораторному інструменті. Там, де Google має такі дані для окремих типів сторінок, подаю їх окремо. Прогалини в цих даних описую в аудиті. Від 12 березня 2024 мірою реакції сторінки є INP, який замінив FID (web.dev).

Які помилки найчастіше знаходжу в SEO-аудитах?

Найчастіше повторюються базові технічні помилки, тобто такі, які інструменти легко виявляють: посилання на редиректи й на помилки 404, мапи сайту з неправильними адресами та дубльовані title й описи сторінок. Внутрішні посилання на адреси з редиректом з'явилися в 24 із 63 аудитів, у 20 із 50 сайтів. Інструменти виявляють їх добре, а вартість виправлення залежить від шаблону й системи сайту.

Рідше повідомлювані проблеми структури можуть мати більший вплив на трафік, ніж базові технічні помилки. Відсутність сторінок під важливі ключові слова повідомлено в 15 із 63 аудитів, і стільки ж разів - блог, у якому немає посилань на сторінки пропозиції й категорій. Каталог надає відсутній сторінці високий пріоритет, коли ключове слово має попит, а конкуренція займає позиції окремими сторінками. Блог без посилань отримує високий пріоритет, коли цільові сторінки мають трафік або дохід, а блог має авторитет. Ці умови перевіряю на даних, перш ніж надати пріоритет.

• 938знахідок у 63 аудитах у 50 сайтах, з яких я збудував каталог із 256 типів проблемАрхів аудитів 2020-2026, каталог від 11.10.2026
• 38%аудитів із внутрішніми посиланнями на адреси з редиректом, найчастіше повідомлюваною проблемою в архіві (24 із 63)Каталог від 11.10.2026
• 15 із 63аудитів із відсутністю сторінок під важливі ключові слова, чого краулер сам не повідомитьКаталог від 11.10.2026
• 14типів рекомендацій, які каталог сьогодні позначає як застарілі, а 30 наступних як змінену практикуКаталог від 11.10.2026

Що змінилося в SEO-аудитах з 2020 року?

В аудитах за 2023-2026 роки структуровані дані й пагінація з'являються частіше, ніж у 2020-2022 роках, а редиректи, канонічні адреси та індексація рідше. Проблеми зі структурованими даними повідомлено в 23 із 33 новіших аудитів проти 16 із 30 старіших. Редиректи й коди відповіді: 23 із 33 проти 27 із 30. Блокування роботів AI з'являються лише в аудитах 2026 року. Рік аудиту - це дата файлу в архіві, тож не завжди рік виконання роботи.

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

Які SEO-рекомендації сьогодні застарілі?

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

Джерела до таблиці: Google про пагінацію, Google про п'ять помилок із rel=canonical, Google про результати FAQ і HowTo, Matt Cutts про nofollow і розподіл сили посилань, John Mueller про редиректи на головну, за Search Engine Roundtable, Google про robots.txt, Google про непідтримувані правила в robots.txt, Google про мапи сайту, Google про поля lastmod, changefreq і priority, web.dev про INP, Google про поле пошуку в результатах.

Тому кожна рекомендація в моєму каталозі має поле актуальності з обґрунтуванням. Каталог позначає сьогодні 14 типів рекомендацій як застарілі й 30 як змінену практику. Рекомендація, яка була правильною кілька років тому, не потрапить в аудит лише тому, що колись працювала.

Як перевірити доступ роботів AI в аудиті?

Доступ роботів AI перевіряю на тому самому кроці, що й доступ Googlebot, бо заблокувати їх може те саме налаштування файрвола чи CDN. CDN - це мережа проміжних серверів, наприклад Cloudflare. У вересні 2026 я перевірив 12 доменів моїх клієнтів, які працюють за Cloudflare. Сам файл robots.txt показав:

• 3 домени блокували той самий набір із семи роботів, що збирають дані для тренування моделей, з ідентичним списком назв. Ідентичний список наводить на думку про спільне джерело, наприклад готове налаштування в панелі Cloudflare. Ззовні цього налаштування не видно, тож його треба підтвердити в самій панелі.
• 1 домен блокував роботів, які завантажують сторінки для відповідей ChatGPT, Perplexity і Claude. Робив це не прямо, а загальним правилом для всіх роботів, не названих на ім'я. Цей самий домен показував GPTBot сторінку захисту без тегу noindex, який виключає сторінку з індексу. Якби таку сторінку отримав робот-індексатор, до індексу могла б потрапити сторінка блокування замість контенту.
• 8 доменів не мали блокувань у robots.txt.

Про роботів, які завантажують сторінки для відповідей, і про роботів, які збирають дані для тренування, ви вирішуєте окремо. У тексті про AI SEO і GEO описав, як їх розрізнити. Від 31 серпня 2026 є також окреме налаштування в Search Console, яке виключає сторінку з AI Overview, режиму ШІ та генеративних функцій у Discover. За словами Google, воно не впливає на решту результатів пошуку (Довідка Search Console). Таке налаштування перевіряю в аудиті так само, як robots.txt, бо хтось міг увімкнути його без відома відповідальної за SEO особи. Чи з'являється марка у відповідях після відкриття доступу, - це вже окреме вимірювання, яке я описав у тексті про видимість марки в AI.

Тест з однієї IP-адреси показує лише частину ситуації, а сам може дати хибну тривогу. Під час того самого огляду серія запитів повідомила на двох доменах про блокування після перевищення ліміту. Це блокування спричинили мої власні попередні запити. Перевірка кілька хвилин потому, з одним ідентифікатором робота й поодинокими запитами, дала п'ять і сім правильних відповідей поспіль. Якби не ця перевірка, двоє клієнтів отримали б інформацію про блокування, якого не було. Лише логи сервера показують, чи ChatGPT справді завантажує сторінку. У тексті про файл llms.txt показую, що видно в логах мого сайту.

Код 200 не означає, що робот отримав контент. В одного клієнта із застосунком на JavaScript Googlebot і Bingbot отримували готовий HTML із сервісу пререндерингу, а роботи AI-асистентів порожню сторінку. Сервіс розпізнавав роботів за назвою й не мав роботів AI у списку. Мій тест дав результат «усе гаразд», бо вимірював код відповіді, а не контент. Відтоді порівнюю контент, який отримує робот, з контентом після виконання JavaScript у браузері.

Чи досить безплатного SEO-аудиту?

Безплатний інструмент покаже список помилок, але з самого звіту не випливає, які з них коштують вам трафіку. За польським запитом «audyt seo» (SEO-аудит) 7 із 9 органічних результатів на першій сторінці Google - це інструменти або пропозиції безплатного аудиту (результати від 17 жовтня 2026). Такий звіт рахує помилки за правилами інструмента, а не за тим, скільки трафіку й доходу від них залежить. Треба також перевірити, чи результат не походить від блокування робота, як у випадку магазину з оцінкою здоров'я 0.

Багато зробите безплатно, якщо знаєте, куди дивитися. Search Console показує дані Google про індексацію, Core Web Vitals і сторінку після виконання JavaScript. Безплатна версія Screaming Frog проходить до 500 адрес за один краулінг (Screaming Frog), чого досить для малого корпоративного сайту. Аудит із консультантом має сенс тоді, коли помилка дорого коштує (міграція, падіння трафіку, великий магазин) або коли ви не маєте часу, щоб зіставити й оцінити дані.

Чи зробить ChatGPT SEO-аудит?

ChatGPT чи інша модель AI не зробить повного аудиту самостійно, бо не бачить сайту так, як робот пошукової системи. Зазвичай бачить його через інструмент, який його завантажує й перетворює на текст. Модель прочитає дані, які ви їй дасте, і запропонує, що перевірити. Інструмент завантаження може, однак, загубити частину сторінки: у вересні 2026 я перевірив, що інструмент завантаження сторінок у Claude Code вирізає структуровані дані під час перетворення сторінки на текст. Модель відповіла, що інформації немає, хоча вона була в розмітці на тій самій сторінці. Аудит, зроблений так, повідомив би про відсутність структурованих даних, яких не бракує. У моєму процесі AI - це інструмент, передусім для агрегації даних із краулінгу, Search Console та інших джерел. Обсяг, оцінку й пріоритети визначаю сам.

Скільки коштує SEO-аудит?

Вартість аудиту розраховую так само, як вартість консультації: 70 EUR нетто за годину роботи, з верхньою межею годин, визначеною до старту. Кількість годин залежить від того, що треба перевірити:

• діагностичний аудит, тобто одна-дві конкретні проблеми (падіння, міграція, індексація), - зазвичай 10-16 годин, тобто 700-1 120 EUR нетто;
• повний аудит із черговістю дій - зазвичай 32-50 годин, тобто 2 240-3 500 EUR нетто;
• малий сайт до 500 адрес ближчий до нижньої межі, а магазин із тисячами адрес і фільтрами - до верхньої;
• мовні версії додають зазвичай 3-5 годин, а триваюча криза, яку треба продіагностувати, - 4-8 годин.

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

Без доступу до Search Console, панелі CDN і хостингу технічну частину повністю не перевірю і кажу про це перед оцінкою вартості. Вказую тоді, чого без цих доступів не зможу підтвердити, і відповідно звужую обсяг. У тексті про SEO-консультацію описав, коли замість аудиту досить розмови про одне рішення.

Найчастіші запитання про SEO-аудит

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

Почніть з одного запитання: сайт втрачає трафік чи взагалі його не залучає. Від відповіді залежить, чи спершу захищаєте сторінки, що мають позиції, чи шукаєте ключові слова, під які бракує сторінок. Потім зробіть три безплатні перевірки з відповіді про самостійний аудит: robots.txt, звіт про індексацію в Search Console і краулінг безплатною версією Screaming Frog. Якщо результат вас здивує або ви не знаєте, що виправити першим, це хороша тема для консультації.