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

Технічний SEO-аудит відповідає на одне запитання: чи можуть пошуковики знайти, відмалювати та проіндексувати сторінки, які мають наводити трафік, і чи розуміють вони, яка версія кожної сторінки справжня. Контент та посилання визначають, наскільки високо сторінка ранжується, а технічні проблеми – чи бере вона участь у гонці взагалі. Ми проводимо такі перевірки на integrono.com (18 мов), на наших продуктах та на сайтах клієнтів, і одні й ті самі десятки проблем зустрічаються знову і знову.

Чек-лист написаний для розробників та засновників, які можуть самі змінювати сайт. Для старту платні інструменти не потрібні: вистачить Google Search Console, браузера, curl та краулера на кшталт Screaming Frog (безкоштовно до 500 URL).

Перед початком: обсяг та дані

• Складіть список типів сторінок, які повинні ранжуватися (головна, послуги, товари, статті, категорії), та тих, яким це не потрібно (кошик, внутрішній пошук, фільтри, адмінка).
• Підтвердьте домен у Google Search Console (DNS-підтвердження охоплює http, https і всі піддомени) та відкрийте звіти «Сторінки», «Файли Sitemap» та Core Web Vitals.
• Проскануйте сайт десктопним краулером з налаштуванням smartphone Googlebot і вивантажте всі URL з кодом відповіді, індексованістю, canonical, title, H1 і числом слів.

1. Доступ для сканування: чи добираються роботи до сторінок?

Почніть з robots.txt. Він повинен віддавати 200, бути звичайним текстом та не блокувати CSS, JavaScript та розділи, які потрібно індексувати. Один рядок Disallow: /, Що залишився від staging-оточення, - класична катастрофа в день запуску.

curl -sI https://example.com/robots.txt | head -n 5
curl -s  https://example.com/robots.txt

# Good minimal example
User-agent: *
Disallow: /admin/
Disallow: /cart
Sitemap: https://example.com/sitemap.xml

Перевірте, що XML-sitemap містить тільки канонічні індексовані URL-адреси з кодом 200: без редиректів, без сторінок з noindex і без 404. Для багатомовних сайтів кожному URL потрібні мовні альтернативи (див. наш гайд по багатомовному SEO). Надішліть sitemap в Search Console і порівняйте «відправлено» з «проіндексовано».

2. Коди відповіді та редиректи

Кожен важливий URL повинен віддавати прямий 200. Перевірте варіанти адрес, які реально запитують люди та роботи:

for u in http://example.com https://example.com https://www.example.com https://example.com/page/ https://example.com/page; do
  printf "%s -> " "$u"; curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "$u"
done

• Один канонічний хост. Контент віддає рівно один варіант з http/https і www/без www, решта редиректят на нього 301 за один крок.
• Без ланцюжків та циклів редиректів. A на B на C витрачає краулінговий бюджет і розмиває сигнали, надсилайте старі URL одразу на фінальний.
• Справжні 404. Відсутня сторінка повинна віддавати 404 або 410, а не сторінку з кодом 200 та текстом "не знайдено" (soft 404).
• Помилки 5xx у логах або Search Console вимагають негайної реакції: часті помилки сервера змушують Google уповільнити сканування.

3. Індексованість: чи дозволена сторінка та чи унікальна вона?

Індексацію визначають три сигнали: meta-тег robots або заголовок X-Robots-Tag, canonical URL і те, чи не дублює сторінку іншу. Перевіряйте шаблони, а не окремі сторінки.

• Витоку noindex. noindex, скопійований зі staging в продакшен або веб-сервером, що відправляється в HTTP-заголовку, мовчки прибирає сторінки з пошуку.
• Canonical. Кожна індексована сторінка має один абсолютний canonical на саму себе. Сторінки пагінації та фільтри повинні або посилатися на розумного батька або бути виключені. Ніколи не вказуйте canonical на URL з редиректом, noindex або 404.
• Дублі. Варіанти зі слешем і без, великі літери в дорозі, UTM-параметри та версії для друку створюють одну сторінку за кількома адресами. Виберіть один і зробіть редирект або canonical для інших.
• "Проскановано, але поки не проіндексовано" в Search Console зазвичай означає слабкий або майже дублюючий контент, а не технічну заборону. Поліпшіть сторінку або поєднайте з іншою.

curl -s https://example.com/page | grep -i -E '<link rel="canonical"|<meta name="robots"'
curl -sI https://example.com/page | grep -i -E 'x-robots-tag|^HTTP|^location'

4. Структура сайту та внутрішні посилання

Пошуковики знаходять сторінки за посиланнями і структурою посилань судять про їх важливість.

• Глибина кліку. Важливі сторінки повинні відкриватися не далі, ніж за три кліки з головною.
• Сторінки-сироти. Сторінки з sitemap без внутрішніх посилань отримують мало уваги. Порівняйте список краулера зі списком sitemap.
• Анкори. Використовуйте описовий текст («технічний SEO-аудит»), а не «натисніть тут». Посилайтеся із сильних сторінок на ті, які хочете просунути.
• Биті внутрішні посилання. Виправляйте посилання, що ведуть на 404 або на редиректи.
• Справжні посилання. Навігація на JavaScript-обробниках кліка замість <a href> може не скануватися.

5. Технічні сигнали на сторінці

• Title та meta description: унікальні на кожній сторінці, title приблизно до 60 символів, щоб його не обрізали. Дублі та порожні поля знайдіть у розвантаженні краулера.
• Один H1, що відповідає інтенту сторінки, з логічними H2/H3 нижче.
• Мова і кодування: коректний <html lang>, скрізь UTF-8, валідний та взаємний hreflang.
• Зображення: зрозумілі імена файлів, alt, сучасні формати ( WebP або AVIF) та явні width і height проти зсувів макета.
• Пагінація та фільтри: переконайтеся, що фасетні URL-адреси не породжують мільйони сканованих комбінацій.

6. Рендеринг та JavaScript

Google вміє виконувати JavaScript, але рендеринг стоїть у черзі і іноді не вдається. Якщо основний контент або посилання з'являються лише після рендерингу клієнтів, перевірте їх у інструменті «Перевірка URL» («Переглянути сторінку» та скріншот). Для контентних сайтів найнадійніший варіант – серверний рендеринг чи статична видача. Порівняйте висновок curl з тим, що видно у браузері: якщо потрібного тексту немає у вихідному HTML, ви залежите від рендерингу.

7. Швидкість та Core Web Vitals

Досвід користувача сторінки - фактор ранжування помірної ваги і дуже важливий фактор конверсії. Перегляньте звіт Core Web Vitals у Search Console (польові дані реальних користувачів) і запускайте PageSpeed Insights або Lighthouse на ваших шаблонах. Звичайні цілі: Largest Contentful Paint менше 2,5 с, Interaction to Next Paint менше 200 мс і Cumulative Layout Shift менше 0,1. Типові швидкі перемоги: стиснути і правильно підібрати розмір зображень, включити Brotli або gzip, надовго кешувати статику, віддавати через CDN і прибрати CSS і скрипти, що блокують рендеринг. PHP-частину ми розуміємо у статті про Core Web Vitals для PHP-сайтів.

8. Структуровані дані

Структуровані дані власними силами не підвищують позиції, але роблять сторінки придатними розширених результатів і допомагають машинам розуміти сутності. Перевіряйте кожен шаблон у Rich Results Test та Schema Markup Validator. Типові типи: Organization, BreadcrumbList, Article, FAQPage, Product з Offer, LocalBusiness. Розмітка повинна відповідати тому, що бачить користувач на сторінці. Готові приклади - у нашому гайді з JSON-LD.

9. Безпека та мобільна версія

• HTTPS скрізь з чинним сертифікатом, редирект з HTTP на HTTPS та відсутність змішаного контенту.
• Адаптивна верстка з правильним meta-тегом viewport: Google індексує спочатку мобільну версію.
• Жодних нав'язливих оверлеїв, що закривають контент на телефоні.
• Заголовки безпеки та здоровий сервер: на ранжування безпосередньо не впливають, але зламаний чи повільний сайт швидко втрачає позиції.

10. Розставте пріоритети та напишіть завдання

Аудит корисний тільки якщо закінчується викаченими виправленнями. Відсортуйте знахідки щодо впливу:

1. Критично: сторінки закриті, під noindex або дають помилки; неправильний canonical на сторінках, які приносять гроші; зламані редиректи.
2. Високий пріоритет: дублі, ланцюжки редиректів, важливі сторінки-сироти, відсутність hreflang, поганий LCP на ключових шаблонах.
3. Середній: повторювані title, відсутність структурованих даних, вага зображень.
4. Низька: косметичні проблеми розмітки.

До кожного пункту додайте шаблон URL, доказ (виведення команди або скріншот), очікуваний результат та відповідальний. "Виправити canonical" - не завдання, а "сторінки товарів з параметром ?sort= повинні посилатися canonical на чистий URL; шаблон product.php, рядок X» - завдання.

Як часто проводити аудит

Робіть легку перевірку раз на місяць (звіти Search Console, швидкий краулінг, статус ключових URL) та повний аудит після міграцій, редизайнів, оновлення фреймворку або коли трафік падає без очевидної причини. Додайте автоматичні перевірки в конвеєр деплою: тест, що головна віддає 200, не містить noindex і має очікуваний canonical, ловить найдорожчі помилки раніше за користувачів.

Чим ми можемо допомогти

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