Что такое мультиязычность сервиса
Мультиязычность сайта: как правильно реализовать
Мультиязычность сайта — это возможность выбрать язык ресурса в зависимости от страны проживания пользователя.
Однако создание мультиязычного сайта актуально не только для Украины. Подобные ресурсы нужны людям, проживающим в одной стране, но пользующимся при этом разными языками. Хороший пример – Швейцария. 63% людей общаются на немецком, но все чаще встречается и английский, и португальский. Главная причина – трудовая миграция.
В этом материале мы разберем вопрос создания и правильной настройки сайтов на нескольких языках.
Варианты реализации мультиязычности
Ее можно внедрить разными способами, но у каждого есть свои плюсы и минусы.
Разные домены
Один из путей – создание отдельных сайтов под каждый язык, метод самый затратный, длительный и сложный. Как это может выглядеть:
На выходе будут 2 независимых сайта, которые нужно продвигать отдельно. Это и есть самый большой минус, так как все правки, которые вы сделаете на первом сайте, придется дублировать и на втором. Также не стоит забывать о внешней оптимизации. У каждого сайта свой ссылочный профиль, и наращивать ссылочную массу придется отдельно для первого и второго ресурса. Соответственно, у вас уйдет больше времени на поиск доменов-доноров для каждой из стран.
Поддомены
Здесь языковая версия выносится перед доменом:
Но этот вариант мы не рекомендуем использовать, ведь поддомен в глазах поисковиков – это отдельный сайт, и продвигать его тоже нужно отдельно. Никаких преимуществ в ранжировании он не даст (возможно, какое-то минимальное, ведь, скорее всего, ресурсы будут перелинкованы между собой, и ПС “свяжет” эти сайты). Хотя со стороны разработки и внедрения каких-либо правок это будет проще.
Папки
Этот вариант считается оптимальным для создания мультиязычного сайта, потому что все действия по переключению языка происходят в пределах одного домена. Вся ссылочная масса сохранится, и можно вносить правки лишь на одном сайте, а это удобно и менее затратно.
Как все может выглядеть:
https://site.com/ – главная версия ресурса на украинском языке;
https://site.com/ru/ – версия на русском.
Мы рекомендуем реализовывать разные языковые версии через подпапки.
Теперь рассмотрим, как это сделать правильно, чтобы в глазах поисковиков наши сайты не выглядели дубликатами. В противном случае это отрицательно повлияет на ранжирование и раскрутку проекта в целом.
О чем нужно помнить при реализации мультиязычности
Атрибут hreflang
Тег должен включать код языка, а также URL-адрес:
Важно! Для определения языка роботу-поисковику не достаточно только кода государства.
Яндекс тоже советует ISO 639-1 и ISO 3166-1 Alpha-2 для стран мира, а также отдельно ISO 3166-2:RU для российских областей.
В исходном коде страницы https://allo.ua/ru/ присутствует следующая конструкция:
Элемент для sitemap.xml
Возьмем тот же сайт allo.ua и сами пропишем участок Sitemap. Получается следующее:
Что мы сделали: с помощью Sitemap.xml сказали роботам о мультиязычных версиях сайта.
Перевод всего контента на требуемые языки
Абсолютно весь контент, который будет на страницах, следует перевести на соответствующий язык. Если у вас нет на это средств или времени, то лучше вообще не делать другую языковую версию либо внедрять “порционно”, то есть переводить часть страниц и открывать их для индексации.
Тексты должны быть понятными, в идеале и структуру самих статей сделать одинаковую, использовать такие же термины.
Для специфических ниш (например, юридическая тематика) нужно обращаться к специалисту, чтобы он вычитал все тексты. Такой контент не должен противоречить местному законодательству. Поэтому с текстами нужно быть очень аккуратными. Лучше не переводить, когда вы не располагаете средствами и временем.
«Переключатель» языка
Главное – простота выбора языка сайта для пользователей. Например, подойдет обычная кнопка с переключением между RU и UA.
Что важно не упустить
Заголовки и метатеги
Всегда проверяйте, чтобы заголовки Title, H1 и meta Description были правильно переведены. Рассчитывать на онлайн-ресурсы по типу Google Translate мы не советуем, так как машинный перевод далек от идеального. Обратитесь к носителю языка или переводчику – текстовые зоны документа должны быть читабельными и корректными.
Перелинковка
Все внутренние, сквозные ссылки (в футере и хедере) должны меняться. При выборе украинского языка все ссылки должны вести именно на украинскую версию до того момента, пока пользователь сам не сменит языковые настройки.
Дополнительные страницы: новости, акции, спецпредложения
Все дополнительные страницы, присутствующие практически на каждом сайте, тоже нужно перевести на соответствующий язык. Но будьте аккуратны: если уникальное предложение действует только на территории определенной страны, то его не надо переводить, а тем более показывать в других регионах 🙂
Служебные страницы: корзина, авторизация
Аналогично для страниц заказа, корзины и авторизации. Все так называемые служебные страницы должны быть переведены. Понятное дело, что они зачастую закрыты от индексации, но не от посетителей.
Теперь представьте, что пользователь из Германии добавил товар в корзину, перешел на страницу “Оформить заказ”, а там весь текст на русском языке. Как вы думаете, он будет дальше пытаться заказать товар или закроет ваш сайт? 🙂
В заключение
1. Существует несколько вариантов реализации мультиязычности. Мы советуем внедрять ее через подпапки.
2. При настройке учитывайте следующие технические моменты:
3. Чтобы мультиязычный сайт хорошо ранжировался, уделите этому достаточное количество времени. Вариант со “сделать на коленке” не подойдет – в итоге вы можете только ухудшить свой проект.
SEO многоязычного сайта без географической привязки под Google
Введение
В этой статье речь пойдет о важных элементах при продвижении сайта, переведенного на большое количество языков и не имеющего конкретной географической привязки, то есть нас интересует органический трафик на любом языке с любой точки планеты.
Мой опыт основывается на продвижении сайта для экспатов и путешественников со всего мира, контентные страницы которого формируются из базы данных. Сайт с миллионами страниц генерированного из базы данных контента.
Многоязычность и формирование URL
В моем примере сайт необходимо было перевести на 15 основных языков, соответственно, необходимо было выбрать схему построения URL для каждого языка.
Есть четыре варианта как это можно сделать:
1- Каждый язык на отдельном субдомене
Пример: de.example.com, ru.example.com
Преимущества — не выявлены.
Недостатки — неудобство администрирования.
2- Каждый язык на отдельном домене (Пример: example.de, example.ru)
3- Для каждого языка свои параметры в URL (Пример: example.com?leng=de, example.com?leng=ru)
Преимущества — не выявлены.
Недостатки — URL с параметрами хуже индексируются и участвуют в поиске.
4- Каждый язык в отдельном подкаталоге (Пример example.com/de/, example.com/ru/)
Преимущества — не выявлены.
Недостатки — не выявлены.
Даже несмотря на то что второй вариант, в отличие от остальных, имеет преимущество, мной был выбран четвертый в силу простоты реализации и отсутствия недостатков.
Атрибут hreflang — показываем Google на каком языке показывать страницу в выдаче
В работе над сайтом я столкнулся с проблемой. Google и Яндекс сейчас используют атрибут hreflang для определения языка и страны для которой показывать данную версию страницы.
пользователям, запрашивающим на русском языке из Австралии будет показываться версия example.com/ru-au
пользователям, запрашивающим на русском языке из Великобритании будет показываться версия example.com/ru-gb
пользователям, запрашивающим на немецком языке из Великобритании будет показываться версия example.com/de-au
пользователям, запрашивающим на немецком языке из Великобритании будет показываться версия example.com/de-gb
Проблема моего сайта заключалась в том, что любая языковая версия страницы может быть запрошена из любой географической точки. Например, русскоговорящий человек может запросить страницу из России, Австралии, Германии и любой другой точки мира.
Следовательно, мне пришлось бы писать полотна атрибутов, учитывающие все сочетания языков и стран для каждой страницы.
Решение заключается в установке параметров атрибута hreflang без указания географии, то есть мы показываем Google только языковые версии страницы, без привязки к региону.
пользователям, запрашивающим на русском языке из любой точки мира будет показываться версия example.com/ru
пользователям, запрашивающим на немецком языке из любой точки мира будет показываться версия example.com/de
GeoShape — микроразметка географического положения объектов
Как оказалось, hreflang лишь частично решил проблему. Так как сайт формирует страницы из базы данных (а ее содержимое не переводится на разные языки) получилась ситуация что я имею миллионы страниц дублей по основному контенту, отличающихся лишь названием запрашиваемой страны в заголовке, а остальной контент часто абсолютно идентичен, либо незначительно отличался. Как пример, аналоги русских лекарств во Франции, Италии и вообще по Евросоюзу будут практически одни и те же. Получается что разные для пользователей страницы Италии и Франции, будут дублями в глазах Google.
Теперь задача состояла в том, чтобы показать Google что страницы с одинаковым или похожим контентом предназначены для разных стран. Как мы помним, hreflang использовать для этой задачи нельзя, так как это будут либо сотни строк атрибутов, либо станицы с различными языками будут доступны не из всех стран.
На помощь мне пришла микроразметка. Столкнувшись с проблемой, я стал анализировать сайты, подобные моему, и на booking.com наткнулся на тег структурированных данных GeoShape. Они используют его для обозначения местоположения отелей.
Проверив валидность кода при применении GeoShape в разметке лекарств (сайт речь о котором в статье про аналоги лекарств) я установил все на сайт.
Теперь Google видит разницу в географии между страницами, предназначенными для разных стран, но с похожим контентом, а пользователи могут получить свою языковую версию страницы из любой точки планеты.
Sitemap.xml — Улучшаем индексацию
Здесь все довольно просто, но также есть нюансы.
Реализация мультиязычности на сайте без рисков для SEO
Статья из блога АРТИЗАН-ТИМ
Запуск мультиязычной версии сайта — важный шаг для проектов, нацеленных на глобальный рынок. Использование многоязычности также актуально для локальных проектов, в странах, где жители разговаривают на нескольких языках. С технической точки зрения — это не самая сложная задача, но на поверку она влечет немало скрытых рисков для SEO. О принципах безопасного внедрения мультиязычности и тонкостях ее настройки — рассказываем в нашем материале.
Три способа реализации мультиязычности
Существует три основных способа запустить многоязычную версию сайта. На преимуществах и недостатках каждого из них остановимся более подробно.
Отдельные версии на разных доменах
Речь идет о том, чтобы под конкретную языковую локализацию сделать отдельный сайт. С точки зрения лояльности поисковиков и удобства для пользователей — это самое эффективное решение. Но, как несложно догадаться, такой способ более сложный в плане технической реализации и на порядок затратнее.
Под каждую локализацию компания реализовала отдельную версию сайта. Доменные зоны наглядно отображают, на какую языковую аудиторию ориентирован каждый проект.
С точки зрения SEO преимущества такой стратегии в том, что версии ресурсов полностью автономны и не зависят друг от друга в вопросах продвижения. При этом поисковики лучше ранжируют сайты на национальных доменах в локальной выдаче. В то же время такая реализация многоязычности ― палка о двух концах. Из плюсов вытекают минусы, которые при отсутствии серьезных корпоративных бюджетов делают эту стратегию неподъемной.
В этом случае необходимо с нуля разработать несколько версий сайтов. Для каждого ресурса нужно приобрести отдельное доменное имя, которое к тому же может оказаться занятым в какой-то из зон. В дальнейшем каждая версия сайта будет нуждаться в отдельном администрировании и автономном SEO. Таким образом, бюджет на веб-поддержку и поисковое продвижение, по сути, придется умножить на количество имеющихся сайтов. Из-за своей организационной сложности и дороговизны к такому варианту прибегают редко. Обычно, это делают только крупные международные компании, с серьезными бюджетами на веб-разработку и продвижение своего бренда.
Языковые версии на поддомене
Поддомены (домены третьего уровня или субдомены) используют для создания отдельных версий сайта внутри основного проекта. Это еще один популярный способ внедрения мультиязычной архитектуры. В этом случае языковая версия сайта отображается в адресной строке через точку слева от основного названия. К слову, на поддомены могут быть вынесены не только версии сайта на другом языке, но и региональные филиалы, например, того же магазина или функционировать разделы сайта. 
Такой способ создания мультиязычности — нечто среднее между отдельным сайтом и использованием разделов и папок (об этом ниже). Ему свойственны свои особенности, которые необходимо принимать во внимание. В плане технической реализации здесь не все так сложно (и дорого) как с сайтами на разных доменах, но и не так просто как может казаться изначально.
Версия на поддомене — это полностью самостоятельный сайт с отдельной базой данных. Такая архитектура требует больше ресурсов на оптимизацию, чем, если бы речь шла о создании разделов. Помимо основных работ (проработка структуры, наполнение контентом, заполнение метатегов и пр.) для всех поддоменов необходимо создать отдельный robot.txt и sitemap.xml. Что касается ссылочного веса, то хотя он и перераспределяется между основным доменом и поддоменами, происходит это не так эффективно. Передача веса от домена становится возможной главным образом за счет грамотной перелинковки, поэтому ей уделяют основное внимание в рамках внутренней SEO-оптимизации.
Чтобы улучшить пользовательский опыт, можно настроить специальный скрипт, который будет распознавать IP-адрес посетителей и автоматически перенаправлять их на нужную версию сайта.
Несмотря на все вышеописанные сложности, мультиязычная архитектура, созданная по принципу домен+поддомен, обладает важными преимуществами. При такой схеме имеется возможность переноса данных на отдельный сервер. Когда речь идет о крупных ресурсах, это становится стратегическим преимуществом, позволяющим снизить нагрузку на сайт и оптимизировать скорость его загрузки.
Размещение поддомена на отдельном сервере может сыграть на руку проектам, которые имеют стабильную аудиторию по всему миру. Например, разместив англоязычную версию сайта на иностранном сервере, а русскоязычную — у местного хостера, можно добиться оптимальной скорости загрузки сайта для всех пользователей, вне зависимости от их географической удаленности.
Отдельно стоит отметить вопрос аналитики. В случае с поддоменами она существенно упрощается, поскольку нет необходимости сегментировать данные для поддерикторий — настройка счетчика реализуется для всего поддомена.
Создание разделов на основном сайте
Создание категорий и папок на основном домене — самый популярный способ реализации мультиязычности. Такая архитектура дает больше всего преимуществ с точки зрения поискового продвижения и внедряется значительно проще, чем описанные выше варианты.
Поскольку действие происходит в рамках общего домена — ссылочный вес эффективно перераспределяется между всеми страницами. Версии документов на другом языке наследуют трастовость основного домена, что положительным образом сказывается на их позициях в выдаче. Ускоренная индексация страниц — еще один существенный плюс мультиязычной архитектуры, реализованной через папки и категории. Также, поскольку при таком подходе языковая версия является лишь одним из разделов домена — отпадает необходимость в создании отдельного Sitemap.
Реализация мультиязычности через разделы удобна тем, что изменения на сайте можно внедрить сразу на всех страницах. Это значит, что добавив какой-то функционал, например, на русскоязычной версии сайта, он будет реализован во всех остальных языковых адаптациях. С теми же поддоменами такого не получится — изменения на каждой версии придется вносить отдельно, что добавляет немало головной боли при проведении работ по внутренней оптимизации сайта. 
Мультиязычность через разделы — это оптимальный вариант, если вы планируете использовать не два-три языка, а значительно больше версий. С поддоменами вы будете ограничены в этом вопросе, т.к. количество субдоменов зависит от настроек сервера. Разделов же может быть сколько угодно в рамках одного сайта. При этом не стоит забывать, что чем больше языковых версий используется на сайте, тем выше нагрузка на сервер, и потребуется больше дискового пространства.
Что касается практической реализации такого способа, то в большинстве случаев это делают автоматизированным методом, используя специальные модули, которые сами создают категории и папки под контент на другом языке. Во многих расширениях имеется возможность автоматического перевода страниц. Если такая опция отсутствует, это можно реализовать при помощи отдельных плагинов машинного перевода.
Таким образом, создание мультиязычности через папки — самый простой и доступный способ в плане реализации и наиболее эффективный с точки зрения SEO. Именно поэтому он используется на абсолютном большинстве многоязычных проектов. Но есть один существенный нюанс — в этом случае следует особенно ответственно подойти к разметке локализованных страниц.
Атрибут hreflang
Использование атрибута hreflang помогает поисковым системам идентифицировать версии страниц на разных языках. Пренебрежение этой разметкой может привести к тому, что Google и «Яндекс» посчитают страницы с переведенным контентом за дубли, что повлечет серьезные проблемы с SEO. Грамотно заданные атрибуты hreflang не только предотвратят эту ситуацию и исключат риск склейки, но и обеспечат определенные преимущества при региональном ранжировании. В этом случае поисковые системы будут формировать выдачу, учитывая языковые настройки пользователей и их местоположение.
Использование атрибута hreflang является базовой рекомендацией, вне зависимости от того каким именно способом внедрена мультиязычность на сайте. Мы не будем останавливаться на практических аспектах реализации разметки для локализованных версий страниц — подробно об использовании атрибута hreflang можно почитать в официальной справке Google и «Яндекса».
Элемент в Sitemap.xml
Оптимизация тегов
Корректная локализация тегов — еще один важный пласт работ, от которого во многом зависит качество SEO мультиязычного сайта. В идеале перевод Title, H1 и Description следует поручить профессиональному переводчику. Нечитабельные теги не только ухудшают CTR и наносят существенный урон поведенческим, но и могут расцениваться поисковыми системами как спам, что повлечет проблемы с SEO для всего сайта.
Владельцам проектов, которые не имеют возможности выделить ресурсы на перевод и вычитку метатегов, необходимо делать максимально короткие Title и H1 — так вероятность грубых ошибок при машинном переводе будет существенно ниже. Заполнением Description в таких случаях целесообразно пренебречь вовсе. Перевод тегов для страниц, которые генерируют больше всего трафика, целесообразно поручить специалисту.
Контент и другие нюансы языковой локализации
Использовать мультиязычность на сайте не имеет особого смысла, если его страницы останутся пустыми. Как и в случае с тегами, поручать перевод контента целесообразно специалистам. Когда такой возможности нет — единственной альтернативой остается машинный перевод.
Чтобы улучшить качество перевода и избежать нечитабельных текстов, которые сразу подрывают доверие к сайту, рекомендуем придерживаться следующих правил. В первую очередь необходимо сократить объем текста на переводимой странице до максимального минимума. В рекомендациях Google и «Яндекса» ничего не говорится на этот счет, но практика показывает, что уже 150 слов обеспечат гарантированное попадание страницы в индекс. Также этого объема будет достаточно, чтобы использовать в тексте несколько вхождений ключевых слов.
Используя переводчик, старайтесь максимально упрощать синтаксис исходного текста — простые короткие предложения уменьшают вероятность некорректно переведенных конструкций. Сам текст лучше переводить предложениями или небольшими абзацами, это помогает улучшить результат на выходе. Также важно обращать внимание на грамматические ошибки в исходном тексте, поскольку алгоритм не распознает такие слова и оставляет их в непереведенном виде. Адаптацию контента для главной, основных категорий и трафикогенерирующих страниц уместно поручать специалисту.
Важно не забывать, что языковая локализация сайта также предполагает перевод всех интерфейсов. В противном случае пользователи не смогут полноценно взаимодействовать с ресурсом и обеспечивать хорошие поведенческие, которые напрямую влияют на позиции сайта в выдаче. В рамках языковой адаптации дополнительно проводят аудит структуры ресурса: определяют какие страницы имеют сугубо локальную специфику и не нуждаются в переводе, например, разделы с акциями, региональными предложениями и т.д.
Правильная архитектура мультиязычного магазина с импортом данных из нескольких систем
Постановка задачи
Весной 2020-го года мы получили заказ на разработку мультиязычного b2b интернет-магазина для крупного бренда. Целевая аудитория: несколько тысяч дилеров из России, Европы и США. У всех наших проектов есть изюминка, из-за которой пришли именно к нам. Этот проект выделялся хранением данных: товары (картинки, описания, переводы) в postgre, цены и остатки — в нетиповой конфигурации 1С.
Проект масштабный, разработка все еще идет, но архитектура уже определена. В качестве базы выбрали тиражное решение, чтобы сконцентрироваться на нетиповом обмене, архитектуре и получить наглядный результат как можно скорее. В этой статье мы расскажем, как считаем правильным с технической стороны разрабатывать такой мультиязычный сайт с нестандартной учетной системой.
Архитектура
От postgre и нетиповой 1С избавиться на первом этапе не представляется возможным, в первые годы жизни сайта они точно останутся. Но нужно предусмотреть копирование всех данных из postgre в сайт на Битриксе (который на mysql), чтобы в дальнейшем безболезненно отказаться от старой базы.
Как хранятся товары
В БД postgre хранится вся информация о товарах: название, описание, свойства, фотографии (каждый текст, каждый файл в 10-ти вариантах: на популярных европейских языках).
БД postgre устроена иначе, чем любимая Битриксом mysql (речь про допустимое количество колонок в таблице). Сделать копию данных 1 к 1 на новом сайте не получилось, пришлось трансформировать (почти транспонировать) данные.
Binoculars Praktica 10×25 WA
Jumelles Praktica 10×25 WA
Binocolo Praktica 10×25 WA
Discovery Sky Trip ST80 Telescope
Discovery Sky Trip ST80 Télescope
Discovery Sky Trip ST80 Telescopio
Binoculars Praktica 10×25 WA
Jumelles Praktica 10×25 WA
Binocolo Praktica 10×25 WA
Discovery Sky Trip ST80 Telescope
Discovery Sky Trip ST80 Télescope
Discovery Sky Trip ST80 Telescopio
Так как структура всех подобных таблиц в postgre была идентичной, удалось сделать единый механизм импорта с простыми настройками: из какой таблицы postgre взять данные, в какой Hl-блок сложить и сопоставить поля. Так мы смогли синхронизировать 24 таблицы.
Как хранятся цены
У заказчика сложная система ценообразования: для основных стран Европы есть до 4-х цен, как с НДС, так и без. Всего насчитывается 57 типов цен и все они используются, каждая для своей группы клиентов. Каждый дилер покупает товар по одной из этих цен. По какой именно — решает менеджер и фиксирует в 1С, в зависимости от страны дилера и его объема закупок.
Как данные попадают на сайт
Для 2-ух источников данных (postgre, 1C) разработали 2 с половиной механизма обмена.
Каждый день по расписанию сайт «ходит» в postgre по SQL-соединению и синхронизирует данные в своих HL-блоках
По расписанию 1С присылает на сайт через REST API данные каталога, дилеров, склады (пореже), цены и остатки (почаще). При этом сразу создаются неактивные товары без фото, без описания и свойств, так как в 1С этого нет.
Постоянно работающий агент на сайте следит за товарами. Он их “обогащает” переводами, фотографиями, свойствами из HL-блоков и “включает”.
Преимущества такого подхода:
База переводов в понятном виде хранится на сайте в стандартном табличном интерфейсе HL-блоков. Когда понадобится — сделаем более удобный интерфейс и отключим postgre.
1С “знает” что происходит на сайте. Запросы к REST API сайта синхронные, завершаются ответом, что было успешно импортировано, а что нет.
Сразу после выгрузки на сайте создается “скелет” каталога — настоящие разделы и “пустые” товары (без фото, текстов — только служебные названия, цены и остатки).
В течение нескольких минут у каждого “пустого” товара заполняются поля на нужном языке, товар “включается” и его уже можно покупать. Проблем с кешем это не создает, так как такие изменения происходят редко и массово.
Как организована мультиязычность
Мы выбрали “хитрый” способ: копипаст с автоматизацией. У товаров в базе заказчика всегда есть перевод хотя бы на английский, и если нужного языка нет — берем его. Когда проблему замечает контент-менеджер, то исправляет в postgre, и данные постепенно мигрируют в публичный каталог, чтобы новый перевод начал радовать глаз иностранного посетителя.
Много было споров по поводу архитектуры каталога — очень хотелось сделать 1 каталог, и все к этому шло. Проблему с языковыми версиями можно было бы решить, напрямую используя для вывода HL-блоки с переводами. Это бы создало предсказуемые проблемы с поиском и генерацией фидов, которые мы знали, как решать.
А где же результат увидеть?
После 2-ой итерации в конце 2020-го, когда техническая сторона была готова, решили все таки сделать собственный дизайн для сайта. Следующая остановка была летом 2021-го года, тогда мы начали тестирование на реальных дилерах.
Этот проект отлично демонстрирует, какие задачи мы можем и хотим решать: веб-интеграцию любых систем с 1С и сайтом. Продолжение в следующей статье.