Міжнародне SEO: як структурувати сторінки для різних країн

Вступ

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

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

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

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

Орієнтація на країни починається з URL-адреси

У власній документації Google щодо управління багаторегіональними сайтами викладено реалістичні варіанти: домени для окремих країн, піддомени, підкаталоги та параметри URL-адреси. Останній варіант позначено як «не рекомендується», тож залишається три серйозні варіанти:

• Домени з кодом країни (example.de, example.fr) надсилають найчіткіший сигнал геотаргетингу, але кожен із них може орієнтуватися лише на одну країну, і кожен доданий домен розділяє ваш авторитет та збільшує обсяг робіт з обслуговування.
• Піддомени легко налаштовувати, але користувачі часто не можуть визначити за URL-адресою, чи «de» означає німецьку мову, чи німецький ринок.
• Підкаталоги на одному глобальному домені концентрують авторитет в одному місці та мінімізують витрати на обслуговування, саме тому вони стали стандартом для більшості міжнародних продуктів.

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

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

Модель «хаб-і-спиці» для одного продукту на багатьох ринках

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

Туристичні платформи використовують цю модель для сторінок напрямків, SaaS-компанії — для сторінок з цінами для кожної країни, і ця модель виходить далеко за межі сфери технологій. Оператори ставок також її використовують: розділ «Lucky Numbers» на Hollywoodbets, південноафриканській платформі ставок, розгалужується на сторінки на рівні країн для одного продукту з фіксованими коефіцієнтами, побудованого навколо лотерейних розіграшів із десятків країн (продукт для аудиторії, яка досягла віку, дозволеного для азартних ігор на регульованих ринках). Один продукт, один шаблон, одна центральна URL-адреса та сторінка-відгалуження для кожного ринку, який охоплює цей контент.

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

Логіка SEO цього шаблону проста:

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

Hreflang, крок за кроком

Структура повідомляє пошуковим системам, що існує; hreflang повідомляє їм, для кого призначена кожна версія. У посібнику Google щодо локалізованих версій сторінок перелічено три рівнозначні способи їхнього оголошення: теги посилань у заголовку HTML, заголовки HTTP або XML-карта сайту. Використання більше ніж одного способу не дає додаткової переваги в пошуку, тому виберіть той, який ваш стек підтримує найнадійніше, і дотримуйтесь його послідовно.

Три правила допоможуть уникнути більшості проблем із hreflang:

1. Зробіть це взаємним. Якщо британська сторінка посилається на німецьку, німецька сторінка повинна посилатися назад. Анотації, які не мають зворотного посилання, можуть ігноруватися, а відсутність лише одного тегу зворотного посилання може непомітно порушити роботу всього кластера.
2. Завжди встановлюйте x-default. Зарезервоване значення x-default охоплює користувачів, мова та регіон яких не відповідають жодній із ваших версій, і це правильне місце для будь-якої сторінки вибору країни.
3. Додавайте анотації до кожної сторінки, включаючи саму себе. Hreflang працює на рівні сторінок, тому кожна сторінка в кластері вказує як свою власну URL-адресу, так і всі її альтернативні варіанти. Створення шаблону для цього — саме той вид роботи, який має бути вбудований у структуру «spoke», а не покладатися на чиюсь пам’ять.

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

• en-GB та en-US можуть вказувати на дві сторінки тією самою мовою, локалізовані для різних ринків;
• простий es може охоплювати іспаномовних користувачів скрізь, де немає версії для конкретної країни.

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

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

Місцеві SERP — це зовсім інший світ

Джерело: Magnific

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

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

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

• декілька пріоритетних ринків отримують індивідуальні розділи, локальні дані та цілеспрямоване побудовування посилань;
• «довгий хвіст» менших ринків працює на загальному шаблоні, доки показники не виправдають необхідність більшого.

Дослідження ключових слів починається заново на кожному ринку

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

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

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

Оцінюйте результати за кожним ринком окремо, інакше ви лише гадаєте

Джерело: Magnific

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

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

• Якщо кожна «спиця» показує низькі результати в одній країні, слід запідозрити проблеми з сигналами таргетингу або атрибутом hreflang.
• Якщо один з «променів» показує низькі результати скрізь, слід перевірити саму сторінку.

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

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

1. Перегляньте динаміку «сторінок, що приносять прибуток», у розрізі кожної країни.
2. Порівняйте найбільші розбіжності з актуальними результатами пошуку на місцевому рівні.
3. Позначте ті напрямки, де місцеві конкуренти мають структурно кращі сторінки.
4. Заплануйте роботи з локалізації там, де, згідно з даними, це буде вигідно.

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

Типові причини невдач, на які варто звернути увагу під час аудиту

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

• Суперечливі сигнали. Домен верхнього рівня (ccTLD), що вказує атрибут hreflang на підкаталоги іншого домену, або сторінки країн, канонізовані на глобальний хаб, що неявним чином повідомляє Google, що ці сторінки є дублікатами, які не варті ранжування.
• Автоматичні перенаправлення на основі IP-адреси. Вони блокують доступ як користувачам, так і роботам-сканерам до тих версій, які їм насправді потрібні. Google радить уникати автоматичних перенаправлень і створювати посилання між версіями, щоб користувачі могли вибрати ту, яка їм потрібна, оскільки визначення місцезнаходження за IP-адресою є ненадійним.
• Неперекладені шаблонні елементи. Меню, нижній колонтитул та процеси оформлення замовлення, залишені іншою мовою на інакше локалізованій сторінці, підривають як довіру користувачів, так і мовні сигнали сторінки.

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

Структура — це стратегія

Міжнародне SEO винагороджує команди, які послідовно виконують нудні завдання:

• єдина продумана структура URL-адрес;
• один добре структурований шаблон «хаб-і-спиці» для кожного продукту;
• взаємні атрибути hreflang із x-default;
• дослідження ключових слів для кожного ринку окремо;
• відстеження позицій у рейтингу за кожною країною, що замикає цикл.

Приклади можна знайти всюди, якщо їх шукати — від сторінок з цінами на SaaS до сайтів, присвячених розіграшам лотерей, — і всі вони вчать одного й того самого. Сторінки не займають високі позиції в рейтингах тому, що їхній контент скрізь геніальний. Вони займають високі позиції тому, що їхня структура ніколи не залишає питання «для кого призначена ця сторінка?» відкритим для інтерпретації.