Як користуватися генератором hreflang?
Інструмент підходить для корпоративних сайтів, інтернет-магазинів, SaaS-проєктів, каталогів та інших ресурсів із кількома локалями. З його допомогою можна розробити hreflang онлайн, додати x-default і підготувати код для HTML або XML Sitemap залежно від обраної схеми застосування.
В англомовних інтерфейсах та документації такий сервіс часто називають hreflang generator, hreflang code generator або hreflang tag generator. Назви різняться, але завдання залишається одним: правильно зв'язати альтернативні мовні та регіональні URL між собою.
Для створення розмітки спочатку підготуйте список еквівалентних сторінок. Усі URL всередині однієї групи повинні вести на однаковий за призначенням контент, перекладений або адаптований для конкретної мови та регіону. Головна українська сторінка, наприклад, має зв'язуватися саме з відповідною англійською чи польською версією, а не з довільною сторінкою розділу.
Після заповнення полів перевірте адреси, мову та регіон кожної версії. Потім додайте x-default, якщо проєкту потрібна універсальна сторінка для користувачів, яким не підходить жодна вказана локаль. Такий порядок знижує ризик помилок ще до перенесення розмітки на код сайту.
Додати мовні версії сторінок
Для кожної локалізованої версії вкажіть повну адресу сторінки. Якщо сайт доступний українською, англійською та польською мовами, в одній групі повинні знаходитися три еквівалентні URL-адреси, які відповідають одному товару, послузі, статті або іншій сутності сайту.
Наприклад, група може включати https://example.com/uk/page/, https://example.com/en/page/ та https://example.com/pl/page/. Такі альтернативні URL повинні містити основний контент, інакше пошуковій системі буде складніше правильно інтерпретувати мовні зв'язки.
Для великих проєктів краще заздалегідь вивантажити список локалізованих сторінок та перевірити відповідність URL між мовними версіями. Це особливо корисно для інтернет-магазинів, де одна помилка в шаблоні може торкнутися тисячі карток товарів чи категорій.
Вкажіть мову та регіон
Код мови показує, якою мовою опубліковано сторінку, а код регіону уточнює цільову країну чи ринок. Наприклад, en означає англійську мову без регіонального обмеження, тоді як en-US відноситься до англійського контенту для аудиторії США, а en-GB – для користувачів із Великобританії.
Регіон не потрібно автоматично додавати до всіх мовних сторінок. Якщо одна англійська версія підходить відвідувачам із різних країн, достатньо en. Коли контент, ціни, доставка або комерційні умови різняться за ринками, можна використовувати окремі значення на зразок en-US та en-GB.
Генератор hreflang тегів повинен отримувати фактичні дані структури сайту, а не передбачувану географію аудиторії. Неправильно вибраний регіон здатний заплутати розмітку навіть при правильному синтаксисі HTML.
Додати x-default
Значення x-default використовують для універсальної сторінки, яку пошукова система може розглядати як стандартний варіант. Такою сторінкою часто стає міжнародна головна сторінка вибору країни або загальна версія сайту без прив'язки до конкретної мови або регіону.
Генератор x-default допомагає включити таку URL-адресу в загальний набір посилань разом з локалізованими варіантами. Додавати його варто тоді, коли в архітектурі проєкту справді існує логічна сторінка за промовчанням для користувачів, яким не підходить жодна задана локаль.
Якщо такої сторінки немає, створювати окрему URL-адресу тільки заради x-default не потрібно. Розмітка має відображати реальну структуру сайту та реальні варіанти контенту, а не штучно розширювати набір тегів.
Згенеруйте та скопіюйте код
Після заповнення мовних версій, генератор створює готовий набір тегів, який можна передати розробнику або впровадити самостійно. Перед копіюванням ще раз перевірте протокол, домен, шлях сторінки, мову, регіон та відповідність кожної локалі потрібному URL.
Після впровадження коду бажано перевірити безпосередньо на опублікованій сторінці. Помилка може виникнути на боці шаблону, CMS, серверного рендерингу чи XML Sitemap, тому коректний результат генерації ще не підтверджує правильності кінцевої реалізації.
Якщо потрібний hreflang generator online для регулярної роботи, збережіть єдиний порядок заповнення локалів усередині команди. Це спрощує перевірку великих груп сторінок та знижує ймовірність того, що різні фахівці почнуть використовувати різні схеми позначення мов та регіонів.
Як правильно впровадити hreflang?
Hreflang можна передати пошуковій системі декількома способами. Для звичайних HTML-сторінок частіше застосовують теги в <head>, але у великих проєктах зв'язку можна зберігати в XML Sitemap. Для документів без стандартної HTML-розмітки підходить HTTP Link header.
Вибирати відразу кілька способів для однієї групи URL зазвичай не потрібно. Чим складніша схема, тим важче підтримувати її після зміни адрес, додавання мов або перенесення сайту, тому краще вибрати одне стабільне джерело даних.
При впровадженні орієнтуйтесь на можливості CMS та масштаб проєкту. Для кількох десятків сторінок зручно керувати HTML-тегами, тоді як каталогу з сотнями тисяч локалізованих URL-адрес може бути простіше централізовано генерувати зв'язки всередині карти сайту.
| Спосіб | Де розміщується | Коли зручний |
|---|---|---|
| HTML | У <head> кожної сторінки | Невеликі та середні сайти |
| XML Sitemap | У карті сайту | Великі каталоги та магазини |
| HTTP Link header | У HTTP-заголовку відповіді | PDF та інші не-HTML документи |
Умовну складність супроводу цих варіантів при збільшенні кількості URL можна представити у відсотках:
| Спосіб впровадження | Умовна складність підтримки |
|---|---|
| HTML | 80% |
| XML Sitemap | 50% |
| HTTP Link header | 70% |
Відсотки показують порівняльну складність супроводу, а не технічну оцінку Google чи офіційний норматив. Реальне навантаження залежить від CMS, кількості локалів, структури URL, способу зберігання перекладів та рівня автоматизації проєкту.
Hreflang в HTML
При HTML-варіанті набір посилань розміщується всередині <head> кожної локалізованої сторінки. Українська, англійська та польська версії повинні містити один і той же набір альтернатив з різними значеннями hreflang та відповідними адресами.
Такий підхід зручно перевіряти у вихідному коді сторінки. Він добре підходить проєктам, де CMS знає зв'язок між перекладами та може автоматично виводити потрібні теги під час серверного рендерингу.
Якщо посилання додаються вручну, ризик зміни зростає після зміни структури URL. Тому навіть для невеликого сайту краще зберігати зв'язки між перекладами даних сторінки, а не прописувати адреси безпосередньо всередині загального шаблону.
Коли підходить HTML-варіант?
HTML-розмітка зручна, коли сайт містить обмежену кількість мовних версій, а розробник може контролювати вміст <head>. Особливо добре такий підхід працює у CMS, де кожна сторінка знає ідентифікатори своїх перекладів та генерує посилання автоматично.
Для невеликих корпоративних сайтів та сервісних сторінок підтримка HTML-тегів, як правило, залишається зрозумілою навіть після розширення структури. Помилки легко побачити під час перегляду вихідного коду або автоматичного сканування сайту.
Якщо проєкт швидко зростає і вже містить десятки тисяч локалізованих URL-адрес, керування такими зв'язками через HTML може вимагати додаткової автоматизації. У цій ситуації варто порівняти підтримку тегів у шаблоні із централізованою генерацією XML Sitemap.
Hreflang у XML Sitemap
XML Sitemap може містити зв'язок між альтернативними мовними сторінками через елементи xhtml:link. Такий варіант особливо зручний, коли на сайті багато URL-адрес і потрібні відносини між локалями вже зберігаються в базі даних.
За запитом hreflang xml sitemap generator користувачеві зазвичай потрібний готовий XML-фрагмент, який можна додати до існуючої карти сайту або використовувати як основу для автоматичної генерації. Важливо зберегти валідний XML і вказати простір імен XHTML.
Кожен основний URL всередині sitemap отримує набір альтернативних посилань на пов'язані локалі. Ті ж зв'язку повинні послідовно повторюватися для інших членів групи, щоб пошукова система бачила повну структуру відповідності.
Коли використовувати XML Sitemap?
XML-підхід зручний інтернет-магазинам, маркетплейсам, каталогам нерухомості, медіа та іншим проєктам з великою кількістю сторінок. Він скорочує обсяг додаткового коду HTML і дозволяє централізовано формувати мовні зв'язки.
Для великих сайтів hreflang tags generator часто стає частиною серверної логіки, яка отримує дані про переклади з бази та на їх основі збирає sitemap. Ручне заповнення тисяч груп URL у проєкті створює надто високий ризик невідповідностей.
Після створення XML необхідно окремо перевірити доступність всіх адрес і валідність файлу. Наявність посилання на карті сайту не виправляє 404, редирект, noindex або неправильний canonical на самій сторінці.
Hreflang через HTTP-заголовок
HTTP Link header використовують для ресурсів, які не мають звичайного HTML-блоку <head>. Типовий приклад – PDF-документи, опубліковані в кількох мовних версіях та доступні за різними URL-адресами.
У HTTP-відповідь можна додати посилання на альтернативні версії з тими самими значеннями мови та регіону. Логіка self-reference, взаємності та відповідності локалів залишається такою самою, як при використанні звичайних HTML-тегів.
Для стандартних вебсторінок цей спосіб зазвичай складніший у супроводі, оскільки його не можна побачити безпосередньо у HTML. Перевіряти заголовки доводиться через інструменти розробника, краулер чи спеціальний валідатор hreflang.
Я завжди перевіряю hreflang разом з canonical, індексованістю та HTTP-кодами сторінок. Навіть правильно згенерований тег не виправить ситуацію, якщо мовна версія віддає редирект, закрита через noindex або канонізована на інший URL. Для українських проєктів я окремо дивлюсь поєднання мови та регіону. Наприклад, ru-UA означає російськомовну сторінку для аудиторії України, тоді як ru-RU задає вже інший регіональний контекст, тому автоматично підміняти один варіант іншим не можна.
Головні правила коректного hreflang
Коректний синтаксис ще не гарантує правильної міжнародної розмітки. Пошуковій системі потрібно отримати узгоджену групу доступних URL, де кожна сторінка підтверджує решту версій і одночасно містить посилання на себе.
Додатково перевіряються canonical, індексованість, редиректи та HTTP-коди. Якщо одна локаль веде на віддалену адресу або закрита від індексації, вся група стає менш надійною, хоча решта рядків може виглядати технічно правильно.
При автоматичній генерації ці правила краще контролювати на рівні даних та шаблону. Тоді додавання нової мови оновлює набір альтернатив одночасно всіх пов'язаних сторінках.
Кожна версія має посилатися на саму себе
Self-reference означає, що сторінка є у власному наборі hreflang. Якщо українська URL-адреса містить посилання на англійську та польську версії, серед них також має бути посилання на поточну українську сторінку.
Такий self-referencing hreflang запис допомагає пошуковій системі бачити повний набір локалів без необхідності вгадувати роль поточного URL. Правило застосовується однаково до HTML та XML Sitemap.
Якщо генератор автоматично додає поточну сторінку, перевірте її адресу після зміни домену, протоколу або структури каталогів. Старий URL всередині self-reference здатний зберегтися непомітно після міграції.
Посилання між версіями мають бути взаємними
Reciprocal links означають, що зв'язок підтверджується з обох сторін. Коли українська сторінка вказує англійську як альтернативну, англійська версія має містити зворотне посилання на українську URL-адресу.
Взаємні посилання особливо легко втратити, коли нову мову запускають поступово. Розробник додає нову URL-адресу на новій сторінці, але старі локалі продовжують працювати з колишнім набором тегів.
Для великих сайтів таку проблему краще шукати автоматичне сканування. Перевірка hreflang повинна порівнювати групи URL та відзначати випадки, де одна сторінка посилається на іншу без зворотного підтвердження.
Використовуйте абсолютні URL
У href слід вказувати повну адресу разом із протоколом та доменом, наприклад https://example.com/en/page/. Відносний шлях /en/page/ краще не використовувати міжнародної розмітки.
Абсолютна URL-адреса зменшує неоднозначність і зберігає зрозумілий зв'язок навіть між сторінками на різних доменах або піддоменах. Це особливо важливо для проєктів, де локальні версії розміщуються у різних національних доменних зонах.
Після міграції перевіряйте, щоб усередині тегів не залишилися тестові домени, старий HTTP або колишня структура каталогів. Такі помилки трапляються частіше, ніж неправильний синтаксис самого атрибуту.
Hreflang повинен відповідати canonical
Canonical і hreflang вирішують різні завдання, але їх сигнали не повинні суперечити один одному. Локалізована сторінка, що індексується, зазвичай вказує canonical URL на власну канонічну версію і одночасно зв'язується з перекладами через hreflang.
Проблема виникає, коли англійська сторінка містить hreflang на себе, але canonical відправляє пошукову систему на українську URL. У такій конфігурації один сигнал просить вважати англійську сторінку самостійною локаллю, а інший пропонує вибрати іншу канонічний адресу.
Усі сторінки мають бути доступні для індексації
Кожен URL групи бажано віддавати з кодом HTTP 200 і дозволяти індексування. Якщо альтернативна версія закрита через noindex, заблокована технічними правилами або постійно перенаправляє користувача, зв'язок втрачає практичне значення.
Додатково потрібно перевірити robots.txt, canonical, редирект та доступність сторінки для пошукового робота. Помилки на цьому рівні часто залишаються непомітними, коли фахівець перевіряє наявність рядків rel="alternate".
Після масових змін корисно просканувати весь набір локалізованих сторінок. Такий контроль покаже не лише проблеми hreflang, а й 3xx, 4xx, втрачені URL, конфліктуючі канонічні адреси та інші технічні розбіжності.
Що саме ми робили
Стоматологія · Київ і Чернігів
+44% кліків із пошуку
Домен без історії, сайт на конструкторі. Зібрали семантику під послуги й обидва міста, переробили посадкові сторінки, з нуля побудували посилальний профіль. За чотири місяці: 34,8 тис. кліків, покази 1,32 → 1,76 млн, DR 0 → 41.
E-commerce · міжнародний ринок
+96% кліків за два місяці
Каталог цифрових 3D-моделей. Кластеризували семантику, перебудували хабові сторінки, закрили дублі та помилки індексації. Користувачі з Google 247 → 532, CTR 2,4% → 4%.
Медичний центр · Україна
+68,75% видимості за перший місяць
Вузька видимість і мала семантика на старті. Семантика, структура посадкових, метадані та перелінковка, поступове посилення посиланнями.
Відповіді на ваші запитання
Що робить генератор hreflang?
Генератор створює набір посилань між мовними та регіональними версіями однієї сторінки. Користувач вказує URL, вибирає потрібні локалі та отримує готовий код, який можна впровадити в HTML або використовувати для формування XML Sitemap.
Такий сервіс особливо зручний, коли потрібно зв'язати кілька локалізованих сторінок без ручного написання кожного рядка. При великій кількості мов він також знижує ризик друкарських помилок в адресах, кодах і структурі тегів.
При цьому генератор не перевіряє автоматично всю технічну конфігурацію сайту, якщо така функція окремо не передбачена. Після публікації слід перевірити доступність URL, canonical, reciprocal links та інші зв'язані сигнали.
Чи можна створити hreflang онлайн безкоштовно?
Якщо поточна версія інструмента Seo-Gen доступна без оплати, hreflang можна створити у браузері без ручного написання коду. Для роботи достатньо підготувати адреси відповідних мовних сторінок та вибрати потрібні локалі.
Запит створити hreflang онлайн зазвичай пов'язаний саме з таким завданням: швидко одержати готові рядки для передачі розробнику. Якщо сервіс пізніше отримає обмеження щодо тарифу або кількості URL, опис сторінки потрібно оновити відповідно до фактичних умов.
Також зустрічається запит hreflang generator online, який позначає той же інтент користувача. В обох випадках людині потрібний готовий код, а не довгий теоретичний посібник без самого інструменту.
Що таке x-default у hreflang?
x-default позначає стандартну сторінку для користувачів, яким не відповідає жодна з явно заданих мовних або регіональних версій. Це може бути глобальна домашня сторінка, міжнародна версія або екран вибору країни.
Таке значення не замінює мовні теги і не повинно використовуватись замість основної локалі. Воно додається до загального набору як окреме посилання за промовчанням, коли архітектура проєкту передбачає універсальний варіант.
Якщо окремої універсальної URL-адреси немає, генератор x-default можна використовувати без додавання відповідного рядка. Наявність x-default залежить від структури сайту, а не від формальної вимоги заповнити кожне поле.
Чи потрібно додавати hreflang на кожну мовну версію?
Так, пов'язані сторінки повинні підтверджувати один одного. Якщо українська версія вказує англійську та польську, аналогічний набір альтернатив необхідно розмістити на англійській та польській сторінках.
Крім взаємних посилань, кожна сторінка має містити self-reference. Завдяки цьому пошукова система отримує повний та узгоджений список локалей незалежно від того, з якого URL почала обхід групи.
При автоматичній генерації краще будувати весь набір із єдиного джерела даних. Тоді додавання або видалення локалі одночасно змінить розмітку всіх пов'язаних сторінках і зменшить ризик односторонніх зв'язків.
Що краще – hreflang у HTML чи XML Sitemap?
Обидва методи передають один тип інформації, тому вибір залежить від архітектури проєкту. Для невеликого сайту зручно розміщувати теги безпосередньо в <head>, де їх легко побачити та перевірити разом із рештою SEO-метаданних.
На великому сайті XML Sitemap може бути простіше у супроводі, особливо якщо групи локалізованих сторінок вже формуються автоматично з бази даних. Такий підхід зменшує кількість додаткової розмітки в HTML.
Не варто дублювати обидва варіанти без практичної причини. Чим більше джерел однієї інформації доводиться підтримувати, тим вище ймовірність розбіжності після зміни URL або додавання нової мови.
Чи можна використовувати hreflang для сторінок у різних доменах?
Так, альтернативні версії можуть знаходитися на різних доменах, піддоменах або каталогах одного сайту. Hreflang пов'язує конкретні URL, тому єдина доменна структура його роботи не обов'язкова.
Наприклад, локальні версії можуть використовувати національні домени, а міжнародна версія розташовуватиметься на основному .com. Головне, щоб кожна сторінка була доступна пошуковій системі та містила узгоджений набір взаємних посилань.
При кількох доменах особливо ретельно перевіряйте протокол, редиректи та canonical. Помилка однієї адреси може бути менш помітна візуально, оскільки різні домени часто обслуговуються різними конфігураціями CMS і серверів.
Чи потрібно одночасно використовувати canonical і hreflang?
Так, ці елементи можуть використовуватись разом, оскільки вирішують різні завдання. Canonical показує кращий URL серед дублів або близьких варіантів, а hreflang пов'язує самостійні мовні та регіональні сторінки.
Для звичайної локалізованої сторінки найчастіше потрібен self-canonical на її власну адресу, що індексується. Після цього через hreflang вона зв'язується з іншими версіями, які також мають власні канонічні URL-адреси.
Якщо canonical веде на сторінку іншої мови, необхідно перевірити причину такої настройки. У більшості міжнародних структур це створює протиріччя між сигналами та заважає коректно інтерпретувати локалізовані сторінки.
Чи впливає hreflang безпосередньо на позиції сайту?
Hreflang не дає гарантованого підвищення позицій і не замінює якість контенту, внутрішнє перелінкування, технічну оптимізацію або зовнішні сигнали. Його завдання пов'язана насамперед із вибором відповідної мовної чи регіональної сторінки.
Коректна розмітка може зменшити ситуації, коли користувач показує невідповідну локаль із групи схожих сторінок. Це покращує узгодженість міжнародної структури, але не створює самостійної переваги щодо релевантності запиту.
Тому результат слід оцінювати разом із станом кожної локальної версії. Сторінка повинна відповідати пошуковому інтенту, мати нормальну індексацію та містити інформацію, яка підходить саме її аудиторії.
Суміжні послуги
Перевірка позицій за запитами
Keyword Rank Checker – онлайн-перевірка позицій сайту за ключовими словами у Google. Дізнайтеся поточну позицію, ranking URL та результати SERP за вибраним запитом, країною та пристроєм.
Перевірка видачі Google
Google SERP Checker для перевірки реальної видачі Google за ключовим запитом, країною, містом, мовою та пристроєм. Дивіться локальні SERP онлайн без VPN.
Hreflang варто налаштовувати як пов'язану систему, де мова, регіон, canonical, індексованість і реальні URL узгоджені між собою. Сам тег має простий синтаксис, але помилки у логіці сторінок зустрічаються значно частіше, ніж помилки всередині одного рядка коду.
Використовуйте генератор hreflang, щоб підготувати розмітку для HTML або XML Sitemap, додати x-default за необхідності та скоротити ручну роботу. Після генерації обов'язково перевірте код на опублікованих сторінках, взаємність посилань, відповіді сервера та відповідність кожної локалі до її канонічного URL.
Додайте мовні версії сторінки у форму, виберіть потрібні коди та отримайте готовий набір hreflang для впровадження на сайт.
Відповідаємо протягом робочого дня. Без розсилок і дзвінків «просто нагадати».
Подивиться сайт сам, а не передасть менеджеру.
Докладніше: Генератор hreflang
Що таке hreflang і навіщо він потрібний?
Hreflang повідомляє пошуковій системі, які URL-адреси є мовними або регіональними варіантами однієї сторінки. За цими зв'язками Google може вибрати версію, яка найкраще відповідає мові користувача та цільовому регіону, якщо інші сигнали сторінки також узгоджені.
Така розмітка особливо корисна для мультимовного сайту, де однакова послуга, категорія чи стаття публікується кількома мовами. Вона також застосовується на мультирегіональному сайті, коли одна мова використовується для різних ринків, але пропозиції, ціни чи умови різняться.
Hreflang не гарантує зростання позицій і не замінює міжнародне SEO цілком. Сторінки, як і раніше, повинні бути доступні для обходу, коректно індексуватися, мати відповідний canonical URL, корисний контент і логічну внутрішню архітектуру.
Як виглядає тег hreflang?
Стандартний HTML-запис може виглядати так:
<link rel="alternate" hreflang="uk-UA" href="https://example.com/page/" />
У цьому прикладі атрибут rel="alternate" повідомляє про наявність альтернативної версії, hreflang задає мову та регіон, а href містить повну адресу сторінки.
Такий link tag розміщують усередині секції HTML-документу. Для кожної пов'язаної версії додається окремий рядок, тому українська, англійська та польська сторінки отримують однаковий набір посилань із відповідними URL-адресами.
Синтаксис короткий, проте помилки частіше виникають не всередині тега, а в логіці зв'язків. Неправильна локаль, відсутнє зворотне посилання або URL з редиректом можуть зробити коректно написаний рядок марним для пошукової системи.
Мова та регіон – у чому різниця?
Мова описує зміст сторінки, тоді як регіон уточнює ринок, котрого призначена конкретна версія. Ці параметри пов'язані, але не взаємозамінні. Наприклад, іспанська мова використовується в багатьох країнах, тому однієї мовної версії іноді достатньо, а в інших проєктах потрібні окремі регіональні варіанти.
Регіональне націлення має сенс при реальних відмінностях між сторінками. Це можуть бути валюта, умови доставки, контакти, юридична інформація, асортименти або інші елементи, пов'язані з конкретним ринком.
Якщо відмінностей між країнами немає, додавання регіонів лише заради розширення розмітки не приносить користі. Структура hreflang повинна відповідати тому, як проєкт справді поділяє мовні версії сторінок та регіональні версії.
Код мови
Для мови зазвичай застосовують дволітерний код стандарту ISO 639-1. Наприклад, uk позначає українську, en – англійську, de – німецьку, pl – польську, а fr – французьку мову.
Код мови пишеться першим і може використовуватись самостійно. Якщо сторінка призначена всім англомовних користувачів незалежно від країни, значення en часто точніше, ніж штучно обраний регіон на зразок en-US.
Під час створення необхідно використовувати існуючий код, який відповідає фактичній мові сторінки. Довільні скорочення, назви країн та внутрішні позначення CMS для hreflang не підходять, навіть якщо такі значення використовуються всередині адміністративної панелі сайту.
Код регіону
Для регіону використовують дволітерний код ISO 3166-1 Alpha-2. Він додається після мови через дефіс, тому виходять комбінації uk-UA, en-US, en-GB, de-DE або pl-PL.
Регістр не є основним джерелом помилок, проте загальноприйнятий запис робить структуру зрозумілішою: мову пишуть малими літерами, регіон – великими. Набагато важливіше не плутати код мови з позначенням країни та обирати регіон за реальною цільовою аудиторією.
Наприклад, GB означає Великобританію, тому запис en-GB коректний для англійської англійської версії. Варіант en-UK, який іноді зустрічається на сайтах, не відповідає потрібному коду регіону та використовувати його не слід.
Що таке x-default у hreflang?
Значення x-default означає варіант сторінки без прив'язки до певної мови або регіону з поточного набору. Пошукова система може використовувати його як запасну адресу для аудиторії, яка не відповідає іншим локалям.
Приклад виглядає так:
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Як href можна вказати міжнародну головну, універсальну англомовну версію або сторінку, де відвідувач самостійно вибирає країну та мову.
Запит x-default hreflang generator зазвичай виникає у проєктів із великою кількістю країн, де неможливо перерахувати окрему локаль для кожного можливого користувача. При цьому наявність x-default має відповідати архітектурі сайту, а не використовуватися як обов'язковий формальний рядок.
Коли використати x-default?
x-default є доречним, коли сайт має окрему глобальну сторінку для відвідувачів без певної локалі. Такий варіант часто зустрічається у міжнародних компаній, маркетплейсів та SaaS-проєктів, які спочатку пропонують вибрати країну, а вже потім переводять користувача у локальну версію.
Ще один поширений сценарій – загальна англійська версія, призначена для всіх країн, які не отримали окремої регіональної сторінки. У цьому випадку важливо не створювати конфлікт між en, регіональними англійськими версіями та вибраним URL за промовчанням.
Перед додаванням x-default визначте, куди дійсно має потрапляти користувач за межами цих ринків. Така логіка має збігатися з навігацією сайту, редиректами та правилами вибору мови.
Коли x-default не потрібний?
Якщо проєкт працює лише з двома або трьома чітко визначеними мовними версіями та універсальної сторінки не існує, x-default можна не додавати. Відсутність цього значення сама по собі не робить hreflang неправильним.
Не варто спрямовувати x-default на випадкову локаль лише тому, що вона вважається основною всередині компанії. Посилання має виконувати зрозумілу функцію для міжнародної аудиторії та відповідати реальній поведінці сайту.
Також не потрібно створювати окрему технічну сторінку без корисного змісту заради одного тега. Розмітка працює краще, коли вона описує існуючу інформаційну архітектуру, а не змушує перебудовувати її задля формального заповнення полів.
Часті помилки при створенні hreflang
Більшість проблем пов'язані з тим, різні елементи міжнародної структури оновлюються несинхронно. Нова мова вже опублікована, але старі сторінки ще не отримали посилання на неї, або одна URL переїхала після редизайну, а стара адреса залишилася всередині шаблону.
Окрема група помилок з'являється через неправильні коди мов та регіонів. Внутрішні позначення CMS, довільні скорочення країн та схожі коди можуть виглядати логічно людині, але не відповідати стандарту, на який очікує пошукова система.
| Помилка | Чому виникає | Що зробити |
|---|---|---|
| Немає self-reference | Поточну сторінку виключено зі свого набору | Додати поточний URL з правильною локаллю |
| Немає зворотного посилання | Одна версія оновлена раніше за інших | Синхронізувати набір на всіх сторінках |
| Невірний код мови | Використовується внутрішнє скорочення CMS | Перевірити значення ISO 639-1 |
| Невірний регіон | Країна обрана формально за мовою | Вказати реальний цільовий ринок |
| Помилковий x-default | Вибраний випадковий URL | Призначити реальну сторінку за промовчанням |
| Відносна URL | Вставлено лише шлях сторінки | Використовувати абсолютну HTTPS-адресу |
| Конфлікт з canonical | Локаль канонізована іншою мовою | Узгодити canonical і hreflang |
| URL віддає 3xx або 4xx | Сторінка переїхала чи видалена | Оновити посилання на робочий HTTP 200 |
Після виправлення таблиці помилок потрібно перевірити всю групу, а не лише проблемну сторінку. Hreflang працює як пов'язана структура, тому зміна однієї адреси часто потребує оновлення кількох локалізованих URL одночасно.
Для регулярного контролю зручно поєднувати генератор та валідатор hreflang. Перший допомагає створити правильний набір, другий перевіряє, що цей набір справді з'явився на опублікованих сторінках та не конфліктує з іншими SEO-сигналами.
Приклади hreflang для мультимовного сайту
Розглянемо сайт з українською, англійською та польською версіями однієї сторінки. Додатково проєкт використовує міжнародну головну як x-default, куди можуть переходити користувачі, для яких окрема локаль поки що не створена.
Такий приклад показує відразу кілька елементів: код мови, регіон, self-reference, альтернативні сторінки та URL за замовчуванням. У реальному проєкті адреси та набір локалей потрібно замінити на фактичні дані сайту.
Для створення схожого набору можна використовувати hreflang tags generator, вказавши кожну локалізовану сторінку окремим рядком. Отриманий код потім переноситься в HTML або перетворюється на потрібний формат XML Sitemap.
Приклад HTML-коду
Для української сторінки набір може виглядати так:
<link rel="alternate" hreflang="uk-UA" href="https://example.com/page/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="pl-PL" href="https://example.com/pl/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />
Той самий набір має бути присутнім на англійській та польській версіях, якщо всі чотири URL утворюють одну логічну групу. Змінюється поточна сторінка, але список відповідних альтернатив залишається узгодженим.
Після впровадження перевірте вихідний HTML, а не лише відображення сторінки у браузері. Деякі клієнтські скрипти можуть писати теги після завантаження, тоді як серверний HTML залишається без необхідної розмітки.
Приклад hreflang у XML Sitemap
У XML Sitemap одна група може виглядати так:
<url>
<loc>https://example.com/uk/page/</loc>
<xhtml:link rel="alternate" hreflang="uk-UA" href="https://example.com/uk/page/" />
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<xhtml:link rel="alternate" hreflang="pl-PL" href="https://example.com/pl/page/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
</url>
Для робочого файлу необхідно коректно оголосити простір імен xhtml. При автоматичній генерації sitemap також слід стежити, щоб видалені чи закриті сторінки своєчасно зникали з груп альтернатив.
Якщо використовується hreflang xml sitemap generator, підсумковий файл слід перевірити валідатором. Помилка структури XML здатна вплинути на велику кількість URL, тому автоматична генерація повинна супроводжуватися технічним контролем.
Приклад для України
Для українського проєкту ru-UA підходить сторінці українською мовою, орієнтованою на аудиторію України. Значення ru-UA може використовуватися для російськомовної версії, якщо вона також призначена користувачам в Україні і дійсно існує як окрема сторінка, що індексується.
Англійська версія не зобов'язана автоматично одержувати en-UA. Якщо вона призначена для міжнародної аудиторії без окремої української регіональної адаптації, значення en може точніше описувати її призначення.
Коди слід вибирати за фактичною логікою проєкту, а не за місцем розташування компанії. Наявність українського бізнесу сама по собі не означає, що кожна мовна сторінка має мати регіон UA.
Як перевірити hreflang після генерації
Після використання відкрийте опубліковану сторінку і перевірте фактичні теги, XML Sitemap або HTTP-заголовки. Адреси повинні збігатися з канонічними версіями URL, а кожен учасник групи повинен підтверджувати решту локалі.
Наступний етап – перевірка відповіді сервера. Альтернативні сторінки повинні існувати, віддавати очікуваний HTTP-код та не перенаправляти робота на іншу мовну версію без зрозумілих причин.
Окремо перевірте індексованість, canonical URL і відсутність noindex. Генератор відповідає за підготовку розмітки, тоді як технічний стан опублікованих сторінок залежить від CMS, серверних правил та поточної конфігурації сайту.
Що перевіряти після зміни структури сайту?
Hreflang потрібно повторно перевіряти після міграції, зміни домену, зміни мовних каталогів чи перекладу проєкту іншу CMS. Навіть якщо вміст сторінок залишився незмінним, URL-адреса всередині старої розмітки може більше не відповідати робочій структурі.
Така сама перевірка потрібна після додавання нової локалі. Зв'язок повинен з'явитися на всіх існуючих мовних версіях відповідної сторінки, інакше нова сторінка буде включена до набору лише частково.
При видаленні мови старі посилання також потрібно видалити. Якщо вони продовжують вести на 404 або старий редирект, пошукова система отримує застарілі карти міжнародних зв'язків і змушена самостійно розбиратися з конфліктуючими сигналами.
Генератор hreflang для міжнародного SEO
В international SEO hreflang відповідає за зв'язок між локалізованими сторінками, але працює разом із загальною архітектурою сайту. Структура каталогів, домени, canonical, внутрішня перелінковка, sitemap і індексованість повинні описувати ті ж мовні та регіональні відносини.
Правильна розмітка допомагає пошуковій системі вибрати відповідну версію з кількох схожих сторінок. Це особливо корисно, коли один і той же продукт чи матеріал публікується кількома мовами та відмінності між локалями обмежені перекладом, валютою чи регіональними умовами.
Генератор hreflang прискорює технічну підготовку посилань та зменшує кількість ручних помилок. Після створення все одно потрібна перевірка кінцевої реалізації, тому що пошукова система оцінює опублікований код і доступні URL, а не результат всередині форми інструменту.