Технічне SEO: повний посібник з чого почати — індексація, Core Web Vitals, schema.org, hreflang

Технічне SEO — оптимізація технічної інфраструктури сайту, щоб пошукові роботи могли знайти, просканувати, проіндексувати і коректно ранжувати ваші сторінки. На відміну від контентного SEO (що пише сторінка) і off-page SEO (хто на неї посилається), технічне SEO відповідає за доступність і коректність обробки: чи може Googlebot зайти на сайт, чи правильно інтерпретує canonical, чи бачить мобільну версію, чи завантажується LCP швидше 2.5 секунд. Без міцного технічного фундаменту найкращий контент не отримує трафіку — Google або не індексує його, або не довіряє через повільне завантаження, або індексує дублі замість оригіналу.

Ця стаття — повний посібник по technical SEO для початківців: від crawling/indexing до Core Web Vitals, schema.org і hreflang. Покрокова логіка побудована від фундаменту (чи бачить вас Google) до тонкої оптимізації (rich snippets, international targeting). Якщо ви запускаєте новий сайт — пройдіть всі секції підряд; якщо у вас є існуючий і ви проводите аудит — користуйтеся як чек-лістом.

Що таке технічне SEO і чим відрізняється від інших напрямків

SEO ділиться на три рівні:

Технічне SEO — передумова: без нього content і off-page не працюють. Найкращий гайд про SaaS-аналітику з 50 беклінками не отримає трафіку, якщо canonical вказує на видалену сторінку, або сайт блокується через Disallow: / у robots.txt. Зворотно, ідеальне технічне SEO без контенту і backlinks теж не дає трафіку — це саме фундамент, на якому будується решта.

Розподіл впливу (приблизний, на конкурентних нішах):

• Технічне SEO — 25-30% (легко зіпсувати все)
• Контентне SEO — 35-40% (визначає на які запити взагалі ранжуєтесь)
• Off-page (backlinks) — 30-35% (визначає позицію в межах ніші)
• Brand і поведінкові сигнали — 5-10%

Як працює пошукова система: crawling, indexing, ranking

Google працює у три етапи:

Crawling → Indexing → Ranking
   ↓          ↓          ↓
Знайти    Зберегти   Показати

1. Crawling (сканування). Googlebot обходить інтернет, переходячи по посиланнях. Точки входу: відомі URL з попередніх обходів, sitemap.xml, посилання з інших сайтів. Бот завантажує HTML, рендерить JavaScript (через Chromium), знаходить нові посилання — далі рекурсивно.
2. Indexing (індексація). Google аналізує контент: парсить текст, структуровані дані, мета-теги, виявляє дублі через canonical, визначає мову. Якщо сторінка пройшла фільтри якості — додається в індекс. Якщо містить noindex, або є дублем без canonical — виключається.
3. Ranking (ранжування). Коли користувач робить запит, Google підбирає з індексу релевантні сторінки і ранжує їх за ~200 факторами (релевантність, авторитет, поведінкові сигнали, технічна якість).

Технічне SEO впливає на перші два етапи: доступність для crawling і прийняття в індекс. Якщо технічна частина зламана, content і backlinks не мають значення — Google просто не бачить сторінку.

Crawling: як зробити сайт доступним для роботів

Robots.txt — інструкція для роботів

Файл за адресою https://example.com/robots.txt каже роботам, що можна і не можна сканувати:

User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /search/
Allow: /

User-agent: GPTBot
Disallow: /

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

Базові правила:

• User-agent: * — для всіх ботів. Можна налаштовувати окремо для Googlebot, Bingbot, GPTBot (OpenAI), ClaudeBot (Anthropic).
• Disallow: /path/ — заборонити сканування. Підтримує wildcard * і $.
• Allow: /path/ — явно дозволити (важливо для виключення з широкого Disallow).
• Sitemap: — вказати URL мапи сайту.

Важливе обмеження: robots.txt блокує сканування, але не індексацію. Якщо на заблоковану URL ведуть зовнішні посилання, вона з’явиться в індексі (без сніпета) як «No information available». Для гарантованого виключення — noindex мета-тег.

Перевірка синтаксису — через наш Robots.txt Tester.

Sitemap.xml — карта сайту для Google

Sitemap.xml — XML-файл зі списком URL, які ви хочете проіндексувати. Допомагає Google швидше знаходити нові сторінки і пріоритизувати crawl budget.

Базовий формат:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-05-07</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://example.com/article/seo-guide/</loc>
    <lastmod>2026-05-07</lastmod>
  </url>
</urlset>

Найкращі практики:

• Включайте тільки canonical-URL з 200-статусом, без noindex, без redirect.
• Оновлюйте <lastmod> при реальних змінах контенту — Google використовує це для пріоритизації обходу.
• <changefreq> і <priority> — Google їх в основному ігнорує, але не шкодять.
• Ліміт — 50 000 URL або 50 МБ на один файл. Для більших сайтів — sitemap index, що посилається на десятки sitemap-файлів.
• Окремі sitemap для різних типів контенту: sitemap-posts.xml, sitemap-products.xml, sitemap-images.xml, sitemap-videos.xml — допомагає в діагностиці.
• Подайте sitemap у Google Search Console → Sitemaps. Slow-індексовані сайти отримують прискорення.

Архітектура сайту і внутрішня перелінковка

Глибина сторінки (скільки кліків від home до сторінки) — критичний crawl-фактор. Найкраща практика: усі важливі сторінки на 3 кліки від home (home → category → article). Якщо стаття на 5+ кліках, Googlebot може її не сканувати тижнями.

Принципи:

• Hub-spoke структура. Pillar-сторінка з оглядом теми (hub) → 5-15 spoke-статей з deep-dive. Hub лінкує на всі spoke, spoke лінкують назад на hub і на 2-3 сусідні spoke.
• Breadcrumbs на всіх сторінках з BreadcrumbList schema — дає Google зрозуміти ієрархію + красиві крихти у сніпеті.
• Контекстні внутрішні посилання з тілу статті, не тільки з navigation. Кожна стаття має мати 5-15 internal links на пов’язані матеріали.
• Анкори осмислені, не «click here» — це сигнал релевантності.

Indexing: як гарантувати, що сторінки потрапляють в індекс

Index Coverage report у Google Search Console

Головний звіт для технічного SEO — GSC → Pages. Сторінки розділені на:

• Indexed — у пошуку.
• Not indexed з підкатегоріями:
  • Discovered – currently not indexed — Google знає URL, але не сканував. Часто — низька якість або crawl budget.
  • Crawled – currently not indexed — сканував, але вирішив не індексувати. Контент сприйнятий як низькоякісний або дубль.
  • Page with redirect — 301/302 на іншу URL.
  • Duplicate without user-selected canonical — дубль, Google сам обрав canonical (часто не той, що ви хотіли).
  • Excluded by 'noindex' tag — явно виключено вами.
  • Blocked by robots.txt — заблоковано.
  • Soft 404 — сторінка повертає 200, але виглядає як 404 (немає контенту).

Цільовий показник для здорового сайту: >80% важливих URL у Indexed, <20% у Not indexed.

Noindex meta-тег

Для гарантованого виключення сторінки з індексу:

<meta name="robots" content="noindex, follow">

follow дозволяє Google переходити по посиланнях зі сторінки (передавати link equity далі), noindex — не індексувати саму сторінку. Типове застосування: пагінація (/blog/page/2/), результати фільтрів, тестові сторінки, thank-you-after-purchase.

Canonical-теги — боротьба з дублями

<link rel="canonical" href="https://example.com/page/"> у <head> каже Google, яка URL є основною серед дублів. Без canonical Google може індексувати дубль (наприклад, /page/?utm_source=email) і розпорошувати link equity.

Критичні сценарії:

1. E-commerce фільтри. ?color=red&size=L створює сотні комбінацій URL з тим самим товаром — всі вказують canonical на основну.
2. Параметри трекінгу. ?utm_*, ?fbclid, ?gclid від реклами.
3. HTTP vs HTTPS і www vs non-www. Обираєте одну версію як canonical і ставите 301 з решти.
4. Пагінація. /page/2/ має canonical на /page/2/ (self-referencing), не на першу сторінку.
5. Гостьова публікація. Якщо публікуєте свою статтю на чужому сайті — попросіть canonical на ваш оригінал.

Помилки:

• Canonical на 404 або noindex-сторінку.
• Canonical на іншу мову (треба hreflang, не canonical).
• Кілька canonical-тегів на одній сторінці.
• Canonical на не-індексовану версію URL.

Core Web Vitals: швидкість як ranking-фактор

З 2021 року Core Web Vitals — офіційний ranking-фактор Google. У 2026 без CWV у зеленій зоні неможливо ранжуватися на конкурентних запитах.

Три метрики CWV

INP замінив FID у березні 2024. INP більш суворий: вимірює всі взаємодії (FID — тільки першу), включає час обробки + рендеринг.

Як покращити LCP

LCP-елементом зазвичай є hero-зображення або заголовок above the fold. Кроки:

1. Оптимізувати зображення. WebP/AVIF замість JPEG/PNG. Розмір під реальний viewport (responsive srcset). Lazy load для не-LCP зображень.
2. CDN. Cloudflare, Bunny, Fastly — приближають контент до користувача.
3. Server-side rendering. SPA з client-side rendering = повільний LCP. Next.js, Astro, Hugo — швидкі.
4. Preload критичних ресурсів. <link rel="preload" href="hero.webp" as="image">.
5. TTFB <600мс. Швидкий сервер — фундамент. Hosting на cheapest shared hosting часто дає TTFB 1-2с — і LCP вже не впишеться у 2.5с.
6. Compression. Brotli > gzip. Включається на nginx/Apache рівні.

Як покращити INP

INP — про responsiveness JavaScript:

1. Зменшити JS bundle. Code splitting, tree shaking, lazy load компонентів.
2. Прибрати long tasks. Розбити важкі обчислення на chunks через setTimeout або requestIdleCallback.
3. React/Vue оптимізація. useMemo, React.memo, virtual scrolling для великих списків.
4. Web Workers для важких CPU-задач (графіка, парсинг).
5. Прибрати third-party скрипти. Google Tag Manager не входить у бюджет — він синхронно блокує main thread.

Як покращити CLS

CLS — про візуальну стабільність:

1. Width/height для зображень і відео. Без них браузер не знає розміру і пересуває контент після завантаження.
2. Резервувати простір під рекламу і embeds. min-height на контейнері, навіть якщо реклама не завантажилася.
3. Не вставляти контент над існуючим. Cookie-banner унизу замість зверху, lazy-load nicht над viewport.
4. Web fonts з font-display: optional або swap + preload найважливіших шрифтів.
5. Skeleton screens замість порожньої білої сторінки під час завантаження.

Перевірка CWV: PageSpeed Insights (lab data + real Chrome UX Report) і GSC → Core Web Vitals report.

Mobile-first indexing

З 2019 року Google використовує мобільну версію сайту для ранжування. Якщо у вас десктопна версія багатша за мобільну (більше тексту, більше функцій) — Google все одно дивиться на mobile.

Чек-лист готовності:

1. Сайт проходить Mobile-Friendly Test Google.
2. Контент і структуровані дані ідентичні між desktop і mobile.
3. Зображення мають коректні alt і width/height.
4. Шрифт ≥14px без необхідності зуму.
5. Кнопки і tap-targets ≥48×48px.
6. Viewport meta-тег: <meta name="viewport" content="width=device-width, initial-scale=1">.
7. Без horizontal scroll.
8. Немає блокованих ресурсів (CSS, JS) для мобільного Googlebot.

Сучасний підхід — responsive design (один HTML, адаптивні CSS-стилі). Окремі мобільні домени (m.example.com) — застаріла практика з купою проблем (canonical, hreflang, дублі).

HTTPS і безпека

З 2014 HTTPS — ranking-фактор Google. З 2018 Chrome помічає HTTP-сайти як «Not secure». У 2026 — HTTPS обов’язковий.

Базові вимоги:

1. SSL-сертифікат — Let’s Encrypt безкоштовно, автоматичне оновлення кожні 90 днів.
2. 301 redirect з HTTP → HTTPS усіх URL.
3. HSTS заголовок — Strict-Transport-Security: max-age=31536000; includeSubDomains; preload — браузер змушує HTTPS навіть для першого запиту.
4. Без mixed content — усі ресурси (images, scripts, styles) на HTTPS.
5. TLS 1.2+ — старі версії TLS 1.0/1.1 deprecated.

Перевірка — Mozilla Observatory і SSL Labs Test.

Schema.org структуровані дані

Schema.org — словник для розмітки контенту, що допомагає Google показувати rich snippets (зірки рейтингу, FAQ-блок, ціна, час приготування). Формат — JSON-LD у <script type="application/ld+json"> (рекомендований Google).

Топ-10 найкорисніших типів

1. Article / NewsArticle / BlogPosting — для редакційного контенту, дає рейтинг автора.
2. FAQPage — Q&A блок під сніпетом, +30-50% CTR (як у цій статті).
3. HowTo — кроки у сніпеті (з 2023 показуються тільки на мобільних в окремих категоріях).
4. Product — ціна, рейтинг, наявність для e-commerce.
5. BreadcrumbList — хлібні крихти у сніпеті замість URL.
6. Organization / LocalBusiness — для Knowledge Panel і Google Maps.
7. Recipe — час, інгредієнти, рейтинг для кулінарних сайтів.
8. Event — дата, місце для івентів.
9. VideoObject — для індексації відео в Google Videos.
10. WebSite з Sitelinks Search Box — окрема пошукова форма у сніпеті бренду.

Приклад FAQPage schema

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Що таке технічне SEO?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Оптимізація технічної інфраструктури сайту..."
    }
  }]
}
</script>

Перевірка — Google Rich Results Test і наш Schema Generator.

Hreflang для багатомовних сайтів

Якщо у вас сайт на кількох мовах (наприклад, UK + RU + EN), hreflang каже Google, яку версію показати кожному користувачу. Без hreflang може показатися російська версія українському користувачу або злиття дублів.

Базова структура

У <head> кожної сторінки:

<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/">
<link rel="alternate" hreflang="ru" href="https://example.com/ru/page/">
<link rel="alternate" hreflang="en" href="https://example.com/en/page/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page/">

Критичні правила

1. Реципрокність. Кожна мовна версія має посилатися на всі інші, включно з собою. Якщо UK-сторінка лінкує на RU, але RU не лінкує назад на UK — Google ігнорує hreflang.
2. Абсолютні URL з протоколом https://.
3. Коректні коди. ISO 639-1 для мови (uk, ru, en) + ISO 3166-1 для регіону (en-US, en-GB, pt-BR). НЕ uk-UA за стандартом — uk достатньо, бо мова сама по собі є регіональною. Однак pt-BR (бразильська) і pt-PT (європейська) — критичні розділення.
4. x-default — fallback версія для невідомих мов.
5. Альтернативи розташування: <link> у <head> HTML, HTTP-заголовок Link: (для PDF), або в sitemap.xml.

Перевірка

• Наш Hreflang Generator — створює коректний код.
• GSC → International Targeting → Language report.
• Ahrefs Site Audit — секція Hreflang Issues.

URL-структура

Гарні URL — короткі, описові, без параметрів сесії. Принципи:

• Слова, не ID. /seo/technical-guide/ краще за /p?id=12345.
• Дефіси, не підкреслення. Google трактує seo-guide як 2 слова, seo_guide — як 1.
• lowercase. Уникайте mixed case — створює дублі (case-sensitive на більшості серверів).
• Без stop words. /seo-guide/ краще за /the-seo-guide/.
• Стабільні структури. Зміна URL = втрата ranking. Якщо зміна неминуча — обов’язковий 301 redirect.
• HTTPS обов’язково.
• Trailing slash. Виберіть один варіант (/page/ або /page) і дотримуйтеся послідовно.

Типові помилки технічного SEO

1. Robots.txt блокує весь сайт. Disallow: / після рестейджингу — класична катастрофа. Завжди перевіряйте через GSC → URL Inspection після релізу.
2. Canonical на 404 або іншу мову. Перевірити через Screaming Frog або наш Meta Tag Checker.
3. Sitemap.xml містить redirect-URL або noindex-сторінки. Каже Google «індексуй це» і одразу «не індексуй» — заплутує.
4. Дублі без canonical. Параметри URL, фільтри, sort, mobile/desktop версії — створюють тисячі дублів.
5. Mixed content на HTTPS. Картинки/скрипти з http:// на https:// сторінці — браузер блокує + Google не довіряє.
6. Hreflang без реципрокності. UK→RU без RU→UK — Google ігнорує всі hreflang.
7. Великий JS bundle і відсутність SSR. SPA без server-side rendering = повільний LCP, проблеми з indexing JS-контенту.
8. Відсутність schema.org на критичних сторінках. Втрачаєте rich snippets і CTR.
9. Crawl traps. Календарі-pagination з нескінченними URL /calendar/2099/12/, фасетна навігація без обмежень — з’їдають crawl budget.
10. Soft 404. Сторінка повертає 200, але контент порожній або «Page not found». Google вважає це низькоякісним сигналом.

Інструменти для технічного SEO

Безкоштовні (must-have)

• Google Search Console — головний інструмент. Index coverage, Crawl errors, CWV, Mobile usability, hreflang, Sitemaps, URL Inspection.
• PageSpeed Insights — LCP/INP/CLS і поради з оптимізації.
• Mobile-Friendly Test і Rich Results Test — швидка перевірка одного URL.
• Lighthouse у Chrome DevTools — повний аудит з performance/accessibility/SEO.
• Bing Webmaster Tools — окремий індекс Bing/DuckDuckGo + IndexNow API.

Платні (для великих сайтів)

• Screaming Frog SEO Spider — desktop crawler, $259/рік.
• Ahrefs Site Audit — cloud crawler з трекінгом помилок у часі.
• Semrush Site Audit — альтернатива Ahrefs.
• Sitebulb — desktop crawler з гарними візуалізаціями.

Наші онлайн-інструменти

• Robots.txt Tester — перевірка синтаксису і блокувань.
• Hreflang Generator — генерація коректного коду.
• Meta Tag Checker — швидка перевірка title/description/canonical.
• Schema Generator — JSON-LD для топ типів.
• SERP Preview — як виглядатиме сніпет у Google.

Готовий пошаговий чек-лист — SEO Audit Checklist і Website Launch Checklist.

Чек-лист технічного аудиту

Топ-15 пунктів для першої перевірки нового або існуючого сайту:

• GSC підключений, sitemap поданий.
• Index Coverage — >80% важливих URL у Indexed.
• Robots.txt не блокує важливі розділи.
• Sitemap.xml містить тільки canonical-URL з 200-статусом.
• Canonical-теги на всіх сторінках (self-referencing мінімум).
• HTTPS на всьому сайті без mixed content + 301 з HTTP.
• HSTS заголовок встановлений.
• Mobile-Friendly Test проходить.
• Core Web Vitals у зеленій зоні (LCP <2.5с, INP <200мс, CLS <0.1).
• 404-помилки мінімізовані, redirect-ланцюги <2 хопи.
• Hreflang коректний (для мультимовних) — реципрокний, валідні коди.
• Schema.org на всіх типах сторінок (Article, FAQPage, BreadcrumbList мінімум).
• URL-структура — слова замість ID, дефіси, lowercase.
• Глибина сторінок — важливі контентні сторінки на 3 кліки від home.
• TTFB <600мс, Brotli compression, CDN.

Технічне SEO + аналітика: вимірювати що оптимізували

Технічне SEO без вимірювання = робота наосліп. Підключіть:

• Google Search Console — органічний трафік, позиції, impressions, CWV, indexing.
• Google Analytics 4 — поведінка користувачів на сайті, конверсії, attribution.
• Google Tag Manager — для управління аналітикою без правок коду.
• PageSpeed Insights API + щотижневі снапшоти CWV — трекати регресії після релізів.

Без аналітики ви не побачите, що оновлення сайту зменшило INP на 100мс або що 301 redirect розгубив 30% трафіку.

Пов’язані ресурси на сайті

Глосарій:

• Backlink — зворотне посилання
• Подія (Event) у GA4
• DataLayer і структура даних

Інструменти:

• Robots.txt Tester
• Hreflang Generator
• Meta Tag Checker
• Schema Generator
• SERP Preview

Чек-листи:

• SEO Audit Checklist — повний пошаговий аудит.
• Website Launch Checklist — перед релізом нового сайту.
• GA4 Setup Checklist — налаштування аналітики.

Посібники:

• Google Analytics 4 — повний посібник
• Google Tag Manager — основи

Часті запитання (FAQ)

Що таке технічне SEO простими словами?

Оптимізація технічної інфраструктури сайту, щоб пошукові роботи Google могли знайти, просканувати, проіндексувати і коректно ранжувати ваші сторінки. На відміну від контентного і off-page SEO, technical SEO відповідає за доступність і коректність обробки.

Що перевірити в першу чергу при технічному аудиті?

Топ-10: GSC Index Coverage, robots.txt, sitemap.xml, canonical, HTTPS, Mobile-friendly test, CWV, 404/5xx помилки, hreflang, schema.org. Закриття цих пунктів — мінімальний фундамент.

Що таке Core Web Vitals?

Три метрики Google: LCP (<2.5с — швидкість найбільшого елемента), INP (<200мс — затримка відгуку, замінив FID), CLS (<0.1 — стабільність макету). Офіційний ranking-фактор з 2021.

Як працює robots.txt?

Текстовий файл за https://example.com/robots.txt, що інструктує ботів. Блокує сканування, не індексацію — для виключення з індексу треба noindex meta-тег.

Що таке canonical-тег?

<link rel="canonical" href="https://..."> у <head> каже Google, яка URL основна серед дублів. Критично для e-commerce фільтрів, UTM-параметрів, пагінації.

Як налаштувати hreflang?

Для кожної мовної версії в <head> — посилання на всі інші версії включно з собою (реципрокність), абсолютні URL, валідні коди ISO + x-default fallback.

Що таке mobile-first indexing?

З 2019 Google використовує мобільну версію сайту для ранжування. Сучасний підхід — responsive design з ідентичним контентом між desktop і mobile.

Які типи schema.org найкорисніші?

Article, FAQPage, BreadcrumbList, Product, Organization, HowTo, Recipe, Event, VideoObject, WebSite з Sitelinks Search Box. Формат — JSON-LD.

Скільки сторінок Google може просканувати?

Crawl budget. Для маленьких сайтів (<1000 URL) — не проблема. Для великих (10k+) — критичний параметр. Збільшується через швидкий сервер, відсутність 404, sitemap з lastmod, backlinks.

Які інструменти потрібні?

Безкоштовні must-have: GSC, PageSpeed Insights, Mobile-Friendly Test, Rich Results Test, Lighthouse, Bing Webmaster Tools. Платні: Screaming Frog ($259/рік), Ahrefs Site Audit, Semrush.