Многоязычный сайт: как согласовать языки, URL и обновление переводов

Начните с задачи языковой версии, а не с количества языков

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

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

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

Разделите язык, страну и условия обслуживания

Русскоязычный посетитель не обязательно находится в России, а англоязычный — в Великобритании. Язык интерфейса, территория обслуживания, валюта и договорные условия — разные поля. Не выводите одно из другого только по выбранному значку. Флаг обозначает страну и часто создаёт лишнюю неоднозначность; понятное название языка обычно точнее объясняет переключение.

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

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

Составьте карту языковых URL до вёрстки

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

Связывайте переводы через постоянный идентификатор материала. Адрес может измениться, а связь «описание этой услуги на другом языке» должна сохраниться. Хранение пары только в названии страницы или в совпадающем окончании URL становится ненадёжным, когда редактор меняет структуру или переводит сам адрес.

Это модель будущих адресов, а не существующие разделы badriklab.ru. В рабочей карте добавьте владельца, статус перевода и допустимое действие при отсутствии пары. Смена языка из карточки услуги не должна незаметно уводить на главную страницу другого языка и заставлять искать материал заново.

Связывайте соответствующие материалы, а не любые страницы

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

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

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

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

Согласуйте canonical, hreflang и язык документа

Эти настройки решают разные задачи. Canonical указывает предпочтительный URL для документа; hreflang связывает языковые или региональные варианты; lang описывает язык HTML. Последнее отдельно объясняет справочник MDN. Наличие одного атрибута не заменяет содержимое или остальные настройки.

Для самостоятельных переведённых страниц в нашей модели canonical у каждой версии ведёт на неё саму. Не ставьте во всех переводах ссылку на русский оригинал по правилу «он главный». Решение о дублях требует отдельного анализа; назначение canonical разобрано в материале о sitemap, robots.txt и canonical.

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

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

Не считайте XML единственным универсальным местом для языковых связей. Google описывает несколько способов, а документация Яндекса предупреждает, что sitemap для языковых версий больше не поддерживается. В нашем примере связи находятся в HTML head; обычный sitemap и его URL проверяются отдельно.

Сделайте переключение языка предсказуемым

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

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

Если перевода ещё нет

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

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

Назначьте источник текста и владельца каждого перевода

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

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

Автоматический перевод можно обсуждать как этап подготовки черновика. Перед выпуском человек проверяет терминологию, смысл, факты и возможность выполнить действие. Нельзя объявлять материал проверенным только потому, что сервис вернул текст. Не отправляйте во внешний переводчик приватные обращения или закрытые документы без отдельного разрешения.

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

Определите, что происходит после изменения оригинала

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

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

В исходном учебном наборе общая версия материала — 2, а у перевода хранится отметка, с какой версией он согласован. Несовпадение блокирует нашу внутреннюю приёмку. Это проверка редакторской дисциплины, не требование hreflang и не сигнал, который сам по себе видит поисковая система.

Рабочий пример: девять проверок пяти учебных страниц

Мы выполнили девять сценариев на локальном HTTP-сервере: две пары RU/EN — услуга и контакты — и одну русскую новость без перевода. В каждом сценарии проверяющий сделал шесть HTTP-запросов: пять существующих адресов и отсутствующий /en/news/. Всего получено 54 ответа. Запросов к внешним сайтам не было; данные и тексты специально созданы для обучения.

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

Скачать учебный пример и инструкцию. Нужен Python 3 со стандартной библиотекой. Распакуйте архив и выполните python3 hreflang-example.py. Скрипт запускает сервер только на 127.0.0.1 со свободным портом, выполняет сценарии, останавливает сервер и записывает результат в evidence/hreflang-example-result.json. Установка пакетов, доступ к вашей CMS и настоящие обращения не нужны.

Что этот пример не доказывает

Проверяющий знает только учебный контракт ru, en и x-default; он не заменяет полный справочник кодов. Он также не определяет язык основного текста, не оценивает перевод и не проверяет индексирование. Соответствие lang реестру нельзя выдавать за подтверждение, что все абзацы написаны на правильном языке. Рабочий сайт дополнительно проверяют редактор и ответственный за его реальную конфигурацию.

Принимайте языковую версию по маршруту посетителя

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

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

Выпускайте согласованный набор страниц и зависимостей

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

Проверяйте финальные документы после всех плагинов и преобразований. Шаблон может быть верным, а другой генератор — перезаписать canonical, список альтернатив или OG-картинку. Сопоставьте видимый язык, адрес, поисковое описание и карточку для отправки в мессенджер. Подпись на обложке тоже относится к содержанию версии.

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

Наблюдайте за актуальностью, а не только за индексацией

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

В поисковых системах проверяйте фактическое состояние нужных URL отдельно. Корректные теги не гарантируют включение в индекс, позиции, трафик или цитирование AI-системами. Если версия не достигает своей задачи, различите техническую проблему, непонятное предложение и отсутствие подходящего спроса. Для каждого объяснения нужны собственные данные.

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