У кошику порожньо!
Більшість сайтів, які роками топчуться на одних позиціях, мають не слабкий контент і не брак посилань — у них технічні блокери, які заважають пошуковому роботу нормально працювати з ресурсом. Технічний SEO-аудит — це діагностика, яка виявляє ці блокери до того, як ви вкладаєте бюджет у зовнішнє просування.
У цьому гайді — структурована методологія: що перевіряти, якими інструментами, і як розставляти пріоритети, щоб виправлення давали результат, а не просто закривали задачі. Підходить і для самостійної роботи, і для постановки ТЗ розробнику. Якщо потрібна допомога — команда SEO-Factory займається SEO-просуванням сайтів під ключ.
Зміст
- Що входить до технічного аудиту
- Підготовка до аудиту: необхідні інструменти
- Краулінг і бюджет сканування
- Краулінг і індексація: robots.txt, sitemap, GSC
- Дублювання контенту та канонікалізація
- Core Web Vitals і швидкість завантаження
- Мобільна оптимізація
- HTTPS, редиректи і структура URL
- Структурні дані і Schema.org
- Звіт за підсумками аудиту
- Як пріоритизувати виправлення
Що входить до технічного аудиту
Технічний SEO охоплює все, що впливає на здатність пошукового робота знаходити, обходити та індексувати сторінки. На відміну від контентного чи посилального аналізу, тут немає суб'єктивності: або помилка є, або її немає.
Основні блоки перевірки:
- Краулінг — чи може Googlebot обійти всі потрібні сторінки без обмежень
- Індексація — які сторінки потрапляють у пошуковий індекс, а які заблоковані
- Швидкість і Core Web Vitals — відповідність вимогам Page Experience
- Мобільна версія — коректність Mobile-First індексації
- HTTPS і безпека — наявність SSL і правильна реалізація редиректів
- Структура URL — читабельність, канонізація, ланцюжки редиректів
- Дублювання контенту — технічні дублікати, canonical теги
- Schema.org і розмітка — структуровані дані, hreflang, Open Graph
Підготовка до аудиту: необхідні інструменти
Перед запуском аудиту потрібен правильний інструментальний стек. Різні завдання вимагають різних інструментів — і жоден окремий не замінює решту.
Google Search Console
Безкоштовний і незамінний. Перед аудитом переконайтеся, що сайт підтверджений: додайте HTML-тег у <head>, завантажте файл верифікації або через DNS-запис. Якщо є обидві версії — www та non-www — підтвердіть обидві і встановіть основну властивість. Підключіть GSC до Google Analytics 4 через розділ «Зв'язки» в GA4: це дозволяє аналізувати органічні ключові слова безпосередньо в GA4 і відстежувати конверсії в розрізі пошукових запитів.
Google Analytics 4
Для аудиту важливі звіти: «Залучення» → «Сторінки та екрани» (які сторінки отримують трафік і конвертують), «Acquisition» → «Organic Search» (трафік з пошуку), а також аналіз поведінки на посадкових сторінках. Після з'єднання з GSC у GA4 з'явиться звіт «Search Console» з органічними запитами та позиціями — це дає повну картину до і після виправлень.
Screaming Frog SEO Spider
Безкоштовна версія обходить до 500 URL — достатньо для малого сайту. Для більшого — ліцензія коштує близько £149/рік. Ключові налаштування перед краулінгом:
- JavaScript рендеринг: Configuration → Spider → Rendering → вибрати «JavaScript». Це дозволяє Screaming Frog рендерити сторінки як браузер і знаходити контент, який завантажується через JS. Важливо для SPA та сайтів на React/Vue.
- Custom Extraction: Configuration → Custom → Extraction — можна витягувати довільні дані через CSS-селектор або XPath. Наприклад, перевірити наявність canonical на кожній сторінці або виловити конкретний мета-тег.
- Crawl limits: для великих сайтів встановіть ліміт глибини (Configuration → Spider → Limits → Max Crawl Depth) щоб не витрачати час на надглибокі сторінки.
- Crawl a sitemap: Mode → List → завантажте sitemap.xml — так перевіряєте тільки URL з sitemap.
Ahrefs Site Audit або Semrush Site Audit
Хмарні краулери — запускаються без встановлення ПЗ і дають готові звіти з категоризацією помилок. Ahrefs Site Audit добре виявляє проблеми з внутрішніми посиланнями і orphan-сторінками. Semrush Site Audit має детальніший звіт по Core Web Vitals і HTTPS. Обидва підходять для регулярного моніторингу — налаштовуєте автоматичний краулінг раз на тиждень і отримуєте сповіщення про нові помилки.
Доступ до сервера
Для повноцінного аудиту великого сайту корисні лог-файли сервера — вони показують, які сторінки реально обходив Googlebot і як часто. Доступ через cPanel (розділ «Логи» або Raw Access Logs) або SSH (cat /var/log/nginx/access.log | grep Googlebot). Інструменти для аналізу логів: Screaming Frog Log File Analyser або Botify. Якщо Googlebot не відвідує важливі сторінки — це сигнал проблем із краулінговим бюджетом.
Мінімальний стек для старту: Google Search Console + Screaming Frog (безкоштовна версія) + PageSpeed Insights. Цього достатньо для аудиту сайту до 500 сторінок і виявлення 80% критичних проблем.
Краулінг і бюджет сканування
Перший крок аудиту — зрозуміти, як пошуковий робот бачить ваш сайт. Запускаєте Screaming Frog і робите повний краулінг. На виході — список усіх URL зі статусами, заголовками, кодами відповіді, глибиною вкладеності.
Що шукати:
- Сторінки з кодом 4xx — биті посилання, сторінки що не існують. У GSC вони збирають crawl errors і вбивають краулінговий бюджет.
- Ланцюжки редиректів — 301 → 301 → 301. Google рекомендує не більше одного редиректу в ланцюжку. Кожен зайвий — втрата PageRank і уповільнення краулінгу.
- Велика глибина вкладеності — сторінки, до яких потрібно зробити 5+ кліків від головної. Критичні сторінки мають бути доступні за 3 кліки.
- Orphan-сторінки — сторінки без внутрішніх посилань. Робот може їх просто не знайти.
Порада: У GSC є звіт «Покриття» (Coverage). Порівняйте кількість сторінок у Screaming Frog і кількість у GSC-індексі — розрив більше 15–20% потребує розслідування.
Краулінговий бюджет важливий для великих сайтів (від 10 000+ сторінок). Якщо сайт генерує тисячі параметричних URL (наприклад, фільтри в інтернет-магазині), значна частина бюджету витрачається на непотрібні сторінки замість важливих. Саме такі проблеми виявляє технічний аудит у складі SEO-просування.
Краулінг і індексація: robots.txt, sitemap, GSC
Robots.txt — перше, що читає пошуковий робот при відвідуванні сайту. Помилка в цьому файлі може заблокувати від індексації цілі розділи або весь ресурс. Таке буває після переїзду між CMS або після «тимчасового» закриття в тестовий режим, який забули скасувати.
Як читати robots.txt і типові помилки
Файл знаходиться за адресою https://example.com/robots.txt. Директива Disallow: / забороняє обхід усього сайту — одна з найбільш руйнівних помилок. Інші типові проблеми:
- Заблокований CSS/JS:
Disallow: /wp-content/themes/абоDisallow: *.js— Google не може рендерити сторінки, бачить їх «голими». Перевірте у GSC → Інструмент перевірки URL → «Дозволяє Google переглядати цю сторінку?» - Заблокований WordPress admin: правильно блокувати
/wp-admin/, але не/wp-admin/admin-ajax.php— він потрібен для AJAX-запитів. - Disallow: / для всього Googlebot — найчастіше залишок від розробки. Перевіряйте після кожного переїзду.
Що має бути у правильному robots.txt: Sitemap: URL, блокування пошуку (/?s=), кошика (/cart/), кабінету (/my-account/) і технічних сторінок WordPress (/wp-login.php).
XML sitemap: валідний формат і оновлення
Sitemap.xml має містити тільки канонічні URL зі статусом 200 і без noindex. Для великих сайтів використовуйте sitemap index — файл, який посилається на окремі sitemap-файли по розділах (товари, статті, категорії). Кожен підфайл — не більше 50 000 URL або 50 МБ.
Поле lastmod — тільки для сторінок, які реально змінювалися. Якщо генерувати однакову дату для всіх сторінок — Google ігнорує цей сигнал. Після кожної публікації новий матеріал має з'являтися в sitemap автоматично (якщо CMS налаштований правильно) або додаватися вручну.
Google Index Coverage Report
У GSC → «Покриття» чотири статуси:
- Valid — проіндексовано, усе добре.
- Valid with warning — проіндексовано, але є питання (наприклад, сторінка в sitemap, але закрита через noindex).
- Excluded — не проіндексовано, але Google вважає це нормальним (noindex, canonical на іншу сторінку, дубль).
- Error — помилка: 404, server error (5xx), заблоковано robots.txt, редирект.
Помилки і попередження потребують негайної уваги. Для кожної сторінки зі статусом «Error» використовуйте «Інструмент перевірки URL» (URL Inspection) — він показує, що саме бачить Google при краулінгу.
Запит на індексацію через GSC
Після виправлення помилки або публікації нової сторінки: GSC → Інструмент перевірки URL → введіть URL → «Запросити індексацію». Google перевіряє сторінку протягом декількох годин-днів. Масово додати нові URL в індекс можна через оновлений sitemap — GSC перевіряє його регулярно автоматично.
Soft 404 vs 404: різниця та вирішення
Жорсткий 404 — сервер повертає код 404, сторінка не існує. Правильно: якщо сторінка більше не потрібна — нехай повертає 404 або 410 (Gone). Якщо переїхала — 301 на нову адресу.
Soft 404 — сервер повертає код 200, але контент каже «товар не знайдено» або «нічого не знайдено». Google бачить порожню сторінку з кодом 200 і витрачає на неї краулінговий бюджет. Рішення: налаштуйте сторінки «товар не знайдено» і «немає результатів пошуку» повертати реальний 404.
На одному e-commerce проєкті з 12 000 товарів виявили 3 400 soft-404 — сторінки розпроданих товарів з кодом 200 і написом «немає в наявності». Після переведення їх на 410 краулінговий бюджет звільнився для важливих категорій, і за 6 тижнів кількість проіндексованих сторінок зросла на 18%.
Дублювання контенту та канонікалізація
Google не штрафує за дублікати напряму, але витрачає на них краулінговий бюджет і розмиває PageRank. У результаті жодна версія не ранжується так добре, як могла б.
Типи дублів і причини їх виникнення
| Тип дублювання | Причина | Рішення |
|---|---|---|
| HTTP vs HTTPS версія | Немає 301-редиректу | Додати редирект 301 |
| www vs non-www | Не обрано основний домен | 301 + налаштування GSC |
| URL з параметрами фільтрів | ?sort=price, ?color=red тощо | Canonical або noindex |
| Сторінки пагінації | /page/2, /page/3... | Self-canonical на кожній |
| Trailing slash vs без | /blog і /blog/ як різні URL | Обрати один варіант + 301 |
| Printer-friendly версії | /print/ або ?format=print | Canonical на основну сторінку |
| Сесійні параметри | ?sessionid=abc123 | Canonical або параметри в GSC |
Canonical тег: правильне впровадження
Тег canonical у <head>: <link rel="canonical" href="https://example.com/canonical-url/">. Якщо сторінка унікальна — self-canonical (вказує на себе). Якщо дублікат — canonical на оригінал.
Типові помилки:
- Canonical вказує на сторінку з noindex — суперечливий сигнал.
- Canonical chain: сторінка A canonical → B, B canonical → C. Google може не прийняти C як канонічну. Завжди вказуйте на фінальну URL.
- Canonical конфліктує з hreflang: якщо для мовних версій canonical вказує на головну мову — Google проігнорує hreflang.
- Canonical на редирект — має вказувати на кінцеву сторінку, не на ту що редиректить.
hreflang для мультимовних сайтів
Якщо сайт має мовні версії, hreflang повідомляє Google: яку версію показувати якій аудиторії. Базовий формат:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/">
<link rel="alternate" hreflang="ru" href="https://example.com/ru/page/">
<link rel="alternate" hreflang="x-default" href="https://example.com/page/">
Теги мають бути взаємними: якщо UK-версія посилається на RU-версію, RU-версія мусить посилатися назад на UK. Перевіряйте через Screaming Frog (Hreflang → Hreflang All) або в GSC → «Міжнародне таргетування».
Порада: Використовуйте інструмент hreflang Tags Testing Tool від TechnicalSEO.com — він перевіряє взаємність тегів і виявляє конфліктні canonical.
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 для тапу
- Елементи не накладаються, горизонтальний скрол відсутній
Інструмент: GSC → «Зручність для мобільних» показує конкретні сторінки із проблемами. Додатково — Mobile-Friendly Test від Google для перевірки окремих URL.
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 — виправити
Структурні дані і Schema.org
Структурована розмітка не є прямим ранжувальним сигналом, але дає rich snippets у пошуковій видачі — зірки, ціни, FAQ, хлібні крихти. Це збільшує CTR на 20–30% навіть без зміни позиції.
Які типи розмітки дають rich snippets
| Тип Schema | Rich snippet | Де використовувати |
|---|---|---|
| FAQ | Розгортувані питання під сніпетом | Сторінки послуг, лендінги |
| HowTo | Покрокові інструкції з іконками | Гайди, статті-інструкції |
| Product + Review | Зірки, ціна, наявність | Картки товарів e-commerce |
| BreadcrumbList | Хлібні крихти замість URL | Усі сторінки сайту |
| Organization | Знання-панель компанії | Головна сторінка |
| LocalBusiness | Адреса, телефон, години роботи | Контактна сторінка, лендінг |
JSON-LD проти Microdata
Google рекомендує JSON-LD — розмітку розміщують у <script type="application/ld+json"> блоці в <head> або перед </body>. Перевага: не потребує зміни HTML-структури, легко підтримувати, можна додавати через GTM. Microdata вбудовується у HTML-атрибути — більш трудомістка і схильна до помилок при оновленні шаблону.
Практичний приклад BreadcrumbList JSON-LD
BreadcrumbList — найпростіша і найефективніша розмітка для будь-якого сайту. Замінює URL у видачі на читабельні хлібні крихти і покращує CTR. Приклад для сторінки послуги:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Головна", "item": "https://example.com/"},
{"@type": "ListItem", "position": 2, "name": "Послуги", "item": "https://example.com/poslugy/"},
{"@type": "ListItem", "position": 3, "name": "SEO-просування", "item": "https://example.com/poslugy/seo/"}
]
}
</script>
Для статей блогу додайте також тип Article з полями headline, datePublished, dateModified і author — це сигнал E-E-A-T і підстава для відображення дати публікації в сніпеті.
Перевірка і помилки
Перевіряйте через Rich Results Test від Google — показує, які rich snippets доступні для сторінки і де помилки. У GSC → «Покращення» відображаються помилки структурованих даних по всьому сайту: неправильне поле, відсутній обов'язковий елемент, невідповідність типу.
Важливо: розмітка Review (зірки) на власних сторінках компанії без агрегатора — Google все частіше її ігнорує або позначає як маніпулятивну. Для зірок у сніпеті потрібен або агрегатор відгуків (Trustpilot, Google Reviews), або Product/Recipe з реальними відгуками третіх осіб.
Звіт за підсумками аудиту
Проведений аудит без якісного звіту — витрачений час. Звіт — це не список помилок зі скриншотами, а документ, за яким команда розробників може діяти.
Як пріоритизувати знахідки
Усі знахідки діляться на три рівні:
- Критичні (Critical): блокують індексацію або краулінг. Виправляти негайно. Приклади: Disallow: / в robots.txt, масовий noindex на важливих сторінках, зламаний SSL, ланцюжки редиректів на головних сторінках.
- Важливі (Important): знижують ефективність але не блокують. Виправляти протягом 2–4 тижнів. Приклади: погані CWV-показники, відсутні canonical на дублях, помилки hreflang, sitemap з 404-сторінками.
- Низький пріоритет (Low): незначний вплив, виправляти в рамках наступного спринту. Приклади: відсутні alt-теги на декоративних зображеннях, неоптимальні meta description, зайві HTML-атрибути.
Формат технічного звіту для клієнта
Оптимальна структура звіту: виконавче резюме (3–5 речень про стан сайту і ключові ризики) → зведена таблиця по блоках (краулінг, індексація, CWV, mobile, дублі, Schema) → детальний розділ по кожному блоку з конкретними URL і скриншотами → трекер виправлень з відповідальними і дедлайнами.
Трекер виправлень
Google Sheets — найпростіший варіант. Стовпці: опис проблеми | URL / шаблон | пріоритет | відповідальний | дедлайн | статус | дата перевірки. Після виправлення — помічаєте «Виправлено», після реіндексації — «Підтверджено в GSC». Це дозволяє відстежувати прогрес і не повертатися до одних і тих же питань двічі.
Повторний аудит через 30–60 днів
Перший аудит фіксує стан «до». Повторний через 30–60 днів — оцінює ефект від виправлень: скільки помилок GSC зникло, як змінились CWV-показники, чи виросла кількість проіндексованих сторінок. Це також виявляє нові проблеми, які могли з'явитися після оновлень сайту.
Рекомендована частота аудитів: повний технічний аудит — раз на 6 місяців або після великих змін на сайті (переїзд домену, зміна CMS, редизайн). Міні-перевірка — щомісяця: GSC Coverage на помилки, PageSpeed Insights для 3–5 ключових сторінок, перевірка sitemap. Два-три дні уваги раз на місяць запобігають накопиченню критичних проблем, які потім потребують тижнів виправлення.
Що має містити фінальний звіт
Якісний звіт про технічний аудит — це документ, який може читати і розробник, і маркетолог, і власник бізнесу. Оптимальна структура:
- Виконавче резюме — 3–5 речень: загальний стан сайту, найкритичніші знахідки, очікуваний ефект від виправлень. Без технічного жаргону — для прийняття рішень.
- Зведена таблиця блоків — краулінг, індексація, CWV, мобільна, дублі, Schema — статус кожного (добре / потребує уваги / критично) і кількість знахідок.
- Детальні секції по кожному блоку — конкретні URL, скриншоти, опис проблеми, рекомендоване рішення.
- План дій (Action Plan) — завдання згруповані за пріоритетом: що виправити цього тижня, що протягом місяця, що запланувати на квартал.
- Трекер виправлень — таблиця (Google Sheets) з колонками: проблема, URL/шаблон, пріоритет, відповідальний, дедлайн, статус.
KPI аудиту
Результат аудиту вимірюється конкретними метриками до/після:
- % проіндексованих сторінок від загальної кількості (ціль: >90% для важливих розділів)
- Кількість помилок у GSC Coverage (ціль: 0 або мінімум)
- PageSpeed Score (ціль: >70 mobile, >85 desktop)
- LCP, INP, CLS у польових даних GSC (ціль: «Добре» для 75%+ сторінок)
- Кількість сторінок у sitemap vs. кількість проіндексованих (розрив <10%)
Як пріоритизувати виправлення після аудиту
Типовий аудит середнього сайту дає 50–200 проблем. Правильний підхід — матриця «вплив на SEO × складність виправлення».
| Квадрант | Вплив | Складність | Дія | Приклади |
|---|---|---|---|---|
| Зробити першими | Високий | Легко | Цього тижня | Robots.txt, canonical, 301 редиректи |
| Запланувати | Високий | Складно | Наступний спринт | CWV оптимізація, рефакторинг URL |
| Після головного | Низький | Легко | В міру можливості | Meta description, alt-теги |
| Відкласти | Низький | Складно | Переоцінити пізніше | Редизайн заради мінімального ефекту |
На практиці 20% технічних помилок дають 80% негативного впливу на ранжування. Знайдіть ці 20% і виправте їх — результат відчується за 2–4 тижні після переіндексації.
Часті запитання
Що входить до технічного SEO-аудиту сайту?
Технічний аудит охоплює 6 блоків: індексація (robots.txt, sitemap, GSC Coverage), швидкість завантаження і Core Web Vitals, структура URL і редиректи, метатеги і дублі контенту, мобільна оптимізація, мікророзмітка Schema.org. Додатково перевіряють HTTPS, внутрішнє посилання і краулінговий бюджет.
Як часто потрібно проводити технічний SEO-аудит?
Повний аудит — раз на 6–12 місяців. Після великих змін на сайті (переїзд, редизайн, нові розділи) — обов'язково позапланово. Базову автоматичну перевірку (Screaming Frog або Ahrefs Site Audit) варто запускати щомісяця для раннього виявлення проблем.
Якими інструментами проводять технічний SEO-аудит?
Основний стек: Screaming Frog (краулінг), Google Search Console (індексація та помилки), PageSpeed Insights / Lighthouse (швидкість), Ahrefs або Semrush Site Audit (комплексні перевірки). Для перевірки структурованих даних — Google Rich Results Test. Усі базові інструменти мають безкоштовні версії або пробний доступ.
Скільки часу займає технічний аудит і коли чекати результатів?
Сам аудит займає 1–3 дні залежно від розміру сайту. Після виправлень Google потребує 2–8 тижнів для переобходу і переіндексації сторінок. Критичні помилки (5xx, заблоковані robots.txt важливі сторінки) можна виправити і прискорити переіндексацію через запит у GSC «Перевірити URL».
Потрібен технічний SEO-аудит?
Команда SEO-Factory проведе повний технічний аудит з детальним звітом і дорожньою картою виправлень. Визначимо пріоритети, дамо чіткий план дій і перевіримо результат через 30–60 днів.
