Головне
- Типи платформ: проксі-сервіси перекладу, багатомовні плагіни CMS, headless CMS із локалізацією, i18n-модулі фреймворків і системи управління перекладами.
- Hreflang працює лише тоді, коли кожна версія вказує на себе й на всі альтернативи, сторінки посилаються одна на одну, а URL повні. Платформи відрізняються тим, наскільки надійно це виводять.
- Підказки перекладу зі ШІ пришвидшують роботу, але політика спаму Google називає автоматичний переклад прикладом зловживання контентом у масштабі, коли він створює багато сторінок без цінності для користувача, тож перевіряйте те, що публікуєте.
- Перевірте будь-яку платформу за трьома пунктами, перш ніж зобов'язуватися: який hreflang вона видає, які метадані перекладає і кому належать переклади, якщо ви підете.
Що має робити багатомовна платформа
Багатомовна платформа має публікувати окрему URL кожною мовою, зв’язувати відповідні сторінки через hreflang і давати змогу редагувати перекладений контент та метадані. ШІ допомагає створити чернетку перекладу. Система публікації все одно повинна формувати правильні сторінки й теги. Порівнюйте готовий результат, а не лише перелік функцій.
П'ять типів платформ
| Тип | Hreflang | Локалізовані метадані | Підказки перекладу зі ШІ | Головний компроміс |
|---|---|---|---|---|
| Проксі або надбудова для перекладу (типовий приклад: Weglot) | Зазвичай автоматично | Часто охоплені, зокрема заголовки й описи | Вбудовані, з редактором для перевірки | Швидко запускається майже на будь-якому сайті, але переклади й робота з URL залежать від постачальника |
| Вбудована багатомовність CMS (WordPress з WPML чи Polylang, Shopify Markets, Wix, Webflow) | Зазвичай автоматично | Для кожної мови, наскільки дозволяють CMS і плагіни | Вбудовані або через додаток | Зручно для типових сайтів, обмежено, коли потрібні нестандартні структури |
| Headless CMS із локалізацією (Storyblok, Contentful, Sanity та подібні) | CMS його не видає. Це має робити ваш фронтенд | Переклад на рівні полів для будь-яких метаданих, які ви змоделюєте | Через власні функції чи інтеграції | Найгнучкіша модель контенту, більше інженерної роботи |
| i18n-модулі фреймворків (Nuxt i18n, next-intl, Astro i18n) | Генерується з конфігурації маршрутів | Настільки повні, наскільки ви їх побудуєте | Не входить. Додайте скрипти чи сервіс | Повний контроль над URL і розміткою, підтримуєте ви |
| Системи управління перекладами (Crowdin, Lokalise, Phrase, Smartling) | Ні. Вони постачають переклади іншим шарам | Рядки й поля, які ви синхронізуєте | Сильні: підказки, пам'ять перекладів і глосарії | Це не вебплатформа, тож потрібен один із типів вище |
Як виглядає правильний hreflang
Google приймає hreflang в HTML-заголовку, у HTTP-заголовках або в карті сайту й вважає їх рівноцінними, тож немає сенсу робити це двічі. Яка б не була платформа, перевірте результат за цими правилами з документації Google та однією поширеною практикою.
- Кожна версія вказує на себе й на всі інші. Якщо дві сторінки не вказують одна на одну, Google ігнорує теги.
- URL повні, разом із https.
- Коди мов відповідають ISO 639-1, а коди регіонів: ISO 3166-1 alpha-2. Код країни без мови недійсний, а EU чи UK не є дійсними кодами регіону.
- Запис x-default вказує резервну сторінку для користувачів, чиєї мови немає в списку.
- Поширена практика, а не правило Google: кожна мовна версія має canonical URL, що вказує на неї саму, щоб ваші переклади не зливалися в одну сторінку.
Які метадані варто локалізувати
- Тег title і meta description, написані під місцевий пошуковий запит, а не перекладені слово в слово.
- Теги Open Graph і соціальні теги, щоб поширені посилання читалися правильно.
- Текст структурованих даних, як-от назви, описи й відповіді FAQ, а також властивість inLanguage.
- Альтернативний текст і підписи до зображень.
- Слаги URL, коли перекладений слаг допомагає читачеві. Після публікації тримайте їх стабільними.
- Атрибут lang в html і перемикач мов зі справжніх посилань, за якими можуть ходити краулери.
Як переклад зі ШІ працює з SEO-метаданими та hreflang?
Сам по собі інструмент перекладу зі ШІ не робить добре жодного з цього. Він перекладає текст, який йому дають. Чи включено тег title, meta description, соціальні теги й альтернативний текст зображень, залежить від того, чи ваша платформа або конвеєр надсилає йому ці поля, а hreflang узагалі не завдання перекладу: його створює платформа чи фреймворк, що публікує сторінки. Переклад зі ШІ допомагає зі словами, а сигнали має обробляти платформа.
| Елемент | Чи робить це переклад зі ШІ? | Що перевірити |
|---|---|---|
| Основний текст | Так, як чернетку | Людина читає його на точність і тон |
| Title і meta description | Лише якщо ці поля надсилаються на переклад | Довжину після перекладу, бо довший заголовок можуть обрізати у видачі, і формулювання під місцевий пошук |
| Теги Open Graph і соціальні теги | Лише якщо включені | Поширені посилання читаються правильно кожною мовою |
| Альтернативний текст зображень і текст структурованих даних | Лише якщо включені | Назви, описи й відповіді FAQ збігаються зі сторінкою |
| Слаги URL | Рідко і лише за налаштування | Тримати стабільними після публікації й використовувати остаточні URL у hreflang і canonical |
| Теги hreflang | Ні, їх створює платформа | Взаємні, з посиланням на себе, повні URL, а також x-default |
| Canonical URL | Ні | Кожна мовна версія вказує на себе |
| Мовний атрибут і записи карти сайту | Ні | Атрибут lang в html встановлено для кожної сторінки, а кожна версія є в карті |
Є два збої, що повторюються. Шар перекладу, який підміняє текст у браузері за допомогою JavaScript, залишає пошуковикам лише сторінку мовою оригіналу. А перекладені сторінки, опубліковані без своїх пар hreflang, сприймаються як непов'язані. Перевірте, переглянувши вихідний код перекладеної сторінки й звіривши обидва пункти.
Де переклад зі ШІ допомагає, а де може нашкодити
Підказки ШІ добре підходять для чернетки, для послідовної термінології через глосарій і для великих обсягів. Вони слабші в юридичних формулюваннях, у культурно специфічних виразах і в усьому, де помилка має ціну. Політика спаму Google щодо зловживання контентом у масштабі каже, що створення багатьох сторінок без цінності для користувача є зловживанням, хоч би як їх створено, і серед технік називає автоматичні перетворення, як-от переклад. Проблема в браку цінності, а не в інструменті.
Вісім речей, які варто перевірити перед вибором
- Перегляньте вихідний код перекладеної сторінки й перевірте блок hreflang за правилами вище.
- Переконайтеся, що кожна мова має власний індексований URL, а не скрипт, який міняє текст у браузері.
- Перевірте, що перекладаються заголовки, описи й соціальні теги, а не лише основний текст.
- Перевірте, що карта сайту містить кожну мовну версію.
- Запитайте, кому належать переклади і чи можна експортувати їх у стандартному форматі.
- Запитайте, що станеться з вашими URL і позиціями, якщо ви перестанете платити.
- Перевірте, що перед публікацією тексту ШІ є крок людської перевірки.
- Виміряйте швидкість сторінки з увімкненим шаром перекладу.
Опишіть мови, редакційний процес і поточну платформу. Допоможемо обрати багатомовне рішення або створити його під ваш контент.
Спланувати багатомовний сайтFAQ
Який тип платформи поєднує hreflang, метадані та переклад зі ШІ?
Проксі-сервіси перекладу та вбудовані багатомовні плагіни CMS поєднують усе три найповніше. Headless-конфігурації та фреймворки дають більше контролю, але ви збираєте частини самі, зазвичай із системою управління перекладами для підказок ШІ.
Чи шкодить SEO машинний переклад?
Сам по собі ні. Політика спаму Google спрямована на сторінки, створені у великих масштабах без цінності для користувача, незалежно від способу створення. Перевірені, точні переклади, що служать реальній аудиторії: це нормально.
Чи потрібен hreflang і в HTML, і в карті сайту?
Ні. Google вважає HTML-теги, HTTP-заголовки та записи карти сайту рівноцінними, тож оберіть один метод і тримайте його правильним.
Джерела
- Google Search Central, Tell Google about localized versions of your page
- Google Search Central, Spam policies for Google web search: scaled content abuse
- Документація модуля Nuxt i18n
Про автора
Erik Salo Akimov · Співзасновник · Інженерія
Erik очолює інженерію в ESADEX. Він проєктує платформи, інфраструктуру та засоби безпеки, що стоять за системами клієнтів.
