Погляньте на сам конструктор
Один сайт, до восьми мов, з hreflang і резервним варіантом, які обробляються автоматично під час додавання кожної мови.
Практичний посібник з багатомовного сайту: URL, запасні варіанти, пріоритети
Додавання другої мови зазвичай описують як задачу перекладу. Насправді це задача структури: де живуть перекладені сторінки, що відбувається, поки перекладено ще не все, і які сторінки заслуговують уваги першими. Налаштуйте структуру правильно — і переклад стане просто набором тексту. Помиліться зі структурою — і пошукові системи індексуватимуть дубльовані чи напівпорожні сторінки, хоч наскільки хороший сам переклад.
Де насправді розташовані перекладені сторінки
Є кілька поширених способів віддавати той самий вміст кількома мовами, і з погляду пошуку вони не взаємозамінні:
Підкаталоги — example.com/es/page — найпоширеніший рекомендований варіант. Усі мови мають спільний домен, тож увесь авторитет і довіра до сайту накопичуються в одному місці, а пошукові системи можуть обходити кожну мову від одного кореня.
Піддомени — es.example.com — технічно розділяє мови, але пошукові системи можуть сприймати піддомен як напівокрему сутність, що розмиває сигнал про належність усіх цих сторінок до одного сайту.
Окремі домени — example.es, example.de — повне розділення; звичний вибір для великих міжнародних брендів, яким потрібна справді місцева присутність у кожній країні, але це помножує обсяг роботи з SEO: кожен домен нарощує авторитет самостійно, з нуля.
Параметр запиту — example.com?lang=es — дешево впровадити, але пошукові системи непослідовні в тому, чи вважати URL-адреси з параметрами цілком окремими сторінками, і саме цей варіант найчастіше спричиняє плутанину з дубльованим вмістом.
Узагалі без окремої URL-адреси — перемикання мови на боці клієнта, яке не змінює адресний рядок. Саме цього варіанта варто уникати для будь-якого вмісту, який ви хочете бачити в індексі: якщо URL-адреса не змінюється, пошуковій системі нема чого індексувати як «іспанську сторінку», і тегу hreflang нема на що вказувати.
Мова за замовчуванням: із префіксом чи без?
Поширена й розумна конвенція — залишити мову за замовчуванням без префікса в корені (
/pricing) і додавати префікс кожній іншій активній мові (/es/pricing, /de/pricing). Це читається природно, це означає, що ваші наявні посилання й уся вхідна SEO-вага кореневих URL лишаються недоторканими, коли ви додаєте другу мову, і це дає вам однозначний «типовий» URL, до якого можна відкотитися, коли нічого іншого не пасує, — а це важливо для тега hreflang x-default (розглянутого в супутньому посібнику з hreflang).Що має відбуватися, коли перекладу немає
Хтось завжди вмикає нову мову раніше, ніж готова кожна остання сторінка — важливо, що відбувається саме в цьому проміжку. Добре побудований ланцюжок резервних варіантів пробує по черзі: точну запитану локаль, потім її базову мову (відвідувач із
es-MX все ще може прочитати сторінку es), потім типову мову сайту, і лише тоді те, що взагалі є. Чого він ніколи не повинен робити — показувати порожню секцію чи зламану сторінку: відвідувач завжди має бачити повний контент, навіть якщо частина його приходить резервною мовою, а не тією, яку він запитав.Запуск другої мови без шкоди для першої
1
Спершу перекладіть навігацію та сторінки з найбільшим трафіком
Відвідувач значно охочіше пробачить допис у блозі, що залишився мовою за замовчуванням, ніж головну сторінку чи сторінку цін, яка не збігається з обраною ним мовою. Починайте там, де трафік і рішення про покупку.
2
Далі — юридичні сторінки та політики
Сторінки умов, конфіденційності та повернень мають реальні наслідки, якщо їх зрозуміють неправильно: їх варто перекласти як слід раніше, ніж контент довгого хвоста, навіть якщо трафіку в них менше.
3
Тримайте тексти оформлення замовлення та транзакційних листів в одному ритмі з рештою
Вітрина, яка перемикає мову скрізь, окрім останнього кроку оплати, підриває довіру саме тоді, коли вона найважливіша.
4
І лише потім розбирайте довгий хвіст
Усе інше — архівний вміст, старі дописи блогу, вузькоспеціальні статті довідки — можна перекладати у власному темпі, не псуючи враження більшості відвідувачів.
5
Не публікуйте мову, доки основні сторінки справді не витримуватимуть перевірки
Вмикати мову на всьому сайті до того, як готові справді важливі сторінки, — це міняти реальну проблему (неперекладені сторінки) на гіршу (перемикач мов, який помітно веде в порожнечу).
Як це влаштовано в Olmira
Сайт на Olmira працює з до восьми мов — дві на пробному періоді, три на Starter, усі вісім від Pro і вище — і структура вище є вбудованою поведінкою, а не налаштуванням:
URL-адреси — типова мова залишається без префікса, а кожна інша активна мова отримує власний шлях //, а hreflang і альтернативи x-default генеруються для кожної сторінки в момент, коли активна друга мова.
Резервні варіанти — контент розв'язується як точна мова, потім базова мова, потім типова мова сайту, тож незавершений переклад плавно деградує, а не показує порожнечу. Нові відвідувачі отримують мову, яку запитує їхній браузер (серед тих, що ви увімкнули); явний вибір закріплюється. Якщо ви продаєте, вітрина — назви каталогу, підписи форм, підтвердження бронювань, живий чат — теж слідує мові відвідувача.
Сама робота перекладу — вкладка Translations перелічує кожен заголовок сторінки, meta description і секцію тексту по кожній мові з простим відсотком покриття, і готує чернетки відсутнього за допомогою ШІ на запит: один рядок, одна мова чи весь сайт одразу. Жодна пропозиція ШІ не зберігається, поки ви її не прочитаєте й не натиснете зберегти, а мова, яку ви увімкнули, але не завершили, залишається вимкненою на опублікованому сайті, поки її контент справді не заповнений — правило впровадження вище, забезпечене за вас, а не залишене на дисципліну. Повний конструктор: конструктор сайтів.