Виправлення помилок hreflang у багатомовному WordPress (та відновлення мовного таргетингу Google)

Що hreflang насправді робить (і чого не робить)

hreflang — це не хитрий прийом для підвищення ранжування. Це не чарівний «вмикач, щоб ранжуватись у Німеччині». Це сигнал розрізнення, який каже Google: «Ці URL — еквівалентні сторінки різними мовами або регіональними варіантами. Будь ласка, показуйте відповідну сторінку відповідному користувачу.»

В операційному плані: hreflang — це таблиця маршрутизації для результатів пошуку. Якщо таблиця маршрутизації непослідовна, пакети все одно йдуть — просто не туди, куди треба.

На що впливає hreflang

• Таргетинг мови/регіону в результатах пошуку: допомагає Google вибрати правильний варіант.
• Обробка дубльованого контенту між локалями: зменшує ймовірність, що переклади вважатимуться дублями, які конкурують між собою.
• Гігієна індексу: допомагає згрупувати варіанти у чистий набір.

Чого hreflang не робить

• Не замінює якість перекладу. Машинний неякісний контент все одно поводиться як машинний неякісний контент.
• Не переважає canonical. Canonical — сильніший сигнал консолідації; якщо canonical конфліктує з hreflang, Google зазвичай слідує canonical і ігнорує hreflang.
• Не виправляє проблеми геолокації/IP. Якщо сервер робить редирект на основі IP або Accept-Language без стабільних URL, hreflang вас не врятує.

Опінійне зауваження: якщо ви робите багатомовний сайт, вам потрібні стабільні, індексовані URL для кожної локалі. Якщо цього немає, перестаньте гратися з тегами і спочатку перерахуйте стратегію URL.

Цитата, варта вашого робочого столу, бо вона болісно підходить до SEO-сигналів:

John Allspaw (парафразована ідея): «Надійність походить від проєктування систем, які очікують відмов — і коректно з ними працюють.»

hreflang — це інженерія надійності для таргетингу пошуку. Ви проектуєте під режим відмов, коли Google заплутається — бо Google таки заплутається.

Цікавинки та історичний контекст

Трохи контексту допомагає, бо проблеми з hreflang рідко бувають «просто баг плагіна». Вони зазвичай — зіткнення старих веб-рішень із сучасною поведінкою індексації.

1. hreflang з’явився раніше за більшість WordPress плагінів для мультимовності. Він набув популярності на початку 2010-х, коли глобальні сайти зрозуміли, що лише canonical не впорається з мовними варіантами.
2. Спочатку Google та інші пошукові системи впроваджували hreflang по-різному. Та спадщина пояснює, чому ви ще бачите дивні «працює для Bing, не працює для Google» звіти.
3. «x-default» було введено як аварійний вихід. Воно призначене для загальної сторінки вибору або fallback, а не як смітник «я не знаю».
4. hreflang — підказка, а не директива. Навіть ідеальний набор сигналів Google може віддати перевагу іншому URL, якщо інші сигнали (canonicalи, внутрішні посилання, sitemapи, редиректи) суперечать.
5. Повертальні теги на практиці обов’язкові. Спеку можна читати вільно, але Google очікує взаємного зв’язування між альтернативами (A вказує на B, B повертає посилання на A).
6. Коди локалей суворі. «en-UK» — неправильно; правильно «en-GB». Ці крихітні помилки викликають непропорційну плутанину.
7. XML-карти сайтів теж можуть містити hreflang. Це корисно, коли HTML кешований чи шаблонізований непослідовно, але це додає ще одне місце для помилок.
8. WordPress історично не був створений для багатомовних URL. Multisite, директорії локалей та плагіни для перекладів усе «допилюють» до ядра, яке припускає один сайт = одна мова.

Швидкий план діагностики

Якщо ви відповідаєте за ліквідацію SEO-пожеж (вітаю, ви приєдналися до особливого клубу), вам потрібен короткий шлях до істини. Ось найшвидший спосіб знайти вузьке місце, не читаючи 40 сторінок інтерфейсу Search Console.

По-перше: визначте, чи Google бачить неправильний HTML

• Отримайте HTML сторінки як клієнт-павук і перевірте теги hreflang.
• Порівняйте HTML, що подається з куками та без них, а також з різними заголовками Accept-Language.
• Перевірте, чи кеші не віддають невідповідну локаль (заголовки Vary, правила CDN, ключі повно-сторінкового кешу).

По-друге: перевірте canonical і редиректи («сильні» сигнали)

• Підтвердіть, що кожен URL локалі має self-canonical (або canonical на правильний URL локалі) послідовно.
• Перевірте, що немає ланцюгів редиректів, які об’єднують локалі назад в один URL.
• Переконайтеся, що нормалізація слешів і параметрів запиту не створює дублів без відповідних hreflang.

По-третє: підтвердьте взаємність і повноту

• Для кожного мовного варіанту: всі альтернативи присутні, коди правильні, абсолютні URL коректні.
• Кожна альтернатива повертає посилання назад (return tags).
• x-default існує лише коли у вас є справжній досвід за замовчуванням.

По-четверте: зіставте sitemap і HTML

• Якщо ви використовуєте hreflang у sitemap, переконайтеся, що він точно збігається з HTML.
• Виберіть кілька репрезентативних URL; не намагайтеся переглянути 10 000 рядків очима.

По-п’яте: підтвердьте поведінку кластеризації Google

• Шукайте симптоми «Duplicate, Google chose different canonical than user».
• Точково перевірте результати індексації по локалях. Чи правильно індексуються сторінки? Чи вони згортаються в один?

Жарт №1: налагодження hreflang — як DNS — зрештою ви виявите, що це було не «Google», а ви, шість тижнів тому, після одного пива.

Режими відмов: як hreflang ламається у WordPress

1) Плагін генерує hreflang, тема також генерує hreflang

Це класична проблема «два джерела істини». Ви отримуєте дубльовані link rel="alternate" теги, іноді з різними URL. Google не вибирає ввічливо кращий; він вважає набір ненадійним.

Що робити: оберіть рівно одного генератора: WPML/Polylang/MultilingualPress/ваш кастомний SEO-плагін. Вимкніть усі інші точки інжекції hreflang (тему, кастомні функції, модулі SEO-плагіна).

2) Canonical вказує на неправильну локаль

Якщо ваша англійська сторінка має canonical на домашню сторінку за замовчуванням, ви дали Google сигнал «це одне, консолідуйте». hreflang намагається сказати «це різні варіанти». Зазвичай перемагає canonical.

3) Автоматичні редиректи на основі мови браузера

Редиректи за мовою браузера здаються «зручними для користувача», поки ви не зрозумієте, що вони блокують краулінг, ламають стабільні URL і змушують Googlebot бачити різний контент в залежності від заголовків. Якщо це необхідно, робіть це делікатно (банер/пропозиція) і зберігайте доступність URL локалі.

4) Ключі кешу не враховують локаль

Повно-сторінкові кеші та CDN часто кешують лише за URL. Якщо вибір мови базується на cookie або заголовку, ви можете віддавати німецький HTML на англійському URL — разом з німецькими hreflang тегами. Це не «багатомовність». Це рулетка.

5) Невідповідність слешів та нормалізації URL

Якщо hreflang вказує на /fr/page, але canonical — /fr/page/, ви штучно створюєте дублікати. Те ж стосується http/https, www/non-www, верхнього/нижнього регістру та параметрів запиту як трекінг-теги.

6) Відсутні повернені теги з однієї локалі

Типова ситуація: англійська сторінка містить альтернативи для всіх мов, але одна перекладена сторінка зовсім не має альтернатив (перевизначення шаблону, noindex або контент створено іншим типом поста). Це руйнує кластер.

7) Неправильні коди мова-регіон

«en-UK» — найпоширеніша помилка. Також «es-LA» (невалідний регіон) і «cn» (China — «CN», мова — «zh»). Google не виправить ваше домашнє завдання.

8) Ви змішуєте моделі перекладу

Директорії локалей (/en/, /fr/) плюс окремі домени плюс параметри. Не робіть цього. Оберіть одну модель і реалізуйте її чисто, бо кожен гібрид перетворюється на кар’єру налагоджувача.

Практичні завдання: команди, результати та рішення (12+)

Це базові перевірки, які ви можете виконати з терміналу. Вони не замінять Search Console, але скажуть, що ваші сервери реально віддають. Кожне завдання включає: команду, приклад виводу, що це значить і яке рішення прийняти.

Завдання 1: Отримати HTML і витягти теги hreflang

cr0x@server:~$ curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/en/product/widget/ | grep -i 'rel="alternate"'
<link rel="alternate" hreflang="en" href="https://example.com/en/product/widget/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/widget/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt/widget/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/product/widget/" />

Що це значить: hreflang присутній в HTML цієї сторінки. Хороший початок.

Рішення: Якщо теги відсутні або явно невірні — виправляйте генерацію на джерелі (плагін/тема). Якщо вони виглядають правильно, переходьте до перевірки взаємності та canonical.

Завдання 2: Перевірити canonical на кожній локалі

cr0x@server:~$ curl -sS https://example.com/fr/produit/widget/ | grep -i 'rel="canonical"'
<link rel="canonical" href="https://example.com/en/product/widget/" />

Що це значить: Французька сторінка має canonical на англійську. Це каже Google консолідувати французьку в англійську.

Рішення: Виправте canonical, щоб він був самопосилальним для локалі (або вказував на правильний URL локалі). Потім перевірте hreflang вдруге.

Завдання 3: Перевірити поведінку редиректів (чи не згортаються локалі?)

cr0x@server:~$ curl -sS -I https://example.com/de/produkt/widget/ | sed -n '1,10p'
HTTP/2 301
date: Sat, 27 Dec 2025 10:11:12 GMT
location: https://example.com/en/product/widget/
cache-control: max-age=3600

Що це значить: Німецький URL редиректить на англійську. hreflang не зможе працювати, якщо ціль не залишається на місці.

Рішення: Приберіть або звужуйте редиректи. Кожен URL локалі має повертати 200 з відповідним локалізованим контентом.

Завдання 4: Виявити проблеми з перемиканням мови на основі cookie

cr0x@server:~$ curl -sS -I https://example.com/product/widget/ | grep -i 'set-cookie'
set-cookie: pll_language=fr; path=/; secure; HttpOnly

Що це значить: «За замовчуванням» URL встановлює cookie мови. Це може бути нормально, але це червоний прапорець для кешування та консистентності ботів.

Рішення: Забезпечте, щоб боти отримували послідовні hreflang і canonical теги, і щоб кешування правильно різнилось (або уникайте cookie-базованої локалі на спільних URL).

Завдання 5: Порівняти вивід при різних Accept-Language заголовках

cr0x@server:~$ curl -sS -H "Accept-Language: de-DE,de;q=0.9" https://example.com/en/product/widget/ | grep -i 'html lang=' | head -n 1
<html lang="de-DE">

Що це значить: Ви запросили /en/, але отримали німецький HTML. Це серйозна помилка: URL і мова не повинні суперечити.

Рішення: Вимкніть перемикання по заголовках для URL локалей; залиште це для сторінки селектора або лише для кореневого URL з правильним x-default.

Завдання 6: Перевірити заголовок Vary (коректність кешу)

cr0x@server:~$ curl -sS -I https://example.com/en/product/widget/ | grep -i '^vary:'
Vary: Accept-Encoding

Що це значить: Кеш не варіюється за cookie чи Accept-Language. Якщо сайт змінює мову залежно від одного з них, ваш кеш може змішувати мови.

Рішення: Або припиніть змінювати контент по cookie/заголовку для одного й того ж URL, або додайте коректну поведінку Vary та сегментацію кешу (часто складно з CDN).

Завдання 7: Підтвердити, що sitemap містить очікувані URL локалей

cr0x@server:~$ curl -sS https://example.com/sitemap_index.xml | grep -Eo '<loc>[^<]+' | head
<loc>https://example.com/page-sitemap.xml
<loc>https://example.com/product-sitemap.xml
<loc>https://example.com/fr/page-sitemap.xml
<loc>https://example.com/de/page-sitemap.xml

Що це значить: У вас є sitemap для кожної локалі (добре). Тепер перевірте, чи вони містять правильні URL і розширення hreflang, якщо використовується.

Рішення: Якщо sitemap не містить URL локалей — виправте конфіг SEO-плагіна; не покладайтеся на автоматичне виявлення.

Завдання 8: Витягти hreflang з sitemap (якщо є)

cr0x@server:~$ curl -sS https://example.com/product-sitemap.xml | grep -i 'xhtml:link' | head -n 6
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/product/widget/" />
<xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/widget/" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/produkt/widget/" />

Що це значить: hreflang на рівні sitemap існує. Чудово — якщо він не суперечить HTML.

Рішення: Зробіть HTML і sitemap однаковими. Оберіть одне авторитетне джерело мапінгу URL (зазвичай плагін перекладу) і генеруйте обидва виходи з нього.

Завдання 9: Перевірити наявність кількох генераторів hreflang (дубльовані теги)

cr0x@server:~$ curl -sS https://example.com/en/product/widget/ | grep -ic 'rel="alternate"'
12

Що це значить: Дванадцять alternate тегів — підозріло, якщо тільки у вас не справді багато варіантів. Часто це дубльовані блоки.

Рішення: Подивіться секцію head і ідентифікуйте, який компонент емулює кожен набір. Вимкніть зайвий емiтер.

Завдання 10: Переконатися, що всі альтернативи повертають статус 200

cr0x@server:~$ for u in \
https://example.com/en/product/widget/ \
https://example.com/fr/produit/widget/ \
https://example.com/de/produkt/widget/ ; do
  printf "%s " "$u"
  curl -sS -o /dev/null -w "%{http_code}\n" "$u"
done
https://example.com/en/product/widget/ 200
https://example.com/fr/produit/widget/ 200
https://example.com/de/produkt/widget/ 404

Що це значить: Одна альтернатива неіснуюча (404). Це ламає кластер і викликає симптоми «відсутні повернені теги» / «невалідний hreflang».

Рішення: Виправте відсутній URL перекладу або приберіть його з hreflang, поки він не з’явиться. Не рекламуйте мертві кінцеві точки.

Завдання 11: Перевірити вживані коди мова-регіон на сайті

cr0x@server:~$ curl -sS https://example.com/en/product/widget/ | grep -Eo 'hreflang="[^"]+"' | sort -u
hreflang="de-DE"
hreflang="en-UK"
hreflang="fr-FR"
hreflang="x-default"

Що це значить: «en-UK» — невірно. Використовуйте «en-GB». Також вирішіть, чи вам справді потрібні регіональні варіанти; якщо ні — дотримуйтесь простих кодів мови (en, fr, de).

Рішення: Нормалізуйте коди по всьому сайту. У налаштуваннях WordPress плагінів це зазвичай опція для кожної мови.

Завдання 12: Швидко виявити невідповідність canonical/hreflang

cr0x@server:~$ curl -sS https://example.com/fr/produit/widget/ | awk 'BEGIN{IGNORECASE=1} /rel="canonical"/{print} /rel="alternate"/{print}'
<link rel="canonical" href="https://example.com/en/product/widget/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/produit/widget/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/widget/" />

Що це значить: Сторінка стверджує, що вона французька, але canonical каже «вважай мене англійським». Це конфлікт.

Рішення: Виправте правила canonical. Для багатомовних сторінок безпечно мати self-canonical для кожної локалі.

Завдання 13: Переконатися, що директиви robots не блокують локаль

cr0x@server:~$ curl -sS https://example.com/de/produkt/widget/ | grep -i 'meta name="robots"' || echo "no meta robots tag found"
<meta name="robots" content="noindex,follow" />

Що це значить: Ви говорите Google не індексувати німецьку сторінку. hreflang не покаже сторінку, яка не індексується.

Рішення: Приберіть випадковий noindex з продакшен-локалей; залишайте noindex для стейджингу.

Завдання 14: Перевірити robots.txt — чи не блокує він шляхи локалей

cr0x@server:~$ curl -sS https://example.com/robots.txt | sed -n '1,120p'
User-agent: *
Disallow: /wp-admin/
Disallow: /de/
Sitemap: https://example.com/sitemap_index.xml

Що це значить: /de/ заблоковано. Це автогол.

Рішення: Приберіть заборону для продакшен-локалей. Повторне сканування займе час, але потрібно спочатку припинити блокування.

Завдання 15: Знайти змішані хости (www vs non-www) в альтернативах

cr0x@server:~$ curl -sS https://example.com/en/product/widget/ | grep -i 'hreflang' | grep -Eo 'https?://[^"]+' | sort -u
https://example.com/en/product/widget/
https://www.example.com/fr/produit/widget/

Що це значить: Альтернативи змішують хости. Це створює дубльовану ідентичність URL і робить кластери непередбачуваними.

Рішення: Нормалізуйте налаштування site URL у WordPress і застосуйте редиректи, щоб hreflang завжди використовував канонічний хост.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: в результатах пошуку багато користувачів бачать сторінки не тією мовою

Корінна причина: Canonical вказує на одну «первинну» мову, згортаючи всі локалі. Або редиректи примушують користувачів до однієї локалі.

Виправлення: Self-canonical для кожної локалі. Приберіть редиректи, що згортають локалі. Переконайтеся, що кожен URL локалі повертає 200 і індексується.

2) Симптом: Search Console показує «No return tags»

Корінна причина: Одна або кілька альтернатив не посилаються назад (відсутній шаблон тегів, 404 або noindex). Іноді ламаються лише певні типи постів.

Виправлення: Переконайтеся, що мапінг перекладів повний. Переконайтеся, що кожний варіант локалі емулює повний набір альтернатив, включаючи себе.

3) Симптом: «Unknown language code» або «invalid hreflang»

Корінна причина: Невірні ISO коди («en-UK»), вигадані регіони («es-LA») або використання підкреслень («en_US» замість дефісу).

Виправлення: Нормалізуйте до валідних BCP 47 тегів, які використовує Google: мова-регіон з дефісом, регіон великими літерами (en-GB), або лише мова (en).

4) Симптом: hreflang теги є, але Google їх ігнорує

Корінна причина: Конфліктуючі «сильні» сигнали: невідповідність canonical, непослідовні внутрішні посилання, змішані хости або розбіжність sitemap і HTML.

Виправлення: Узгодьте canonical + hreflang + внутрішні посилання + sitemap. Google довіряє послідовності більше, ніж будь-якому окремому тегу.

5) Симптом: одна локаль індексується нормально; інші ледь індексуються

Корінна причина: robots.txt disallow, meta noindex або серверні блокування (правила WAF), які застосовуються лише до певних шляхів.

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

6) Симптом: альтернативи ведуть у ланцюги 301/302

Корінна причина: Плагін емулює неканонічні URL (http vs https, відсутній слеш) або CDN накладає редиректи пізніше.

Виправлення: Зробіть hreflang URL кінцевими (200). Виправте налаштування WordPress «Site URL», правила посилань та будь-які редирект-правила на краю.

7) Симптом: користувачі відмовляються, бо їх кидає в неправильну локаль після кліку

Корінна причина: Редирект на основі мови браузера спрацьовує після переходу з пошуку, відправляючи користувачів кудись ще (іноді на головну). Це ламає наміри та аналітику.

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

8) Симптом: багато попереджень «Duplicate, Google chose different canonical than user»

Корінна причина: Схожі сторінки між локалями з некоректними canonical, або ідентичний контент у «перекладах» (ледачі копії), через що Google консолідує.

Виправлення: Виправте canonical. Переконайтеся, що переклади справді перекладені. Якщо контент навмисно однаковий між регіонами, подумайте, чи дійсно вам потрібні окремі URL.

Чеклісти / покроковий план

Крок 1: Оберіть і задокументуйте модель URL

• Один домен, директорії: /en/, /fr/ (поширено для WordPress).
• Окремі домени: example.fr, example.de (сильніше розділення, більше операційної роботи).
• Субдомени: fr.example.com (середній варіант).

Робіть: оберіть один і дотримуйтеся його.

Уникайте: змішування директорій, параметрів і окремих доменів «через маркетинг». Маркетинг просить багато чого.

Крок 2: Зробіть canonical нудними

• Кожна сторінка локалі зазвичай має мати self-referential canonical.
• Якщо у вас є регіональні варіанти, які є фактичними дублями, canonical може їх консолідувати — але тоді hreflang має відповідати цій логіці уважно.

Крок 3: Генеруйте hreflang з одного авторитетного мапінгу

• Мапінг плагіна перекладів (ID постів, пов’язані між мовами) — звичайне джерело правди.
• Не редагуйте hreflang вручну для продакшен-сторінок, якщо не любите постійну виснажливу роботу.

Крок 4: Забезпечте консистентність на краю мережі

• Примусіть https і один хост (www або без).
• Нормалізуйте слеші відповідно до налаштувань пермалінків WordPress.
• Переконайтеся, що hreflang використовує нормалізовані URL.

Крок 5: Запобігайте «отруєнню» кешу між мовами

• Якщо локаль змінюється за шляхом URL — кешування простіше.
• Якщо локаль змінюється за cookie/заголовком — ви повинні правильно варіювати ключі кешу, інакше віддаватимете змішаний контент на той самий URL.

Крок 6: Перевірте взаємність на вибірці

• Виберіть 20 URL по шаблонах: головна, категорія, продукт, пост у блозі, лендинг.
• Для кожного переконайтесь: альтернативи повні, повернені теги присутні, цілі — 200, canonical — адекватні.

Крок 7: Визначте, як використовувати x-default

• Використовуйте x-default, коли є селектор мови або загальна посадкова сторінка, не прив’язана до локалі.
• Не використовуйте x-default як «англійська сторінка», якщо лише англійська не є вашим глобальним досвідом за замовчуванням.

Жарт №2: x-default — це не сміттєве відро. Якщо ви так з ним вчиняєте, Google перерахує ваш трафік кудись ще.

Крок 8: Впроваджуйте зміни обережно

• Міняйте по одній речі за раз: спочатку логіку canonical, потім hreflang, потім sitemap-и.
• Після деплою очищуйте кеші (апп-кеш, object cache якщо є, CDN).
• Перед святкуванням перепровірте тестовий набір командами, які вказані вище.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Вони припустили, що Google «сам розбереться». Компанія мала багатомовний WordPress: англійська, французька, німецька. Зовнішньо все виглядало досить чисто. Користувачі могли перемикатися мовами. Дашборд керівництва показував міжнародний трафік. Всі заспокоїлися.

Потім регіональна команда поскаржилась, що німецький пошуковий трафік різко впав. SEO-команда подивилась Search Console і побачила болото: німецькі сторінки були в індексі, але вони з’являлися для англійських запитів, а англійські сторінки ранжувалися в Німеччині. hreflang був присутній, тож припущення було: «hreflang працює».

Ні, не працював. Canonical на кожній перекладеній сторінці вказував на англійський оригінал, бо хтось налаштував SEO-плагін на «canonicalize translations to original». Це звучить акуратно. Але це катастрофа, якщо ваша мета — мовний таргетинг. Google зробив саме те, що йому сказали: консолідував сигнали в англійську, а іноді показував німецьку сторінку тому, що контент був релевантний.

Виправлення було негероїчним: зробити canonical самопосилальним, регенерувати hreflang з мапінгу перекладів, очистити кеші і повторно відправити sitemap-и. Ранжування стабілізувалося протягом тижнів. Не миттєво — бо системи індексації розподілені і доволі терплячі у найгіршому сенсі.

Урок: якщо canonical і hreflang суперечать — зазвичай перемагає canonical. Не «припускайте, що Google зрозуміє». Google — машина, що винагороджує послідовність, а не оптимізм.

Міні-історія 2: Оптимізація, що відкотилася

Інша організація хотіла швидше глобальне завантаження. Вони поставили CDN перед WordPress і ввімкнули «cache everything». Час до першого байта одразу покращився. Усі були задоволені. Потім служба підтримки почала отримувати дивні скарги: користувачі в Іспанії бачили німецькі сторінки. Німці бачили англійські рядки інтерфейсу. Брендинг здавався «випадковим».

Сайт використовував cookie для збереження мовних налаштувань. CDN кешував HTML лише за URL. Тож перший відвідувач на /product/widget/ німецькою ініціював кеш з німецьким HTML. Наступний відвідувач — незалежно від мови — отримував ту кешовану сторінку. З німецьким hreflang. На англійському URL.

Пошукові роботи краулювали змішані версії в залежності від таймінгу. Деякі сторінки виявились індексованими не тією мовою, і кластери hreflang стали непослідовними. Search Console показувала помилки return tag і «alternate page with proper canonical» непослідовно. Нічого не сходилось, бо система перестала бути детермінованою.

Оптимізацію відкотили: кеш налаштували варіювати по cookie для невеликого набору URL, де cookie-локаль існувала, і для решти перейшли на path-based локалі. Продуктивність залишилась хорошою, а випадковість зникла.

Урок: кешування — підсилювач. Якщо ваш вибір мови не є частиною ключа кешу, ви не маєте багатомовності — у вас мовна лотерея.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна команда підприємства зробила річ, що виглядала мучительно повільною на зустрічі: вони написали односторінковий «Контракт URL локалі». Він документував дозволені коди мов, шаблони URL, правила canonical і хто відповідає за генерацію hreflang. Там також був маленький тестовий скрипт у CI, що підтягував 10 репрезентативних сторінок на локаль і перевіряв: статус 200, self-canonical, наявність усіх альтернатив і відсутність змішаних хостів.

Черези кілька місяців оновлення теми змінило header-шаблон і видалило хук плагіна, що інжектував hreflang теги — але тільки для кастомного типу поста, що використовувався кампаніями. Команді кампаній хотілося запустити мультимовний набір лендингів без hreflang і з несумісними canonical, прямо у платний трафік і органіку.

CI-перевірка виявила проблему того ж дня. Реліз був заблокований. Люди бурчали, бо блокувати релізи нелюбимо, поки воно не зберігає вас від пояснень лідерству про втрату доходу. Виправлення було невеликим патчем теми: відновити хук, підтвердити вивід, відправити.

Урок: нудні перевірки запобігають дорогим драмам. hreflang — не разова настройка; це контракт, який треба підтримувати.

Як думати про hreflang у WordPress: архітектурні рішення, що зменшують біль

Директорії локалей — найменш операційно несподівані

Для WordPress шляхові локалі (/en/, /fr/) зазвичай — найкращий вибір: просте кешування, чітке розділення та менше проблем з крос-доменами. Окремі домени теж підходять, але важчі в операційному сенсі: сертифікати, редиректи, властивості Search Console і більше місць для помилок конфігурації.

Одна система мапінгу перекладів, одна SEO-система, одна стратегія кешу

Якщо взяти щось одне з цього тексту: уникайте перекриття відповідальностей. WPML/Polylang підтримують зв’язки перекладів. SEO-плагін може виводити canonical і sitemap-и. Ваша тема може виводити мета-теги. CDN може переписувати заголовки. Якщо два з цих шарів «допомагають» з hreflang, ви отримаєте дублювання або конфлікт.

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

Виявлення мови для людей — це UX-функція. Для ботів це джерело невизначеності. Тримайте стабільні URL локалей. Пропонуйте перемикач. Якщо дуже треба виявляти — робіть це лише на кореневому URL і зберігайте детермінованість локаль-них URL.

Операційна валідація: як виглядає «правильно»

Правильний hreflang-кластер (мінімально життєздатний)

• Кожний URL локалі повертає 200.
• Кожний URL локалі включає rel="alternate" для всіх варіантів локалі, включно з самим собою.
• Кожний URL локалі має canonical, що відповідає бажаному URL для індексації цієї локалі.
• Усі цілі альтернатив є канонічними, остаточними URL (не редиректять, не заблоковані, не мають noindex).
• Коди мова/регіон валідні та послідовні.
• Внутрішні посилання здебільшого ведуть на сторінки тієї ж локалі (не крос-посилання скрізь на англійську).

Коли використовувати лише мову, а коли мову-регіон

Якщо у вас немає суттєвих регіональних відмінностей, не вигадуйте їх. Використовуйте en, fr, de. Регiональні варіанти (en-GB, en-US) потрібні для реальних відмінностей: ціноутворення, юридичні умови, правопис, доставка або справді регіональний контент.

Опінійний погляд: таргетинг за регіоном затратний. Якщо ви не можете сформулювати різницю в одному реченні, ймовірно ви створюєте зайві URL, що конкурують між собою.

Поширені питання

1) Чи потрібен мені hreflang, якщо в мене лише одна мова, але кілька країн?

Якщо контент справді однаковий і ви хочете одну англійську сторінку для всього світу, не створюйте кілька URL для країн. Якщо ж у вас окремі URL (ціни, доставка, юридичні вимоги) — тоді так: hreflang із регіональними варіантами може допомогти.

2) Куди ставити hreflang: в HTML, у sitemap чи в обидва?

Оберіть один метод, якщо немає сильної операційної причини для двох. HTML — прямий і простий для аудиту. Sitemap корисні, якщо HTML складно контролювати або сильно кешований. Якщо робите обидва — вони повинні точно збігатися, інакше виникне роздвоєність сигналів.

3) Які стосунки між hreflang і canonical?

Canonical вказує Google, який URL є бажаним представником для індексації. hreflang каже Google, як обирати між еквівалентами для різних локалей. Якщо canonical згортає варіанти в один URL, hreflang втрачає більшу частину своєї цінності.

4) Чи обов’язковий x-default?

Ні. Це опціонально. Використовуйте його, коли є нейтральна сторінка fallback (наприклад, селектор мови) або коли кореневий досвід не прив’язаний до конкретної локалі. Не застосовуйте x-default «бо так радять». Рекомендації без контексту — джерело інцидентів.

5) Чи можна використовувати hreflang з автоматичними плагінами перекладу?

Технічно так, але не плутайте «перекладено» з «корисно». Google може визнати сторінки низької якості або занадто схожими і консолідувати їх. Hreflang не врятує поганий контент.

6) Чому Search Console показує помилки hreflang, а трафік здається нормальним?

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

7) Чи треба перекладати slug-и, щоб hreflang працював?

Ні. Slug-и можуть залишатися однаковими для всіх локалей. Головне — щоб кожна локаль мала стабільний URL і коректний hreflang-мапінг. Переклад slug-ів може покращити UX і CTR на деяких ринках, але також підвищує ризик помилок при міграції.

8) Скільки часу Google потребує, щоб відобразити виправлення hreflang?

Очікуйте від декількох днів до тижнів залежно від частоти краулінгу і розміру сайту. Ви можете пришвидшити виявлення оновленими sitemap-ами і внутрішніми посиланнями. Не можна змусити миттєву перекластеризацію. Якщо хтось обіцяє миттєве — він продає вам відчуття.

9) Що робити, якщо переклад для сторінки не існує?

Не включайте hreflang-альтернативу для неіснуючої сторінки. Або опустіть ту мову для цього URL, або обережно вкажіть користувачам на підходящий fallback. Фейкові альтернативи створюють помилки return tag і неправильну кластеризацію.

10) Чи робить WordPress multisite hreflang простішим?

Іноді. Multisite може зробити розділення локалей чистішим (окремі сайти для кожної мови), але додає операційної складності (деплої, плагіни, керування користувачами, крос-сайтовий мапінг). «Простіше» залежить від здатності вашої команди це оперувати.

Висновок: наступні кроки, що дійсно рухають показники

Помилки hreflang у багатомовному WordPress рідко — це один зламаний тег. Зазвичай це відмова консистентності через шари: вивід плагіна, логіка canonical, редиректи, кешування і генерація sitemap. Ставтеся до цього як до інциденту в продакшені: встановіть одне джерело правди, усуньте конфліктні сигнали і валідуйте поведінку зовні.

Практичні наступні кроки (робіть у порядку)

1. Оберіть 10 репрезентативних URL по шаблонах і локалях. Запустіть вищезгадані командні перевірки і збережіть вивід.
2. Виправте конфлікти canonical в першу чергу. Якщо canonical неправильний — hreflang ніколи не стане стабільним.
3. Переконайтеся, що кожний URL локалі детермінований: жодних примусових редиректів, жодного перемикання мови на шляхах локалей.
4. Зробіть генерацію hreflang з одного джерела (плагін/модуль), потім очистіть кеші.
5. Нормалізуйте коди і хости (en-GB, не en-UK; тільки https; www vs non-www).
6. Узгодьте sitemap і HTML, якщо публікуєте hreflang в обох місцях.
7. Налаштуйте невелику автоматизовану перевірку (CI або cron), щоб виявляти регресії після оновлень тем/плагінів.

Якщо ви виконаєте ці кроки, Google залишиться Google — повільний, розподілений, іноді загадковий — але ваша система перестане постачати йому суперечливі сигнали. Саме тоді мовний таргетинг почне поводитися як інженерія, а не як фольклор.