«1000 SEO-порад»-листикли — це окремий жанр. Вони існують, бо SEO-софтверним компаніям треба, щоб контент-команда щось публікувала щотижня. Реальний список речей, що мають значення на маркетинговому сайті — це приблизно 20. Двадцять, зроблені правильно, виграють у тисячі, зроблених наполовину.
Це той список. По п'ять у чотирьох категоріях: технічне, on-page, продуктивність, контент. З тим, як перевірити кожне, який інструмент використати, і що рахується за «достатньо добре».
Технічне (5)
1. Canonical URL
У кожної сторінки один canonical URL. Дублі (з або без слешу в кінці, з або без query-параметрів) вказують на нього через <link rel="canonical">.
Перевірка: view source на кількох сторінках, пошук canonical. Має з'являтись рівно раз на сторінку, вказувати на URL, під яким сторінка має ранкуватись.
Поширений баг: сторінки з ?utm_source=... отримують canonical на самі себе, розщеплюючи ранкінгові сигнали. Canonical має завжди бути чистим URL.
2. XML sitemap
Sitemap у /sitemap.xml, що перелічує кожну індексуєму сторінку сайту. Подано у Google Search Console. Регенерується, коли контент змінюється.
Перевірка: відвідайте /sitemap.xml. Порахуйте URL. Точково перевірте, що URL правильні і включають canonical-версію (не дублі). Для мультимовних сайтів sitemap має включати hreflang-анотації.
Для Next.js: app/sitemap.ts генерує динамічно. Для статичних сайтів — build-крок пише файл.
3. Robots.txt
/robots.txt у корені, що каже crawler-ам, що вони можуть і не можуть.
Дефолт для маркетингового сайту:
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xmlУсе. Складність у robots.txt приходить з команд, що намагаються заблокувати staging-URL чи адмін-сторінки. Використовуйте авторизацію для цього; robots.txt — це підказка, не межа безпеки.
Перевірка: відвідайте /robots.txt. Підтвердіть, що рядок sitemap вказує на правильний URL.
4. JSON-LD structured data
Schema.org розмітка як JSON-LD у head кожної сторінки. Мінімум:
Organizationсхема на головнійWebSiteсхема на весь сайтBlogPostingна блог-постахServiceна сторінках послугBreadcrumbListна будь-якій сторінці з хлібними крихтамиFAQPage, якщо у вас є FAQ
Перевірка: використайте Google Rich Results Test на кількох сторінках. Підтвердіть відсутність помилок. Підтвердіть, що structured data описує те, що сторінка насправді показує.
Поширений баг: JSON-LD на блог-пості заявляє author як «Acme Studio», але видима сторінка каже «Автор: Sam Hollis». Оберіть один.
5. Hreflang (якщо мультимовний)
Якщо сайт більш ніж однією мовою — hreflang на кожній сторінці, що оголошує кожну локаль. Див. пост про hreflang щодо режимів провалу.
Якщо сайт одномовний — пропустіть це повністю. Додавання порожнього або неправильного hreflang гірше за відсутність.
On-page (5)
6. Title tag, 50-60 символів
<title> кожної сторінки. 50-60 символів — солодке місце, що переживає обрізку Google. Основний ключ у перших 30 символах. Читається як те, що написала б людина.
Перевірка: точково перевірте source кількох сторінок. Title tag має бути унікальним на сторінку. Жодних паттернів «Home | Acme»; title головної має описувати, що робить Acme, не казати «Home».
7. Meta description, 140-160 символів
<meta name="description">. Google іноді показує це у результатах пошуку, іноді ігнорує. Коли показує — впливає на CTR.
Перевірка: те саме, що title. Унікально на сторінку, 140-160 символів, конкретна вигода чи заява, основний ключ включено природно.
Не генеруйте описи з вмісту сторінки автоматично. Вони гірші за відсутні.
8. Один H1
У кожної сторінки рівно один <h1>. Його текст збігається з title tag близько (не ідентично — вони служать різним аудиторіям).
Перевірка: пошук <h1 у відрендереному source. Має з'являтись раз. Якщо двічі — виправте шаблон.
Поширений баг: <h1> для лого чи назви сайту у header, потім ще <h1> для title сторінки. Використовуйте <h1> лише для title контенту сторінки; лого — це <p> або <div>.
9. Внутрішні посилання, 2-5 на сторінку
Кожна контентна сторінка посилається принаймні на 2-5 інших релевантних сторінок того ж сайту. З описовим anchor-текстом (не «натисніть тут»).
Перевірка: порахуйте внутрішні посилання на кількох ключових сторінках. Сторінки послуг мають посилатись на кейси. Кейси мають посилатись на послуги. Блог-пости мають посилатись на пов'язані блог-пости і послугу, до якої вони ladder up.
Сайти з поганим внутрішнім лінкуванням ранкуються гірше за той самий контент. Граф посилань — це ранкінговий фактор; будуйте його свідомо.
10. Alt-текст зображень
Кожен <img> має атрибут alt. Порожній (alt="") для декоративних зображень. Описовий для контентних. Див. WCAG-пост щодо специфіки.
Перевірка: швидке сканування axe DevTools або Lighthouse зловить відсутні alt. Читання alt вголос має сказати вам, чи воно має сенс.
Продуктивність (5)
11. Largest Contentful Paint (LCP) під 2.5s
Найбільший видимий елемент на сторінці (зазвичай hero-зображення чи перший headline) має рендеритись за менше ніж 2.5 секунди на mid-tier мобільному.
Перевірка: PageSpeed Insights для lab-data. CrUX (Chrome User Experience report) для real-user data. CrUX-цифра — це те, на чому ранкує Google.
Поширена причина: велике hero-зображення без priority хінта, або без srcset, або PNG замість WebP.
12. Cumulative Layout Shift (CLS) під 0.1
Речі на сторінці не мають стрибати, коли вантажаться. CLS вимірює сумарну стрибучість.
Перевірка: ті самі інструменти. Поширені причини — зображення без width/height, шрифти, що swap і reflow, реклама/ембеди, що інжектують контент над існуючим.
13. Interaction to Next Paint (INP) під 200ms
Наскільки відгуклива сторінка, коли користувач щось робить (клік, тап, друк). INP замінив FID у Core Web Vitals.
Перевірка: CrUX. Lab-інструменти апроксимують це, але реальне вимірювання — від реальних користувачів.
Поширена причина: важкий JavaScript, що блокує main thread при інтеракції. Code-split, defer не-критичних скриптів, приберіть polyfill-и.
14. Час відповіді сервера (TTFB) під 800ms
Time-to-first-byte. Від кліку на посилання до прибуття першого байта HTML.
Перевірка: WebPageTest або PageSpeed Insights показують це у lab-data. Real-user data з CrUX також розбита за TTFB.
Поширена причина: повільні database-запити, cold-start serverless-функції, відсутній CDN. Див. пост про аудит продуктивності щодо діагностики.
15. Вага сторінки під 500KB (перше завантаження)
Сумарні байти, надіслані при першому завантаженні. Mid-tier мобільний на ринку, що розвивається, має обмежену пропускну здатність; сторінки понад 1MB повільні для великого шматка користувачів світу.
Перевірка: filmstrip view у WebPageTest або вкладка network у Chrome DevTools. Фільтр на «First load», виключаючи кешовані ресурси.
Поширений надлишок: великі неоптимізовані зображення, шрифти завантажені, але не використані, polyfill-и, third-party скрипти.
Контент (5)
16. Дослідження ключів, що засноване на інтенті
Для кожної сторінки знайте основний ключ, під який вона намагається ранкуватись, і пошуковий інтент за тим ключем (інформаційний, транзакційний, порівняльний, навігаційний).
Сторінка, що таргетить «найкраща CRM для бізнесу» (порівняльний інтент), не має бути продажною сторінкою одного продукту. Має бути порівнянням.
Перевірка: пошукайте ключ у Google. Подивіться на топ-10 результатів. Вони кажуть вам, який інтент Google матчить. Ваша сторінка має бути тієї самої форми.
17. Глибина, що відповідає темі
Як довгим має бути контент — визначається темою, не SEO-правилом. «Як приготувати каву вдома» може бути 800 слів. «Як GDPR застосовується до SaaS-компанії» імовірно потребує 3000.
Перевірка: знову, топ-10 результатів за вашим ключем. Перевірте їхні довжини. Цільтесь у середнє, не у найдовше. Підбивка губить читачів; глибина їх заробляє.
18. Сигнали E-E-A-T
Experience, expertise, authoritativeness, trustworthiness. Quality-фреймворк Google. Для маркетингового сайту це перекладається як:
- Авторські bylines на блог-постах (з біо і кредитами)
- Сторінка About з реальними іменами і реальними фото
- Кейси з названими клієнтами
- Справжні тестимоніали клієнтів
- Перевірні заяви (цифри, дати, посилання)
Перевірка: уявіть, що ви скептичний читач. Чи можете сказати, хто це написав, яка його експертиза, чи він насправді робить роботу, яку описує? Якщо ні — у вас E-E-A-T-проблема.
19. Свіжість
Деякі запити винагороджують свіжий контент (новини, тренди, «найкраще X у 2026»). Інші — ні (timeless how-to, evergreen-пояснення).
Для сторінок, що таргетять свіжі запити: оновлюйте. Додайте «востаннє оновлено». Відображайте нову інформацію. Застарілий контент за свіжими запитами обганяють.
Для evergreen-контенту: лишіть у спокої, поки він не помилковий. Оновлення «Як приготувати каву» щокварталу — busywork.
Перевірка: пошукайте ваш цільовий ключ. Якщо топ-10 — усі з останніх 6 місяців — свіжість важить. Якщо охоплюють роки — ні.
20. AI-search citability
Новіший вимір. Чи цитуватимуть AI Overviews Google, Perplexity або ChatGPT search вашу сторінку при відповіді на underlying-запит?
Паттерн, що цитується:
- Відповідь — у першому абзаці кожної секції, не похована.
- Конкретні факти (цифри, імена, дати), а не загальні заяви.
- Визначення в'юнхауз (не припускайте, що читач має контекст).
- Списки і таблиці, які можна вирізати чисто.
Див. GEO-пост, коли опублікуємо. Поки що: пишіть кожну секцію так, щоб перше речення було повною, цитуваною заявою.
1000 порад, які можна пропустити
Речі, що SEO-листикли рекомендують, які можна ігнорувати:
- Щільність ключів. Перестало мати значення десять років тому.
- Тег meta keywords. Google ігнорує повністю.
- «LSI keywords». Не існує в алгоритмі Google.
- «Schema всюди». Використовуйте schema там, де вона релевантна (за списком вище), пропускайте в інших місцях.
- Подача у пошукові системи вручну. Google знаходить ваш сайт через посилання.
- Disavow кожного випадкового беклінка. Disavow-tool — для серйозних випадків, не рутини.
- Цілі word count на кшталт «блог-пости мають бути 2000+ слів». Неправильно; див. #17.
- Мікрооптимізації header-тегів (кілька H2 у конкретному порядку). Використовуйте заголовки семантично; структуруйте логічно.
Якщо у списку SEO-завдань 47 пунктів і ви не можете сказати, які 20 важать — у вас проблема зі списком.
Прохід перевірки перед запуском
Пройдіть 20 пунктів по порядку. Для кожного:
- Перевірте, що зроблено правильно.
- Точково перевірте принаймні на трьох сторінках (головна + дві інші).
- Задокументуйте пункти «ми поки що не можемо це зробити» як відомі gaps.
Сайт, що хітить 18 з 20 з двома відомими gaps, у кращому стані за сайт, що заявляє 20 з 20 без перевірки. Чесність має значення.
Якщо хочете маркетинговий сайт, побудований з усіма 20 від першого дня, подивіться, як ми працюємо.