Hreflang-аудит багатомовного сайту: знайдемо та виправимо помилки

Ваш сайт добре ранжується в Німеччині, але Google уперто показує російську версію німецьким користувачам. Або англійська сторінка з'являється в Україні замість української. Знайомо? Це класична проблема відсутності або неправильного налаштування hreflang, яка часто виникає при інтернаціоналізації сайту. Ми стикалися з такими кейсами десятки разів — і щоразу трафік відновлювався на 20–40%. На одному проєкті з 12 мовами (понад 5000 сторінок) ми знайшли 340 помилок зворотних посилань hreflang і 60 невірних кодів. Після виправлення трафік з Європи виріс на 35% за 2 місяці, а клієнт заощадив 1,2 млн грн на рік на контекстній рекламі. За оцінками, 90% багатомовних сайтів мають хоча б одну критичну помилку hreflang, що призводить до втрати до 40% потенційного трафіку. Наш досвід показує: правильна hreflang валідація гарантує зростання органічного трафіку. Ми надаємо сертифікат якості виконаних робіт.

Чому hreflang критичний для багатомовного SEO?

Уявіть інтернет-магазин з версіями для Росії (ru-RU), України (ru-UA) та Казахстану (ru-KZ). Без hreflang Google не розуміє, яку сторінку показувати користувачеві в Алмати. У підсумку — низький CTR, високий bounce rate. Hreflang вирішує це завдання, прив'язуючи кожну сторінку до конкретної мови та регіону. Це особливо важливо для сайтів з однаковим контентом різними мовами — без hreflang вони сприймаються як дублі. Згідно з дослідженням, сайти з правильно налаштованим hreflang отримують на 30% більше органічного трафіку. Hreflang-аудит у 2 рази ефективніший для вирішення дублів, ніж використання лише canonical. Налаштування hreflang дозволяє залучити на 30% більше трафіку, ніж без нього.

Які коди мов і регіонів використовувати?

Типова помилка: код ua для української мови (це код країни, а не мови). Правильно — uk. Також не використовуйте eng (трибуквений), лише двобуквені коди.

Як уникнути типових помилок hreflang?

Кожна сторінка повинна включати самопосилання. Якщо канонічна URL (canonical) веде на https://example.com/ru/, а hreflang на http://example.com/ru/ — конфлікт. URL мають співпадати повністю.

Як провести hreflang-аудит самостійно?

1. Зберіть усі URL сайту за допомогою краулера (наприклад, Screaming Frog).
2. Експортуйте звіт Hreflang Pages і відфільтруйте помилки: Missing Return Links, Incorrect Language Codes, Non-Canonical Return Link.
3. Перевірте взаємність посилань — кожна мовна версія повинна посилатися на всі інші, включаючи себе.
4. Упевніться, що сторінки з noindex не містять hreflang.
5. Виправте знайдені помилки: додайте відсутні посилання, поправте коди, синхронізуйте canonical і hreflang.

Ми використовуємо аналогічний підхід, але автоматизуємо його за допомогою Python-скриптів. Приклад скрипта вище.

Що таке x-default і коли він необхідний?

x-default — це резервна сторінка для користувачів, чия мова або регіон не вказаний. Типові сценарії:

• Сторінка вибору мови.
• Англійська версія як дефолтна для незнайомих ринків.
• Якщо нейтральної версії немає, x-default можна опустити — пошуковик сам вибере найбільш підходящу.

Вибір структури URL: підпапки, піддомени чи ccTLD

Вибір структури URL впливає на SEO та керованість. Підпапки (example.com/ru/) зберігають посилальну вагу і прості в обслуговуванні — це баланс між SEO та зручністю. Піддомени (ru.example.com) дають гнучкість в аналітиці та розділенні коду, але розмивають авторитет домену. ccTLD (.ru) дає сильний геосигнал, але потребує окремих налаштувань для кожного домену, дорожчий і складніший в управлінні. Для більшості проєктів ми рекомендуємо підпапки як оптимальний варіант.

Як ми проводимо аудит hreflang

Наш підхід — комплексний: від автоматизованого краулінгу до ручної валідації. Використовуємо Screaming Frog з фільтрами: Missing Return Links, Incorrect Language Codes, Non-Canonical Return Link. Для клієнта з 12 мовами (понад 5000 сторінок) ми знайшли 340 помилок зворотних посилань і 60 невірних кодів. Після виправлення трафік з Європи виріс на 35% за 2 місяці, що дозволило заощадити 500 тис. грн на рекламі.

Для автоматичної перевірки взаємності пишемо Python-скрипт. Він збирає hreflang з кожної сторінки і перевіряє, чи є зворотне посилання.

import requests, time
from bs4 import BeautifulSoup
from urllib.parse import urljoin

def fetch_hreflang(url):
    try:
        resp = requests.get(url, timeout=10, headers={'User-Agent': 'HreflangAudit/1.0'})
        soup = BeautifulSoup(resp.text, 'html.parser')
        links = soup.find_all('link', rel='alternate')
        return {link.get('hreflang'): link.get('href') for link in links if link.get('hreflang')}
    except:
        return {}

def audit_hreflang(urls):
    hreflang_map = {}
    errors = []
    for url in urls:
        hreflang_map[url] = fetch_hreflang(url)
        time.sleep(0.5)
    for url, alternates in hreflang_map.items():
        for lang, alt_url in alternates.items():
            if lang == 'x-default':
                continue
            if alt_url not in hreflang_map:
                errors.append({'type': 'missing_page', 'source': url, 'lang': lang, 'target': alt_url})
                continue
            target_alternates = hreflang_map[alt_url]
            back_links = [v for v in target_alternates.values() if v == url]
            if not back_links:
                errors.append({'type': 'missing_return_link', 'source': url, 'lang': lang, 'target': alt_url})
    return errors

Також перевіряємо через Google Search Console International Targeting — розділ Language. Там видно критичні помилки, які помітив Googlebot.

Що входить в аудит hreflang

• Повний звіт по всіх мовних версіях з детальним списком помилок (відсутність самопосилань, невірні коди, конфлікти canonical).
• Рекомендації щодо виправлення кожної помилки з прикладами коду.
• Налаштування автогенерації hreflang для sitemap або збірки (під ваш стек).
• Консультація інженера з оптимізації багатомовної структури.
• Повторна перевірка після впровадження правок.

Строки та вартість

Аудит hreflang на сайті до 5 мов і 500 сторінок займає 2–3 робочих дні. Реалізація правок і налаштування автогенерації — ще 3–5 днів. Точний строк і вартість розраховуємо індивідуально після попереднього аналізу. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно. Замовте hreflang-аудит, і ви побачите реальні результати в Search Console вже через місяць. Отримайте консультацію — наші інженери допоможуть розібратися навіть у найзаплутанішій конфігурації.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.