Технічний SEO-аудит сайту: що перевіряти і як виправляти помилки

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

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

Що входить до технічного аудиту

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

Основні блоки перевірки:

• Краулінг — чи може Googlebot обійти всі потрібні сторінки без обмежень
• Індексація — які сторінки потрапляють у пошуковий індекс, а які заблоковані
• Швидкість і Core Web Vitals — відповідність вимогам Page Experience
• Мобільна версія — коректність Mobile-First індексації
• HTTPS і безпека — наявність SSL і правильна реалізація редиректів
• Структура URL — читабельність, канонізація, ланцюжки редиректів
• Дублювання контенту — технічні дублікати, canonical теги
• Schema.org і розмітка — структуровані дані, hreflang, Open Graph

Інструменти мінімального набору: Google Search Console (безкоштовно) + Screaming Frog SEO Spider (безкоштовна версія до 500 URL). Для великих сайтів — Ahrefs Site Audit або Semrush Site Audit. PageSpeed Insights і Chrome DevTools для роботи зі швидкістю.

Краулінг і бюджет сканування

Перший крок аудиту — зрозуміти, як пошуковий робот бачить ваш сайт. Запускаєте Screaming Frog і робите повний краулінг. На виході — список усіх URL зі статусами, заголовками, кодами відповіді, глибиною вкладеності.

Що шукати:

• Сторінки з кодом 4xx — биті посилання, сторінки що не існують. У GSC вони збирають crawl errors і вбивають краулінговий бюджет.
• Ланцюжки редиректів — 301 → 301 → 301. Google рекомендує не більше одного редиректу в ланцюжку. Кожен зайвий — втрата PageRank і уповільнення краулінгу.
• Велика глибина вкладеності — сторінки, до яких потрібно зробити 5+ кліків від головної. Критичні сторінки мають бути доступні за 3 кліки.
• Orphan-сторінки — сторінки без внутрішніх посилань. Робот може їх просто не знайти.

Краулінговий бюджет важливий для великих сайтів (від 10 000+ сторінок). Якщо сайт генерує тисячі параметричних URL (наприклад, фільтри в інтернет-магазині), значна частина бюджету витрачається на непотрібні сторінки замість важливих.

Індексація: robots.txt і sitemap.xml

Robots.txt — перше, що читає пошуковий робот при відвідуванні сайту. Помилка в цьому файлі може заблокувати від індексації цілі розділи або весь ресурс. Таке буває після переїзду між CMS або після «тимчасового» закриття в тестовий режим, який забули скасувати.

Що перевіряти в robots.txt:

• Немає директиви Disallow: / для Googlebot
• Заблоковано технічні директорії: /wp-admin/, /cart/, /checkout/, /?s=
• Не заблоковано CSS і JS-файли, потрібні для рендерингу
• Вказано URL sitemap: Sitemap: https://example.com/sitemap.xml

Sitemap.xml повинен містити тільки канонічні URL зі статусом 200. Якщо в sitemap потрапляють сторінки з noindex, редиректи чи 404 — це суперечливий сигнал для Google.

• Обсяг одного sitemap-файлу: не більше 50 000 URL або 50 МБ
• Для великих сайтів — sitemap-index із посиланнями на дочірні файли
• Дата lastmod має бути реальною датою оновлення, не генеруватися автоматично для всіх сторінок

Core Web Vitals і швидкість завантаження

З 2021 року Core Web Vitals є офіційним ранжувальним сигналом. У конкурентних нішах, де решта сигналів рівна, погані CWV-показники дають перевагу конкуренту.

Як перевіряти: PageSpeed Insights показує лабораторні та польові дані. Орієнтуйтеся на польові — вони впливають на ранжування. GSC → «Основні показники» — агрегований звіт по всіх сторінках.

Найпоширеніші причини поганого LCP: повільний сервер (TTFB > 800 мс), зображення без fetchpriority="high", рендерблокуючі ресурси у <head>, відсутність CDN.

Найпоширеніші причини CLS: зображення без width/height, рекламні блоки що вставляються після завантаження, шрифти без font-display: swap.

Мобільна оптимізація і Mobile-First індексація

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

Що перевіряти:

• Мобільна версія має той самий контент, що й десктопна
• Viewport meta-тег: <meta name="viewport" content="width=device-width, initial-scale=1">
• Кнопки і посилання — мінімум 48×48 px для тапу
• Елементи не накладаються, горизонтальний скрол відсутній

HTTPS, редиректи і структура URL

HTTPS

SSL на сайті встановлений — не означає, що реалізований правильно. Типові помилки: не всі сторінки редиректять з HTTP на HTTPS, є mixed content, внутрішні посилання містять HTTP, SSL-сертифікат прострочений.

Структура URL і редиректи

URL повинна читатися людиною і містити ключове слово: /poslugy/seo-prosuvanniya/ — добре, /p=1423 — погано.

• URL з параметрами без canonical або noindex — закрити
• Дублювання URL із / і без / в кінці — обрати один варіант + 301
• Ланцюжки 301→301 — замінити на прямий редирект
• Редиректи 302 де мають бути 301 — виправити

Дублювання контенту і канонічні теги

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

Canonical tag у <head> вказує пошуковику канонічну URL. Якщо сторінка унікальна — self-canonical. Якщо дублікат — canonical на оригінал. Перевірте: canonical не вказує на сторінку з noindex, і не суперечить hreflang.

Як пріоритизувати виправлення після аудиту

Типовий аудит середнього сайту дає 50–200 проблем. Правильний підхід — матриця «вплив на SEO × складність виправлення».

На практиці 20% технічних помилок дають 80% негативного впливу на ранжування. Знайдіть ці 20% і виправте їх — результат відчується за 2–4 тижні після переіндексації.

Висновок

Технічний SEO-аудит — це регулярна гігієна, а не разова процедура. Послідовність: краулінг через Screaming Frog → перевірка GSC → чеклист robots.txt і sitemap → Core Web Vitals → розбір дублікатів. Від 3 до 8 годин залежно від розміру сайту — і ви маєте чітку картину технічного стану ресурсу.