Как настроить hreflang для мультиязычного сайта WordPress

Если у сайта есть несколько языковых версий, поисковику нужно явно показать, какая страница для какого языка и региона предназначена. Для этого и используют hreflang. Без него Google и другие системы могут показывать не ту версию страницы, смешивать языки в выдаче или считать переводы дубликатами слабо отличающимися страницами.

На WordPress задача обычно сводится не к одной метке в коде, а к правильной организации самих языковых версий: отдельные URL, взаимные ссылки между переводами, корректные канонические адреса и одинаковый набор альтернатив на всех версиях страницы. Если это не выстроить, одна только разметка не спасёт.

Что именно должен делать hreflang на мультиязычном сайте

hreflang сообщает поисковику, что у страницы есть альтернативы на других языках или для других регионов. Например, у русской версии есть английская и немецкая, а у английской — обратные ссылки на русскую и немецкую. Поисковик использует эту связку, чтобы подбирать пользователю подходящую локаль в выдаче.

Для WordPress-сайта это особенно важно, если:

у вас один и тот же контент опубликован на нескольких языках;
языковые версии живут на отдельных URL, а не переключаются только скриптом;
есть не только страницы, но и записи, категории, товары, шаблонные блоки, меню и другие элементы интерфейса;
сайт работает в нескольких странах или на нескольких рынках.

Если у вас просто вставлен машинный перевод в один и тот же URL без отдельных адресов, это не полноценная мультиязычность. Для поисковика такой сайт остаётся одной страницей с разным отображением, а не набором языковых версий.

Как должна выглядеть правильная структура языковых версий

Перед настройкой hreflang нужно выбрать структуру URL. Для WordPress чаще всего используют один из трёх вариантов:

/en/, /de/, /fr/ — подпапки на основном домене;
поддомены вроде en.example.com;
отдельные домены для каждого языка или региона.

Для большинства сайтов на WordPress подпапки проще в поддержке: меньше возни с DNS, SSL и аналитикой, проще связывать версии между собой. Поддомены и отдельные домены имеют смысл, когда у проекта уже есть жёсткое разделение по рынкам, отдельные команды или локальные требования к брендингу и SEO.

Какой бы вариант вы ни выбрали, у каждой языковой версии должен быть свой постоянный URL. Это важно: hreflang не работает как переключатель текста на лету. Он описывает уже существующие страницы.

Что нужно разметить на самом деле

Частая ошибка — добавить hreflang только на главную. На практике разметка должна быть на каждой индексируемой странице, у которой есть переводы. Если у русской статьи есть английская и немецкая версии, то все три страницы должны ссылаться друг на друга через одинаковый набор альтернатив.

Минимальный набор для одной страницы выглядит так:

сама страница указывает на все языковые версии, включая себя;
каждая альтернативная версия делает то же самое;
URL в разметке ведут на канонические адреса, без лишних параметров и редиректов;
код языка используется в формате ISO 639-1, а при необходимости региона — в формате язык-страна, например en-GB или pt-BR.

Если у вас есть отдельные региональные версии, не подменяйте язык регионом. en-US и en-GB — не одно и то же, а en без региона подходит только когда региональная привязка не нужна.

Как настроить hreflang в WordPress без ручной правки шаблона

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

Если вы используете плагин мультиязычности, проверьте, что он умеет:

создавать отдельные URL для языков;
связывать переводы одной сущности между собой;
выводить корректный hreflang в <head>;
работать с записями, страницами, категориями, товарами WooCommerce, если магазин уже есть;
не ломать канонические URL и sitemap.

Если плагин этого не делает, не стоит пытаться «допилить» всё только вручную. На небольшом сайте это ещё возможно, но на проекте с десятками или сотнями страниц вы быстро упрётесь в поддержку и ошибки синхронизации.

Ручная настройка через тему подходит, когда языковых версий немного и структура очень простая. Тогда в head можно вывести набор альтернативных ссылок через хук wp_head. Но такой подход требует аккуратной логики: нужно получать правильные URL всех переводов, не дублировать теги и не забывать обновлять разметку при изменении структуры сайта.

Пример ручного вывода hreflang через wp_head

Этот вариант уместен только если у вас уже есть собственная логика сопоставления переводов. Код ниже показывает принцип, а не готовое решение для любого сайта:

add_action( 'wp_head', function () {
    if ( ! is_singular() ) {
        return;
    }

    $translations = array(
        'ru' => 'https://example.com/ru/page/',
        'en' => 'https://example.com/en/page/',
        'de' => 'https://example.com/de/page/',
    );

    foreach ( $translations as $lang => $url ) {
        printf(
            '<link rel="alternate" hreflang="%s" href="%s" />' . "\n",
            esc_attr( $lang ),
            esc_url( $url )
        );
    }
} );

Такой код нужно адаптировать под реальную структуру сайта: подставлять не статические адреса, а URL конкретной переведённой записи или страницы. Если этого не сделать, вы получите разметку, которая выглядит правильно, но ведёт не туда.

Что проверить после настройки

После внедрения hreflang не ограничивайтесь просмотром исходного кода одной страницы. Проверка должна быть по нескольким уровням.

Откройте русскую, английскую и другие версии одной и той же страницы и убедитесь, что в <head> у всех совпадает набор альтернатив.
Проверьте, что каждый URL отвечает кодом 200, а не редиректит на другую версию или на главную.
Убедитесь, что в разметке нет битых ссылок, лишних параметров и URL с UTM-метками.
Проверьте, что канонический URL указывает на саму страницу, а не на другую языковую версию, если у вас отдельные локализованные страницы.

Для быстрой проверки удобно использовать просмотр исходного кода страницы в браузере и поиск по строке hreflang. Для более точной диагностики лучше смотреть HTML, который отдаёт сервер, а не то, что дорисовал браузер скриптами.

Если сайт уже добавлен в Google Search Console, используйте отчёты по индексированию и проверяйте, как поисковик видит альтернативные страницы. Но не ждите мгновенного эффекта: поисковым системам нужно время, чтобы переобойти сайт и пересобрать связи между версиями.

Типичные ошибки, из-за которых hreflang не работает

На мультиязычных WordPress-сайтах я чаще всего вижу одни и те же проблемы:

Нет взаимности. Русская страница ссылается на английскую, а английская — нет на русскую. Для поисковика это слабая или некорректная связка.
Разные наборы альтернатив. На одной версии есть немецкий URL, на другой его забыли добавить.
Ссылки ведут на редиректы. В разметке указан старый адрес, который потом перенаправляется. Это лишний шум и риск ошибок.
Смешаны язык и регион. Например, на сайте с русским и английским контентом ставят только ru и en, хотя фактически есть отдельные версии для США и Великобритании.
Разметка стоит только на главной. Внутренние страницы остаются без альтернатив, и поисковик не понимает структуру всего сайта.
Переведён только текст, а URL и метаданные остались общими. Тогда поисковику сложнее разделить версии, а пользователю — понять, что он попал на нужную локаль.

Отдельно следите за меню, хлебными крошками, заголовками, метаописаниями и таксономиями. Для мультиязычного сайта это не косметика, а часть общей структуры. Если переведена только статья, но не категория и не навигация, качество локализации будет заметно хуже, чем кажется по одному тексту.

Когда лучше использовать плагин, а когда — ручную разметку

Сценарий	Что выбрать	Почему
Небольшой блог на 2–3 языках	Плагин мультиязычности	Проще связать записи, меню и таксономии без ручной поддержки
Корпоративный сайт с редкими обновлениями	Плагин или ручная настройка	Если страниц немного, можно контролировать разметку вручную, но плагин снижает риск ошибок
Интернет-магазин WooCommerce	Плагин с поддержкой товаров и атрибутов	Нужно переводить не только карточки товаров, но и категории, фильтры, валюту, интерфейс
Сложный проект с несколькими рынками	Плагин и отдельная SEO-логика	Ручная разметка быстро становится хрупкой

Если у вас магазин на WooCommerce, не ограничивайтесь переводом карточек товаров. Для корректной мультиязычности обычно нужно переводить категории, атрибуты, вариации, системные сообщения, письма и часть интерфейса. Иначе hreflang будет указывать на страницы, которые выглядят локализованными только наполовину.

Если вам нужно не просто перевести интерфейс WordPress, а выстроить полноценную локализацию сайта с отдельными URL, переводом контента и корректной SEO-разметкой, лучше сразу выбирать решение, которое закрывает весь сценарий, а не только выводит текст на другом языке. Иначе позже придётся переделывать структуру адресов, связи между страницами и метаданные.

Хорошо настроенный hreflang не делает сайт автоматически «международным» в глазах поисковика, но убирает двусмысленность. Для WordPress это обычно и есть главная задача: дать поисковым системам понятную карту языковых версий и не мешать им редиректами, дублями и неполной разметкой.