Hreflang: настройка и проверка языковых версий сайта

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

Когда сайту нужен hreflang

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

Если сайт полностью одноязычный и альтернатив нет, список вымышленных версий не создаёт международное присутствие. Сначала нужны содержание и возможность обслужить посетителя. Переведённые кнопки вокруг прежнего текста также не заменяют редакторскую проверку основного материала.

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

Карта соответствий для hreflang

Создайте реестр групп: одна группа представляет один материал или одно сопоставимое предложение. Внутри неё перечислите существующие локализации. Полезно опираться на постоянный внутренний ID материала, поскольку перевод заголовка и смена пути могут разрушить сопоставление по названию.

Не связывайте все английские страницы со всеми русскими. Совпадение языка задаёт лишь один признак. Английская карточка доставки должна соответствовать той же услуге, а не общей главной странице только потому, что другая ссылка пока неизвестна.

Проверяйте смысл соответствия

Откройте варианты рядом. Сравните предмет, назначение и существенные условия. Если в одной версии описана подписка, а в другой разовая услуга, уточните продуктовую логику. Технически правильная ссылка не исправляет неверное редакторское сопоставление.

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

Основные правила hreflang для Google

Документация Google о локализованных версиях допускает HTML в head, HTTP-заголовок Link и XML Sitemap. Методы равнозначны; одновременное использование всех трёх не даёт отдельного преимущества. В группе указывают абсолютные адреса, собственную версию и альтернативы, поддерживая обратные связи.

Код начинается с языка; регион при необходимости добавляют после дефиса. Например, en обозначает английский без конкретного региона, en-GB — английский для Великобритании. Нельзя заменить язык только страной или использовать en-UK вместо подходящего кода. Google определяет язык по содержимому, а не по самому hreflang.

Для HTML строка выглядит так: <link rel="alternate" hreflang="en" href="https://example.com/en/service/">. Здесь адрес учебный. Код показан как текст примера: вставка в видимый абзац статьи не настраивает head страницы. Реализацию проверяют в фактически отдаваемом документе.

Отдельно решите, нужен ли x-default

Google поясняет применение x-default для посетителей, чьи языковые настройки не совпадают с указанными версиями. Назначением может быть подходящая страница выбора. Не копируйте адрес корня сайта во все группы без проверки: человек должен понимать, какое предложение он выбирает и как продолжить путь.

Решение о запасном назначении внесите в реестр. Проверьте, понятно ли посетителю, где выбрать вариант и как вернуться к нужному предложению.

Как выбрать способ внедрения hreflang

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

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

• Кто создаёт и подтверждает новую локализацию?
• Где хранится принадлежность страницы к группе?
• Когда URL считается готовым для публичной связи?
• Как изменение пути попадает в опубликованные сведения?
• Кто удаляет связь при снятии версии?
• Как команда проверяет результат после обновления?

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

Как работать с неполными переводами

Предположим, услуга А готова на русском, английском и немецком, а услуга Б — только на русском и английском. Это две группы разного размера. Не создавайте немецкий URL услуги Б, который открывает английскую копию или главную страницу, лишь ради одинакового числа строк.

Заведите состояния «планируется», «редактируется», «готово» и «снято». Публичные связи формируются из подтверждённых вариантов. Такой порядок помогает не путать отсутствие перевода с техническим сбоем и заранее определять, что произойдёт после его публикации.

Изменение предложения на одном рынке

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

При временном отсутствии продукта согласуйте поведение страницы с владельцем предложения. Нельзя поручать шаблону угадывать бизнес-решение. В реестре должно быть ясно, сохраняется ли локализованный материал, заменяется ли он и кто подтвердил новое назначение.

Как проверить hreflang перед выпуском

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

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

Ищите причину на правильном уровне

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

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

Как посчитать объём настройки

Учебный пример: у 20 материалов 12 групп содержат по три языковые версии, а 8 групп — по две. Всего опубликовано 12 × 3 + 8 × 2 = 52 URL. Если в каждой версии перечислены все участники её группы вместе с ней самой, трёхъязычная группа даёт 9 аннотаций, двуязычная — 4.

Итого получится 12 × 9 + 8 × 4 = 140 аннотаций. В этом расчёте нет x-default и других дополнительных назначений. Число 140 не означает 140 страниц или 140 независимых материалов. Оно помогает проверить полноту ожидаемой выгрузки для указанной модели.

При добавлении новой версии пересчитайте затронутую группу и проверьте существующие страницы, а не только новую. Иначе в реестре появится перевод, но старые варианты продолжат отдавать прежний состав. Ожидаемое количество удобно как сигнал, после которого всё равно проверяются конкретные пары.

Как поддерживать hreflang после запуска

Включите проверку групп в выпуск перевода, смену адреса, объединение материалов и снятие предложения. Владелец содержания отвечает за смысловую связь, разработчик — за её публикацию, SEO-специалист — за техническую приёмку и наблюдение.

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

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

Вопросы и ответы