У кошику порожньо!
Міжнародне SEO — це не лише hreflang. Правильна структура URL, геотаргетинг у GSC, локалізований контент і CDN разом визначають, чи знайде вас аудиторія у кожній цільовій країні.
Зміст
- Що охоплює міжнародне SEO
- Вибір структури URL: ccTLD, субдомен, підпапка
- Hreflang: правильне впровадження
- Геотаргетинг у Google Search Console
- Локалізація vs переклад контенту
- IP-геолокація і редиректи
- CDN для міжнародних сайтів
- Типові помилки міжнародного SEO
- Технічний чеклист
- Часті запитання
Що охоплює міжнародне SEO
Більшість команд починають міжнародну експансію з hreflang і зупиняються. Насправді hreflang — лише один вузол у значно більшій системі. Міжнародне SEO охоплює архітектуру URL, технічну сигналізацію для Google щодо цільових країн і мов, локалізацію контенту, швидкодію для географічно розподілених користувачів та управління дублікатами між мовними версіями.
У нашій практиці найчастіша причина провалу міжнародного виходу — це коли компанія запускає, скажімо, польськомовну версію сайту, але забуває налаштувати геотаргетинг у GSC і підключити CDN-вузол у Польщі. Google бачить сторінки, але не розуміє, для якої аудиторії вони призначені, а польські користувачі отримують повільний сайт.
Ключові компоненти системи міжнародного SEO:
- Структура URL — ccTLD, субдомен або підпапка
- Hreflang — сигнал мови й регіону для пошукової системи
- Геотаргетинг у GSC — пряма вказівка цільової країни
- Контент-локалізація — адаптація для реальних пошукових запитів ринку
- IP-геолокація — коректний редирект користувачів
- CDN — швидкодія у всіх цільових регіонах
Міжнародне SEO — це не переклад сайту, а переосмислення пошукового досвіду для кожного ринку окремо.
Вибір структури URL: ccTLD, субдомен, підпапка
Це перше і найважливіше архітектурне рішення. Від нього залежить, як Google розподіляє авторитет між версіями, скільки ресурсів потребує підтримка і наскільки сильний геосигнал отримує кожна версія.
Порівняння трьох підходів
| Параметр | ccTLD (example.ua) | Субдомен (ua.example.com) | Підпапка (example.com/ua/) |
|---|---|---|---|
| Геосигнал | Найсильніший | Середній | Слабший (GSC компенсує) |
| Авторитет домену | Окремий для кожного TLD | Частково від основного | Повністю від основного |
| Складність впровадження | Висока | Середня | Низька |
| Вартість підтримки | Висока (N доменів) | Середня | Низька |
| Лінкбілдинг | Окремий для кожного TLD | Частково спільний | Спільний |
Коли обирати ccTLD
ccTLD — правильний вибір, якщо ви виходите на ринок з сильними локальними конкурентами і маєте ресурс на окремий лінкбілдинг та технічну команду для кожного домену. Наприклад, для виходу великого інтернет-магазин на ринки Німеччини (.de), Франції (.fr) і Польщі (.pl) одночасно — це обґрунтований вибір. Але для стартапу з командою 5 осіб така архітектура стане тягарем.
Коли підпапки кращі за все
Підпапки (example.com/de/, example.com/fr/) акумулюють авторитет основного домену і є найпростішими у розгортанні. Геосигнал слабший, але він компенсується правильним налаштуванням GSC і hreflang. Для більшості SaaS-продуктів, агентств і медіа — це оптимальний вибір. Ми у SEO-Factory зазвичай починаємо клієнтів саме з цієї структури і переходимо до ccTLD лише коли є реальна потреба.
Практичне правило: Якщо ваш бюджет на лінкбілдинг обмежений — обирайте підпапки. Один сильний домен краще за п'ять слабких.
Субдомени: коли виправдані
Субдомени (de.example.com) — компромісний варіант, який використовують переважно великі платформи, де різні мовні версії обслуговуються різними CMS або командами. Технічно Google розглядає субдомени як частково окремі сайти, тому авторитет передається не повністю. Якщо немає технічного обмеження, що змушує вас використовувати субдомен — краще обрати підпапку.
Hreflang: правильне впровадження
Hreflang повідомляє Google, яка версія сторінки призначена для якої мови і регіону. Але понад 50% впроваджень hreflang містять помилки — і більшість із них зводять нанівець всю роботу.
Де розміщувати hreflang
Є три місця для розміщення hreflang-анотацій. Важливо використовувати лише одне — не комбінуйте методи:
- У <head> кожної сторінки — найпоширеніший спосіб, підходить для більшості CMS
- У XML-sitemap — зручно для великих сайтів (100k+ сторінок), де додавати теги в <head> складно
- У HTTP-заголовках — лише для не-HTML-файлів (PDF тощо)
Синтаксис hreflang
Кожна сторінка повинна містити посилання на всі мовні версії, включно із собою. Для загальної мовної версії без прив'язки до країни використовується x-default:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/" /> <link rel="alternate" hreflang="ru" href="https://example.com/ru/page/" /> <link rel="alternate" hreflang="en" href="https://example.com/en/page/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />
Критичні вимоги до hreflang
Нижче — найчастіші причини, через які hreflang не працює. Перевіряйте їх в першу чергу:
- Зворотне підтвердження (return link) — версія A посилається на B, B повинна посилатися на A
- Абсолютні URL — відносні посилання не обробляються коректно
- Коди мов за ISO 639-1 — uk, ru, de, fr (не укр, рос тощо)
- Коди країн за ISO 3166-1 Alpha-2 — uk (Великобританія), ua (Україна), де потрібна регіональна прив'язка
- Canonical узгоджений із hreflang — canonical кожної версії має вказувати на саму себе, не на іншу версію
Часта пастка: hreflang="uk" означає мову — українська. Для Великобританії — hreflang="en-GB". Не плутайте мовні коди з кодами країн.
Для автоматизованої перевірки hreflang використовуйте наш детальний гайд по hreflang або Screaming Frog із вкладкою Hreflang.
Геотаргетинг у Google Search Console
GSC дозволяє явно повідомити Google, на яку країну орієнтована та чи інша версія сайту. Це особливо важливо для підпапок і субдоменів, де Google не може автоматично визначити географію зі структури домену.
Як налаштувати геотаргетинг
Процес складається з кількох кроків. Важливо: геотаргетинг налаштовується окремо для кожної мовної версії.
- Додайте кожну версію сайту як окремий ресурс у GSC (для підпапок — тип "URL prefix", наприклад
https://example.com/uk/) - Підтвердіть права власності на ресурс
- Перейдіть до: Legacy tools and reports → International Targeting → Country
- Оберіть цільову країну зі списку
- Збережіть налаштування
Важливо: Для ccTLD (.ua, .de, .fr тощо) геотаргетинг у GSC не потрібен — Google визначає країну автоматично за TLD. Налаштовуйте його лише для підпапок і субдоменів.
Моніторинг у GSC після налаштування
Після запуску міжнародних версій щомісяця аналізуйте такі звіти в GSC для кожного ринку:
- Performance → Countries — перевіряйте, чи зростають покази й кліки у цільових країнах
- Coverage — відстежуйте помилки індексації специфічні для кожної мовної версії
- International Targeting — моніторьте помилки hreflang, якщо Google їх виявить
Детальніше про роботу з GSC читайте у нашому повному гайді по Google Search Console.
Локалізація vs переклад контенту
Це один із найважливіших, але найбільш недооцінених аспектів міжнародного SEO. Механічний переклад — навіть якісний — не дає SEO-результату, якщо люди у цільовій країні шукають за зовсім іншими термінами.
Чим переклад відрізняється від локалізації
| Переклад | Локалізація |
|---|---|
| Конвертація тексту між мовами | Адаптація всього досвіду для ринку |
| Зберігає структуру оригіналу | Змінює структуру під місцевий контекст |
| Використовує ті самі ключові слова (калькований переклад) | Дослідження нативних пошукових запитів ринку |
| Та сама валюта, одиниці, приклади | Місцева валюта, метрики, культурні референції |
| Швидко і дешево | Потребує нативного спеціаліста з ринку |
Практичний приклад
Припустимо, ви просуваєте послуги з оптимізації сайту в Польщі. Буквальний переклад «просування сайту» — «promocja strony». Але польські користувачі частіше шукають «pozycjonowanie stron» або «SEO Warszawa». Якщо ваш контент побудований навколо калькованого перекладу, він не ранжуватиметься за реальними запитами.
Чеклист локалізації контенту
- Дослідження ключових слів нативною мовою через Ahrefs або Google Keyword Planner для цільової країни
- Адаптація CTA — «Замовити» може перекладатися по-різному і мати різне сприйняття
- Локальні приклади — кейси з відомих місцевих компаній, а не іноземних
- Валюта і ціни в місцевій валюті (де актуально)
- Дати і формати — DD/MM/YYYY vs MM/DD/YYYY
- Юридичні вимоги — cookie consent, GDPR, місцеві закони
- Нативна редактура — носій мови перевіряє природність тексту
E-E-A-T для міжнародних версій: Додайте локальні сигнали довіри — місцевий номер телефону, фізична адреса в країні, відгуки від клієнтів із цього ринку. Це впливає і на ранжування, і на конверсію.
IP-геолокація і редиректи
IP-геолокація дозволяє автоматично перенаправляти користувачів на відповідну мовну версію сайту на основі їхнього місцезнаходження. Але реалізувати це коректно з точки зору SEO — складніше, ніж здається.
Проблема автоматичних редиректів
Якщо ви автоматично перенаправляєте всіх відвідувачів з IP-адрес певної країни на локальну версію — ви заблокуєте Googlebot від індексації деяких версій сайту. Googlebot зазвичай краулить із США і може ніколи не побачити вашу, наприклад, польську версію, якщо редирект відбувається на рівні IP.
Правильний підхід
- Не застосовуйте 301/302-редиректи на основі IP для Googlebot
- Використовуйте JavaScript-редирект або банер із пропозицією перейти на локальну версію замість примусового редиректу
- Якщо редирект необхідний — дозволяйте доступ до всіх версій за прямим URL без редиректу
- Зберігайте вибір мови користувача у cookie, щоб не редиректити його знову при наступному візиті
Google прямо вказує: автоматичні редиректи на основі IP ускладнюють краулінг і можуть перешкодити індексації. Краще пропонувати вибір, а не нав'язувати версію.
Геолокація і hreflang разом
IP-геолокація і hreflang — різні механізми, які працюють паралельно. Hreflang повідомляє Google, яку версію показувати у пошуковій видачі. Геолокація впливає на те, яку версію бачить користувач після кліку. Вони повинні бути узгоджені: якщо hreflang вказує польського користувача на /pl/, то й геолокаційний редирект має вести туди ж.
CDN для міжнародних сайтів
Core Web Vitals (LCP, INP, CLS) вимірюються окремо для кожної країни. Сайт, що завантажується за 1.2 секунди в Україні, може вантажитись за 4–5 секунд у Бразилії, якщо сервер знаходиться в Європі. Для Google це означає погані CWV — і нижче ранжування — саме у Бразилії.
Як CDN вирішує цю проблему
Content Delivery Network кешує статичні ресурси на вузлах у різних географічних точках. Користувач у Токіо отримує файли з найближчого вузла в Азії, а не із сервера у Франкфурті. Результат — різке зниження TTFB і кращі показники LCP у всіх регіонах.
На що звертати увагу при виборі CDN
- Покриття вузлів у цільових країнах — перевіряйте наявність PoP у кожному регіоні, де ви конкуруєте
- Edge computing — можливість виконувати логіку редиректів і hreflang на рівні CDN
- HTTP/3 і QUIC — суттєво покращують швидкодію на мобільних мережах
- Інтеграція з вашим стеком — чи є плагіни для вашої CMS
Популярні рішення для міжнародних сайтів
- Cloudflare — найпопулярніший вибір, безкоштовний план для базових потреб, 300+ вузлів
- AWS CloudFront — підходить для складних архітектур на AWS
- Fastly — потужний для програмованої логіки на краю
- BunnyCDN — доступний варіант із хорошим покриттям
Читайте також про технічні аспекти швидкодії у нашому гайді Core Web Vitals: LCP, INP та CLS.
Типові помилки міжнародного SEO
За кілька років роботи з мультирегіональними проєктами ми бачили одні й ті самі помилки знову і знову. Ось найдорожчі з них:
1. Дублювання контенту між мовними версіями
Якщо uk.html і ru.html мають майже однаковий текст — це не тільки неефективно, але й шкодить SEO. Google може не знати, яку версію ранжувати, або вважатиме їх дублікатами. Рішення — локалізований контент, де різниця є не лише у мові, а й у прикладах, ключових словах, структурі.
2. Неповні або однобічні hreflang
Якщо сторінка A посилається на B через hreflang, але B не посилається на A — Google ігнорує всю анотацію. Перевіряйте hreflang-ланцюжки після кожного оновлення сайту.
3. Canonical вказує на іншу мовну версію
Одна з найнебезпечніших помилок. Якщо польська версія сторінки має canonical на англійську — Google не буде індексувати польську версію. Кожна мовна версія повинна мати rel="canonical" на саму себе. Докладно про canonical читайте у нашому гайді по canonical-тегах.
4. Один sitemap для всіх версій без hreflang-анотацій
Якщо ви додаєте всі мовні версії до одного sitemap без розмітки hreflang — ви втрачаєте можливість повідомити Google про зв'язки між версіями. Використовуйте окремі sitemap або правильно розмічайте hreflang у спільному.
5. Ігнорування локальних пошукових систем
На деяких ринках Google — не єдина гравець. У Росії — Яндекс. У Чехії — Seznam. У Китаї — Baidu. Якщо ви виходите на такі ринки — врахуйте вимоги до SEO специфічних для кожної платформи.
6. IP-геолокація, що блокує Googlebot
Описано вище: примусові редиректи на основі IP можуть приховати частину сайту від краулерів. Це одна з найскладніших помилок для діагностики.
7. Відсутність локального лінкбілдингу
Навіть ідеально технічно оптимізований сайт не ранжуватиметься в новому регіоні без посилань від місцевих авторитетних джерел. Google оцінює авторитет локально: посилання від польських новинних сайтів важать більше для ранжування в Польщі, ніж посилання від американських. Читайте про стратегії лінкбілдингу для міжнародних проєктів.
Технічний чеклист для мультирегіонального сайту
Перед запуском нової мовної версії або аудитом існуючої — пройдіться по цьому списку. Він базується на офіційних рекомендаціях Google та практиці нашої команди.
Архітектура та структура
- Обрано структуру URL (ccTLD / субдомен / підпапка) і вона відповідає ресурсам команди
- Кожна версія доступна за стабільним URL без залежності від cookies або JavaScript
- Robots.txt не блокує жодну мовну версію
- Sitemap включає всі мовні версії з hreflang-анотаціями (або окремі sitemap)
Hreflang
- Hreflang присутній на всіх сторінках усіх мовних версій
- Зворотні посилання підтверджені — кожна версія посилається на всі інші
- x-default вказаний для URL без мовної прив'язки
- Використовуються коректні коди ISO 639-1 / ISO 3166-1
- Всі URL абсолютні, з протоколом і доменом
- Перевірено Screaming Frog або аналогом після деплою
GSC і геотаргетинг
- Кожна версія додана як окремий ресурс у GSC
- Геотаргетинг налаштований для підпапок і субдоменів
- Performance моніториться окремо для кожного ринку
Контент і локалізація
- Ключові слова досліджено нативною мовою, не калькований переклад
- Мета-теги унікальні для кожної версії
- CTA адаптовані для культурних норм ринку
- Нативний редактор перевірив текст
- Canonical на кожній версії вказує на саму себе
Технічна швидкодія
- CDN підключений із вузлами у цільових країнах
- TTFB перевірено з кожної цільової країни (PageSpeed Insights з різними локаціями)
- Core Web Vitals відповідають порогам у кожному регіоні
IP-геолокація
- Googlebot не блокується редиректами на основі IP
- Вибір мови зберігається у cookie
- Всі версії доступні за прямим URL без редиректу
Часті запитання
Що краще для міжнародного SEO — ccTLD, субдомен чи підпапка?
Підпапки найлегше впровадити і вони накопичують авторитет основного домену. ccTLD дають найсильніший геосигнал, але потребують окремого лінкбілдингу та ресурсів. Субдомени — проміжний варіант. Для більшості проєктів з обмеженим бюджетом підпапки є оптимальним вибором.
Чи обов'язковий hreflang для міжнародного сайту?
Hreflang критичний, якщо у вас є схожий контент для різних мов або регіонів. Без нього Google може показати не ту версію або позначити сторінки як дублікати. Але він — лише один із сигналів: геотаргетинг у GSC, локалізований контент і структура URL також важливі.
Як налаштувати геотаргетинг у Google Search Console?
Додайте кожну версію сайту як окремий ресурс у GSC. Для підпапок використовуйте тип URL-prefix. Потім у Legacy tools → International Targeting → Country вкажіть цільову країну. Для ccTLD це не потрібно — Google визначає країну автоматично.
У чому різниця між локалізацією і перекладом контенту?
Переклад — конвертація тексту між мовами. Локалізація — адаптація всього досвіду: ключові слова, валюта, приклади, CTA, культурні референції. Для SEO важливо саме локалізований контент, бо він відповідає реальним пошуковим запитам аудиторії.
Питання про Міжнародне SEO
Що таке міжнародне SEO і навіщо воно потрібне?
Міжнародне SEO — це комплекс технічних і контентних налаштувань, які допомагають пошуковикам зрозуміти, для якої країни й мови призначений кожен розділ сайту, щоб правильно показувати його потрібній аудиторії. Детальний технічний гайд із прикладами є на seo-factory.com.ua.
Як налаштувати hreflang для мультирегіонального сайту?
Теги hreflang прописуються в
або sitemap і вказують пошуковику точну мовно-регіональну версію сторінки — наприклад uk-UA, ru-UA або x-default для дефолтного варіанту. Покрокову інструкцію з частими помилками розібрано на seo-factory.com.ua.Коли варто переходити на субдомени замість підпапок у міжнародному SEO?
Субдомени виправдані тоді, коли регіональні версії сайту технічно незалежні або розміщені на різних серверах для швидкості — але в більшості випадків підпапки краще передають авторитет кореневого домену. Порівняння стратегій із рекомендаціями під різні ситуації є на seo-factory.com.ua.
Виходите на нові ринки? Зробимо міжнародне SEO правильно
Аудит hreflang, налаштування геотаргетинг, локалізація та технічний чеклист — від команди SEO-Factory.
Замовити просування
