Практическое руководство по международной архитектуре сайта производителя: языки и рынки, домены и URL, hreflang, локализация каталога, единицы, документы и экспортные заявки.
Мультиязычный сайт производителя — это не русская версия, которую однажды перевели на английский. Для экспортного B2B он должен одновременно объяснять продукт на языке местного закупщика, учитывать рынок поставки и сохранять единые технические данные. Если просто размножить страницы через автоперевод, компания получает несколько похожих сайтов, которыми трудно управлять, а покупатель — цены, документы и контакты, не относящиеся к его стране.
Я начинаю такой проект не с выбора плагина перевода, а с карты рынков. Нужно понять, кому продаёт производитель, какой ассортимент доступен в каждой стране, кто отвечает на запрос, какие единицы измерения и документы ожидает клиент. Только после этого имеет смысл проектировать URL, `hreflang`, каталоги и формы.
В этой статье я разбираю именно международную архитектуру сайта производителя: языковые и региональные версии, SEO, локализацию продукта, документацию и экспортные обращения. Общую структуру промышленного сайта здесь намеренно не повторяю.
Язык отвечает на вопрос «как человек читает страницу», а регион — «для какого рынка действует предложение». Это разные измерения. Английскую страницу могут читать в Великобритании, ОАЭ, Индии и Казахстане, но условия поставки, сертификаты, валюта, минимальная партия и контактное лицо будут различаться.
Поэтому до разработки я составляю матрицу версий.
Эта таблица быстро выявляет ложную простоту. Если русская и английская версии отличаются только текстом, достаточно языковых URL. Если английская версия для Великобритании и английская версия для ОАЭ показывают разный ассортимент и разные условия, это уже региональные страницы.
У международного сайта обычно есть три рабочих варианта: национальные домены, поддомены или подкаталоги. Универсально лучшего решения нет.
Для первого экспортного запуска я чаще выбираю подкаталоги на общем домене: авторитет и техническая платформа не дробятся, а команде проще поддерживать каталог. Национальные домены оправданы, когда за ними стоит реальная локальная деятельность, а не надежда получить позиции одной только доменной зоной.
Параметры вроде `?lang=de` для основных индексируемых версий я не использую. Язык или регион должны иметь стабильный адрес, который можно открыть, передать, проиндексировать и связать с альтернативами.
Языковой переключатель должен вести не на главную выбранного языка, а на эквивалент текущей страницы. Покупатель, который изучает конкретную модель, ожидает увидеть ту же модель, а не начинать путь заново.
Для этого каждой сущности нужен постоянный внутренний идентификатор. Например, одна серия оборудования хранится как единый объект, а её названия, описания, документы и условия публикации задаются по рынкам. Тогда система знает, что `/ru/catalog/seriya-a/` и `/en/catalog/series-a/` — версии одной сущности.
Не у каждой страницы обязана быть полная пара. Если продукт не поставляется в Германию, нельзя связывать русскую карточку с немецкой категорией или похожей моделью только ради заполненного `hreflang`. В немецкой версии лучше показать честное отсутствие позиции, предложить допустимый аналог либо вообще не создавать страницу.
`hreflang` помогает поисковой системе выбрать подходящую языковую или региональную версию. Он не заменяет перевод, не гарантирует позиции и не исправляет слабый контент.
Для каждой группы эквивалентных страниц я соблюдаю четыре правила:
1. Каждая версия указывает на себя и на все доступные альтернативы.
2. Связи взаимны: если английская страница указывает русскую, русская должна указывать английскую.
3. В `href` используются полные абсолютные URL с `https://`.
4. Код сначала обозначает язык, а при необходимости — регион: `en`, `de`, `en-GB`, `en-AE`.
Пример для русской, общей английской и немецкой версий:
`x-default` я использую для нейтральной страницы выбора рынка или версии, которая предназначена для пользователей без точного соответствия. Это не замена основной языковой версии.
Аннотации можно разместить в HTML, HTTP-заголовках или XML-карте сайта. Я выбираю один способ, который команда способна автоматически поддерживать. Дублировать одну и ту же логику сразу в трёх местах обычно означает утроить вероятность расхождений.
Распространённая ошибка — поставить на все переводы canonical русской страницы. Так разработчик фактически сообщает, что локальные URL не являются предпочтительными.
Если страницы переведены и предназначены для индексирования, каждая обычно получает canonical на собственный URL, а связь между версиями задаётся через `hreflang`. Исключение возникает при реальных дублях на одном языке для нескольких регионов: там выбор канонической версии нужно принимать отдельно, учитывая содержание и коммерческую задачу.
Я проверяю связку целиком:
Автоматический жёсткий редирект по IP или языку браузера выглядит удобным, но часто мешает. Закупщик может находиться в одной стране и отвечать за другую. Представитель головного офиса может проверять страницу зарубежного подразделения. Поисковый робот тоже не обязан приходить из целевого региона.
Вместо принудительного перенаправления я показываю ненавязчивое предложение: «Похоже, вам нужна версия для Германии — перейти?». Явный переключатель языка и рынка остаётся доступным на каждой странице, а выбор пользователя можно запомнить.
Ссылки переключателя должны быть обычными HTML-ссылками. Выпадающий список, который меняет содержимое только через JavaScript и cookie, не создаёт надёжной структуры для обхода.
Профессиональный перевод терминов необходим, но для экспортного сайта этого недостаточно. Локализация затрагивает сам продуктовый ответ.
На каждом рынке я проверяю:
Переводчик может идеально передать фразу, но не знает, что в конкретной стране модель продаётся только через дистрибьютора. Поэтому публикацию должны принимать вместе редактор языка, продуктовый специалист и сотрудник, отвечающий за рынок.
Единицы нельзя заменять поиском по тексту. Значение должно храниться отдельно от единицы и правила преобразования. Для одного рынка мощность может привычно показываться в кВт, для другого дополнительно в hp; размеры — в миллиметрах и дюймах; температура — в °C и °F.
Я придерживаюсь трёх правил:
1. Исходное инженерное значение сохраняется без изменений.
2. Конвертированное значение показывается рядом, а не подменяет исходное.
3. Округление и допустимая точность задаются для конкретного параметра.
Это особенно важно для диапазонов, допусков, резьб, давления и производительности. Ошибка локализации здесь может превратиться из SEO-недочёта в ошибку подбора. Таблица характеристик должна быть понятна человеку и доступна текстом в HTML, а не только на чертеже.
Производители часто переводят страницы, но оставляют общий каталог PDF без пояснений. Покупатель не понимает, действует ли сертификат в его стране и относится ли инструкция к текущей модификации.
Для каждого документа я храню:
PDF нельзя считать полноценной заменой HTML-страницы продукта. На странице должны оставаться ключевые характеристики, область применения и сведения о документе. Для альтернативных языковых PDF при необходимости можно передавать языковые связи через HTTP-заголовок, но на практике важнее сначала навести порядок в версиях и привязках.
Одинаковая форма на всех языках часто отправляет заявки в общий ящик, где часть обращений теряется. На этапе проектирования я описываю маршрут: рынок → продукт → тип запроса → ответственное подразделение → резервный получатель.
Форма запроса КП может собирать:
Не стоит требовать двадцать полей для первого контакта. Технический опросный лист можно открыть после выбора сложной категории или предложить как второй шаг. При этом пользователь должен заранее понимать, кто получит данные и в какой стране они будут обрабатываться.
На странице контактов я показываю не декоративный список офисов, а зону ответственности: какие страны обслуживает подразделение, на каких языках отвечает, какие категории ведёт и когда работает.
В одном из архивных мультиязычных проектов для мясоперерабатывающего предприятия главная сложность была не в переводе интерфейса. Разные рынки требовали разной подачи номенклатуры, упаковки, документов и контактов. Если бы мы построили версии как независимые копии страниц, данные начали бы расходиться после первого же обновления ассортимента.
Практический вывод, который я использую до сих пор: сначала проектируется единая продуктовая модель, затем правила доступности и локальные поля, и только после этого — страницы. Общими остаются внутренний код продукта, базовые характеристики и связи. Локальными становятся название, описание, документы, упаковка, коммерческие условия и маршрут обращения.
Такой подход не исключает ручную редактуру. Наоборот, он отделяет то, что должно синхронизироваться автоматически, от того, за что отвечает эксперт конкретного рынка.
Перевод русского запроса не равен реальному запросу зарубежного закупщика. В другой стране могут использовать иной отраслевой термин, сокращение, стандарт или способ описания задачи. Поэтому семантика строится на языке рынка: поисковые подсказки, выдача, сайты конкурентов, отраслевые каталоги, вопросы отдела продаж.
Я распределяю спрос по тем же бизнес-сущностям, но не требую полного зеркала:
Если на одном языке есть устойчивый спрос на отдельную задачу, для неё может появиться самостоятельная страница, даже если точного аналога в русской версии нет. Главное — не включать её в группу `hreflang` с нерелевантным материалом.
Мультиязычность часто реализуют на клиенте: браузер загружает один пустой шаблон, затем JavaScript получает словарь и продуктовые данные. Для пользователя с хорошим соединением это может работать, но поисковый робот, корпоративный браузер или AI-краулер не всегда увидит полноценную страницу вовремя.
Я проверяю сырой HTML каждого типа страницы. В нём должны быть корректные title, description, H1, основной текст, ссылки на языковые версии, canonical, `hreflang` и структурированные данные. Для React/Vue это достигается SSR, статической генерацией или пререндерингом — выбор зависит от частоты обновления каталога.
Важно тестировать не только главную. Ошибки чаще проявляются в карточках, фильтрах, PDF, снятых моделях и редких региональных версиях.
Структурированные данные помогают однозначно связать производителя, продукт, характеристики и предложение, но не должны создавать отдельную «SEO-версию» фактов.
Я использую подходящие типы `Organization`, `Product`, `Offer`, `BreadcrumbList`, `Article` и другие только там, где соответствующая сущность есть на странице. Название, валюта, наличие, адрес и характеристики в JSON-LD должны совпадать с видимым содержанием локальной версии.
Для региональных подразделений важно не размножать вымышленные компании. Если это представительство или дилер, связь и роль должны быть названы честно. Структурированная разметка не заменяет страницу контактов, юридические данные и подтверждение полномочий.
Нейросети лучше работают с материалом, где продукт назван однозначно, характеристики даны с единицами, документы снабжены контекстом, а область поставки указана прямо. Отдельного «секретного тега для ChatGPT» нет.
Чтобы локальная версия могла стать источником ответа, я обеспечиваю:
Это не гарантирует упоминание в конкретном ответе AI-системы, но устраняет технические и содержательные причины, по которым страницу невозможно корректно прочитать и проверить.
Запуск одной версии — это начало сопровождения. Я формирую отдельный мониторинг по языкам и рынкам, потому что общий отчёт скрывает проблемы небольших сегментов.
Само по себе количество международного трафика ничего не доказывает. Важны обращения из целевых стран по тем продуктам, которые компания действительно готова поставить.
Я не рекомендую сразу переводить тысячи URL. Рабочая последовательность выглядит так:
1. Выбрать один рынок и подтвердить его коммерческие условия.
2. Запустить главную, компанию, контакты и приоритетные категории.
3. Добавить востребованные серии и модели с документами.
4. Настроить маршрутизацию заявок и измерение результата.
5. Проверить индексацию, `hreflang`, качество перевода и обратную связь продаж.
6. Расширять каталог по фактическому спросу и готовности данных.
7. Только после стабилизации переносить модель на следующий рынок.
Так команда раньше находит ошибки модели данных и не умножает их на пять языков.
Если экспортный сайт уже состоит из несвязанных переводов, начинать нужно не с очередной локализации текста, а с инвентаризации URL, продуктовых данных, документов и ответственных. Затем можно выбрать целевую архитектуру и переносить версии без потери работающих страниц.
При новом проекте выгоднее заложить мультиязычную модель сразу, даже если в первом релизе будет один язык. Идентификаторы сущностей, локальные поля, права редакторов и маршруты заявок обходятся значительно дешевле до наполнения каталога.
Обсудить разработку промышленного сайта для экспортных рынков
SEO-продвижение промышленного сайта
Google Search Central: управление мультирегиональными и мультиязычными сайтами
Google Search Central: локализованные версии страниц и hreflang
Яндекс Вебмастер: региональность сайта
Сильный мультиязычный сайт производителя строится вокруг единой продуктовой модели и честных различий между рынками. URL, `hreflang` и canonical помогают поиску выбрать версию, но ценность создают локальный ассортимент, точные единицы, действующие документы, реальные контакты и понятный путь экспортной заявки.
Мой главный принцип прост: синхронизировать то, что является фактом о продукте, и локализовать то, что зависит от покупателя и рынка. Тогда сайт не распадается на набор переводов, а становится управляемым международным каналом продаж.