Що таке технічний аудит сайту
Власники бізнесу часто питають: «ми вже пишемо контент і отримуємо посилання — навіщо ще якийсь аудит?» Відповідь проста: якщо фундамент сайту тріснутий, на ньому не збудуєш нічого надійного. Технічний аудит — це саме перевірка фундаменту.
Під технічним аудитом розуміють комплексну перевірку сайту на наявність помилок, які заважають пошуковим системам коректно сканувати, розуміти і ранжувати ваші сторінки. Це не про красиві тексти і не про посилання — це про те, чи може Google фізично прочитати ваш сайт так, як він задуманий.
З практики: у восьми з десяти клієнтів, які приходять до нас із проблемою «сайт є, а трафіку немає», під час аудиту ми знаходимо щось критичне. Іноді це дрібниця — robots.txt з одним зайвим рядком, який блокує цілий розділ. Іноді серйозніше — сайт після редизайну випадково переїхав з HTTPS на HTTP без правильних редиректів, і Google місяцями індексував стару версію.
Навіщо технічний аудит потрібен бізнесу
Є розповсюджена помилка: «якщо сайт відкривається і виглядає нормально — значить все добре». Для користувача — можливо. Для Google — зовсім не факт.
Пошуковий робот бачить сайт зовсім не так, як ви. Він читає HTML, перевіряє заголовки, аналізує швидкість завантаження, дивиться на canonical-теги і robots.txt. Красива верстка для нього не має значення — має значення структура і технічна чистота.
Ось конкретний приклад. Один з наших клієнтів — інтернет-магазин будматеріалів — роками вкладав гроші в контент-маркетинг. Статті, огляди, порівняння матеріалів. Трафік рос повільно і нестабільно. Під час аудиту виявилось: фільтрові сторінки каталогу генерували тисячі URL-дублів без canonical-тегів. Google витрачав весь crawl budget на ці дублі і майже не заходив на сторінки з реальним контентом. Після виправлення — трафік почав зростати вже через 6 тижнів, без жодної нової статті.
Технічний аудит потрібен якщо: у вас новий сайт (перевірити ще до запуску), після редизайну або переїзду на новий домен, якщо трафік раптово впав без очевидної причини, і просто регулярно — як техогляд автомобіля.
Найпоширеніші технічні помилки
За вісім років роботи я провів понад 200 технічних аудитів сайтів різного масштабу — від невеликих корпоративних ресурсів до e-commerce з сотнями тисяч SKU. Є помилки, які зустрічаються майже скрізь. Ось вони — від найкритичніших до тих, на які теж варто звертати увагу.
Проблеми з індексацією
Перше, що ми перевіряємо — чи взагалі Google бачить ваш сайт. Відкрийте Google Search Console → розділ «Індексування сторінок» → «Чому сторінки не індексуються». Якщо там десятки або сотні сторінок зі статусом «Виключено», починаємо розбиратись чому.
Найчастіші причини проблем з індексацією:
- Noindex на потрібних сторінках. Буває після розробки — розробник ставить noindex «щоб не індексувався тестовий сайт», потім забуває прибрати після запуску. Ми бачили це не раз.
- Блокування в robots.txt. Рядок
Disallow: /або занадто широкі правила, які закривають цілі розділи сайту. - Orphan pages. Сторінки без внутрішніх посилань — Google їх просто не знаходить, навіть якщо вони є в sitemap.
- Зламані редиректи. Ланцюжки редиректів більше двох кроків, або редиректи-петлі — Google таке погано переносить.
Швидкість і Core Web Vitals
З 2021 року Core Web Vitals — офіційний фактор ранжування Google. Три метрики, які вимірюються:
| Метрика | Що вимірює | Хороший показник |
|---|---|---|
| LCP | Час завантаження найбільшого елементу на сторінці | менше 2,5 сек |
| INP | Час реакції сайту на взаємодію користувача | менше 200 мс |
| CLS | Зміщення елементів під час завантаження | менше 0,1 |
Найчастіша проблема, яку ми бачимо — незоптимізовані зображення. Фото товарів або банери розміром 3–5 МБ, завантажені без стиснення і без lazy-load. На мобільних пристроях такий сайт відкривається 8–12 секунд, і LCP через дах. Просте конвертування в WebP і додавання loading="lazy" на зображення нижче першого екрану дає іноді 60–70% покращення LCP.
Інша поширена причина поганого CLS — шрифти, які підключаються без font-display: swap. Сторінка завантажується, текст з'являється, потім замінюється шрифтом і весь контент «стрибає» вниз. Для Google це CLS, для користувача — роздратування.
Мета-теги і дублі контенту
Дублі — один з найтихіших вбивць SEO. Вони не дають явної помилки, сайт виглядає нормально, але Google не розуміє яку з двох однакових сторінок показувати у видачі — і в підсумку не показує жодну, або показує не ту.
Звідки беруться дублі на практиці:
- Сторінки доступні і з
www, і без — два різних URL з однаковим контентом. - Версії з
/в кінці URL і без — знову дублі. - Фільтри і сортування в e-commerce генерують сотні URL на одну і ту ж категорію товарів.
- Пагінація без canonical або без rel=«next/prev».
- Сторінки теггування в блозі без noindex.
Рішення — canonical-теги. На кожній сторінці має бути <link rel="canonical" href="..."/> що вказує на основну версію. Фільтрові сторінки без унікального контенту краще закривати через canonical на батьківську категорію.
Дублювання мета-тегів — окрема тема. Якщо десятки сторінок мають однаковий title або description — це сигнал для Google, що контент не унікальний. Перевіряємо через Screaming Frog: фільтруємо по «Duplicate Page Titles» і «Duplicate Meta Descriptions».
Schema.org розмітка
Структуровані дані Schema.org — не обов'язкова вимога, але потужний інструмент. Правильна розмітка дає розширені сніпети у видачі: зірочки рейтингу, ціну товару, дату публікації, FAQ. Розширений сніпет займає більше місця на екрані і дає вищий CTR навіть при нижчій позиції.
Найчастіші помилки в Schema.org: синтаксичні помилки в JSON-LD (зайва кома, пропущена дужка), використання застарілих типів (наприклад, Product без обов'язкових полів name і offers), або розмітка, яка не відповідає реальному контенту сторінки — Google за таке може накласти санкцію.
Потрібен технічний аудит вашого сайту? Отримайте детальний звіт з пріоритетами — за 48 годин.
Інструменти для технічного аудиту
Хороша новина: базові інструменти для аудиту безкоштовні. Ось стек, який ми використовуємо самі і рекомендуємо клієнтам.
Безкоштовні інструменти
Google Search Console — обов'язковий старт. Показує реальні дані про індексацію, покриття, Core Web Vitals і помилки Schema.org. Якщо сайт не підключено до GSC — підключіть прямо зараз, це перше, що ми робимо на новому проєкті.
PageSpeed Insights — аналіз Core Web Vitals по конкретному URL. Важливо: дивіться на дані Field Data (реальні користувачі), а не тільки Lab Data (синтетичний тест). Вони часто суттєво розрізняються.
Google Rich Results Test — перевірка Schema.org розмітки. Підсвічує помилки і попередження, показує як виглядатиме розширений сніпет.
Screaming Frog SEO Spider (безкоштовна версія до 500 URL) — краулер, який сканує сайт як Google. Знаходить зламані посилання, дублі, відсутні мета-теги, проблеми з canonical і редиректами.
Платні інструменти (для серйозної роботи)
Screaming Frog без ліміту — £259 на рік, окупається на першому великому аудиті великого сайту. Ahrefs Site Audit — найкращий для моніторингу в часі, зручне відображення динаміки помилок по тижнях. Semrush Site Audit — хороша альтернатива, особливо якщо вже використовуєте Semrush для аналізу ключових слів.
Як виглядає реальний аудит: покроково
Коли ми беремо новий проєкт на аудит, послідовність завжди приблизно однакова. Ділюся нашим внутрішнім чеклістом.
Крок 1. Перевірка базової індексації. GSC → кількість проіндексованих сторінок vs кількість сторінок на сайті. Якщо сильно розходяться — починаємо копати чому. Паралельно перевіряємо robots.txt і sitemap.xml на наявність і коректність.
Крок 2. Аналіз технічних помилок через Screaming Frog. Запускаємо повний краул, фільтруємо по: 4xx помилки, 5xx помилки, redirect chains, дублі title/description, відсутні H1, зображення без alt-тегів.
Крок 3. Core Web Vitals. GSC → Core Web Vitals → дивимось які URL позначені як «Needs Improvement» або «Poor». Перевіряємо їх через PageSpeed Insights, визначаємо першопричину для кожної метрики.
Крок 4. Schema.org перевірка. Перевіряємо головну, типову сторінку послуги/товару, статтю блогу. Rich Results Test покаже помилки. Якщо сайт використовує кілька типів розмітки — перевіряємо кожен тип.
Крок 5. Внутрішня перелінковка. Аналізуємо через Screaming Frog «orphan pages» — сторінки без жодного внутрішнього посилання. Перевіряємо глибину сторінок: комерційні сторінки не повинні бути глибше 3 кліків від головної.
Крок 6. Мобільна версія. Google Mobile-Friendly Test для ключових сторінок. GSC → «Юзабіліті мобільних» — там видно реальні проблеми на мобільних з реальних пристроїв.
Результат аудиту — звіт з пріоритизованим списком задач: критичні (виправити негайно), важливі (виправити цього кварталу), бажані (виправити при нагоді).
Як часто проводити технічний аудит
Однозначної відповіді немає — залежить від розміру сайту і темпу змін. Для невеликих корпоративних сайтів достатньо повного аудиту раз на квартал і щотижневого моніторингу GSC. Для великих e-commerce з активною розробкою — моніторинг потрібен постійний, тому що кожен деплой потенційно може щось зламати.
Є ситуації, коли аудит обов'язковий незалежно від графіку: переїзд на новий домен, зміна CMS або хостингу, великий редизайн, раптове падіння трафіку або позицій. У всіх цих випадках перше, що потрібно зробити — технічний аудит, щоб виключити технічну причину.
Ще одна корисна практика — автоматизований моніторинг. Ahrefs і Semrush вміють запускати аудит за розкладом і надсилати звіт на email, якщо з'явились нові критичні помилки. Це не заміна повноцінному аудиту, але добра «рання система попередження».
Підсумок: що робити після прочитання
Якщо ви ніколи не робили технічний аудит свого сайту — почніть просто зараз з безкоштовних інструментів. Відкрийте Google Search Console, перейдіть у розділ «Індексування» і подивіться скільки сторінок виключено з індексу і чому. Потім запустіть PageSpeed Insights для головної сторінки і однієї комерційної. Це займе 15 хвилин і дасть перше розуміння стану сайту.
Якщо сайт великий, або ви вже бачите проблеми але не розумієте їхньої причини — варто звернутись до фахівців. Не тому що «самому не розібратись», а тому що досвідчений SEO-фахівець витратить на повний аудит 4–8 годин, а не тиждень, і відразу дасть пріоритизований план дій.
Технічне SEO — це не найцікавіша частина просування. Але якщо технічна база не в порядку, всі інші зусилля — контент, посилання, аналітика — дають набагато менший ефект. Спочатку фундамент, потім все інше.
