Сайт выходит на несколько стран: добавляется английская версия, казахская, отдельная для Европы. Сразу возникают вопросы, которые переводом не решаются. Как устроить адреса языковых версий? Как объяснить поисковикам, какую версию кому показывать? Нужен ли отдельный сервер в каждой стране, или хватит одного? Ниже — практические ответы: структура URL, разметка hreflang, ошибки с автоопределением языка и схемы размещения от «один сервер и CDN» до серверов в разных регионах.
Как устроить адреса языковых версий
| Схема | Пример | Плюсы | Минусы |
|---|---|---|---|
| Подкаталоги | example.com/en/, example.com/kk/ | Один домен и сертификат, вес домена общий, проще всего обслуживать | Все версии на одном сервере и в одной юрисдикции |
| Поддомены | en.example.com | Версии можно разнести по разным серверам | Поисковики частично воспринимают их как отдельные сайты |
| Отдельные домены | example.kz, example.de | Сильный сигнал стране и пользователям, можно разные юрлица и юрисдикции | Несколько доменов и сертификатов, продвижение каждого с нуля |
Для большинства проектов разумный выбор по умолчанию — подкаталоги. Отдельные домены оправданы, когда в странах разные компании, ассортимент, цены и законы. Поддомены — промежуточный вариант, удобный, если версии технически живут на разных серверах.
Чего делать не стоит: держать языковую версию по одному и тому же адресу и переключать язык через cookie или параметр. Поисковый робот увидит только одну версию, остальные в поиск не попадут.
Hreflang: как сказать поисковику, кому какая версия
Без разметки поисковик видит несколько похожих страниц и может показать пользователю из Германии русскую версию, а из Москвы — английскую. Разметка hreflang перечисляет все языковые варианты страницы. В <head> каждой версии:
<link rel="alternate" hreflang="ru" href="https://example.com/ru/tarify/"> <link rel="alternate" hreflang="en" href="https://example.com/en/pricing/"> <link rel="alternate" hreflang="kk-KZ" href="https://example.com/kk/tarifter/"> <link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing/">
Правила, на которых чаще всего ошибаются:
- Связи взаимные. Если русская страница ссылается на английскую, английская обязана ссылаться на русскую. Односторонние ссылки игнорируются.
- Страница указывает и на себя. Набор одинаковый во всех версиях, включая ссылку на саму страницу.
- Код языка — ISO 639-1, региона — ISO 3166-1:
en,en-GB,es-MX.en-UKилиkzвместоkk— ошибки, их молча пропускают. x-default— версия для тех, чей язык не совпал ни с одним вариантом. Обычно английская или страница выбора языка.- Canonical каждой версии указывает на неё саму, а не на «главную» языковую версию. Иначе остальные выпадут из индекса.
Если страниц тысячи, разметку удобнее вынести в sitemap: для каждого адреса перечисляются альтернативы через xhtml:link. Google и Яндекс учитывают hreflang. Для Яндекса дополнительно полезно указать регион сайта в Вебмастере, если версии рассчитаны на разные страны.
Автоопределение языка: осторожно
Соблазнительно определять страну по IP и сразу перебрасывать посетителя на «его» версию. На практике это мешает:
- человек в командировке получает не тот язык и не может переключиться обратно;
- поисковый робот обходит сайт из одной страны и видит только одну версию;
- пользователи VPN и корпоративных сетей попадают куда угодно.
Разумнее так: принудительно перенаправлять можно только с корня сайта (/), и только один раз, по языку браузера (заголовок Accept-Language), а не по IP. Внутренние страницы открываются на том языке, который в адресе. Переключатель языка заметен на каждой странице, выбор запоминается в cookie. Если язык браузера не совпадает с языком страницы, можно показать ненавязчивую подсказку «Есть версия на русском», но не перебрасывать.
Язык — это ещё и регион
Английский для США и для Великобритании, русский для России и для Казахстана различаются не только словами. Валюта, формат дат и чисел, способы оплаты, доставка, телефонные форматы, юридические тексты. Цена не в той валюте или отсутствие привычного способа оплаты отталкивают сильнее неидеального перевода. Поэтому версии обычно привязывают не к языку, а к паре «язык + регион».
Один сервер или несколько
Главный технический вопрос. Ответ зависит от того, насколько далеко аудитория и насколько сайт динамический.
Вариант 1. Один сервер + CDN — для большинства
Сервер в точке, удобной для основной аудитории; картинки, стили и скрипты отдаёт CDN с узлов рядом с пользователями. HTML с сервера идёт одним запросом, всё тяжёлое приезжает из ближайшего узла. Для аудитории в Европе и СНГ один сервер в Нидерландах или Финляндии обычно закрывает всё. Сколько стоит расстояние и как его измерить — в статье «Высокая задержка».
Вариант 2. Отдельный сервер на регион
Нужен, когда аудитории на разных континентах, а сайт сильно динамический (личный кабинет, интерактив), или когда законы требуют хранить данные в определённой стране. Самая простая рабочая схема — независимые региональные сайты: свой сервер и своя база в каждом регионе, общий только код. Например, example.com на сервере в Европе и example.us на сервере в США.
Сложнее — один сайт с единой базой на несколько регионов: потребуется репликация базы, решение, где происходят записи, и гео-DNS, который направляет пользователя на ближайший сервер. Это заметно дороже в разработке и обслуживании, и браться за это стоит, только когда простые схемы перестали справляться.
Учитывайте законы о данных
Если одна из версий собирает персональные данные граждан России, по 152-ФЗ они должны записываться и храниться в базе на территории России. Для такого проекта естественная схема: российская версия с базой на сервере в России, международная — на европейском сервере со своей базой. Подробнее о требованиях — в статье «Приватность на VPS».
| Ситуация | Схема |
|---|---|
| Аудитория в Европе и СНГ, обычный сайт или магазин | Один сервер в Нидерландах или Финляндии + CDN для статики |
| Россия + Казахстан и Средняя Азия | Один сервер в России или Казахстане; при требованиях к данным — по серверу в каждой стране |
| Европа + Северная Америка, сайт с личным кабинетом | Отдельные региональные сайты: Нидерланды и США |
| Данные россиян и международная аудитория | Российская версия с базой в России, международная — в Европе |
Технические мелочи
- Кодировка UTF-8 везде — в базе (
utf8mb4в MySQL), в соединении с базой, в заголовках ответа. Иначе казахские, турецкие или немецкие символы превращаются в вопросы. - Атрибут
langв теге<html>каждой версии:<html lang="kk">. Его используют браузеры, программы чтения с экрана и переводчики. - Сертификат на все домены и поддомены версий — «SSL на VPS».
- Кэш с учётом языка. Если язык определяется не по адресу, а по cookie, ключ кэша должен его учитывать, иначе одни посетители увидят страницу на чужом языке.
- Резерв. Сервер в другом регионе может быть и резервной площадкой на случай аварии основного — схема в статье «Сервер для бэкапа».
Площадки под регионы
| Аудитория | Площадка | Задержка из РФ |
|---|---|---|
| Европа целиком | Нидерланды: крупнейший узел обмена трафиком, NVMe | 40–60 мс |
| Россия и Европа | Финляндия: Xeon Gold 3.0 GHz, NVMe | 20–40 мс |
| Казахстан, Средняя Азия | Казахстан (Алматы) | 50–80 мс |
| Северная Америка | США (Нью-Йорк, Лос-Анджелес) | 100–150 мс |
Start в Нидерландах — $10/мес Start в США — $10/мес Start в Казахстане — $10/мес
Цены указаны на момент публикации, оплата у провайдера. Start — 2 vCPU и 2 ГБ памяти; для сайта на CMS с несколькими языковыми версиями этого обычно хватает.
Коротко
- По умолчанию — подкаталоги (
/en/,/kk/); отдельные домены, когда в странах разный бизнес. - Hreflang взаимный, со ссылкой на себя, с правильными кодами и
x-default; canonical каждой версии — на себя. - Не перебрасывайте по IP; перенаправление — только с корня и по языку браузера, переключатель на каждой странице.
- Для большинства хватит одного сервера и CDN; отдельные серверы — для разных континентов с динамикой или из-за законов о данных.
- Данные россиян — в базе в России; международная версия может жить отдельно.