WebEngine

0%
SEO та аналітика

SEO-чекліст 2026: 60 пунктів для сайту, який має ранжуватися

Повний чекліст SEO — від індексації та robots.txt до Core Web Vitals, мікророзмітки й контенту. Кожен пункт з поясненням, чому він впливає на позиції.

Pavlo9 хв читання

Більшість сайтів не ранжуються не через складні причини, а через п’ять-шість базових речей, які ніхто не перевірив. Нижче — чекліст із 60 пунктів у шести блоках, за яким ми проходимо кожен проєкт перед запуском і раз на пів року після. Кожен пункт сформульований так, щоб на нього можна було відповісти «так» або «ні» за хвилину, без інтерпретацій і без окремого аудиту.

60

пунктів у шести блоках

~80%

проблем — у перших двох блоках

2 дні

на повний прохід сайту до 100 сторінок

6 міс

періодичність повторної перевірки

Як користуватися чеклістом і в якому порядку

Порядок блоків не випадковий. Немає сенсу вилизувати заголовки на сторінці, яка закрита від індексації, і немає сенсу нарощувати посилання на сайт, де половина сторінок дублює одна одну. Ідіть згори вниз і не переходьте далі, поки в поточному блоці залишаються «ні».

ЧергаБлокКоли перевірятиЦіна помилки
1Індексація та краулінгДо запуску і після кожного релізуСторінок немає в пошуку взагалі
2Семантика та структураНа етапі прототипу, потім раз на рікПереробка URL і втрата позицій
3On-pageДля кожної нової сторінкиСлабкий CTR при непоганих позиціях
4Технічна база та швидкістьЩомісяця за польовими данимиПросідання на мобільних
5Розмітка й мобільна версіяПісля запуску, потім щокварталуНемає розширених сніпетів
6Контент, посилання, аналітикаПостійноЗростання зупиняється на плато

Блок 1. Індексація та краулінг

Найдорожчі помилки живуть тут, і майже всі вони — наслідок релізу. Найчастіший випадок у нашій практиці: Disallow: / переїхав з тестового сервера на бойовий і три тижні ніхто не помічав.

Блок 1 — 10 пунктів

  • У robots.txt немає Disallow: /, що приїхав із тестового середовища
  • Домен доданий у Search Console, карта сайту подана й прочитана без помилок
  • sitemap.xml містить лише канонічні URL з кодом 200 — без редиректів і 404
  • Кожна сторінка має один самопосилальний canonical
  • Дублі www/без www, http/https, зі слешем і без зведені 301-м на один варіант
  • Кошик, фільтри й внутрішній пошук закриті через noindex, а не лише в robots.txt
  • Пагінація має унікальні title і не має canonical на першу сторінку
  • У звіті «Сторінки» немає росту категорії «Виявлено — не проіндексовано»
  • Немає ланцюжків редиректів довших за один крок
  • Неіснуюча сторінка віддає код 404, а не 200 із текстом «нічого не знайдено»

Перевіряти це вручну довго, тому перші вісім пунктів закриваються звітом «Сторінки» та інструментом перевірки URL — як їх читати, розібрано в гайді по Google Search Console.

Блоки 2 і 3. Структура та on-page

Структура вирішує, за що ви взагалі можете конкурувати, on-page — чи клікнуть по вас у видачі. Перше змінюється дорого, друге — за годину, тому не плутайте пріоритети.

Блок 2 — семантика та структура

  • Зібрано ядро запитів із частотністю та інтентом, а не список «гарних слів»
  • Кожен кластер запитів має рівно одну цільову сторінку
  • URL читабельні, без дат і параметрів на кшталт ?id=274
  • Будь-яка сторінка досяжна за три кліки від головної
  • Хлібні крихти є на всіх сторінках, крім головної
  • Меню повторює логіку попиту, а не оргструктуру компанії
  • Кожна послуга має власну сторінку, а не пункт у спільному списку
  • Комерційні й інформаційні запити рознесені: послуги окремо, блог окремо
  • Немає сторінок-сиріт без жодного внутрішнього посилання
  • Фільтри каталогу з реальним попитом віддають індексовані статичні URL

Блок 3 — on-page оптимізація

  • title унікальний, 50–60 символів, головний запит на початку
  • description 140–158 символів і містить причину клікнути, а не перелік ключів
  • Один h1 на сторінку, який не дублює title слово в слово
  • Заголовки h2/h3 йдуть без пропусків рівнів
  • Перший абзац відповідає на запит у перших двох реченнях
  • В усіх змістовних зображень є alt з описом, а не «img_2043»
  • Зображення у WebP або AVIF, із заданими width і height
  • Внутрішні анкори описові — не «тут» і не «детальніше»
  • Немає прихованого тексту, накрутки ключів і блоку тегів унизу
  • Дата оновлення реальна й видима, якщо тема чутлива до часу

Пункт про один кластер на сторінку — той, який найчастіше порушують. Дві сторінки під один інтент не подвоюють шанси, а ділять сигнали навпіл: Google обирає одну, зазвичай не ту. Як розводити кластери на етапі збору, показано в методиці підбору запитів.

Блоки 4 і 5. Швидкість, розмітка, мобільні

Тут важливо міряти польові дані реальних користувачів, а не лабораторний прогін на ноутбуку розробника з гігабітом. Розрив між ними — типово вдвічі.

Блок 4 — технічна база та швидкість

  • LCP до 2.5 с на мобільному за польовими даними
  • INP до 200 мс на найважчому сценарії — зазвичай це фільтр або форма
  • CLS до 0.1: банерам, рекламі й шрифтам зарезервоване місце
  • HTTPS із валідним сертифікатом і без mixed content
  • Увімкнено стиснення Brotli або gzip
  • Статика віддається з CDN і кешується на рік із хешем у назві файлу
  • JS на головній — до 200 КБ після стиснення
  • Шрифти локальні, з font-display: swap і preload основного накреслення
  • На ключових сторінках немає помилок у консолі
  • TTFB тримається до 600 мс під навантаженням

Блок 5 — мікророзмітка й мобільна версія

  • Organization або LocalBusiness на головній із коректними контактами
  • BreadcrumbList на всіх внутрішніх сторінках
  • Product з ціною й наявністю для магазину, Article для блогу
  • FAQPage лише там, де питання реально видимі користувачу
  • Розмітка проходить Rich Results Test без помилок
  • Немає горизонтальної прокрутки на екрані 360 px
  • Зона натискання кнопок і посилань — не менша за 44×44 px
  • Основний текст від 16 px, контраст не нижчий за 4.5:1
  • Мобільна версія містить той самий контент, що й десктопна
  • Спливні вікна не перекривають контент одразу після завантаження

Якщо значення в цьому блоці «червоні», не намагайтеся виправити все одразу: LCP і CLS зазвичай лікуються за день-два, а INP вимагає роботи з логікою. Що саме означає кожна метрика й чим її лагодять — у розборі Core Web Vitals.

Цей блок ніколи не буває «закритим» — його перевіряють постійно. Саме тут ховається різниця між сайтом, який дійшов до плато на 300 візитах, і сайтом, який росте другий рік поспіль.

Блок 6 — 10 пунктів

  • Кожна сторінка вирішує одне завдання користувача і має один основний заклик
  • Обсяг тексту диктується запитом, а не нормою «3000 слів»
  • Немає двох сторінок, які конкурують за той самий запит
  • Є сторінка «Про нас» із реальними людьми, адресою й досвідом
  • З кожної статті йде 3–5 контекстних внутрішніх посилань
  • Профіль посилань зростає рівномірно, без стрибків у 200 доменів за місяць
  • Компанія є в Google Business Profile, якщо має фізичну адресу
  • GA4 і Search Console з’єднані, ціль налаштована на заявку, а не на перегляд
  • Позиції відстежуються за групами запитів, а не за окремими фразами
  • Раз на квартал перевіряються биті посилання й нові 404

Пункт про рівномірне зростання профілю посилань — єдиний у списку, який можна закрити «успішно» і при цьому нашкодити сайту. Купівля 200 доменів за місяць формально виконує вимогу зростання, а фактично додає ризик. Які посилання ще працюють і як перевірити донора до оплати — у розборі безпечного лінкбілдингу.

Чекліст не робить SEO. Він лише показує, у скількох місцях ви зараз програєте конкуренту, який пройшов той самий список раніше.

Часті питання про SEO-чекліст

Скільки часу займає повний прохід усіх 60 пунктів?

Для сайту до 100 сторінок це приблизно два робочі дні, якщо є доступи до Search Console, аналітики та коду. Для інтернет-магазину на кілька тисяч URL — від тижня, бо блоки індексації та структури доводиться перевіряти краулером, а не вручну. Виправлення знайденого займає більше часу, ніж сама перевірка.

З чого починати, якщо «ні» стоїть майже скрізь?

Починайте з індексації: сторінка, якої немає в індексі, не отримає трафіку незалежно від якості тексту. Далі закривайте дублі й канонікали, потім швидкість на мобільних. Контент і посилання чіпайте останніми — вони дають приріст лише на здоровому технічному фундаменті.

Чи достатньо пройти чекліст один раз?

Ні. Блоки індексації та швидкості ламаються під час релізів, тому їх перевіряють після кожного оновлення сайту. Структуру й семантику переглядають раз на рік, а контент, посилання й аналітику контролюють постійно. Практичний ритм — повний прохід раз на пів року плюс швидка перевірка після кожного релізу.

Чи можна пройти цей список без розробника?

Приблизно половину пунктів можна закрити самостійно через панель керування сайтом: заголовки, описи, alt-тексти, внутрішні посилання, контент. Індексація, швидкість, кешування, мікророзмітка й серверні налаштування майже завжди вимагають доступу до коду. Розумний поділ — власник робить контентну частину, розробник технічну.

Коли після виправлень з’являється результат?

Технічні помилки індексації дають ефект найшвидше: сторінки з’являються в пошуку протягом одного-трьох тижнів після переобходу. Покращення заголовків і сніпетів впливають на CTR за два-чотири тижні. Структурні зміни й контент розкриваються повільніше — від трьох до шести місяців.

Коротко

  • Порядок важливіший за повноту: індексація, потім структура, потім усе інше.
  • Близько 80% реальних проблем закриваються першими двома блоками з двадцяти пунктів.
  • Швидкість міряйте польовими даними мобільних користувачів, а не лабораторним прогоном.
  • Блоки 1 і 4 ламаються під час релізів — перевіряйте їх після кожного оновлення, а не раз на рік.
  • Якщо технічний блок дає чотири й більше «ні», потрібен повноцінний технічний аудит, а не подальше проходження списку.
Поділитися
  • SEO
  • чекліст
  • аудит

Схожі матеріали

SEO та аналітика

Core Web Vitals: LCP, INP і CLS простими словами

Три метрики, які Google використовує як сигнал ранжування. Пояснюємо кожну і показуємо, що ламає їх найчастіше.

8 хв читання