SEO-чекліст 2026: 60 пунктів для сайту, який має ранжуватися
Повний чекліст SEO — від індексації та robots.txt до Core Web Vitals, мікророзмітки й контенту. Кожен пункт з поясненням, чому він впливає на позиції.
Більшість сайтів не ранжуються не через складні причини, а через п’ять-шість базових речей, які ніхто не перевірив. Нижче — чекліст із 60 пунктів у шести блоках, за яким ми проходимо кожен проєкт перед запуском і раз на пів року після. Кожен пункт сформульований так, щоб на нього можна було відповісти «так» або «ні» за хвилину, без інтерпретацій і без окремого аудиту.
60
пунктів у шести блоках
~80%
проблем — у перших двох блоках
2 дні
на повний прохід сайту до 100 сторінок
6 міс
періодичність повторної перевірки
Як користуватися чеклістом і в якому порядку
Порядок блоків не випадковий. Немає сенсу вилизувати заголовки на сторінці, яка закрита від індексації, і немає сенсу нарощувати посилання на сайт, де половина сторінок дублює одна одну. Ідіть згори вниз і не переходьте далі, поки в поточному блоці залишаються «ні».
| Черга | Блок | Коли перевіряти | Ціна помилки |
|---|---|---|---|
| 1 | Індексація та краулінг | До запуску і після кожного релізу | Сторінок немає в пошуку взагалі |
| 2 | Семантика та структура | На етапі прототипу, потім раз на рік | Переробка URL і втрата позицій |
| 3 | On-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 символів, головний запит на початкуdescription140–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.
Блок 6. Контент, посилання й аналітика
Цей блок ніколи не буває «закритим» — його перевіряють постійно. Саме тут ховається різниця між сайтом, який дійшов до плато на 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-аудит: що перевіряти і в якому порядку
Технічні помилки коштують позицій тихо. Порядок аудиту, який ловить найдорожчі з них першими.
Core Web Vitals: LCP, INP і CLS простими словами
Три метрики, які Google використовує як сигнал ранжування. Пояснюємо кожну і показуємо, що ламає їх найчастіше.
Семантичне ядро: як зібрати запити, які приносять клієнтів
Більшість ядер збирають за частотністю і програють. Показуємо, як збирати за наміром користувача.