Мультимовне SEO: чому перекладені сторінки не ранжуються на своїх ринках

Один бізнес виходить на кілька ринків, а не один сайт перекладається кількома мовами.

Бізнес, що продає у трьох країнах, не має одного сайту трьома мовами.

У нього один бізнес, що виходить на три пошукові ринки, у кожного з яких свої конкуренти, своя лексика, своя купівельна поведінка і своє уявлення про те, що важливе в продукті.

Переклад переносить слова. Він не переносить бізнес на ринок.

Саме на цій відмінності тихо провалюється більшість мультимовних проєктів, і працює вона на двох рівнях.

Перший механічний: набір технічних декларацій, які повідомляють пошуковим системам, яка версія кому призначена. Коли вони хибні, в решти немає шансів, бо сторінки не доходять до ринку, для якого написані.

Другий стратегічний, і це та частина, яку майже ніхто не закладає в бюджет: розуміння, що ринок не дорівнює мові, і що сторінка, яка ранжується в одній країні, може відповідати на питання, якого в іншій ніхто не ставить.

Стаття охоплює обидва рівні, саме в такому порядку, бо механічний шар визначає, чи стане стратегічна робота взагалі видимою.

Шар, який ламається тихо

Шар, який ламається тихо

У технічного шару мультимовного SEO є незвична властивість: коли він ламається, тобі ніхто не повідомляє.

Сторінки відкриваються. Перемикач мов працює. Помилок ніде немає. Німецька версія просто ніколи не з'являється в німецькій видачі, а замість неї показується англійська.

Це пояснюється двома фактами.

По-перше, Google трактує hreflang як підказку, а не як директиву. Зламана реалізація не відхиляється з попередженням. Вона ігнорується, і сайт продовжує працювати так, ніби розмітки немає взагалі.

По-друге, звітності, яка раніше існувала, більше немає. Google оголосив про застарілість звіту International Targeting у Search Console в серпні 2022 року і видалив його у вересні, зазначивши, що таргетинг за країнами через Search Console мав мало цінності для екосистеми і більше не підтримується. Той самий звіт містив монітор помилок hreflang, і його нічим не замінили. Документація Google тепер відсилає до сторонніх інструментів.

Щодо масштабу проблеми, чесна позиція така: рецензованих вимірювань не існує. Вендорські аналізи великих краулів повідомляють про частку помилок приблизно від 60 до 80 відсотків міжнародних сайтів, причому одна цифра приписується даним Screaming Frog, інші окремим агентським аудитам. До точного відсотка варто ставитись обережно. Значуще те, що незалежні вибірки раз за разом потрапляють в один і той самий діапазон.

Набір має бути узгоджений

Набір має бути узгоджений

Мовні версії утворюють набір, який перевіряється цілком, а не посторінково.

Google Search Central формулює основне правило прямо: якщо сторінка X посилається на сторінку Y, сторінка Y має посилатись назад на X, а відсутність зворотних посилань призводить до того, що анотації ігноруються або інтерпретуються хибно.

Вимога захисна, а не педантична. Без взаємності будь-який сайт міг би оголосити себе альтернативною версією будь-якого іншого.

Поруч із ним друга вимога: кожна сторінка має містити анотацію, що вказує на саму себе, а не лише на альтернативи. Самопосилання встановлює, яке місце сторінка займає в наборі, який вона описує.

Відсутність самопосилань часто трапляється в системах управління контентом, що генерують ці посилання динамічно, бо природний спосіб написати такий цикл, вивести всі мови крім поточної. Цей цикл хибний одразу на кожній сторінці сайту.

Жодна з помилок не проявляється на запуску. Вони виникають пізніше, коли додається мова, а наявні версії не оновлюються, щоб її оголосити, або коли змінюється URL, а посилання на нього ні.

Взаємність не впроваджують одного разу. Це стан, у якому потрібно лишатись.

Конфлікт із canonical

Конфлікт із canonical

Це одна з найруйнівніших помилок, і зазвичай її вносить той, хто намагається бути акуратним.

Теги canonical існують, щоб об'єднувати дублікати. Власник сайту бачить кілька майже ідентичних сторінок різними мовами, розмірковує, що вони не мають конкурувати між собою, і спрямовує всі canonical на англійську версію.

Така конфігурація повідомляє пошуковим системам, що неанглійські сторінки є дублікатами англійської. Результатом може стати те, що англійський URL буде обраний канонічним, а перекладені версії не будуть проіндексовані чи показані як передбачувані альтернативи.

Canonical і hreflang, це окремі системи, що відповідають на різні питання, і вони мають узгоджуватись. Сайт не має одночасно сигналізувати, що сторінка підходить конкретному ринку, і що її канонічним представником є інший URL.

Стандартна конфігурація така: кожна еквівалентна мовна версія канонізується на саму себе. Це не дублікати, що конкурують за один запит. Це альтернативи, які обслуговують різні ринки, і hreflang, це механізм, який про це повідомляє.

Варто бути точним у тому, що hreflang робить, а чого ні. Гері Іллієс з Google описував його як такий, що не є прямим сигналом ранжування, але при цьому несе суттєву цінність усередині контентного кластера. Коректні анотації визначають, яка версія кому показується. Вони не змушують цю версію ранжуватись краще, ніж вона ранжувалась би інакше.

Коди суворіші, ніж здається

Коди суворіші, ніж здається

Коди мов і регіонів слідують опублікованим стандартам і не трактуються поблажливо. Мова використовує ISO 639-1. Регіон, якщо присутній, використовує ISO 3166-1 alpha-2, і мова завжди йде першою.

Помилки достатньо однотипні, щоб їх перелічити.

• Коди регіонів, які виглядають правильними і такими не є, найчастіше en-uk там, де стандарт вимагає en-gb
• Континентальні групування на кшталт en-eu, неприпустимі, бо ЄС не країна
• Код країни, використаний окремо, наприклад mx, який є регіоном, а не мовою
• Трилітерні коди мов там, де потрібні дволітерні
• Плутанина між писемністю і регіоном, наприклад використання zh-CN, коли передбачувана відмінність, це спрощена китайська як система письма, що позначається zh-Hans

Невалідний код не приймається частково. Анотація, що містить його, ігнорується, а оскільки набір залежить від взаємності, сторінки, які на неї посилались, теж втрачають цей зв'язок.

З цим пов'язаний x-default, що задає запасний варіант для користувачів, чия мова і регіон нічому в наборі не відповідають. Він ставиться один раз, на сторінці-запасному варіанті. Застосування його до кожної мовної версії, поширене хибне прочитання, що позбавляє його сенсу.

Архітектура, це бізнес-рішення

Архітектура, це бізнес-рішення

Під анотаціями лежить рішення, ухвалене значно раніше, зазвичай без участі SEO, і воно задає стелю для всього, що знаходиться вище.

Національний домен, один із найсильніших географічних сигналів, доступних пошуковій системі. Саме це робить його цінним удома і дорогим за кордоном. Google описував національні домени як такі, що отримують перевагу локалізації для користувачів, які шукають із відповідної країни, що іншими словами означає, що ця перевага не переноситься.

Вона не переноситься навіть між ринками, що говорять однією мовою. Французький національний домен вказує на Францію, а не на Бельгію чи Швейцарію.

Це стало живою проблемою для бізнесів, які виросли швидше за свій домен. Компанія запускається на національному розширенні, бо обслуговує цю країну, потім роки по тому продає до Німеччини, Польщі і США, додає мовні версії, коректно впроваджує hreflang і не може зрозуміти, чому нові ринки не відгукуються.

Дві обставини роблять це складнішим, ніж здається.

Таргетингу за країнами в Search Console більше не існує, він був видалений у вересні 2022 року. І для національних доменів він від початку не був доступний, бо Google і так пов'язує такі домени з їхньою країною. Перемикача не було ніколи, а тепер його немає і для загальних доменів.

Google також відносить короткий список національних розширень до загальних, включно з кількома прийнятими технологічними компаніями. Більшість національних розширень до цього списку не входять, і бізнес не може до нього потрапити за бажанням.

Домен заявляє країну. Налаштування, яке скаже інакше, немає.

Нижче домена те саме рішення повторюється на структурному рівні. Підкаталоги консолідують авторитет у межах одного домена, тому посилання, зароблене на будь-якому ринку, підтримує всі ринки, і тому саме вони рекомендуються за замовчуванням для бізнесів, що виходять на нові території. Окремі національні домени дають найсильніший локальний сигнал і розділяють авторитет, тому сила на одному ринку нічого не дає іншому. Піддомени знаходяться між цими двома варіантами і часто успадковують недоліки обох.

Архітектура вирішує, чи накопичується міжнародне зростання, чи починається заново щоразу.

Перегляд рішення пізніше означає повну міграцію з усім, що за цим слідує. Про те, у що це обходиться, ми писали у статті Чек-лист міграції сайту, який пропускають більшість агенцій.

Поведінка не перекладається

Поведінка не перекладається

Щойно механічний шар тримається, починається складніша робота, і жодна коректна розмітка її не замінює.

Усередині того, що більшість бізнесів називає перекладом, ховаються три різні операції, і оплачується зазвичай лише перша.

Переклад конвертує мову. Локалізація конвертує сенс. Міжнародний пошук вимагає розуміння поведінки.

Перші дві, це робота з контентом. Третя, це дослідження, і пропуск його, причина, з якої технічно бездоганні мультимовні сайти все одно провалюються комерційно.

Бо кордон не переживає не лексика. Його не переживає шлях.

Покупці на різних ринках приходять до однієї й тієї самої покупки через різну послідовність питань. Один ринок починає з проблеми і приходить до товарної категорії пізно. Інший починає з бренду. Третій починає з порівняння з конкретним конкурентом, або з регуляторного питання, або з цінового діапазону.

Кожна з цих відправних точок, це інший пошук, на іншій стадії, що вимагає іншої сторінки для відповіді.

Два ринки можуть купувати один товар і ніколи не шукати однаково.

Перекладений сайт побудований навколо послідовності одного ринку. Він відповідає на питання в тому порядку, в якому їх ставить вихідна аудиторія, а отже на новому ринку правильні відповіді існують, але з'являються не в той момент, на сторінках, куди ніхто не приходить.

Видимий симптом помітити простіше, ніж причину. Ключові слова не перекладаються. Ринки використовують різні слова для одного товару, шукають із різним ступенем конкретності, а іноді шукають взагалі інше, бо покупка влаштована інакше.

Найяскравіше це проявляється в частинах сторінки, написаних спеціально під пошук: описи категорій, текст у футері, абзац під сіткою товарів, копірайт, зібраний навколо ключового слова, а не навколо читача.

Ці блоки писались під вихідний ринок. Їх переклад дає граматично коректні речення, оптимізовані під те, як шукає інша країна, націлені на конкурентів, які там не працюють, побудовані на частотностях, які там не діють.

Вони читаються правильно і не націлені ні на що.

Те саме стосується заголовків і мета-описів, що генеруються за шаблоном. Патерн, який працює на одному ринку, часто дає на іншому формулювання, яке ніхто не набирає, бо шаблон кодує припущення про порядок слів і намір, вірне тільки вдома.

Що важливе ринку

Що важливе ринку

Під послідовністю лежить версія тієї самої проблеми, яку пропускають найчастіше, бо вона невидима для будь-кого, хто перевіряє переклад.

Різні ринки не просто по-різному шукають один і той самий товар. Їх хвилює в ньому різне.

Покупці одного ринку приходять із питаннями про сертифікацію, матеріали і відповідність нормам. Інший першою чергою запитує про терміни доставки і умови повернення. Третій зважує ціну і наявність раніше за все інше. Четвертий хоче знати походження і історію виробника і готовий за це доплатити.

Це не відмінності в тональності. Вони визначають, що має бути вгорі картки товару, на які питання зобов'язаний відповідати опис категорії, які заперечення потрібно зняти, перш ніж відвідувач рушить далі, і про що взагалі має бути стаття на цьому ринку.

Перекладена картка товару показує пріоритети вихідного ринку новою мовою. Усе, що місцевий покупець хотів дізнатись, цілком може бути на сторінці, трьома екранами нижче, під тим, про що він не запитував.

Товар той самий. Пріоритети інші.

Дослідження, яке для цього потрібне, неефектне і його важко пропустити непомітно. Читати, як місцеві конкуренти подають ту саму категорію. Вивчати питання, що з'являються в локальних пошукових підказках і на форумах. Відзначати, на що скаржаться в місцевих відгуках, бо скарги, це невиправдані очікування, вимовлені вголос.

Це займає дні, а не тижні, і змінює те, що містять сторінки, а не те, як вони сформульовані. Саме ця робота відділяє сайт, доступний кількома мовами, від сайту, що конкурує на кількох ринках.

Аудит того, що є

Аудит того, що є

На невеликому чи середньому сайті перевірки нижче можна виконати за вечір, і вони виявлять більшість типових збоїв. На великому мультимовному каталозі в десятки тисяч URL вони визначають, що досліджувати, а не складають саме дослідження.

Оскільки Search Console більше не повідомляє про помилки hreflang, технічна частина спирається на зовнішні інструменти: краулер на кшталт Screaming Frog для перевірки всього сайту або безкоштовний тестер hreflang для точкової перевірки окремих сторінок.

• Переконатись, що анотації hreflang присутні у вихідному коді кожної мовної версії
• Переконатись, що кожна сторінка містить анотацію, яка вказує на саму себе
• Узяти одну сторінку і перевірити, що кожна заявлена нею альтернатива заявляє її у відповідь
• Перевірити canonical на неанглійській сторінці і переконатись, що він вказує на неї саму
• Перевірити кожен код мови і регіону на відповідність стандартам
• Переконатись, що x-default трапляється один раз, на передбачуваній запасній сторінці
• Переконатись, що всі URL в анотаціях абсолютні, а не відносні
• Установити, чи не сигналізує доменне розширення про країну, відмінну від цільових ринків
• Прочитати SEO-блоки на невихідній мовній версії і запитати, під який ринок вони писались
• Порівняти картку товару з карткою місцевого конкурента і перевірити, чи йде та сама інформація в тому самому порядку
• Пошукати цільовий запит у регіональному Google і подивитись, яка версія з'являється

Остання перевірка важливіша за всі, бо вона перевіряє результат, а не конфігурацію.

Якщо англійська сторінка з'являється за німецьким запитом у Німеччині, щось у наборі хибне, незалежно від того, як виглядають теги.

Як виглядає виправлення

Як виглядає виправлення

Виправлення не спрацьовують миттєво. Пошуковим системам потрібно заново обійти зачеплені сторінки і переобробити зв'язки між ними, що зазвичай займає кілька тижнів, а на великих сайтах довше.

Це важливо для управління очікуваннями. Правка, викочена в понеділок, не дає результату до п'ятниці, і відсутність негайних змін не є доказом того, що правка була хибною.

Це важливо і для послідовності дій. Ремонт анотацій, поки самі сторінки все ще звернені не до того ринку, дає коректно показувані сторінки, які нікому не потрібні. Технічна робота робить контент досяжним. Вона не робить його релевантним.

Має відбутись і те, і інше, і порядок не взаємозамінний, бо стратегічну роботу не можна виміряти, поки механічний шар продовжує її відкидати.

Архітектура ринків

Архітектура ринків

Рамка, що породжує більшість цих проблем, закладена в самому запиті.

Бізнес просить перекласти свій сайт. Запит звучить як завдання з контенту зі зрозумілим обсягом, і оцінюється і виконується саме так.

Насправді бізнес виходить на ринок, де в нього немає історії, конкуруючи з компаніями, які роками відповідали на питання цього ринку, у пошуковому середовищі зі своєю структурою, і де його власний домен, можливо, сигналізує, що він належить іншому місцю.

Це не проєкт із перекладу. Це експансія, а сайт, та її частина, яка виявилась видимою.

Трактована як переклад, вона дає сайт, доступний кількома мовами і конкурентоспроможний на одному. Трактована як експансія, вона змушує поставити питання, що визначають, чи були решта ринків вигравані в принципі: які ринки виправдовують вкладення, що цим покупцям справді потрібно знати, хто вже займає це місце і чи здатна поточна архітектура понести відповідь.

Мультимовний сайт, це один бізнес на кількох ринках. Не один перекладений сайт.

Контент зазвичай уже існує. Чи зараховується він, залежить від рішень, ухвалених значно вище рівня тегів.

Часті питання

Чому моя перекладена сторінка не ранжується в іншій країні?

Зазвичай з однієї з двох причин. Або технічний набір зламаний, і сторінка ніколи належним чином не пов'язується з цим ринком, або сторінка відповідає на питання вихідного ринку новою мовою. Перше, проблема конфігурації, друге, проблема дослідження, і вони часто присутні разом.

Чи покращує hreflang ранжування?

Ні. Google описував hreflang як такий, що не є прямим сигналом ранжування, але при цьому несе реальну цінність усередині контентного кластера. Коректні анотації допомагають визначити, яка версія кому показується. Вони не змушують цю версію ранжуватись вище, ніж вона ранжувалась би інакше.

Чи має кожна еквівалентна мовна версія канонізуватись на саму себе?

Так. У стандартній мультимовній реалізації кожна еквівалентна мовна версія зазвичай має вказувати canonical на саму себе. Спрямування всіх версій на англійську сторінку може призвести до того, що пошукові системи вважатимуть решту дублікатами і оберуть англійський URL канонічним. Мовні версії, це альтернативи, а не дублікати, і hreflang виражає цей зв'язок.

Підкаталоги кращі за піддомени для мультимовних сайтів?

Для більшості бізнесів так. Підкаталоги утримують авторитет консолідованим у межах одного домена, тому посилання, зароблене на будь-якому ринку, підтримує всі ринки. Піддомени і окремі національні домени цей авторитет розділяють, хоча окремий локальний домен може бути виправданий, коли сильна присутність у конкретній країні є частиною бізнес-стратегії.

Чи достатньо перекласти сайт для міжнародного SEO?

Ні, і саме це припущення викликає більшість описаних вище збоїв. Переклад конвертує мову. Вихід на ринок також вимагає розуміння того, як цей ринок шукає, що він хоче дізнатись насамперед і хто вже відповідає там на ці питання.

Сторона даних тієї самої задачі, де масштаб каталогу множить число станів ще до будь-якого пошуку, розібрана у статті 50 000 товарів, 8 ринків: де масштаб каталогу стає архітектурною задачею.

Сторона даних тієї самої задачі, де масштаб каталогу множить число станів ще до будь-якого пошуку, розібрана у статті Мультикраїновий e-commerce для великих каталогів: архітектурні рішення, що задають стелю.