Hreflang для міжнародного SEO

Коли сайт працює з кількома мовами чи країнами, однієї перекладеної версії сторінок недостатньо. Пошуковій системі потрібно повідомити, які URL відносяться до однієї групи та для якої аудиторії призначена кожна версія.

Для цього завдання використовують hreflang. Він пов'язує мовні та регіональні варіанти сторінок і допомагає Google вибрати відповідну URL-адресу з урахуванням мови та регіону користувача. При цьому саму мову сторінки Google визначає за її вмістом, а hreflang використовує як сигнал про зв'язок між локалізованими URL.

Що таке hreflang і навіщо він потрібний для міжнародного SEO?

Hreflang використовують на мультимовних та мультирегіональних сайтах, де один матеріал, категорія, товар чи послуга мають кілька локальних версій. Наприклад, інтернет-магазин може мати українську сторінку для України, польську для Польщі та англійську для користувачів з інших країн.

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

Як Google використовує hreflang?

Google розглядає hreflang як зв'язок між альтернативними версіями однієї сторінки. Якщо користувач шукає товар англійською мовою з Великобританії, пошукова система може вибрати URL з en-GB, а для користувача зі США використовувати сторінку з en-US.

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

Коли hreflang дійсно потрібен?

Розмітка потрібна, якщо один проєкт обслуговує кілька мов чи ринків. Типовий випадок – мультимовний сайт, де один і той самий розділ доступний українською, англійською, польською та німецькою мовами.

Hreflang також потрібен, коли мова однакова, а ринки різні. Наприклад, сторінки для США та Великобританії можуть бути написані англійською, але відрізнятися валютою, доставкою, цінами, умовами покупки та локальною семантикою.

Основні сценарії застосування:

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

Hreflang слід ставити між еквівалентними сторінками. Не варто пов'язувати через нього різні послуги, товари чи статті лише тому, що вони присвячені схожій темі.

Коли hreflang не потрібно?

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

Наприклад, російськомовна сторінка послуги та інша стаття українською мовою зі схожим ключовим запитом не утворюють групу hreflang. Для коректного зв'язку сторінки повинні відповідати один одному за змістом та призначенням.

Як писати hreflang правильно?

Щоб зрозуміти, як писати hreflang, достатньо розібрати базовий рядок розмітки. У HTML вона виглядає так:

<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/" />

Такий тег повідомляє пошуковій системі, що вказана URL-адреса є українською альтернативною версією поточної сторінки. У розмітці одночасно використовуються rel, параметр hreflang та адреса сторінки href.

З яких параметрів складається тег hreflang?

Кожен рядок містить три основні елементи. rel="alternate" вказує на альтернативну версію документа, hreflang задає мову або поєднання мови та регіону, а href містить повну адресу відповідної сторінки.

Приклад для кількох локалізацій:

<link rel="alternate" hreflang="uk" href="https://example.com/uk/service/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/service/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/service/" />

Для href краще використовувати абсолютну URL-адресу з протоколом і доменом. Google прямо вимагає повністю кваліфікованих адрес для альтернативних версій.

Що означає rel="alternate"?

Значення alternate показує, що посилання веде на альтернативний варіант поточного документа. У зв'язці з hreflang пошуковик розуміє, що йдеться про мовну або регіональну версію сторінки.

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

Що означає параметр hreflang?

Значення hreflang визначає мову, а за потреби ще й регіон. Наприклад, hreflang="en" означає англійську мову незалежно від країни, а hreflang="en-GB" уточнює, що сторінка призначена для англомовної аудиторії Великобританії.

Першим завжди йде код мови. Код країни можна додати другим через дефіс, але використовувати країну без мови не можна. Google підтримує мовні коди ISO 639-1 та регіональні коди ISO 3166-1 Alpha-2.

Що вказується у href?

У href записують абсолютну URL-адресу відповідної мовної або регіональної версії. Краще вказувати кінцеву адресу, яка відразу відповідає кодом 200 і не проходить через ланцюжок редиректів.

Наприклад:

href="https://example.com/en/catalog/"

Варіант /en/catalog/ для hreflang використовувати не слід. Повна адреса спрощує обробку розмітки та виключає неоднозначність під час роботи з кількома доменами.

Як вказувати мову та країну у hreflang?

При базовій локалізації достатньо вказати мову. Якщо в одній мовній версії є кілька різних ринків, до мови можна додати регіон.

Такий підхід є особливо корисним для країн, де використовується одна мова, але різняться ціни, валюта, асортимент, контакти або правила доставки.

Коди мов ISO 639-1

Для мови використовують дволітерний код стандарту ISO 639-1. Для української версії потрібен uk, для англійської – en, для польської – pl, для німецької – de.

Часта помилка українських сайтів – значення ua. UA є кодом країни, а код української мови у hreflang – uk.

Коди регіонів ISO 3166-1 Alpha-2

Якщо сторінку потрібно зв'язати із конкретним ринком, після мови додають код регіону. Наприклад, en-US належить до англійської мови для США, а en-GB – до англійської версії для Великобританії.

Код регіону пишуть після мови через дефіс. Самостійне значення типу US, GB або UA не відповідає формату hreflang.

Чи потрібно завжди вказувати регіон?

Ні, у багатьох випадках досить загального мовного коду. Якщо англійська сторінка підходить користувачам з різних країн, значення en буде більш логічним, ніж прив'язка до одного ринку.

За наявності кількох регіональних версій можна додати спільну сторінку для інших користувачів цієї мови. Наприклад, разом з en-US, en-GB та en-CA може використовуватися варіант en без прив'язки до країни. Google рекомендує такий підхід для географічно невказаної аудиторії однієї мови.

Що таке x-default у hreflang?

x-default задає резервну URL-адресу для користувачів, яким не підходить жодна з явно вказаних мовних або регіональних версій. Найчастіше його ставлять на глобальну головну сторінку або сторінку вибору країни та мови.

Приклад:

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

Таку URL-адресу можна використовувати як fallback, якщо сайт не має локалізації для мови користувача. Google рекомендує x-default для подібних сценаріїв, але не вимагає додавати його до кожної групи hreflang.

Коли використовувати x-default?

Практичний варіант – міжнародний магазин з українською, польською, німецькою та англійською версіями. Користувач із мовою, для якої окремої сторінки немає, може потрапляти на спільний міжнародний розділ або екран вибору країни.

x-default також підходить для глобальної головної сторінки, де відвідувач самостійно обирає регіон. Його не слід сприймати як заміну загальної мовної версії, якщо така сторінка вже передбачена структурою сайту.

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

Google підтримує три способи передачі інформації про альтернативні сторінки: HTML, HTTP headers та XML Sitemap. З погляду пошукової системи ці методи рівнозначні, тому дублювати одну групу одночасно у всіх трьох місцях задля посилення сигналу не потрібно.

Вибір залежить від архітектури проєкту. Звичайному корпоративному сайту часто підходить HTML, для PDF зручніше HTTP headers, а великому магазину з десятками тисяч локалізованих URL може бути простіше керувати групами через sitemap.

Hreflang у HTML-коді сторінки

Теги додають всередину коректного <head>. Кожна версія сторінки повинна містити весь набір альтернатив, включаючи посилання на себе.

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

Якщо таких мов багато, то обсяг блоку помітно збільшується. Тому на великих проєктах іноді зручніше зберігати зв'язки централізовано у XML Sitemap.

Hreflang через HTTP headers

HTTP-заголовки підходять для документів, які не мають HTML <head>. Типовий приклад – PDF-файл, опублікований у кількох мовних версіях.

Приклад:

Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/de/file.pdf>; rel="alternate"; hreflang="de"

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

Hreflang у XML Sitemap

На великих сайтах альтернативні URL-адреси можна вказати в XML Sitemap. Для кожної основної адреси всередині <url> додають xhtml:link із усіма версіями.

<url>
  <loc>https://example.com/en/service/</loc>
  <xhtml:link rel="alternate"
              hreflang="en"
              href="https://example.com/en/service/" />
  <xhtml:link rel="alternate"
              hreflang="uk"
              href="https://example.com/uk/service/" />
</url>

Такий варіант зручний, коли генерація карти сайту вже пов'язана з базою сторінок та локалізацій. Головне – оновлювати sitemap разом із URL, інакше після міграції чи видалення сторінок у ній залишаться старі зв'язки.

Який спосіб реалізації hreflang вибрати?

Для стандартного сайту простіше розпочати з HTML. Якщо проєкт містить велику кількість мов або мільйони URL-адрес, XML Sitemap може знизити обсяг технічної розмітки всередині кожної сторінки.

Одночасно впроваджувати усі три методи без технічної потреби не варто. Чим більше джерел генерують hreflang, тим вищий ризик, що після оновлення сайту вони почнуть розходитися.

Які правила hreflang не можна порушувати?

Робоча розмітка будується як ціла група, а не окреме посилання з однієї сторінки на іншу. Для кожної локалізації потрібно перевірити власне посилання, зворотні зв'язки, доступність URL та відсутність суперечностей з іншими SEO-тегами.

На практиці більшість помилок з'являється після міграцій, змін структури чи запуску нової мови. Тому hreflang варто перевіряти одночасно з canonical, HTTP status та індексованістю сторінок.

Кожна сторінка має посилатися сама на себе

Українська сторінка повинна містити hreflang="uk" зі своєю адресою, англійська – hreflang="en" зі своєю адресою. При цьому кожна з них також перераховує інші версії групи.

Google прямо вказує, що мовна версія має перераховувати саму себе та інші альтернативи. Такий self-referencing hreflang допомагає зберегти однозначну структуру групи.

Hreflang має бути взаємним

Якщо українська URL містить посилання на англійську, англійська URL має посилатися назад на українську. Такі зворотні посилання часто називають return links або reciprocal links.

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

Графічна схема групи:

Українська версія ←→ Англійська версія
        ↕                   ↕
        └────→ Польська ←───┘

Кожна сторінка бере участь в одній групі та містить власну URL-адресу. При додаванні нової локалізації зв'язки потрібно оновити на всіх відповідних сторінках.

Усі hreflang повинні вести на робочі індексовані URL

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

При аудиті групи перевіряють HTTP 200, meta robots, доступність для Googlebot, кінцевий URL та відсутність зайвих перенаправлень. Додатково варто перевірити, чи відповідає вміст сторінки заявленій мові.

Як hreflang повинен працювати разом з canonical?

Canonical та hreflang виконують різні завдання. Canonical допомагає визначити кращий URL серед дублів, а hreflang пов'язує локалізовані варіанти, які мають залишатися доступними у пошуку.

Для повноцінної української, англійської та польської версій зазвичай використовують self-canonical на кожній сторінці. Помилка виникає, коли всі локалізації canonical-посиланням відправляють на одну мовну сторінку, хоча мають індексуватися окремо.

Провідний SEO-спеціаліст — Геннадій

Я перевіряю hreflang як групу пов'язаних URL, а не як окремий тег у вихідному коді. Найчастіше синтаксис написаний правильно, але одна версія відсутня, зворотне посилання втрачено після міграції або canonical вказує на іншу мову. Тому при аудиті я завжди дивлюся одночасно hreflang, canonical, HTTP-коди, індексованість та відповідність сторінок один одному.

Hreflang та структура міжнародного сайту

Розмітка не вимагає єдиного формату URL-адреси. Мовні версії можуть перебувати в підпапках, піддоменах або окремих національних доменах, якщо така структура відповідає завданням проєкту.

Вибір архітектури роблять окремо від hreflang. Після цього для кожної групи сторінок створюють зрозумілу відповідність між усіма мовними і регіональними варіантами.

Підпапки, піддомени чи окремі домени?

Поширені варіанти виглядають так:

Hreflang здатний пов'язувати всі ці формати. Google не вимагає, щоб альтернативні URL-адреси розміщувалися на одному домені.

Для SEO важливіша стабільна структура, коректна індексація та єдина логіка формування локалізованих сторінок. Якщо URL змінюються, разом з ними потрібно оновлювати hreflang і canonical.

Чому переклад та локалізація – не одне й те саме?

Переклад змінює мову тексту, а локалізація враховує особливості конкретного ринку. На комерційному сайті можуть відрізнятися валюта, ціни, одиниці виміру, контактні дані, доставка, способи оплати та юридична інформація.

Тому дві сторінки англійською можуть мати різні регіональні версії. Наприклад, одна призначена для США, а інша для Великобританії, хоча більша частина тексту в них залишається схожою.

Типові помилки hreflang

Більшість проблем пов'язані не зі складністю синтаксису, а з неузгодженістю URL. Одна неправильна адреса всередині великої групи здатна порушити зв'язки одразу між декількома локалізаціями.

Найзручніше перевіряти помилки таблицею, особливо при масовому аудиті інтернет-магазину або сайту з десятками мов.

Після міграції такі помилки особливо часті. Старі URL залишаються у шаблоні або sitemap, хоча самі сторінки вже перенаправляються на нову структуру.

Як перевірити hreflang на сайті?

Спочатку можна відкрити вихідний HTML та знайти rel="alternate". Для невеликої групи цього достатньо, щоб перевірити коди, повний набір локалізацій та власне посилання на сторінку.

Для великого проєкту ручної перевірки недостатньо. Потрібен SEO-краулер, який збере hreflang з усіх URL, що індексуються, і покаже відсутність return links, невірні мовні коди, посилання на редиректи та інші технічні розбіжності.

Перевірка всіх мовних URL

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

Мінімальний список перевірки:

• кожна мовна версія присутня у групі та містить self-referencing посилання;
• між альтернативними URL-адресами налаштовані взаємні зв'язки без пропущених сторінок;
• використовуються коректні мовні та регіональні коди;
• всі адреси повністю вказані та відповідають кодом 200;
• canonical не конфліктує з локалізованою версією;
• сторінки доступні пошуковому роботу та не закриті від індексації;
• x-default веде на відповідну резервну сторінку, якщо вона використовується.

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

Коли проводити повторну перевірку?

Аудит потрібен після запуску нової мови, міграції, змін slug, переходу на іншу CMS або масової перебудови каталогу. Будь-яка операція, яка змінює адреси сторінок, здатна залишити старі URL у hreflang.

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

Приклад правильного hreflang для мультимовного сайту

Припустимо, сторінка послуги існує українською, англійською та польською мовами. Для користувачів без локалізації сайт використовує спільну сторінку вибору мови.

У <head> кожної з трьох локалізованих сторінок буде однаковий набір:

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

Українська сторінка містить посилання на себе та інші версії. Те саме правило застосовується до англійської та польської URL, тому зв'язки всередині групи залишаються взаємними.

Чек-лист налаштування hreflang

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

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

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

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