Hreflang: как связать языковые версии без подмены содержания

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

Hreflang связывает страницы одного смысла на разных языках: каждая версия указывает на себя и на все альтернативы, ссылки взаимны, коды языков и регионов валидны. Canonical по умолчанию указывает на собственный URL, sitemap содержит только реально доступные адреса. Переключатель языка строится из той же матрицы соответствия, что и разметка.

В гипотетическом сценарии: интернет-магазин мебели с филиалом в Алматы добавляет казахскую версию. Переключатель в шапке ведёт на главную, часть карточек товаров остаётся только на русском, а в sitemap указаны URL, которые отдают 404. Робот обходит всё это, и в выдаче появляются дубли и пустые страницы. Сцена условная, но она точно описывает, почему языковые версии ломаются не из-за перевода, а из-за рассинхронизации адресов и связей между ними.

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

Матрица соответствия страниц вместо списка переводов

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

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

Таблица выше — условный пример структуры, а не данные конкретного сайта. Ключевое в ней — колонка «Статус связи»: она говорит разработчику, какие hreflang-пары вообще имеют право существовать. Всё, что помечено «изолирована», не получает обратных ссылок на несуществующие переводы.

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

Почему переключатель языка — не то же самое, что hreflang

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

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

Обратные ссылки: симметрия, которую легко потерять

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

Проверять симметрию вручную по сотням URL бессмысленно. Нужен скрипт или регулярная выгрузка, которая для каждой пары проверяет: есть ли A → B и B → A, совпадают ли коды языков и регионов, нет ли ссылок на несуществующие адреса. Ниже — форма рабочего объекта, которую удобно хранить в репозитории рядом с шаблонами.

{
  "page_id": "service-delivery",
  "variants": [
    {"lang": "ru-RU", "url": "https://example.com/dostavka"},
    {"lang": "kk-KZ", "url": "https://example.com/kk/dostavka"},
    {"lang": "en-US", "url": "https://example.com/en/delivery"}
  ],
  "canonical": "self",
  "status": "linked",
  "checked_at": "2026-01-01"
}

Такой объект — единый источник правды: из него генерируется и разметка в <head>, и переключатель, и записи в sitemap. Когда все три вещи растут из одного файла, рассинхронизация становится технически невозможной, а не «вопросом внимательности».

Canonical, который склеивает версии

Отдельная ловушка — canonical. Если на казахской странице стоит canonical на русскую версию, вы фактически говорите: «эта страница — дубль, не индексируй её». Иногда это осознанное решение (например, при почти идентичном контенте), но чаще — копипаст шаблона. В результате языковая версия существует, но в выдаче не появляется, и бизнес недоумевает, почему «перевод не работает».

Рекомендация: по умолчанию каждая языковая версия канонизирует саму себя. Склейка через canonical оправдана только тогда, когда контент действительно совпадает и вы сознательно не хотите его показывать отдельно — и это решение стоит фиксировать в матрице, а не оставлять на волю шаблона. Официальная документация Google по локализованным версиям прямо описывает, как hreflang и canonical должны сочетаться, и это стоит прочитать перед правками: Localized versions.

Локальный редирект, который перебивает язык

Ещё один конфликт живёт на уровне сервера. Автоматический редирект по геолокации IP часто отправляет пользователя из Казахстана на казахскую версию, даже если он пришёл по прямой ссылке на русскую. Для человека это раздражает, для робота — создаёт путаницу: краулер, обходящий сайт из другого региона, видит не тот контент, что указан в hreflang. Связи начинают указывать на URL, который отдаёт редирект.

Проверка здесь простая: обойти каждую пару из матрицы с явным указанием заголовка Accept-Language и без него, и убедиться, что прямой URL отдаёт 200 и тот язык, который заявлен. Если редирект неизбежен, он не должен срабатывать на явно запрошенный языковой URL. Это вопрос поведения сервера, и его стоит согласовать с тем, кто отвечает за конфигурацию, а не решать «на глаз».

Язык страницы и язык разметки расходятся

Бывает, что hreflang заявляет kk-KZ, а в самом HTML стоит <html lang="ru">, или текст наполовину на русском. Робот получает противоречивые сигналы: разметка говорит одно, содержимое — другое. Это не всегда фатально, но снижает доверие к связям и мешает корректному определению языка.

Здесь помогает дисциплина на уровне шаблона: атрибут lang берётся из того же объекта-источника, что и hreflang. А для страниц с частичным переводом (меню перевели, а текст нет) стоит честно решить: либо это ещё не языковая версия и её не связывают, либо контент доводят до состояния, когда связь оправдана. Полуперевод, выставленный как полноценная альтернатива, — источник и пользовательского, и поискового раздражения.

Sitemap и реально доступные адреса

Sitemap часто живёт отдельной жизнью от разметки. В него попадают URL, которых нет, или, наоборот, новые языковые версии туда не добавляются. Требования к карте сайта описаны в документации: Build and submit a sitemap. Главное для нашей задачи — sitemap должен содержать только те адреса, которые отдают 200 и соответствуют матрице. Ссылка на несуществующую страницу — это не «мелкий недочёт», а сигнал о качестве сайта в целом, о чём говорит и Google Search Essentials.

Практика: генерировать sitemap из того же объекта-источника, что и разметку. Тогда невозможно добавить в карту URL, которого нет в матрице, и наоборот. Регулярная сверка «матрица ↔ sitemap ↔ ответы сервера» закрывает большинство проблем до того, как их заметит робот.

Два эпизода: как это ломается на практике

Первый эпизод условный. Компания переводит раздел «Услуги» на английский, но не переводит статьи блога. Разработчик по привычке ставит в шаблон блога блок hreflang со ссылкой на /en/blog/..., которых не существует. Робот обходит русскую статью, видит ссылку на 404, и связь рвётся. Хуже того, в sitemap попадают эти же несуществующие адреса. Исправление: блок hreflang рендерится только для страниц, у которых в матрице есть реальные варианты, а sitemap собирается из той же матрицы.

Второй эпизод тоже условный. Интернет-магазин добавляет казахскую версию, но canonical в шаблоне остаётся захардкоженным на русский URL. Казахские страницы существуют, отдают 200, связаны обратными hreflang, но канонизируют себя на русские. В итоге они не индексируются как самостоятельные. Диагностика занимает минуты, если есть матрица и скрипт сверки: скрипт показывает, что canonical не равен собственному URL. Исправление — одна строка в шаблоне, но найти её без системной проверки сложно.

Связь языковых версий на экране сотрудника

Разработчику удобны JSON и скрипты, но решения о том, какие страницы связывать, принимает контент-менеджер или маркетолог. Ему нужен не код, а понятный экран: список смысловых страниц, для каждой — какие языки есть, какие связи активны, что сломано. Ошибки стоит показывать человеческим языком: «казахская версия страницы „Доставка“ не имеет обратной ссылки на русскую», а не «hreflang mismatch on line 42».

Хороший интерфейс позволяет отметить страницу как «перевод в работе» и автоматически исключить её из связей и sitemap до готовности. Это снимает главный конфликт: желание показать всё сразу против необходимости не плодить битые связи. Сотрудник не должен помнить правила — система подставляет их из матрицы и подсвечивает расхождения.

Связь языковых версий: исключения и проверка условий

Не всё укладывается в матрицу. Например, региональные варианты одного языка: ru-RU и ru-KZ с почти одинаковым контентом, но разными ценами и условиями доставки. Здесь hreflang с региональными кодами уместен, но canonical должен оставаться собственным, иначе один регион «съест» другой. Другой случай — страницы, которые есть только на одном языке, но должны быть доступны всем: их не связывают, а оставляют как есть, и это нормально.

Отдельное исключение — контент, который нельзя переводить дословно (юридические тексты, названия товаров). Здесь решение о связывании принимает не разработчик, а тот, кто отвечает за содержание, и фиксирует его в матрице с пометкой. Правило простое: если сомневаетесь, связывать ли страницы, — не связывайте, пока не появится ясность. Лишняя связь вреднее отсутствующей.

Тесты перед публикацией

Проверку стоит превратить в набор повторяемых тестов, а не в разовую ручную вычитку. Минимальный набор: для каждой пары из матрицы обе страницы отдают 200; hreflang взаимны; коды языков и регионов валидны; canonical указывает на себя (если не решено иначе); URL из sitemap существуют; прямой запрос языкового URL не редиректит. Эти тесты можно гонять в CI при каждом изменении шаблонов.

Таблица условная по составу, но логика универсальна: чем раньше расхождение поймано, тем дешевле исправление. Ручная проверка хороша для новых типов страниц, автоматическая — для всего остального.

Практикум: собираем матрицу для сайта с тремя языками

Возьмём условный сайт услуг по ремонту с версиями на русском, казахском и английском. Задача — связать существующие страницы, не выдумывая переводов. Шаг первый: выгрузить все URL и сгруппировать их по смыслу, а не по языку. Шаг второй: для каждой группы отметить, какие языки реально есть. Шаг третий: для групп с двумя и более языками прописать взаимные hreflang и проверить canonical. Шаг четвёртый: группы с одним языком оставить изолированными и убрать из шаблона любые ссылки на несуществующие переводы.

Шаг пятый — сгенерировать sitemap из матрицы и прогнать тесты из предыдущего раздела. Шаг шестой — настроить экран для контент-менеджера, где видно статус каждой группы. На этом цикл замыкается: изменения в содержании проходят через матрицу, а не мимо неё. Дальше — регулярная сверка, потому что сайт живёт и меняется.

Что проверить в первую очередь на своём сайте

Начните с одной вещи: откройте переключатель языка на трёх-четырёх разных типах страниц (главная, категория, карточка, статья) и проверьте, ведёт ли он на ту же страницу на другом языке или на главную. Если на главную — у вас уже есть расхождение между навигацией и реальными связями, и это первое, что стоит починить. Дальше — сверка hreflang на симметрию и canonical на самореференцию.

Итог простой: языковые версии ломаются не от плохого перевода, а от рассинхронизации адресов, связей и canonical. Матрица соответствия, единый источник для разметки, sitemap и переключателя, плюс повторяемые тесты — это и есть решение исходной задачи. Один конкретный шаг проверки: возьмите переключатель языка на странице услуги и пройдите по нему — если он ведёт не туда, начните с матрицы, а не с перевода.

Проверка одной пары страниц перед массовой разметкой

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

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

Отдельно проверьте случай отсутствующего перевода. Если французской версии конкретной инструкции пока нет, не нужно подставлять французскую главную как будто это её эквивалент. Состав группы должен отражать существующие соответствующие страницы. Когда перевод появится, обновляют согласованный набор связей и повторно проверяют обратные указания. Значение x-default, если оно применимо в выбранной архитектуре, обозначает запасной вариант для пользователей без совпадения языка, а не исправляет отсутствие содержательного перевода.

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

Смежный вопрос разобран отдельно: Перенос сайта с сохранением SEO: карта URL до переключения.