Посібник з SEO Крок 10: Мультимовне SEO — Досягнення глобальних аудиторій без розмиття ваших рейтингів
Посібник з SEO Крок 10: Мультимовне SEO
Це Крок 10 з 13-крокового посібника з SEO. Мультимовне SEO дозволяє множити ваш органічний трафік, обслуговуючи кожен ринок їхньою власною мовою — якщо зробити неправильно, це створює безлад з дублікатами контенту.
Кожна мова, яку ви додаєте, є множником на ваш існуючий контент. Сайт з 50 сторінками однією мовою має 50 індексованих URL. Додайте 5 мов, і у вас буде 250. Додайте 20 мов, і у вас буде 1,000. Кожен з цих URL може самостійно ранжуватися в їхніх локальних результатах Google.
Але мультимовне SEO є однією з найскладніших з технічної точки зору областей SEO. Неправильна реалізація створює дублікати контенту, розмиває рейтинг і витрачає бюджет на краулинг. Різниця між правильно міжнародно налаштованим сайтом і неправильно — це може бути різниця в трафіку в 10 разів.
LANGR сама працює на 108 мовах у 89 активних локалях — ми вирішили ці проблеми в масштабах. Цей посібник ділиться всім, що ми дізналися.
Що охоплює мультимовне SEO
Мультимовне SEO охоплює 8 критичних областей:
- Реалізація hreflang — Інформування Google, яка сторінка обслуговує яку мову
- Стратегії маршрутизації за локалізацією — Піддомен проти підкаталогу проти TLD
- Якість перекладу — Машинний проти людського проти змішаного перекладу
- Міжнародний таргетинг — Налаштування Search Console
- Локалізація контенту — Поза перекладом: культурна адаптація
- Підтримка RTL — Мови з правона-left (арабська, іврит, фарсі)
- Виявлення мови — Автоматичне обслуговування правильної версії
- Дублікати контенту — Запобігання крос-мовному канібалізму
1. Реалізація hreflang
Теги hreflang повідомляють пошуковим системам, який URL обслуговує яку мову та регіон. Вони є технічною основою мультимовного SEO — і найбільш поширеною неправильно налаштованою частиною.
Основний синтаксис hreflang:
<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="da" href="https://example.com/da/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />
Критичні правила:
- Кожна сторінка повинна посилатися на ВСІ альтернативні версії (включаючи себе)
x-defaultпозначає запасний варіант (зазвичай англійська або вибір мови)- Теги hreflang повинні бути взаємні (сторінка A посилається на B, B повинна посилатися назад на A)
- Використовуйте ISO 639-1 коди мов (
en,da,de), а не коди країн - Для контенту, специфічного для регіону:
en-us,en-gb,pt-br(мова-регіон) - Максимум ~50 записів hreflang на сторінку (обмеження продуктивності)
Три варіанти розміщення:
| Метод | Найкраще підходить | Недоліки | |-------|---------------------|----------| | в | Маленькі сайти (< 10 мов) | Збільшує HTML, повільніший парсинг | | HTTP заголовки | Не HTML файли (PDF, API) | Не широко підтримується | | XML карта сайту | Великі сайти (10+ мов) | Повільніше виявлення краулерами |
Приклад hreflang у карті сайту:
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="da" href="https://example.com/da/page" />
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>
Поширені помилки hreflang:
- Відсутній самопосилальний тег (сторінка не включає себе)
- Невзаємні теги (A посилається на B, але B не посилається на A)
- Неправильні коди мов (
dkзамістьdaдля датської) - Посилання на не-200 URL (перенаправлення, 404)
- Змішування
x-defaultз мовно-специфічною сторінкою
Швидка перемога: Перевірте свій сайт і експортуйте всі теги hreflang. Перевірте на неприйнятні відносини — це найбільш поширена помилка і спричиняє для Google ігнорування вашої всієї налаштування hreflang.
2. Стратегії маршрутизації за локалізацією
Як ви структурируєте URL для різних мов впливає на SEO, досвід користувача та технічну складність. Існує три основні підходи:
Підкаталог (рекомендується)
example.com/en/page
example.com/da/page
example.com/de/page
Плюси: Одна авторитетна доменна зона, легко управляти, один сертифікат SSL, одна аналітика, одна властивість Search Console, найкраще для більшості сайтів.
Мінуси: Менше гео-таргетингових сигналів, ніж ccTLD.
Піддомен
en.example.com/page
da.example.com/page
de.example.com/page
Плюси: Можна хостити на різних серверах/CDN для кожного регіону, окремі бюджети на краулінг.
Мінуси: Кожен піддомен будує авторитет окремо (сила посилань не переходить автоматично), кілька властивостей Search Console, складніша налаштування.
Код TLD країни (ccTLD)
example.com (англійська)
example.dk (датська)
example.de (німецка)
Плюси: Найсильніший гео-таргетинговий сигнал, користувачі довіряють місцевим TLD, кожен домен незалежний.
Мінуси: Дороги (купівля 20+ доменів), окремий авторитет на кожен домен, складна побудова посилань, окрема аналітика/консоль.
Наша рекомендація: Маршрутизація підкаталогу для 90% сайтів. Це концентрує всю авторитетність посилань на єдиному домені, при цьому надаючи чіткі локальні сигнали. Використовуйте формат /{locale}/page.
https://langr.org/page (англійська, за замовчуванням)
https://langr.org/da/page (датська)
https://langr.org/de/page (німецка)
https://langr.org/ja/page (японська)
Швидка перемога: Якщо ви використовуєте піддомени та маєте проблеми з авторитетом, подумайте про міграцію на підкаталоги. Сайти, які мігрують з піддоменів на підкаталоги, зазвичай спостерігають підвищення органічного трафіку на 20-50% протягом 3-6 місяців, коли сила посилань консолідується.
3. Якість перекладу проти машинного перекладу
Якість перекладу безпосередньо впливає на рейтинги. Google може виявити машинний переклад і, можливо, знецінить погано перекладені сторінки. Але в 2026 році AI переклад значно краще, ніж правило від 2020 року.
Спектр якості перекладу:
| Рівень | Метод | Якість | Вартість | Найкраще для | |--------|-------|--------|----------|--------------| | 1 | Сировина GPT/DeepL | 60-75% | ~$0 | Внутрішнє використання, чернетки | | 2 | AI + постредагування | 75-90% | ~$0 | Контент блогів, некритичні сторінки | | 3 | AI + людський перегляд | 90-97% | $0.03-0.08/слово | Сторінки продуктів, ключові цільові сторінки | | 4 | Професійний носій мови | 97-100% | $0.10-0.25/слово | Юридичні, медичні, критично важливі для бренду |
Ключова думка для 2026 року: Рівень 2 (AI з якісними підказками) тепер достатній для більшості веб-контенту. Алгоритми Google для дублікатів контенту більше не покарають добре виконаний машинний переклад — вони покарають поганий переклад, який не надає цінності.
Ознаки перекладу, які шкодять SEO:
- Неперекладені сегменти, змішані з перекладеним контентом
- Елементи UI (кнопки, мітки), які все ще на вихідній мові
- Форматування, специфічне для локалізації, не адаптоване (дати, валюти, телефонні номери)
- Культурні посилання, які не підлягають перекладу (ідіоми, жарти, приклади)
- Одні й ті ж мета заголовки/описи по всіх мовах
Як перевірити якість перекладу:
- Перевірте, що ВСЕ видиме текст переведено (включаючи навігацію, колонтитули, форми)
- Перевірте форматування, специфічне для локалізації (DD/MM/YYYY проти MM/DD/YYYY)
- Тестуйте CTAs — чи звучать вони природно на цільовій мові?
- Перевірте мета теги — заголовок і опис повинні бути незалежно написані для кожної мови
- Переконайтеся, що жодні сирі i18n ключі не виставлені (наприклад,
nav.homeзамість "Головна")
Швидка перемога: Перевірте свої переведені сторінки на наявність змішаного мовного контенту. Якщо будь-які кнопки, мітки або елементи UI все ще на вашій вихідній мові, виправте їх негайно — змішані мовні сторінки сигналізують про низьку якість для Google.
4. Міжнародний таргетинг у Search Console
Налаштування міжнародного таргетингу Google Search Console допомагають Google зрозуміти, які сторінки повинні ранжуватися в яких країнах.
Для налаштувань підкаталогу:
- Ви не можете налаштувати таргетинг країни на підкаталог (тільки на домен/піддомен)
- Натомість покладайтеся на hreflang + мову контенту + сигнали користувачів
- Надішліть карту сайту для кожної локалізації:
sitemap-en.xml,sitemap-da.xml
Для ccTLD:
.dkавтоматично націлений на Данію.deавтоматично націлений на Німеччину- Ніякої ручної налаштування не потрібно
Для загальних TLD (.com, .org, .net):
- Налаштуйте "Міжнародний таргетинг" для кожної властивості в Search Console
- Використовуйте hreflang як основний сигнал
Практичні кроки:
- Підтвердіть свій сайт у Search Console (одна властивість для налаштувань підкаталогу)
- Надішліть вашу карту сайту з анотаціями hreflang
- Перевірте звіт "Міжнародний таргетинг" на наявність помилок
- Моніторте звіт "Покриття" для кожної мови (використовуйте фільтрацію за параметрами URL)
- Перевірте наявність попереджень "Дублікати без вибраного канонічного" — це часто вказує на проблеми з hreflang
Швидка перемога: Перейдіть до Search Console > Продуктивність > Фільтр за країною. Перевірте, чи користувачі в Німеччині потрапляють на ваші англійські сторінки, замість німецьких. Якщо так, ваша конфігурація hreflang має помилки.
5. Локалізація контенту (не лише переклад)
Локалізація виходить за межі перекладу слово в слово. Вона адаптує контент до культурного контексту, місцевої пошукової поведінки та специфічних потреб ринку.
Що локалізувати:
- Валюта та цінові пропозиції: Показувати місцеву валюту (€ в Німеччині, kr в Данії, ¥ в Японії)
- Формати дати/часу: 25/06/2026 (ЄС) проти 06/25/2026 (США) проти 2026/06/25 (ISO/Японія)
- Телефонні номери: Місцевий формат з кодом країни для міжнародних
- Адреси: Відповідати місцевому поштовому формату
- Соціальний доказ: Місцеві імена клієнтів, місцеві компанії, місцеві кейс-стаді
- CTAs: Адаптувати тон (формальний німецькою/японською, неформальний англійською/датською)
- Зображення: Локалізувати текст на зображеннях, використовувати культурно прийнятні візуальні елементи
- Юридичні: GDPR для ЄС, різні вимоги щодо згоди на куки для кожної країни
- Приклади: Місцеві бренди, місцеві вебсайти, місцеві посилання
Контент, який не повинен бути безпосередньо перекладений:
- Пости в блогах на місцеві теми (пишіть унікально для кожного ринку)
- Кейси (використовуйте місцеві бізнеси)
- Сторінки цін (різне ціноутворення для ринку є допустимим)
- Новинний контент (регіональна актуальність варіює)
Локалізація ключових слів: Не перекладайте ключові слова — досліджуйте їх рідною мовою. "Страхування автомобіля" англійською може бути "bilforsikring" датською, але лідером пошукового обсягу може бути "forsikring bil" (інший порядок слів). Використовуйте місцеві інструменти для дослідження ключових слів.
Швидка перемога: Перевірте свою сторінку з цінами для всіх мов. Чи показується правильна місцева валюта? Чи ваші CTAs культурно доречні? CTA "Спробуйте безкоштовно" може потребувати бути "Jetzt kostenlos testen" німецькою — не буквальний переклад, але те, що очікують бачити німецькі користувачі.
6. Підтримка RTL
Мови з правона-left (арабська, іврит, фарсі/персійська, урду, пасhto) вимагають значної адаптації макету. Використання контенту RTL з макетом зліва-направо робить ваш сайт непригодним для ~500 мільйонів носіїв мови.
Технічна реалізація:
<!-- Виявити та застосувати напрямок -->
<html lang="ar" dir="rtl">
Що потрібно перевернути в RTL:
- Вирівнювання тексту (текст тіла вирівняний вправо)
- Напрямок макету (бічні панелі переміщуються зліва направо)
- Порядок навігації (зворотний)
- Іконки з напрямковим значенням (стрілки, індикатори прогресу)
- Паддінг і маржин (перемістіть значення зліва/вправо)
- Радіус кордону (перемістіть кута)
- Напрямок CSS flexbox/grid
Що НЕ повинно перевертатися:
- Телефонні номери та математичні вирази
- Брендовані назви та логотипи зліва направо
- Керуючі елементи аудіо/відео
- Індикатори горизонтального прокручування
- Вбудовані кодові блоки
CSS підхід (сучасний):
/* Використовуйте логічні властивості */
.card {
margin-inline-start: 1rem; /* замінює margin-left */
padding-inline-end: 0.5rem; /* замінює padding-right */
border-start-start-radius: 8px; /* верхній лівий в LTR, верхній правий в RTL */
}
Тестування RTL:
- Додайте
dir="rtl"дота перевірте кожну сторінку - Переконайтеся, що арабський/іврит текст читабельний (не спотворений юнікод)
- Перевірте введення форм (направлення введення тексту)
- Перевірте, що числа правильно відображаються в RTL тексті
Швидка перемога: Якщо ви підтримуєте арабську або іврит, додайте dir="rtl" до вашого HTML елемента для цих локалей і використовуйте логічні властивості CSS (margin-inline-start замість margin-left). Ця одна зміна вирішує 80% проблем з макетом RTL.
7. Виявлення та маршрутизація мови
Як ви вирішите, яку мовну версію показати користувачу, вплине як на UX, так і на SEO.
Найкраща практика: маршрутизація на основі URL з перевагою у куки
- Перше відвідування: Показуйте контент на основі URL (наприклад,
/da/page= датська) - Кореневий URL (
/): Перенаправте на підставі заголовкаAccept-LanguageАБО покажіть за замовчуванням (англійську) - Ручний перемикач: Коли користувач вибере мову, встановіть куки і поважайте їх на майбутніх відвідинах
- Ніколи: Авто-редирект з мовно-специфічного URL
Що потрібно уникати:
- Перенаправлення на основі IP (Google індексує з IP США → лише англійська)
- Виявлення мови лише за допомогою JavaScript (пошукові системи не можуть надійно виконувати JS)
- Перенаправлення
/de/pageна/en/pageдля англійських користувачів (ламає hreflang) - Клоакінг (показування різного контенту на основі користувацького агента)
Правильна поведінка редиректу:
Користувач відвідує: / → 302 редирект на /{detected-locale}/
Користувач відвідує: /da/page → Показати датський контент (ніколи не редиректити)
Користувач відвідує: /nonexistent → 404 (не редиректити на мовний варіант за замовчуванням)
Критичне правило для SEO: Кожен мовний URL повинен бути безпосередньо доступний для Googlebot без редиректів. Якщо Google обходить /da/page і перенаправляє на /en/page, він ніколи не індексує ваш датський контент.
Швидка перемога: Перевірте, чи може Googlebot безпосередньо отримати доступ до всіх ваших мовних URL. У Search Console використовуйте інструмент перевірки URL на не-англійському URL. Якщо показує редирект, виправте логіку маршрутизації.
8. Дублікат контенту між мовами
Мультимовні сайти стикаються з унікальною проблемою дублікатів контенту: схожі сторінки на різних мовах можуть змагатися одна з одною в пошукових результатах.
Коли дублікати контенту стають проблемою:
- Сторінки, які на 90%+ ідентичні між мовами (не перекладений контент)
- Один і той же URL доступний з і без префікса локалізації (
/pageі/en/page) - Відсутність канонічних тегів, що дозволяє обом версіям індексуватися
- Помилки hreflang, що призводять до того, що Google вибирає "помилкову" версію
Рішення:
| Проблема | Рішення | |----------|---------| | Неперекладені сторінки | Використовуйте noindex до перекладу або покажіть англійською з чітким індикатором мови | | Подвійні URL (/page + /en/page) | 301 редирект один до іншого | | Google індексує неправильну мову | Виправте взаємність hreflang, перевірте в Search Console | | Індексовані низької якості переклади | Поліпште якість перекладу або консолідуйте до меншої кількості мов |
Стратегія канонічного тегу:
<!-- Кожна мовна сторінка є своїм канонічним -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />
<!-- /da/page -->
<link rel="canonical" href="https://example.com/da/page" />
Ніколи не вказуйте канонічний тег з однієї мови на іншу (наприклад, датський канонічний тег, що вказує на англійську) — це говорить Google ігнорувати датську версію повністю.
Швидка перемога: Введіть site:yourdomain.com "ваш заголовок сторінки" в Google. Якщо ви бачите обидві англійські та перекладені версії, що з’являються за одним запитом, у вас є проблема з дублікатами контенту або hreflang.
Контрольний список мультимовного SEO
Перевірте це для кожного міжнародного сайту:
- [ ] Теги hreflang на всіх сторінках, включаючи самопосилання та x-default
- [ ] Всі відносини hreflang є взаємними (перевірено з краулером)
- [ ] Правильна маршрутизація локалізації (рекомендується підкаталог):
/{locale}/page - [ ] Ніяких автоматичних редиректів з мовно-специфічних URL
- [ ] Верифікована якість перекладу (немає змішаних мовних сторінок)
- [ ] Мета заголовок і опис унікальні для кожної мови (не дублюються)
- [ ] Валюта, дати та формати локалізовано для кожного ринку
- [ ] Підтримка RTL реалізовано для арабської/іврит/фарсі (якщо застосовно)
- [ ] Надіслано карта сайту для кожної локалізації до Search Console
- [ ] Кожна мовна сторінка має свій канонічний URL (не вказує на іншу мову)
- [ ] Немає сирих i18n ключів видимих на жодній сторінці
- [ ] Перемикач мови доступний на всіх сторінках (посилання на еквівалентні сторінки, а не на домашню сторінку)
Як LANGR перевіряє мультимовне SEO
LANGR має два спеціалізовані модулі для мультимовного SEO:
i18n-checker: Краулить до 5 варіантів локалізації вашіх сторінок та перевіряє:
- Повноту і взаємність тегів hreflang
- Невідомі локальні URL (які повертають 404 або редиректять)
- Хардкодові/неперекладені строки між локалями (виявлення запасів)
- Виставлені сирі i18n ключі як видимий текст
- Відсоток покриття перекладу
Сканер перекладу: Оцінка якості, підкріплена AI:
- Оцінює природність перекладу за шкалою 0-100
- Виявляє артефакти машинного перекладу
- Ідентифікує неперекладені сегменти серед інших перекладених сторінок
- Окремо перевіряє елементи UI (кнопки, мітки, навігація) від основного контенту
У комплекті ці модулі перевіряють вашу реалізацію мультимовності з технічної (hreflang, маршрутизація, канонічні) та якостної (переклад, локалізація) точки зору — дві з 13 дисціплін SEO LANGR.
Поширені помилки мультимовної SEO (ранжовані за впливом)
- Невзаємний hreflang — Google ігнорує всю налаштування
- Авто-редирект на основі IP — Заважає Googlebot індексувати не-англійські версії
- Одні й ті ж мета теги між мовами — Витрачає потенціал ранжування перекладених сторінок
- Сторінки на змішаних мовах — Кнопки англійською, контент німецькою = сигнал низької якості
- Відсутній x-default — Google не може визначити ваш запасний варіант
- Дослівний переклад URL —
/about-us→/uber-unsце нормально, але тримайте це послідовно - Ігнорування RTL — Зламаний макет для 500M+ носіїв мови
- Канонічний тег, вказаний на іншу мову — Вбиває перекладену версію в індексі Google
Що далі?
Крок 11: Виявлення B2B лідів — Перетворення даних SEO на кваліфіковані ліди за допомогою автоматизованого пошуку, оцінювання лідів на основі доменів та розсилки, що базуються на висновках SEO.
Цей посібник є частиною серії LANGR з 13-т блоків з SEO. Запустіть безкоштовний аудит, щоб дізнатися, де ваш сайт стоїть у всіх 13 дисциплінах.