Коли ccTLD має сенс
Вибір між ccTLD, піддоменом і підкаталогом це рішення про бренд, юридичну присутність і SEO одночасно. ccTLD (.ua, .pl, .de, .mx) сильніший локальний сигнал для користувача і часто для довіри на ринку. Але кожен домен це окремий актив зі своїм link equity, hosting, SSL і підтримкою.
На практиці ccTLD виправданий коли ринок живе окремим P&L, а не лише перекладом головного сайту. Український SaaS з офісом у Варшаві може тримати example.com/pl для MVP, але example.pl має сенс коли є польська підтримка, faktura VAT і PR у локальних медіа.
- Окремий бізнес на ринку коли є локальна юридична особа, прайс у валюті та команда контенту.
- Локальні PR і лінки коли outreach йде в національні медіа і каталоги країни.
- Регуляторика коли домен має відповідати країні реєстрації даних (GDPR, локальні вимоги до хостингу).
- Локальна реклама коли Ads і офлайн-кампанії ведуть на «свій» TLD без плутанини з міжнародним брендом.
Для більшості SMB з 2–3 мовами на одному ринку підкаталог часто дешевший старт. Детальніше про multi-regional підхід у Managing multi-regional sites. Якщо бюджет обмежений почніть з підкаталогу і hreflang, а ccTLD додавайте лише під підтверджений попит у GSC і CRM.
Хак на замітку. Перед покупкою .de/.pl/.mx перевірте чи домен вільний у соцмерках і чи немає старого spam-історії в Wayback. «Порожній» ccTLD з поганою репутацією гірший за підкаталог на сильному root.
Піддомен проти підкаталогу
uk.example.com і example.com/uk часто плутають. Підкаталог зазвичай простіше для єдиного CMS, спільного дизайну і внутрішньої перелінковки. Піддомен дає технічну ізоляцію (окремий robots, CDN, staging) але слабший звʼязок з коренем домену без якісних cross-links з головної і footer.
Типовий сценарій підкаталогу — WordPress + WPML/Polylang, один деплой, /uk/ і /ru/ з однаковим шаблоном. Піддомен часто беруть для окремого продукту (blog.example.com, careers.example.com) або коли локальна команда хоче окремий staging і release cycle.
- Підкаталог швидкий запуск, один Search Console property, спільний crawl budget root-домену.
- Піддомен окремі команди, SaaS-лендінги, A/B без ризику для основного сайту.
- ccTLD максимальна автономія ринку і найвищий операційний overhead.
- Змішана модель example.com + shop.example.de — лише з документованою політикою hreflang і 301 при зміні моделі.
| Ситуація | Що обрати | Чому |
|---|---|---|
| 2 мови, один офіс | Підкаталог /uk /ru | Мінімум техніки, швидкий hreflang |
| Окремий продукт за кордоном | ccTLD або піддомен | Ізоляція бренду і юридики |
| Enterprise з IT-політиками | Піддомен на країну | Окремий CDN, WAF, команда |
| Локальний e-commerce | ccTLD + локальний merchant | Довіра до оплати і доставки |
Hreflang і canonical
Без hreflang Google може змішувати uk/ru/pl версії в одній SERP або показувати не ту мову. Кожна URL-пара має вказувати x-default і взаємні alternate. Canonical не замінює hreflang але допомагає при параметрах і пагінації згідно з canonical guidelines.
На практиці hreflang ламається через дрібниці — різний trailing slash, http/https, www/non-www, utm в alternate. Зафіксуйте один шаблон URL і перевірте XML sitemap з hreflang або теги в head без суперечностей між CMS і CDN.
- Однаковий шаблон URL на всіх мовах (/services/ ↔ /ru/services/).
- x-default на мову «за замовчуванням» для міжнародної аудиторії (часто EN або головна).
- Не блокуйте alternate-версії в robots.txt і не ставте noindex на мовні дублі без причини.
- Після міграції з підкаталогу на ccTLD оновіть hreflang і 301 — інакше втратите парність.
Хак на замітку. У Search Console International targeting покаже чи Google бачить конфлікти hreflang. Звірте з Screaming Frog або Sitebulb export — ручна перевірка 10 URL економить місяці «чому німецька версія не в DE».
Технічні ризики дублювання
Geo-redirect за IP, автоматичний swap мови без згоди користувача і різний HTML для бота/людини створюють ризики cloaking і втрати індексації. Google рекомендує не примусово перенаправляти Googlebot за IP — краще manual switcher і стабільні URL для crawl.
Перевіряйте відповідь сервера з USA (де часто crawl) і з цільової країни через VPN або curl з різних edge. Якщо бот отримує 302 на іншу мову а користувач іншу — це червоний прапорець.
| Модель | Плюси | Мінуси |
|---|---|---|
| ccTLD | Локальна довіра, чіткий ринок | Окремий SEO-бюджет, складніша аналітика |
| Піддомен | Ізоляція продуктів/країн | Слабший звʼязок з root, більше GSC-властивостей |
| Підкаталог | Швидкий старт, спільний авторитет | Менше «локального» сигналу в URL |
| Міграція | Можна зберегти equity через 301 | Ризик втрати hreflang і трафіку 3–6 міс |
- Дубль контенту 1:1 переклад без локальних цін, NAP і кейсів — слабкий сигнал для обох версій.
- CDN geo-routing може віддавати різні cache keys — перевірте Vary і cookie.
- Окремі CMS на ccTLD без sync hreflang — класична причина «німецька сторінка в UA SERP».
Чекліст вибору структури
Чекліст на замітку (20–30 хвилин). Зробіть зараз
- Зафіксуйте список ринків і мов (не «всі країни» одразу).
- Оцініть чи є локальні юридичні особи та хто веде контент.
- Порівняйте вартість доменів, SSL, hosting і підтримки на 12 місяців.
- У Search Console перевірте поточні країни/мови трафіку і top landing.
- Намітьте схему hreflang і canonical до міграції (діаграма URL достатня).
- Підготуйте 301 зі старих URL якщо змінюєте модель — тест на staging.
- Узгодьте аналітику (GA4 property, cross-domain, UTM-словник).
- Зафіксуйте політику geo-redirect (manual switcher vs IP) і передайте dev.
- Заплануйте 90 днів моніторингу після зміни структури.
Орієнтир для SMB — 0–30 днів на аудит і рішення, 30–90 днів на технічну міграцію підкаталогу або hreflang, 6–12 місяців на окремий ccTLD з контентом і лінками якщо ринок підтверджений CRM-даними.
Якщо вже є трафік на /en/ або /de/ не видаляйте URL до запуску 301 і перевірки GSC Coverage. Часта помилка — «переключили DNS і почекали» без моніторингу soft-404 і orphaned hreflang.
Типові помилки
- Купити ccTLD «на майбутнє» без контенту і лінків 12+ місяців — домен старіє в очах користувача і crawl.
- Змішати піддомен і підкаталог без документованої політики — hreflang і analytics ламаються.
- Auto-redirect мови без manual switcher — ризик cloaking і поганий UX для expats.
- Дублювати uk/ru тексти 1:1 без локальних прикладів, NAP і валют.
- Ігнорувати x-default для міжнародної аудиторії.
- Один GSC на всі ccTLD без domain property — втрачаєте visibility по країнах.
- Міграція без 301 з old URL — просадка брендового і небрендового трафіку.
Для enterprise часто будують матрицю «ринок × модель × CMS × analytics» і лише потім запускають пілот на одній країні. Це дешевше ніж паралельно підняти пʼять ccTLD з порожнім контентом.
Перед релізом нової мови прогоніть чекліст hreflang на staging і перевірте 20 URL через URL Inspection у Search Console. Одна помилка x-default часто тягне десятки сторінок у неправильну країну.
Зберігайте документ політики URL — через рік без нього команда повторить старі помилки міграції.
Висновок
ccTLD, піддомен і підкаталог не мають універсального переможця. Для локального бізнесу в одній країні часто достатньо підкаталогу з WPML. Для окремих ринків з власним маркетингом ccTLD виправданий якщо готові інвестувати в кожен домен контент, PR і підтримку.
Головне — узгодити структуру з бізнесом і не змінювати її щокварталу. Кожна міграція коштує link equity і часу команди.
Окремо оцініть вартість підтримки — хто оновлює hreflang при релізі CMS, хто відповідає за SSL на кожному ccTLD, хто моніторить GSC після міграції. Без власника процесу структура «розʼїжджається» за 6–12 місяців.
Допоможемо обрати структуру в рамках GEO SEO і SEO-послуг команда SEO-Studio.