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

Технічний SEO-аудит — це системна перевірка того, чи можуть пошукові системи знайти, просканувати, відрендерити та проіндексувати сторінки, які мають ранжуватися, і чи не заважає їм щось в інфраструктурі сайту. Аудит охоплює сканування, індексацію, robots.txt, sitemap, canonical, редиректи, коди відповіді, JavaScript, мобільну версію, Core Web Vitals, мікророзмітку та логи сервера.

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

Якщо ви лише знайомитеся з темою, почніть зі статті що таке SEO-аудит, а ширший список перевірок (зокрема контент і посилання) є в чеклісті SEO-аудиту.

Що входить у технічний SEO-аудит?

Повний аудит відповідає на пʼять запитань — саме в такій послідовності:

1. Чи можуть пошуковики знайти сторінки? (внутрішні посилання, sitemap, robots.txt)
2. Чи можуть їх просканувати? (коди відповіді, редиректи, помилки сервера, «пастки» для краулера)
3. Чи можуть їх відрендерити? (JavaScript, заблоковані ресурси)
4. Чи проіндексують їх? (noindex, canonical, дублі, якість)
5. Чи зручні проіндексовані сторінки для людей? (мобільна версія, Core Web Vitals, HTTPS, мікророзмітка)

Кожен рівень залежить від попереднього. Немає сенсу покращувати LCP шаблону, який Google взагалі не індексує.

Крок 1. Проскануйте сайт, як пошуковий робот

Почніть із повного сканування краулером — Screaming Frog SEO Spider, Sitebulb чи аналогом. Виберіть user agent Googlebot Smartphone, на першому проході дотримуйтеся robots.txt і, якщо інструмент дозволяє, підключіть Search Console та аналітику.

Із результатів сканування виберіть:

• Коди відповіді: усі URL з 4xx і 5xx, на які є внутрішні посилання.
• Глибину вкладеності: важливі сторінки, до яких більше трьох-чотирьох кліків від головної.
• Сторінки-сироти: URL із sitemap чи аналітики, на які не веде жодне внутрішнє посилання.
• Пастки для краулера: фільтри, календарі та параметри сесій, що генерують безкінечні URL на кшталт /vzuttia?color=red&size=42&sort=price&page=37.

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

Крок 2. Перевірте індексацію в Google Search Console

Звіт «Індексування сторінок» у Google Search Console показує, скільки URL проіндексовано і чому решта — ні. Це найкорисніший екран під час технічного аудиту.

Як читати звіт «Індексування сторінок»?

Відкрийте Індексування → Сторінки і зосередьтеся на таблиці причин, чому сторінки не індексуються. Не кожна причина є проблемою: «Альтернативна сторінка з належним канонічним тегом» і «Сторінка з переспрямуванням» зазвичай очікувані. Увагу варто звернути на «Виключено тегом noindex» для сторінок, які мають ранжуватися; «Дублікат, користувач не вибрав канонічну сторінку»; «Дублікат: Google вибрав іншу канонічну сторінку, ніж користувач»; «Мʼяка помилка 404»; «Заблоковано файлом robots.txt» для важливих URL, а також два статуси: «Виявлено, але наразі не проіндексовано» і «Проскановано, але наразі не проіндексовано». Перший на великих сайтах часто вказує на обмежений бюджет сканування чи слабку внутрішню перелінковку. Другий зазвичай означає, що Google завантажив сторінку, але не вважає її достатньо цінною чи унікальною. Відкрийте причину, експортуйте приклади URL і перевірте кілька з них інструментом «Перевірка URL»: там видно вибрану Google канонічну сторінку, дату останнього сканування та відрендерений HTML.

Крок 3. Перевірте robots.txt

robots.txt керує скануванням, а не індексацією. URL, закритий у robots.txt, усе одно може потрапити у видачу (без сніпета), якщо на нього посилаються інші сторінки. А тег noindex на сторінці, яку заборонено сканувати, Google просто не побачить.

Типова безпечна конфігурація:

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /*?sessionid=

Sitemap: https://example.com.ua/sitemap.xml

Найчастіші помилки:

• Disallow: /, що залишився з тестового середовища.
• Заблоковані папки з CSS чи JavaScript, без яких Google не може відрендерити сторінку.
• Спроби видалити сторінки з індексу через robots.txt замість noindex або 404/410.
• Правила для AI-краулерів (GPTBot, ClaudeBot, PerplexityBot, Google-Extended), які випадково зачіпають і Googlebot. Блокування Google-Extended не впливає на Google Пошук — воно лише керує використанням контенту в Gemini. Детальніше — у статті як потрапити в AI Overviews.

Крок 4. Перевірте XML-карти сайту

Sitemap має містити лише ті URL, які ви хочете бачити в індексі: код 200, без noindex, з canonical на себе. Усе інше дає пошуковику суперечливі сигнали.

Перевірте, що:

• sitemap вказано в robots.txt і додано в Search Console;
• у ньому немає URL з редиректом, 404, noindex чи неканонічних адрес;
• <lastmod> відображає реальні зміни контенту, а не дату генерації файлу;
• кожен файл має до 50 000 URL і до 50 МБ у нестиснутому вигляді; великі сайти використовують індексний sitemap;
• на багатомовних сайтах є всі мовні версії (за потреби — з анотаціями hreflang, див. посібник з hreflang).

Крок 5. Проаналізуйте canonical і дублі

Кожна сторінка, яка має індексуватися, повинна мати canonical на себе з абсолютним URL:

<link rel="canonical" href="https://example.com.ua/poslugy/seo-audyt/">

Дублі зазвичай виникають через варіанти протоколу та хоста (http://, www), слеш у кінці, великі літери, UTM-мітки, сортування і фільтри, версії для друку. Canonical, внутрішні посилання, sitemap і редиректи мають вести на одну й ту саму бажану адресу.

Памʼятайте: canonical — це підказка, а не директива. Якщо «Перевірка URL» показує, що Google вибрав іншу канонічну сторінку, шукайте суперечливі сигнали: внутрішні посилання на іншу версію, майже ідентичний контент або canonical, що вказує на сторінку з редиректом чи noindex.

Крок 6. Виправте редиректи, ланцюжки та коди відповіді

Що таке ланцюжок редиректів і чому це важливо?

Ланцюжок редиректів виникає, коли один URL переспрямовує на інший, а той — ще далі. Наприклад: http://example.com.ua/page → https://example.com.ua/page → https://www.example.com.ua/page → https://www.example.com.ua/page/. Кожен перехід додає затримку для користувача та зайвий запит для краулера, а Googlebot проходить обмежену кількість переспрямувань (Google Search Central згадує до 10), після чого зупиняється. Ланцюжки також розмивають сигнали: внутрішнє посилання, запис у sitemap і canonical можуть вказувати на різні кроки ланцюжка. Рішення просте: налаштуйте для кожної старої адреси один 301 (або 308) редирект одразу на кінцевий URL, а потім оновіть внутрішні посилання та sitemap, щоб редирект залишався лише страховкою для зовнішніх посилань і закладок. Цикли (A → B → A) ще гірші, бо сторінка взагалі не відкривається; зазвичай вони зʼявляються, коли правила CMS і сервера перетинаються.

Також перевірте:

• 302 редиректи для постійних переїздів (потрібні 301/308);
• мʼякі 404: сторінки «не знайдено», що віддають код 200;
• помилки 5xx у звіті «Статистика сканування» — через них Google сповільнює сканування;
• внутрішні посилання на 3xx і 4xx — виправляйте саме посилання, а не лише редирект.

Крок 7. Перевірте рендеринг JavaScript

Google рендерить JavaScript, але рендеринг відбувається після сканування і може затримуватися чи завершуватися помилкою. Інші пошуковики та більшість AI-краулерів JavaScript не виконують узагалі.

Порівняйте вихідний HTML (view-source) з відрендереним («Перевірка URL» → «Переглянути проскановану сторінку»). Title, meta robots, canonical, основний контент, внутрішні посилання та мікророзмітка мають бути у відповіді сервера або щонайменше у відрендереній версії. Типові проблеми:

• посилання у вигляді <div onclick> замість <a href>;
• контент, що зʼявляється лише після дії користувача (клік, прокручування, вкладки з підвантаженням);
• noindex у початковому HTML, який JavaScript потім прибирає — Google може так і не дійти до рендерингу;
• заблоковані в robots.txt скрипти чи API.

Для контентних сайтів найнадійнішим варіантом залишається серверний рендеринг (SSR) або статична генерація.

Крок 8. Перевірте мобільну версію

Google використовує mobile-first індексацію для всіх сайтів, тож індексується саме мобільна версія. Переконайтеся, що на мобільних сторінках той самий основний контент, заголовки, внутрішні посилання, мікророзмітка та метатеги, що й на десктопі. Приховане меню — нормально, відсутній контент — ні. Перевірте також розмір елементів для натискання, шрифти, навʼязливі спливні вікна і коректний viewport:

<meta name="viewport" content="width=device-width, initial-scale=1">

Крок 9. Виміряйте Core Web Vitals

Core Web Vitals оцінюють досвід реальних користувачів: LCP (завантаження, добре — ≤ 2,5 с), INP (чуйність, добре — ≤ 200 мс; замінив FID у березні 2024 року) і CLS (візуальна стабільність, добре — ≤ 0,1). Google оцінює їх за 75-м процентилем польових даних Chrome UX Report (CrUX).

У звіті Core Web Vitals у Search Console знайдіть проблемні групи URL (тобто шаблони), а потім діагностуйте окремі сторінки в PageSpeed Insights. Лабораторні оцінки Lighthouse — інструмент налагодження, а не вердикт. Core Web Vitals входять до сигналів page experience і працюють радше як додатковий фактор за рівних умов, ніж як основний фактор ранжування, але повільні шаблони знижують і конверсію. Причини та способи виправлення для кожної метрики — у статті Core Web Vitals: що це.

Крок 10. Перевірте мікророзмітку

Перевірте JSON-LD у Rich Results Test від Google та в Schema Markup Validator. Розмітка має описувати контент, який справді видно на сторінці, — невідповідність може призвести до ручних санкцій. Пріоритет — типи, що досі дають розширені результати: Product, Review snippet, Article, BreadcrumbList, Organization, LocalBusiness, Event, Video. Не додавайте FAQPage чи HowTo заради розширених сніпетів: HowTo Google прибрав ще у 2023 році, а FAQ-сніпети перестав показувати для всіх сайтів у травні 2026-го.

Крок 11. Проаналізуйте лог-файли сервера

Логи показують, що боти пошукових систем справді запитують, а не те, що імітує краулер. Відфільтруйте перевірений Googlebot (через зворотний DNS-запит, бо user agent легко підробити) і шукайте:

• частку запитів бота, що витрачається на URL із параметрами, редиректи та помилки;
• важливі розділи, які Googlebot відвідує рідко;
• сплески відповідей 5xx і повільний час відповіді;
• активність AI-краулерів (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot), якщо хочете розуміти, як вони використовують сайт.

Немає доступу до логів? Звіт «Статистика сканування» в Search Console (Налаштування → Статистика сканування) дає корисне зведення за кодами відповіді, типами файлів і типами Googlebot.

Які інструменти потрібні для технічного аудиту сайту?

Як розставити пріоритети після технічного SEO-аудиту?

Технічний аудит реального сайту легко видає сотні попереджень, і більшість із них неважливі. Оцінюйте кожну проблему за трьома критеріями: вплив (чи заважає вона скануванню та індексації, чи лише трохи послаблює сигнал), масштаб (один URL чи цілий шаблон) і зусилля (один рядок у конфігурації чи переїзд на нову платформу). Спершу виправляють блокувальні проблеми на шаблонах, що приносять гроші: випадковий noindex, Disallow на ключовій папці, зламані canonical, помилки сервера, контент, який не рендериться. Далі — неефективності на рівні шаблонів: ланцюжки редиректів у навігації, дублі URL, погані Core Web Vitals на групах із великим трафіком. Косметичні зауваження на кшталт відсутнього alt на декоративних зображеннях чи задовгих title в архівних записах — наприкінці. Згрупуйте виправлення в план на 30/60/90 днів, призначте відповідального за кожне і заплануйте повторну перевірку, щоб переконатися, що зміни справді впроваджені та проіндексовані.

Головне

• Проводьте аудит у порядку залежностей: знаходження → сканування → рендеринг → індексація → досвід користувача.
• Звіт «Індексування сторінок» і «Перевірка URL» — головне джерело правди про індексацію в Google.
• robots.txt керує скануванням, а не індексацією; щоб прибрати сторінку з індексу, використовуйте noindex або 404/410.
• Canonical, внутрішні посилання, sitemap і редиректи мають вказувати на одну адресу.
• Не впроваджуйте FAQ чи HowTo розмітку заради розширених сніпетів — їх більше не показують.
• Пріоритет = вплив × масштаб ÷ зусилля; після впровадження обовʼязково перевіряйте результат.

Технічний аудит без десятків годин роботи

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