Многоязычный сайт: hreflang и выбор адресов

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

Отделите язык от региона

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

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

Выберите структуру адресов

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

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

Выбранный адрес должен открываться напрямую и возвращать одну понятную версию содержания. Язык, который хранится только в cookie, затрудняет обмен ссылками и проверку. Автоматическое определение предпочтений можно использовать для предложения подходящей версии, сохраняя посетителю доступ к остальным.

Соберите карту соответствий до генерации тегов

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

Храните внутренний идентификатор группы независимо от адреса. Тогда смена slug не разрушает связь переводов. Для каждой версии полезны статус публикации, ответственный редактор, дата проверки содержания и признак готовности. Черновик не должен попадать в набор альтернатив только из-за того, что в CMS уже создана пустая запись.

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

Минимальные правила hreflang

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

Для внедрения можно выбрать HTML, HTTP-заголовки или sitemap. Методы эквивалентны с точки зрения Google, поэтому обычно разумнее выбрать один управляемый источник, чем вручную поддерживать три. X-default позволяет обозначить запасную страницу для неподходящих языковых вариантов, например экран выбора версии; это не обязательная замена всем языковым связям.

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

Учебный пример: услуга на двух языках

Представим вымышленную инженерную компанию с русской страницей проектирования и её английским переводом. Адреса условные: example.com/ru/design/ и example.com/en/design/. Компания не разделяет англоязычное предложение по странам, поэтому не создаёт региональные копии без причины. Это учебная схема, а не готовая конфигурация для любого бизнеса.

В CMS обе страницы объединены одним идентификатором услуги. Генератор формирует одинаковый набор альтернатив на каждой версии: русская ведёт на русскую, английская на английскую. Затем тест проверяет доступность обоих адресов, наличие основных текстов и отсутствие запрета индексирования. Переключатель языка ведёт именно на соответствующую услугу.

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

Не заставляйте canonical спорить с языковыми связями

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

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

Дополнительный разбор механизма есть в статье о canonical и дублях. В международном проекте особенно важно не копировать настройки исходной версии вместе с переводом: так в новых страницах остаются старые адреса, домены и изображения.

Переключение должно сохранять контекст

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

Проверьте клавиатурную доступность переключателя и его название для вспомогательных технологий. Основной язык документа задаётся отдельно через HTML lang; W3C объясняет это в рекомендациях по объявлению языка. Hreflang в поисковых связях не заменяет язык самого документа.

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

Проверка локализации шире тегов

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

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

Как принять работу и наблюдать результат

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

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

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

Что делать при удалении перевода

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

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

Официальные источники

• Google: локализованные версии
• Google: мультирегиональные сайты
• Google: объединение дублей
• W3C: объявление языка HTML