РесурсыКак реализовать теги 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 на страницы, которые действительно готовы для каждого рынка.

Поделиться этой статьёй

Facebook X (Twitter)LinkedIn Reddit WhatsApp Email

На этой странице

Переводите большой файл?

Не ломайте свой сайт синтаксическими ошибками. Используйте наш ИИ для безопасной обработки переменных и HTML.

Начать перевод бесплатно

Кредитная карта не требуется