РесурсиЯк реалізувати теги hreflang для багатомовного WordPress

Як реалізувати теги hreflang для багатомовного WordPress

SimplePoTranslate Team31 травня 2026 р.

Ви переклали весь свій сайт WordPress шістьма мовами. Файли .po чисті, файли .mo скомпільовані, кожен рядок ідеально відображається французькою, німецькою та японською мовами. Проте через кілька тижнів після запуску ви перевіряєте Google Search Console і виявляєте щось дивовижне: ваша французька сторінка ранжується за німецькими запитами, ваша іспансько-мексиканська сторінка відображається користувачам у Іспанії, а дві ваші мовні версії тихо конкурують одна з одною в рейтингах. Зміст у порядку. Проблема в тому, що Google не має уявлення, яка версія належить якій аудиторії.

Саме це покликані виправити теги hreflang WordPress. Hreflang — це сигнал, який повідомляє пошуковим системам, яку мовну та регіональну версію сторінки показувати якому користувачеві. Якщо зробити це неправильно, ви отримаєте розмиття через дублювання вмісту, результати неправильною мовою та марнотратний бюджет сканування. Якщо зробити це правильно, кожна перекладена сторінка досягне аудиторії, для якої вона була написана. Цей посібник охоплює синтаксис, різницю між кодами мови та мови-регіону, обов'язковий x-default, взаємність зворотних тегів та три практичні способи реалізації цього в WordPress.

Що насправді робить hreflang

Hreflang нічого не перекладає. Це карта зв'язків. Коли у вас є одна й та ж сторінка кількома мовами, анотації hreflang повідомляють Google: "ця URL-адреса є англійською версією, ця – німецькою, а ця – для іспаномовних користувачів у Мексиці". Google використовує цю карту для показу правильної версії в результатах пошуку на основі мовних налаштувань та місцезнаходження користувача.

Анотація знаходиться в <head> вашого HTML як набір елементів <link>. Кожен елемент називає цільову сторінку та мову (та, за бажанням, регіон), яку вона обслуговує. Ось правильний набір тегів hreflang для сторінки, доступної американською англійською, британською англійською та мексиканською іспанською, з резервним варіантом за замовчуванням:

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing/" />
<link rel="alternate" hreflang="es-MX" href="https://example.com/es-mx/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing/" />

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

Чому це важливо для SEO

Без hreflang Google розглядає ваші перекладені сторінки як майже дублікати, що конкурують за одні й ті ж ключові слова. Результатом є розмиття: сигнали ранжування розділяються між версіями замість консолідації. Завдяки правильному hreflang, кожна версія успадковує авторитет всього набору та з'являється перед потрібними пошуковцями. Це один із найефективніших SEO-кроків, який може зробити багатомовний сайт, і він доповнює, а не замінює фактичний переклад вмісту у ваших файлах .po. Ми детально розглядаємо аспект вмісту в нашому посібнику як переклад файлів PO впливає на рейтинги Google.

Коди мови проти кодів мови-регіону

Що вам слід використовувати: en чи en-GB? Використовуйте найпростіший код, що є правдивим. Якщо ваш англійський контент загальний і ви не підтримуєте окремі британські та американські версії, використовуйте лише en. Додавайте субрегіональний тег лише тоді, коли ви дійсно надаєте різний контент для різних країн.

Значення hreflang відповідають формату language або language-region. Частина мови — це код ISO 639-1 (en, es, de, pt). Необов'язковий регіон — це дволітерний код країни ISO 3166-1 Alpha 2 (US, GB, MX, BR). Отже:

en націлений на всіх англомовних користувачів незалежно від країни.
en-GB націлений на англомовних користувачів у Сполученому Королівстві.
es націлений на всіх іспаномовних користувачів.
es-MX націлений конкретно на іспаномовних користувачів у Мексиці.

Важлива деталь: субрегіональний тег — це країна, а не мовний варіант. es-MX не означає "мексиканський діалект іспанської", це означає "іспанська, показана користувачам у Мексиці". Google все одно обслуговує її на основі місцезнаходження користувача. Якщо ви підтримуєте регіональні діалекти у своїх перекладах, код регіону — це те, як ви їх направляєте. Ми заглиблюємося в лінгвістичну сторону цього в нашому посібнику щодо регіональних варіантів іспанської та португальської мов.

Поширений неправильний приклад

Ось несправний блок hreflang, який ми постійно бачимо:

<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="sp" href="https://example.com/es/" />
<link rel="alternate" hreflang="pt-PT_BR" href="https://example.com/pt/" />

Три помилки. en-uk недійсний, оскільки код країни для Сполученого Королівства — GB, а не UK. sp взагалі не є мовним кодом; іспанська — це es. А pt-PT_BR поєднує два регіони з підкресленням, яке не має значення в hreflang. Пошукові системи мовчки ігнорують неправильно сформовані значення, тому ви не отримуєте помилок і переваг, лише години налагодження, розмірковуючи, чому нічого не змінилося.

Зауважте, що hreflang використовує дефіс (en-GB), тоді як локальні файли WordPress використовують підкреслення (en_GB). Не копіюйте коди імен файлів .po безпосередньо в теги hreflang.

x-default та взаємність зворотних тегів

Два правила викликають більше прихованих збоїв hreflang, ніж будь-що інше: відсутність x-default та порушена взаємність.

Значення x-default повідомляє Google, яку сторінку показувати, якщо жодна інша мова не відповідає користувачеві. Це ваш запасний варіант, зазвичай ваш перемикач мови або домашня сторінка для основного ринку. Воно не є строго обов'язковим згідно зі специфікацією, але на практиці його завжди слід включати. Без нього португаломовний відвідувач, для якого у вас немає португальської версії, отримує випадковий результат замість цілеспрямованого значення за замовчуванням.

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

<!-- On the German page, the set must still list ALL versions -->
<link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/about/" />

Самопосилання (de, що вказує на німецьку сторінку під час перегляду німецької сторінки) є обов'язковим, а не необов'язковим. Набір з п'яти мовних версій означає, що кожна з п'яти сторінок виводить усі п'ять тегів <link> плюс x-default.

Три способи реалізації hreflang у WordPress

У вас є три практичні варіанти, від повного ручного контролю до повністю автоматизованого.

Метод 1: Ручний через wp_head

Для невеликого статичного набору сторінок ви можете вставляти теги hreflang безпосередньо через дію wp_head у файлі functions.php вашої теми:

add_action( 'wp_head', function () {
    if ( ! is_page( 'pricing' ) ) {
        return;
    }
    $alternates = array(
        'en-US' => 'https://example.com/en-us/pricing/',
        'es-MX' => 'https://example.com/es-mx/pricing/',
        'x-default' => 'https://example.com/pricing/',
    );
    foreach ( $alternates as $lang => $url ) {
        printf(
            '<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
            esc_attr( $lang ),
            esc_url( $url )
        );
    }
} );

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

Метод 2: Багатомовний плагін

Якщо ви використовуєте Polylang, WPML або TranslatePress, hreflang генерується автоматично на основі ваших перекладних зв'язків. Це правильне рішення для більшості сайтів, оскільки плагін вже знає, який допис є перекладом якого, тому взаємність та x-default обробляються за вас. Вартістю є накладні витрати часу виконання, які додають ці плагіни, що є компромісом, який ми розглядаємо в нашому порівнянні ручних та ІІ підходів до перекладу.

Метод 3: Карта сайту XML з xhtml:link

Замість того, щоб розміщувати hreflang у <head> кожної сторінки, ви можете оголосити зв'язки у вашій карті сайту XML, використовуючи простір імен xhtml:link. Кожен запис <url> перераховує всі свої мовні альтернативи:

<url>
  <loc>https://example.com/en/about/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/about/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/about/" />
</url>

Це робить HTML вашої сторінки компактним і централізує мовну карту в одному файлі, доступному для сканування, який Google із задоволенням читає. Більшість SEO-плагінів можуть генерувати це автоматично.

hreflang доповнює переклад, а не замінює його

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

Справжнє багатомовне SEO складається з двох рівнів. Рівень вмісту — це ваші перекладені файли .po, .pot, .json та .xliff, що перекладають кожен рядок теми та плагіна на цільову мову. Рівень сигналу — це hreflang, що направляє кожну готову версію до своєї аудиторії. Обидва мають бути міцними. Бездоганний набір hreflang поверх сайту, перекладеного на 40 відсотків, лише гарантує гірший досвід швидше.

Саме тут чистота шару перекладу має найбільше значення. Коли ви перекладаєте файли інтерфейсу, заповнювачі, такі як %s, %1$s та {name}, повинні залишатися недоторканими, інакше ваша "перекладена" німецька сторінка відображатиметься з буквальними токенами %s, які виглядатимуть зламаними як для користувачів, так і для пошукових систем. Конвеєр перекладу, що враховує gettext, з Syntax Locking автоматично захищає ці токени, тому кожна альтернативна сторінка, на яку ви вказуєте hreflang, є справді готовою до виробництва. Оскільки він працює в хмарі за допомогою Smart Batching, ви можете пропустити через нього цілий багатомовний сайт без встановлення плагінів для перекладу, які роздувають час виконання, що обслуговує ці самі сторінки.

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

Готові виправити результати пошуку неправильною мовою на джерелі? Спробуйте SimplePoTranslate безкоштовно — кредитна картка не потрібна. Перекладайте свої файли .po, .pot та .json на безкоштовному рівні, а потім спрямовуйте свої теги hreflang на сторінки, які дійсно готові для кожного ринку.

Пов'язані теми

#WordPress #Локалізація #Продуктивність

Поділитися цією статтею

Facebook X (Twitter)LinkedIn Reddit WhatsApp Email

На цій сторінці

Перекладаєте великий файл?

Не зламайте свій сайт синтаксичними помилками. Використовуйте наш ШІ для безпечної обробки змінних і HTML.

Почніть перекладати безкоштовно

Кредитна картка не потрібна