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

Найпоширеніша помилка: почати з другорядного. Хтось переписує meta description на двадцяти сторінках, поки robots.txt закриває від сканування весь розділ. Тому йдіть від загального до дрібного, у п'ять кроків.

1. Сканування: чи може робот отримати сторінку (robots.txt, коди відповіді, редиректи).
2. Індексація: чи дозволено сторінці потрапити в індекс (noindex, canonical, дублікати).
3. Розуміння: чи зрозуміло з розмітки і тексту, про що сторінка (title, заголовки, структуровані дані, мова).
4. Швидкість: чи сторінка завантажується без зайвих затримок.
5. Безпека: чи сайт працює через HTTPS і не віддає браузеру небезпечних налаштувань.

Перед початком вирішіть, що саме ви перевіряєте: одну сторінку, шаблон чи весь сайт. Помилка в шаблоні повторюється на тисячах адрес, тому одна знайдена проблема в шаблоні важить більше, ніж десять окремих сторінок. Для довідки по базових принципах корисний SEO starter guide від Google.

Варто також розуміти межі інструментів. Пасивний сканер читає одну адресу та кілька публічних допоміжних файлів. Він не обходить весь сайт, не виконує JavaScript і не вимірює позиції. Тож для сайту з сотнями сторінок поєднуйте разовий швидкий огляд з Google Search Console.

Почніть із файлу /robots.txt. Перевірте, що він відповідає кодом 200, що правило Disallow: / не діє для всього сайту і що в ньому не закриті каталоги зі стилями та скриптами, потрібні для відображення сторінки. Докладно про синтаксис і типові помилки ми писали в статті robots.txt: як писати і перевіряти.

Далі коди відповіді. Робоча сторінка має віддавати 200, видалена 404 або 410, перенесена 301 або 308 на одну остаточну адресу. Ланцюжки з кількох редиректів уповільнюють сканування, а циклічні редиректи роблять сторінку недоступною. Тимчасовий редирект 302 на постійно перенесеній сторінці теж варто виправити. Про постійні перенаправлення докладно в документації Google.

Окремо перевірте HTTPS-версію і дублікати хоста. Адреса з www і без www не повинні обидві віддавати контент: оберіть одну, а іншу перенаправте. Те саме стосується http та https.

Нарешті, sitemap. Він має існувати, бути оголошеним у robots.txt рядком Sitemap: і містити лише канонічні адреси з кодом 200. Вимоги й помилки розібрані в матеріалі sitemap.xml: вимоги, помилки і перевірка.

Типовий мінімум для цього блоку виглядає так:

User-agent: *
Disallow: /admin/

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

Коли робот дійшов до сторінки, вирішується, чи вона потрапить в індекс. Тут працюють три сигнали, і вони не повинні суперечити один одному.

Директиви noindex

Перевірте метатег robots і HTTP-заголовок X-Robots-Tag. Випадково залишений noindex після запуску сайту належить до найдорожчих помилок: сторінка працює, а в пошуку її немає. Пам'ятайте, що noindex має бути доступний роботові, тому сторінку з noindex не можна одночасно закривати в robots.txt, інакше директиву ніхто не прочитає. Див. опис Google про блокування індексації.

Canonical

Тег rel="canonical" підказує, яку адресу вважати основною серед схожих. Перевіряйте, що він присутній, містить абсолютну адресу з https, веде на сторінку з кодом 200 і не вказує на іншу сторінку без причини. Типові помилки ми зібрали в статті canonical: коли потрібен і типові помилки.

Soft 404

Це сторінки, які показують «нічого не знайдено», але віддають код 200. Пошуковик витрачає на них ресурс сканування, а вам вони нічого не дають. Перевірте, що неіснуюча адреса віддає справжній 404.

Окремий випадок: сторінки з майже порожнім вмістом, наприклад ті, що збираються лише скриптом. Якщо в початковому HTML майже немає тексту, є ризик, що пошукова система побачить менше, ніж користувач.

Це найпомітніша частина аудиту, але не найважливіша. Перевірте мінімум:

• title існує, один на сторінці, описує саме цю сторінку і не складається з загальних слів на кшталт «Головна». Довжину орієнтовно тримайте в межах, де заголовок не обрізається; як Google формує заголовок у видачі, описано в документації про title link.
• meta description є, не збігається з title і не обрізається. Google може переписати опис, але добре складений не завадить, див. документацію про сніпети.
• Рівно один h1 без порожнього тексту, далі підзаголовки без пропусків рівнів.
• Атрибут lang на тегу html з коректним кодом мови.
• meta viewport, щоб сторінка адекватно відображалась на телефоні.
• Атрибути alt в інформативних зображень і розміри width та height.
• Doctype і кодування символів.

Базова голова сторінки може виглядати так:

<!doctype html>
<html lang="uk">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Назва сторінки</title>
  <meta name="description" content="Короткий опис сторінки для видачі.">
  <link rel="canonical" href="https://example.com/page">
</head>

Не женіться за ідеальними довжинами: це орієнтири, а не вимога пошукової системи. Важливіше, щоб метадані були унікальними і чесно описували сторінку.

Внутрішні посилання допомагають і користувачам, і роботам. Перевірте, що на сторінці немає бітих посилань, що адреси не містять ідентифікаторів сесій, що немає некоректних посилань (порожніх чи з помилками в адресі) і що на https-сторінці немає посилань на http. Достатньо вибіркової перевірки кількох внутрішніх посилань, але для великого сайту потрібен повний обхід.

Структуровані дані додають сторінці машинозчитуваний опис. Перевірте, що JSON-LD є, що це валідний JSON, що вказано @context і що тип відповідає вмісту. Які типи справді потрібні звичайному сайту, ми розібрали в матеріалі JSON-LD: що потрібно звичайному сайту. Розмітка не гарантує розширеного сніпета, а розмітка, якої немає на видимій сторінці, суперечить правилам Google.

Якщо сайт багатомовний, окремо перевірте hreflang: правильні коди мов (для української це uk, а не ua), посилання кожної версії на себе, взаємні посилання між версіями і x-default. Найчастіші збої описані в статті hreflang: помилки і як перевірити.

Нарешті, соціальні метадані: Open Graph і Twitter Cards впливають на вигляд посилання в месенджерах, а не на позиції. Іконка сайту (favicon) теж входить до цього блоку, і її відсутність видно одразу.

Швидкість перевіряють двома різними способами, і їх не варто плутати. Польові дані (реальні користувачі) показує звіт Core Web Vitals у Google Search Console та PageSpeed Insights. Лабораторні дані дає Lighthouse. Що означають LCP, INP і CLS і чому їхні межі такі, пояснює стаття Core Web Vitals для початківців.

Пасивний сканер Core Web Vitals не вимірює. Він показує лише непрямі ознаки того, що сторінці може бути важко завантажуватись:

• час відповіді сервера на основний запит (це не метрика Core Web Vitals);
• розмір HTML-документа;
• чи ввімкнене стиснення відповіді;
• чи підтримується HTTP/2;
• чи є заголовки кешування;
• скрипти в head, що блокують відображення;
• кількість сторонніх хостів і шрифтів;
• зображення без заданих розмірів, які можуть спричиняти зсув макета;
• застарілі формати зображень.

Це підказки, де шукати, але не оцінка. Якщо сканер повідомляє про зображення без розмірів, це ризик зсуву макета, а не виміряний CLS. Для цифр використовуйте польові дані.

Безпека входить у технічний аудит з двох причин. По-перше, Google рекомендує віддавати сторінки через HTTPS. По-друге, помилки на кшталт змішаного вмісту, прострочений сертифікат чи форма, що надсилає дані по http, відлякують користувачів і ламають сторінки.

Перевірте таке:

• усі сторінки доступні через HTTPS, а http перенаправляє на https;
• сертифікат дійсний, не прострочений і виданий на потрібне доменне ім'я;
• на сторінці немає змішаного вмісту (скрипти й стилі по http);
• встановлені основні заголовки: Strict-Transport-Security, X-Content-Type-Options, політика Content-Security-Policy і захист від вбудовування у фрейми.

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

Нижче підсумок: що перевіряти і чи є це в пасивному звіті SEOAudit.

Щоб розставити пріоритети, спершу виправляйте те, що блокує показ у пошуку: noindex, закритий robots.txt, помилки сервера, цикли редиректів. Далі йдуть проблеми, що розмивають сигнали: конфліктні canonical, дублікати хоста, помилки hreflang. Метадані, розмітка й дрібні зауваження завершують список. Звіт сканера розрізняє важливі та інформаційні результати, і така розбивка допомагає не гаяти час на дрібницях.

Повторюйте перевірку після кожного значного релізу, зміни шаблону, міграції чи перенесення домену, а також за графіком, наприклад раз на місяць. Для автоматичного огляду є сторінка SEO-аудиту, а якщо цікавить видимість для ШІ-пошуку, дивіться готовність до ШІ-пошуку.