Hreflang для SEO: алгоритм диагностики ошибок языковых версий
Когда посетитель из Казахстана ищет условия доставки и попадает на российскую версию магазина, а Google показывает английскую страницу вместо русской — проблема часто не в синтаксисе тегов hreflang, а в этапах, предшествующих их генерации. Наличие разметки ещё не гарантирует, что отношения между версиями описаны верно. Ошибка может кроться в карте переводов, доступности URL или правилах автоматического перенаправления. Ниже представлен алгоритм диагностики, который переводит абстрактную жалобу «hreflang не работает» в конкретный список исправлений.
Фиксация пользовательского симптома: три типа несоответствия в выдаче
В технических заданиях фраза «исправить hreflang» часто появляется до описания самой неисправности. Первым шагом нужно зафиксировать наблюдение: запрос, поисковую систему, страну проверки, язык интерфейса, дату, показанный URL и адрес, на который человек попал после перехода. Последние два адреса могут различаться, и от этого зависит направление проверки.
Разделяют три симптома, каждый из которых требует отдельного ответственного и критерия исправления:
- В выдаче показана другая языковая или региональная страница — задача для SEO-специалиста, проверяющего индексацию и ранжирование.
- После перехода правильный адрес меняется на неподходящий — задача для разработчика, отвечающего за логику перенаправлений на сервере.
- Адрес остаётся правильным, но предложение внутри страницы не соответствует рынку (цены, доставка, ассортимент) — задача для продуктовой команды и редакторов.
Если нужной страницы вообще нет в индексе, один hreflang не устранит причину её отсутствия. Чёткое разделение симптомов исключает ситуацию, когда разработчик проверяет синтаксис, маркетолог ждёт изменения продаж, а задача остаётся без общего определения результата.
Разделение параметров: язык, регион и содержание предложения
Русскоязычный посетитель не обязательно находится в России. Англоязычная страница не обязательно предназначена для США. Поэтому перед разметкой нужно описать, чем версии отличаются для покупателя: языком, валютой, ассортиментом, доступностью доставки, условиями договора.
Google рекомендует отдельные URL для языковых версий и определяет язык по видимому содержимому. Сам по себе путь
Предположим, у компании есть русская и английская инструкции по настройке одного сервиса — это понятная пара переводов. А российская страница доставки и казахстанская страница доставки описывают одну задачу, но разные условия. Для карты соответствий важны оба случая. Если в новом разделе перевели меню, но оставили старые описания, цены и ограничения, технически аккуратная связь не исправит неполную локализацию. Прежде чем размечать такую страницу, нужно проверить её пригодность для заявленной аудитории.
Построение карты соответствий до генерации тегов
Основа надёжной реализации — стабильный идентификатор материала, товара или услуги, общий для его локальных вариантов. URL может измениться, а связь должна сохраниться. Поэтому соответствия лучше хранить в CMS или отдельном реестре, а не получать их простой заменой
Для аудита достаточно таблицы со столбцами: идентификатор сущности, локаль, URL, тип страницы, статус перевода, доступность предложения, дата проверки и владелец содержимого. Отдельно добавляют технические результаты: HTTP-статус, конечный URL после редиректов, canonical и список альтернатив.
Например, для услуги
Отдельная проверка нужна для товаров. Одинаковое название ещё не доказывает идентичность предложения: могут различаться комплектация или модель. Решение о соответствии должен подтвердить владелец каталога. Именно здесь полезна совместная работа SEO, редактора и продуктовой команды.
Техническая валидация hreflang: взаимные связи и коды локалей
Для Google каждая версия должна указывать на себя и альтернативы полными URL. Связи должны быть взаимными. Код состоит из языка и, при необходимости, региона: например,
Условная группа из двух переводов выглядит так:
Эту же пару нужно проверить на обеих страницах, включая ссылку каждой на себя. Для HTML-реализации элементы
размещаются в
Практично проверять три уровня: допустимость кодов и адресов, совпадение фактических ссылок с картой соответствий, обратные связи. Так можно отличить опечатку в шаблоне от неверного сопоставления материалов. Не стоит добавлять регион только потому, что его можно указать. Если английская инструкция одинакова для всех рынков, сначала обоснуйте необходимость отдельных региональных URL. Чем больше вариантов создаёт команда, тем больше содержимого и связей ей придётся поддерживать после каждого изменения.
Различия внедрения для Google и Яндекс: HTML, заголовки, Sitemap
Google поддерживает три равнозначных способа указания языковых вариантов: HTML, HTTP-заголовки и Sitemap. Одновременная реализация всех трёх не даёт дополнительного преимущества и усложняет сопровождение. Это прямо отмечено в описании способов разметки.
В актуальной справке Яндекса о локализованных страницах есть предупреждение: Sitemap больше не поддерживается для указания языковых версий; рекомендуется разметка страниц через
в
Отсюда практическое решение: если HTML-сайт должен обслуживать обе поисковые системы, выбирают разметку в
Проверка доступности URL, редиректов и согласованности canonical
Следующий проход аудита — доступность всех адресов из карты. Рекомендуется сохранить для каждого URL исходный ответ, цепочку перенаправлений, конечную страницу и её видимое содержимое. Проверка только конечного ответа 200 может скрыть то, что несколько разных альтернатив привели в один общий раздел.
Отдельно сопоставляют
Для самостоятельных полноценных переводов проверяют согласованность
В отчёте полезно сохранять не только флаг «ошибка», но и объяснение: «английская инструкция ссылается на русскую главную» или «альтернатива перенаправляется на другой товар». Так разработчик получает воспроизводимый дефект, а редактор понимает, где требуется решение по содержимому.
Тестирование автоматического выбора языка без сохранённых настроек
Один URL, меняющий содержимое по IP или языку браузера, труднее проверить. У сотрудника сохранены cookies, он всегда видит нужный вариант и не замечает поведения для нового посетителя.
Google предупреждает, что не все варианты
Минимальный сценарий приёмки: открыть каждую версию без сохранённых настроек, проверить прямой вход по ссылке, вручную сменить язык, затем вернуться на исходную страницу. Повторить на нескольких типах страниц, включая глубокую инструкцию и товар, отсутствующий на одном рынке.
Пользователь должен понимать, почему ему предлагают другую версию, и сохранять возможность выбора. Ненавязчивое предложение сменить рынок часто проще проверить, чем безусловный редирект. Конкретное решение зависит от юридических и продуктовых требований сайта; SEO-проверка не заменяет их анализ.
Вопросы и ответы
Почему не стоит сразу генерировать hreflang, не создав карту соответствий?
Без карты соответствий команда опирается на эвристику замены сегментов URL (например,
В чём принципиальное отличие требований Google и Яндекс к способу внедрения hreflang?
Google считает равнозначными HTML-разметку, HTTP-заголовки и Sitemap, не давая преимущества одновременному использованию. Яндекс в актуальной справке прямо указывает: Sitemap больше не поддерживается для языковых версий, рекомендуется разметка через
в
Как проверить автоматический выбор языка, не видя сайт «глазами нового пользователя»?
Нужно открыть каждую версию в чистом браузере без сохранённых cookies и настроек, проверить прямой вход по ссылке, вручную переключить язык и вернуться на исходную страницу. Повторить на разных типах страниц: глубокая инструкция, товар, отсутствующий на одном рынке. Только так воспроизводится поведение для посетителя без истории и для роботов, которые запрашивают страницы без заголовка