Мапінг hreflang: робочий зошит і шаблон QA

Структура URL для міжнародного сайту

Коли використовувати: Оберіть, як розмістити країнові й мовні версії, ще до початку розробки.

Оберіть схему URL для [Brand]

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

• ccTLD: [example.de], [example.fr]: найсильніший географічний сигнал, зрозуміло користувачам, але дорого, і кожен домен має окремий авторитет.
• Підкаталог: [example.com/de/], [example.com/fr/]: авторитет зосереджено на одному домені, найпростіше підтримувати, підходить більшості команд.
• Піддомен: [de.example.com]: гнучкий хостинг, але сигнали можуть сприйматися як більш відокремлені, ніж у підкаталогів.

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

Запишіть рішення та його обґрунтування нижче, щоб наступні учасники команди не імпровізували.

• Обрана структура: [ccTLD / підкаталог / піддомен]
• Причина: [бюджет, розмір команди, географічний пріоритет]
• Локалі в межах проєкту: [список]

План мапінгу hreflang

Коли використовувати: Визначте кожну пару мова-регіон, перш ніж писати перший тег.

Зіставте локалі для [Brand]

Перш ніж щось впроваджувати, складіть головний список усіх локалей, які ви обслуговуєте. Подбайте про правильні коди: hreflang використовує код мови ISO 639-1 (наприклад, en, es, fr), за яким може йти код регіону ISO 3166-1 Alpha-2 (наприклад, US, MX, GB). Спочатку мова, потім регіон.

• en: будь-який англомовний користувач (без регіону) → [URL]
• en-US: англійська, США → [URL]
• en-GB: англійська, Велика Британія → [URL]
• es-MX: іспанська, Мексика → [URL]
• x-default: резервна версія для користувачів без збігу → [URL]

Вказуйте регіон, лише якщо для нього справді є окремий контент. Якщо іспанська сторінка однакова для всіх країн, націлюйтеся просто на es, а не вигадуйте es-MX, es-AR і es-ES.

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

• Локаль: [мова або мова-регіон]
• Цільовий URL: [абсолютний https URL]

Правила впровадження hreflang

Коли використовувати: Дотримуйтеся обов'язкових технічних правил, щоб теги справді працювали.

Правильно впровадьте hreflang для [Brand]

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

1. Посилання на себе: кожна сторінка має вказувати себе серед своїх анотацій hreflang.
2. Зворотні теги: анотації мають бути двосторонніми. Якщо сторінка A посилається на сторінку B, сторінка B має посилатися назад на сторінку A.
3. x-default: додайте резервний запис для користувачів, чию мову чи регіон ви явно не таргетуєте.
4. Абсолютні URL: завжди використовуйте повні https URL, а не відносні шляхи.

Оберіть один спосіб передачі й не змішуйте їх: HTML head (link rel='alternate'), HTTP-заголовки (зручно для PDF та інших не-HTML файлів) або XML sitemap.

Мінімальний коректний набір для однієї локалі виглядає так:

• hreflang: en-us → [URL сторінки для США]
• hreflang: en-gb → [URL сторінки для Великої Британії]
• hreflang: x-default → [резервний URL]

Пам'ятайте: hreflang підказує, яку версію показати, а не підвищує позиції.

Уникайте дубльованого контенту між локалями

Коли використовувати: Використовуйте canonical і hreflang разом, щоб локалі не канібалізували одна одну.

Не давайте локалям конкурувати на [Brand]

Майже ідентичні сторінки для різних регіонів (наприклад, en-US і en-GB) можуть виглядати як дубльований контент. Hreflang і canonical разом розв'язують цю проблему, але лише якщо обидва налаштовано правильно.

1. Кожна сторінка локалі має мати canonical на саму себе.
2. Не ставте всім локалям canonical на один головний URL: так ви кажете пошуковикам відкинути інші версії.
3. Поєднайте canonical на себе з повним двостороннім набором hreflang, щоб пошуковики розуміли: це альтернативні версії, а не дублікати.

Разом вони сигналізують: ці сторінки рівноцінні версії для різних аудиторій, і кожна з них самостійна.

Перевірте кожну сторінку перед публікацією:

• canonical: вказує на [URL цієї ж локалі]
• hreflang на себе: містить [цю локаль]
• hreflang на інші: усі сусідні локалі присутні [так / ні]
• x-default: присутній [так / ні]

Якщо canonical і hreflang для однієї сторінки вказують на різні URL, виправте це. Суперечливі сигнали ігноруються.

Локалізація чи переклад

Коли використовувати: Публікуйте справді локальні сторінки, а не машинні копії.

Локалізуйте, а не просто перекладайте, для [Brand]

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

• Валюта та ціни: показуйте місцеву валюту, податки й способи оплати.
• Мовні нюанси: попросіть носія мови перевірити тон, ідіоми й терміни.
• Одиниці та формати: адаптуйте дати, одиниці виміру, адреси й формати телефонів.
• Локальний намір: досліджуйте ключові слова на самому ринку; дослівний переклад рідко збігається з тим, як місцеві насправді шукають.
• Сигнали довіри: місцеві контакти, доставка, повернення й юридичні сторінки.

Код мови в hreflang має відповідати фактичній мові контенту. Позначка es-MX на сторінці з англійським текстом дає суперечливий сигнал.

Чекліст локалізації для кожної локалі:

• Валюту адаптовано: [так / ні]
• Перевірку носієм мови виконано: [рецензент]
• Локальні ключові слова досліджено: [так / ні]

QA hreflang та типові помилки

Коли використовувати: Перевірте впровадження й знайдіть помилки, які непомітно його ламають.

QA hreflang на [Brand]

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

1. Немає зворотних тегів: переконайтеся, що кожну анотацію підтверджує сторінка, на яку вона вказує.
2. Немає посилання на себе: кожна сторінка має містити себе.
3. Неправильні коди: перевірте, чи немає недійсних кодів регіону: використовуйте коди країн, як-от GB, а не коди на кшталт мовних; UK недійсний.
4. Відносні URL: замініть усі відносні шляхи на абсолютні https URL.
5. Конфлікт із canonical: переконайтеся, що canonical і hreflang для кожної сторінки ведуть на той самий URL.
6. Немає резервної версії: подумайте про x-default для користувачів, які не підпадають під жодну локаль, наприклад сторінку вибору мови.

Використовуйте краулер, який показує взаємність hreflang, і вибірково перевіряйте сторінки інструментом перевірки URL (URL Inspection) у Search Console, щоб валідувати в масштабі (Google вимкнув старий звіт про міжнародне таргетування (International Targeting report)).

Записуйте знайдені проблеми та їхній статус:

• Помилка: [опис]
• Зачеплені локалі: [список]
• Статус: [відкрито / виправлено]

Робочий зошит мапінгу hreflang (для заповнення)

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

Робочий зошит мапінгу

Один рядок на одиницю контенту (продукт, гайд, категорію). Одна колонка на локаль. У кожній клітинці повний https URL або порожньо, якщо в цій локалі версії немає.

Правила для кожного рядка

• Себе й усі інші: кожна версія вказує себе та всі інші версії в рядку. Google може ігнорувати анотації без зворотних посилань.
• Canonical = URL у клітинці: кожна локалізована сторінка є власним canonical. Не ставте перекладам canonical на англійську сторінку.
• Коректні коди: мова за ISO 639-1, за потреби регіон за ISO 3166-1 Alpha-2. Сам регіон без мови недійсний. Велика Британія це GB, а не UK.
• Повні URL: додавайте https://. Відносні URL і URL без протоколу не враховуються.
• Один спосіб: HTML-теги link, HTTP-заголовки або XML sitemap. Google обробляє їх однаково; кілька способів одночасно нічого не дають.

QA кодів і взаємності

Коли використовувати: Перевірки, які варто провести на вибірці рядків після впровадження, і журнал: що не пройшло й хто виправляє.

Перевірки QA

Журнал проблем

Перевірка завершення: вибірка з [кількість] рядків проходить усі перевірки, перевірено [дата].

Приклад заповнення (вигадана софтверна компанія)

Коли використовувати: Три заповнені рядки з вигаданого SaaS-сайту з чотирма локалями та три помилки, які QA виявив до запуску.

Приклад заповнення: Fieldnote

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

Що виявив QA

• Розробник використав en-UK. UK це зарезервований код; його замінили на en-GB.
• Німецькі сторінки мали canonical на англійську сторінку, що суперечило hreflang. Тепер кожна вказує на себе.
• Гайд з ПДВ лише для Великої Британії вказував німецьку альтернативу, якої не існувало. У рядку можуть бути пропуски; тепер гайд вказує лише себе.

Наступний крок

Скористайтеся інструментом Get Source Code of Webpage, щоб побачити теги hreflang, які сторінка віддає насправді, і запустіть аудит сайту для кожної локалі, щоб знайти биті або переспрямовані альтернативи. Якщо ви вказуєте hreflang у sitemap, згенеруйте файли з робочого зошита за допомогою XML Sitemap Generator. Плануєте повноцінний міжнародний запуск? Перегляньте наші послуги SEO та GEO.