Щомісячний SEO-аудит: чек-лист із 12 перевірок за 90 хвилин

Чек-лист щомісячного SEO-аудиту — це короткий набір перевірок, які ви повторюєте раз на місяць, щоб помітити проблеми раніше, ніж вони почнуть коштувати вам трафіку. Він охоплює індексацію, ефективність у пошуку, технічні регресії, Core Web Vitals, доступ AI-краулерів і безпеку. Це не повний SEO-аудит сайту, а перевірка «стану здоров'я» на 60–90 хвилин, яка показує, що змінилося з минулого місяця.

Головне

• Щомісяця проходьте ті самі 12 перевірок у тому самому порядку й записуйте цифри. Динаміка важливіша за будь-яке окреме значення.
• Починайте з індексації та звіту «Ефективність» у Search Console. Падіння там — найраніший сигнал, який ви отримаєте.
• Раз на місяць скануйте сайт, щоб виявити нові 404, ланцюжки редиректів, випадкові теги noindex і змінені canonical. Зазвичай вони з'являються після деплоїв і оновлень плагінів.
• Контент-стратегію, інформаційну архітектуру та аналіз беклінків залиште для повного аудиту раз на квартал або рік.
• Кожна перевірка закінчується рішенням: усе гаразд, стежимо або виправляємо зараз.

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

Щомісячний SEO-аудит — це легкий огляд, який порівнює поточний місяць із попереднім і фіксує регресії. Повний аудит перевіряє весь сайт на відповідність найкращим практикам і дає довгий список виправлень із пріоритетами. Щомісячна перевірка відповідає на питання «чи щось зламалося або просіло?», а повний аудит — «що можна покращити?».

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

SEO чек-лист на місяць: 12 перевірок коротко

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

Крок 1. Чи Google досі індексує ваші важливі сторінки?

Відкрийте звіт «Індексування сторінок» у Search Console і порівняйте кількість проіндексованих сторінок із записом за минулий місяць у журналі. Потім відкрийте кожну причину «не проіндексовано», яка зросла. Повільна, рівномірна зміна — це норма. Різкий стрибок у будь-який бік означає, що на сайті щось змінилося.

Не прагніть 100%. Google прямо пише, що не варто очікувати індексації всіх URL сайту — лише канонічних сторінок, і що всі ваші важливі сторінки мають бути проіндексовані. Тож щомісячне питання не «чому виключено 300 URL?», а «чи є серед них сторінка, яка мені важлива?». Вибірково перевірте 10 сторінок, що приносять найбільше доходу чи заявок, через інструмент «Перевірка URL-адреси».

Ще дві швидкі перевірки:

• Sitemap: переконайтеся, що дата останнього читання свіжа і немає помилок отримання. У нашому посібнику з XML sitemap пояснено, що означає кожен статус.
• robots.txt: відкрийте файл і порівняйте його з копією за минулий місяць. Disallow: / зі staging-середовища, що потрапив на продакшн, — одна з найдорожчих однорядкових помилок у SEO.

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

Крок 2. Чи змінився пошуковий трафік і чому?

У звіті «Ефективність» порівняйте останні 28 днів із попередніми 28 днями, а потім — із тим самим періодом минулого року. Порівняння місяць до місяця показує різкі зламаності, рік до року — відсіює сезонність. Запишіть у журнал загальну кількість кліків, показів, CTR і середню позицію.

Офіційний посібник Google з діагностики падіння пошукового трафіку радить дивитися на довгі періоди, щоб побачити річні закономірності. Причини там згруповано так: оновлення алгоритмів, технічні проблеми, проблеми безпеки, порушення правил щодо спаму, сезонність і переїзд сайту. Також Google наголошує, що невеликий зсув позиції (скажімо, з 2 на 4) означає зовсім інше, ніж великий (з 4 на 29).

Далі копніть глибше:

1. Відсортуйте Сторінки за різницею в кліках і перегляньте 10 найбільших втрат.
2. Зробіть те саме для Запитів.
3. Для кожної великої втрати запитайте себе: чи ми змінювали цю сторінку? Чи змінилася сторінка видачі (новий AI Overview, більше реклами, конкурент)? Чи це сезонне?

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

Крок 3. Що зламалося з минулого місяця? Проскануйте сайт

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

Зосередьтеся на нових проблемах:

• Помилки 404 і 5xx, на які посилаються ваші ж сторінки. Виправте посилання або налаштуйте редирект на найближчу релевантну сторінку.
• Ланцюжки й цикли редиректів. Ведіть внутрішні посилання одразу на кінцевий URL.
• Індексовані сторінки, що отримали noindex. Часто це налаштування шаблону чи плагіна.
• Теги canonical, у яких змінилася цільова сторінка. Шаблон товару, який раптом вказує canonical усіх варіантів на головну, тихо спорожнить індекс. Правильні схеми — у посібнику з тегу canonical.
• Нові сторінки без title або з дубльованими title і meta description.
• Сторінки-сироти: нові URL у sitemap, на які ніщо не посилається.

Сканування з вашого комп'ютера не завжди рендерить JavaScript так, як браузер, тож перевірте один-два ключові шаблони ще й через відрендерений HTML в інструменті «Перевірка URL-адреси». Якщо не хочете сканувати самостійно, безкоштовний аудит SEORecheck просканує ваші сторінки й покаже реальні биті посилання, проблеми з редиректами, canonical і noindex із прикладами URL.

Крок 4. Чи стабільні Core Web Vitals?

Відкрийте звіт Core Web Vitals і запишіть, скільки URL мають статус «Добре», «Потрібно покращити» і «Погано» — окремо для мобільних і десктопу. Порогові значення: LCP ≤ 2,5 с, INP ≤ 200 мс і CLS ≤ 0,1. Позначте кожну групу URL, яка опустилася на рівень нижче.

Пам'ятайте, як працюють ці дані. Звіт побудовано на польових даних Chrome UX Report, і схожі URL у ньому згруповано. Оскільки це дані реальних користувачів, повільна сторінка, випущена цього тижня, може з'явитися у звіті не одразу. Підтвердження виправлення теж триває довше, ніж для індексації: Google описує 28-денний період моніторингу. Це ще одна причина, чому щомісячний ритм добре підходить для цього звіту: перевірили, виклали виправлення, побачили результат наступного місяця.

Якщо група погіршилася, подивіться, що нового з'явилося в цих шаблонах: нове головне зображення, віджет чату, банер згоди на cookie, скрипт A/B-тестування. У посібнику з Core Web Vitals описано виправлення для кожної метрики.

Крок 5. Чи AI-пошук досі має доступ до вашого сайту?

Щомісяця перевіряйте, що AI-пошукові краулери не заблоковані і що ваша видимість в AI-функціях не падає. Ці налаштування часто змінюються непомітно: правило захисту від ботів у CDN, новий шаблон robots.txt або плагін можуть заблокувати потрібних вам краулерів.

Три швидкі перевірки:

1. Правила robots.txt для AI-ботів. Пошукові боти й боти для навчання — це різні речі. OpenAI документує, що OAI-SearchBot використовується для показу сайтів у пошукових функціях ChatGPT, а заборона GPTBot означає, що ваш контент не має використовуватися для навчання базових моделей. Можна дозволити перший і заблокувати другий. Просто переконайтеся, що файл відображає рішення, яке ви справді ухвалили. У посібнику з robots.txt наведено основні user agents.
2. Налаштування генеративного AI в Google. У посібнику Google з AI-оптимізації сказано, що, крім технічних вимог Пошуку, сайт має бути включений у генеративні AI-функції Пошуку в Search Console, щоб мати право з'являтися в AI Overviews і AI Mode. Переконайтеся, що налаштування не змінилося.
3. Звіт про ефективність у генеративному AI. Той самий посібник називає цей звіт Search Console місцем, де вимірюють ефективність контенту в генеративних AI-функціях. Записуйте покази місяць до місяця поруч із класичними даними Пошуку.

Пропускайте ритуали, користь яких не задокументовано. Google каже, що ігнорує текстові файли для AI на кшталт llms.txt, тож там нічого «оновлювати». Що ще варто відстежувати, описано в посібнику з вимірювання SEO і GEO.

Крок 6. Чи є ручні заходи або проблеми безпеки?

Відкрийте звіти «Ручні заходи» і «Проблеми безпеки» в Search Console. В обох має бути написано, що проблем не виявлено. Це займає 30 секунд, але якщо щось з'явиться, воно одразу стає пунктом номер один. Зламана сторінка чи санкції за спам можуть забрати більше трафіку, ніж усі інші пункти цього чек-листа разом узяті.

Заодно перевірте звіт «Статистика сканування» (Налаштування → Статистика сканування) на сплески помилок сервера чи часу відповіді. Хостинг, який гальмує вночі, може шкодити скануванню, і ніхто в команді цього не помітить.

Як вести журнал і вирішувати, що виправляти?

Записуйте цифри щомісяця в одне місце — таблицю, документ чи тікет. Чек-лист працює, лише якщо місяці можна порівняти. Мінімальний запис у журналі виглядає так:

Місяць: 2026-10
Проіндексовані сторінки: 1284 (вер.: 1301)  | Нові причини «не проіндексовано»: немає
Кліки 28 дн.: 9420 (-6% м/м, +3% р/р) | Найбільша втрата: /pricing-guide (-210 кліків)
Сканування: 14 нових 404 (сторінки тегів блогу), 2 ланцюжки редиректів
CWV мобільні: Добре 81% (вер.: 88%) – регресія LCP у шаблоні товару
AI: OAI-SearchBot дозволено, GPTBot заблоковано (навмисно); AI-покази стабільні
Ручні заходи / безпека: немає
Завдання: виправити LCP головного зображення товару; редирект для 404 тегів; переглянути /pricing-guide

Кожна знахідка отримує одну з трьох позначок: гаразд, стежимо (перевірити наступного місяця) або виправити зараз. Розставте пункти «виправити зараз» за впливом і зусиллями. У статті як розставити пріоритети SEO-виправлень є проста модель оцінювання. Більшість місяців мають закінчуватися нулем–п'ятьма завданнями. Якщо щоразу виходить 20, сайту потрібен повний аудит, а не довший щомісячний чек-лист.

Що не варто включати в щомісячну перевірку?

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

• Підбір ключових слів і аналіз прогалин у контенті
• Архітектура сайту та стратегія внутрішньої перелінковки
• Аналіз профілю беклінків (якщо не підозрюєте спам чи негативну кампанію)
• Покриття мікророзміткою всіх шаблонів
• Чистка та об'єднання контенту. Процес зі статті як знайти сторінки, що шкодять SEO, найкраще працює на даних усього сайту.
• Міжнародні налаштування, як-от hreflang, якщо ви не запускали нову мовну версію

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

Скільки часу займає щомісячний SEO-аудит?

Для сайту на кілька сотень сторінок закладайте 60–90 хвилин, коли журнал уже налаштовано: близько 15 хвилин на індексацію та sitemap, 20 — на ефективність, 20–30 — на огляд сканування, 10 — на Core Web Vitals, 10 — на доступ для AI і 5 — на ручні заходи та безпеку. Перший місяць займе більше часу, бо ви створюєте базову точку відліку.

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