Сначала выберите модель языковых версий
На Tilda мультиязычный сайт можно организовать внутри одного проекта или разделить версии по разным проектам и адресам. Выбор зависит от числа языков, структуры, команды и требований к доменам.
Официальная инструкция Tilda описывает оба подхода: языковые версии в одном проекте и отдельные сайты с меню переключения. См. руководство по мультиязычным сайтам.
Архитектура языковых версий
У каждой версии должен быть самостоятельный URL
Поисковику нужен отдельный адрес для каждой языковой версии. Переключение текста на одном URL через JavaScript неудобно для индексации и лишает вас возможности управлять метаданными, внутренними ссылками и аналитикой отдельно.
Примеры понятной структуры:
example.com/ru/иexample.com/en/;example.comиexample.com/en/;- отдельные домены или поддомены, если это обосновано бизнесом.
Главное - выбрать схему один раз и соблюдать ее для всех разделов.
Переводить нужно страницу, а не слова
Заголовок, оффер, примеры, валюта, юридические условия и поисковый спрос могут отличаться по рынкам. Дословный перевод русской страницы редко является полноценной SEO-версией для другой страны.
Перед созданием новой локали проверьте спрос на языке аудитории и реальную выдачу. Иногда структура услуг совпадет, иногда придется объединить или разделить страницы.
Что делает hreflang
hreflang помогает Google понять, какие URL являются языковыми или региональными альтернативами друг друга. Google требует указывать полные URL и рекомендует взаимные ссылки между версиями: если русская страница указывает на английскую, английская должна указывать обратно. Также страница обычно включает ссылку на саму себя. См. документацию Google по localized versions.
Для пары страниц это может выглядеть так:
<link rel="alternate" hreflang="ru" href="https://example.com/ru/service/">
<link rel="alternate" hreflang="en" href="https://example.com/en/service/">
Нужен ли x-default
x-default используют для страницы, которая не привязана к конкретному языку или служит вариантом по умолчанию. Это может быть языковой селектор или основная версия. Не добавляйте его механически, если такой страницы нет.
Canonical не должен склеивать разные языки
Типичная ошибка - поставить canonical со всех языковых страниц на русскую версию. Тогда вы сами сообщаете поисковой системе, что основной URL другой. Если каждая языковая страница самостоятельна, canonical обычно должен быть самоссылочным, а связь локалей задается через hreflang.
Переключатель языка
Переключатель должен вести не просто на главную другого языка, а на эквивалент текущей страницы, если такая версия существует. Пользователь читает условия услуги на английском - после переключения он ожидает русскую версию этой же услуги.
Tilda отмечает ограничения стандартной схемы меню при большом количестве языков. Если локалей больше трех или структура сложная, заранее проектируйте масштабируемый переключатель и шаблоны.
Что настроить отдельно для каждого языка
- Title и Description;
- H1 и текст страницы;
- alt у значимых изображений;
- внутренние ссылки;
- Open Graph;
- формы и сообщения после отправки;
- контакты, валюту и условия, если они различаются;
- аналитику по языковым сегментам.
Минимальный пример hreflang
Если у страницы есть русская и английская версии, каждая из них должна ссылаться на обе версии. Ссылки делают абсолютными:
<link rel="alternate" hreflang="ru" href="https://example.ru/service" />
<link rel="alternate" hreflang="en" href="https://example.ru/en/service" />
<link rel="alternate" hreflang="x-default" href="https://example.ru/service" />
На английской странице набор должен быть симметричным. Если страница A указывает на B, а B не подтверждает связь обратно, конфигурация становится ненадежной. Google рекомендует указывать альтернативы на каждой версии и использовать полностью определенные URL. См. документацию Google по локализованным версиям.
Что проверять кроме тегов
| Слой | Проверка |
|---|---|
| URL | У каждой версии постоянный адрес, нет автоматической подмены языка без возможности открыть URL напрямую |
| Title и Description | Переведены под спрос языка, а не скопированы транслитом |
| Контент | Цены, единицы измерения, контакты и юридическая информация соответствуют рынку |
| Внутренние ссылки | Не отправляют пользователя неожиданно на другую языковую ветку |
| Формы | Письма, ошибки и сообщения после отправки остаются на выбранном языке |
| Аналитика | Язык или ветка URL передаются как отдельный сегмент |
Главная ошибка международного SEO - считать, что технические теги заменяют локализацию. Hreflang помогает поисковой системе выбрать подходящую версию, но не делает слабый машинный перевод полезным для пользователя.
Проверка перед запуском
- откройте пары эквивалентных URL;
- проверьте reciprocal hreflang;
- убедитесь, что canonical не ведет на другой язык;
- пройдите меню на мобильном;
- отправьте формы на каждой версии;
- проверьте 404 и редиректы;
- убедитесь, что язык не меняется принудительно по IP без возможности выбора.
Что делать, если страницы нет на одном языке
Не нужно автоматически вести hreflang на главную другого языка. Связывайте только действительно эквивалентные страницы. Если русская статья не переведена, у нее может не быть английской альтернативы вообще.
То же правило полезно для переключателя: если эквивалентной страницы нет, лучше честно вести в соответствующий раздел или скрыть недоступный переход, чем создавать ощущение, что перевод существует.
Добавление языка к существующему сайту
Если проект уже получает поисковый трафик, не меняйте старые URL только ради красивой общей схемы без необходимости. Новую языковую ветку можно добавить рядом, сохранив существующие адреса. Если перенос все же нужен, подготовьте карту старых и новых URL и 301-редиректы до публикации.
Разделяйте языковые версии в аналитике
После запуска создайте сегменты по языковым каталогам или доменам и сравнивайте их отдельно. У разных рынков будут свои источники, конверсия и популярные страницы. Общий трафик мультиязычного сайта мало говорит о качестве конкретной локали.
Если формы ведут в одну CRM, передавайте язык или URL страницы вместе с лидом. Менеджер должен понимать, на каком языке продолжать коммуникацию.
Когда разделять проекты
Если языки обслуживают разные команды, рынки и контентные планы, отдельные проекты Tilda часто проще администрировать. Для двух почти одинаковых версий небольшой компании один проект может быть удобнее. Решение нужно принимать по архитектуре, а не только по числу страниц.
Если мультиязычность добавляется к уже большому сайту, сначала спроектируйте URL и редиректы. При необходимости такую работу можно включить в редизайн сайта на Tilda или технический аудит.
