Мультиязычный сайт: локализация, структура и SEO

Как подготовить мультиязычный сайт: выбрать языки, организовать переводы, URL, hreflang, формы и проверку качества перед запуском.

Автор: Арнак Меликян, CTO, 404gen.

Когда мультиязычный сайт решает задачу бизнеса

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

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

Полезный первый документ — короткая карта «аудитория → вопрос → страница → действие → ответственный». В ней видно, есть ли смысл в каждой будущей странице. Если в строке отсутствует ответственный за продолжение обращения, сначала решите организационную проблему. Так локализация получает измеримую задачу, а не превращается в декоративный переключатель в шапке.

Язык и регион — разные настройки

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

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

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

Как определить состав первой языковой версии

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

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

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

Адреса страниц: папки, поддомены или отдельные сайты

У каждой индексируемой языковой страницы должен быть устойчивый адрес. Это позволяет отправить ссылку коллеге, вернуться к ней из поиска и проверить её отдельно. Если один адрес показывает разные тексты только из-за cookie, сложнее объяснить пользователю, какую версию он увидит. Автоматическое определение предпочтения может помогать выбрать язык, но не должно лишать человека явного управления.

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

Как хранить переводы и общие данные

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

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

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

Переводческий процесс: от исходника до публикации

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

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

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

Интерфейс: длина строк, числа и направление письма

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

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

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

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

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

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

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

SEO мультиязычного сайта: связи между версиями

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

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

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

Каталог, документы и изображения тоже локализуются

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

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

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

Формы и обработка обращений

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

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

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

Поиск и навигация внутри языковой версии

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

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

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

Как добавить язык на существующий сайт

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

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

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

Что проверять при приёмке

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

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

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

Стоимость владения и поддержка после запуска

Работы продолжаются после перевода первого набора страниц. Меняются характеристики, документы, формы и предложения; устаревают связанные версии. Для бюджета разделите разработку механики, первоначальную адаптацию и последующее сопровождение содержания. Оценка зависит от числа типов данных, сложности локализации и порядка согласования, поэтому универсальную цену «за язык» без обследования проекта назвать нельзя.

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

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

Как подготовить задачу на мультиязычный сайт

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

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

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

Пример связного языкового маршрута показан в концепте промышленного сайта «Меридиан»: каталог, исполнение и запрос спецификации. Компания, товары и параметры вымышлены; изображения оборудования являются иллюстрациями.

Частые вопросы

Можно ли ограничиться автоматическим переводом сайта?

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

Чем мультиязычный сайт отличается от многорегионального?

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

Что делать, если у страницы пока нет перевода?

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

Нужен ли отдельный домен для каждого языка?

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

Достаточно ли настроить hreflang для SEO?

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

Как понять, что новая языковая версия полезна?

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

Источники и границы разбора

Первичные технические источники проверены 15 октября 2026 года. Они объясняют конкретные механизмы; проектные рекомендации нужно сверять с архитектурой и условиями эксплуатации. Иллюстрация обложки создана с помощью ИИ и не является снимком клиентского продукта. Учебные ситуации не описывают достигнутые результаты клиентов 404gen.

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