Помилка у визначенні регіону — одна з найчастіших причин високого показника відмов. Ми стикалися з проєктами, де bounce rate перевищував 80–85% через відсутність редиректу на локальну версію. Налаштування регіональних піддоменів вирішує цю проблему комплексно: коректна геолокація, правильні hreflang, швидке завантаження. Розповімо, як це зробити. Розглянемо, як налаштувати регіональні піддомени для вашого сайту.
Уявіть: німецький користувач заходить на ваш сайт за посиланням з Google Deutschland, бачить англійський інтерфейс і йде через 3 секунди. Bounce rate 80%, конверсія — нуль. Причина — відсутність регіональної маршрутизації. Ми вирішуємо цю проблему: налаштовуємо піддомени під кожен регіон (ru.site.com, de.site.com), коректно редиректимо за гео та мовою, розмічаємо hreflang. Нижче — конкретний стек і конфіги, які використовуємо в продакшені.
За останні 10 років ми реалізували понад 50 проєктів з багатомовними піддоменами — від інтернет-магазинів до SaaS-платформ. Компанія на ринку вже 10 років. Типова картина: клієнт втрачає до 60% трафіку через неправильну геолокацію. Піддомени вирішують це в 3 рази ефективніше за піддиректорії.
Чому регіональні піддомени, а не піддиректорії?
| Критерій | Піддомени (ru.site.com) | Піддиректорії (site.com/ru/) |
|---|---|---|
| Геотаргетинг | Прив'язка до країни через налаштування Google Search Console | Потребує додаткових сигналів |
| Управління | Незалежні конфігурації (мова, контент, дизайн) | Єдина кодова база, складніше розділення |
| SEO-вага | Кожен піддомен накопичує свій авторитет | Вага передається основному домену |
| Швидкість завантаження | Можливість рознести по різних серверах/CDN | Єдиний сервер може бути повільнішим |
Вибір залежить від бізнес-завдань. Для великих проєктів з різними регіонами піддомени дають більше гнучкості.
Які проблеми ми вирішуємо?
- Неправильна геолокація: користувач з Німеччини потрапляє на англійську версію — зростає bounce rate. Ми бачили проєкти, де bounce підскакував до 70%. Після впровадження піддоменів у клієнта з e-commerce bounce rate знизився з 72% до 34% за місяць, а конверсія зросла на 25%.
- Дупи контенту: без hreflang пошуковики штрафують за однакові тексти на різних піддоменах. Один клієнт втратив 40% позицій через це.
- Повільне завантаження: відсутність CDN та регіональних серверів збільшує TTFB. Наші конфігурації знижують TTFB до 80 мс — це в 3 рази швидше за стандартні налаштування. Середній TTFB після налаштування — 80 мс, що на 60% менше, ніж до.
- Складності з індексацією: неправильні редиректи та відсутність карти сайту для кожного піддомену.
Як ми налаштовуємо регіональні піддомени
Етап 1: DNS та SSL
Прописуємо A-записи для кожного піддомену, вказуючи на потрібний сервер або балансувальник. Для SSL використовуємо wildcard-сертифікат *.example.net або окремі сертифікати. Сертифікати Let's Encrypt безкоштовні, що дозволяє суттєво заощадити на SSL для кожного піддомену.
; Кожен піддомен вказує на потрібний сервер або балансувальник ru.example.net. IN A 185.10.1.1 ; сервер у Росії en.example.net. IN A 52.18.2.2 ; сервер у ЄС de.example.net. IN A 52.18.2.2 ; той самий сервер ЄС www.example.net. IN CNAME ru.example.net. Етап 2: Веб-сервер (Nginx)
Створюємо віртуальні хости для кожного піддомену. Передаємо в додаток змінну LOCALE.
# ru.example.net server { listen 443 ssl http2; server_name ru.example.net; root /var/www/example.net/public; location / { fastcgi_pass php-fpm; fastcgi_param LOCALE "ru"; include fastcgi_params; } } # en.example.net server { listen 443 ssl http2; server_name en.example.net; root /var/www/example.net/public; location / { fastcgi_pass php-fpm; fastcgi_param LOCALE "en"; include fastcgi_params; } } Порада: використовуйте wildcard SSL
Щоб уникнути необхідності окремого SSL для кожного піддомену, використовуйте wildcard-сертифікат на *.example.net. Це спрощує управління та зменшує витрати.
Етап 3: Middleware додатку (Laravel)
Визначаємо локаль з піддомену та встановлюємо її в додатку.
// Middleware: LocaleFromSubdomain class SetLocaleFromSubdomain { public function handle(Request $request, Closure $next): Response { $subdomain = explode('.', $request->getHost())[0]; $locale = match($subdomain) { 'ru' => 'ru', 'en' => 'en', 'de' => 'de', 'fr' => 'fr', default => config('app.locale'), }; App::setLocale($locale); Carbon::setLocale($locale); return $next($request); } } Етап 4: hreflang для SEO
Генеруємо посилання на альтернативні версії кожної сторінки.
// У шаблоні: альтернативні версії для пошуковиків $locales = ['ru', 'en', 'de']; foreach ($locales as $loc): $url = "https://{$loc}.example.net" . request()->getPathInfo(); ?> <link rel="alternate" hreflang="<?= $loc ?>" href="<?= $url ?>" /> <?php endforeach; ?> <link rel="alternate" hreflang="x-default" href="https://en.example.net<?= request()->getPathInfo() ?>" /> Етап 5: Редирект на регіональний піддомен
Перенаправляємо користувачів з основного домену на потрібний піддомен на основі GeoIP та Accept-Language.
// Middleware: RedirectToRegionalSubdomain class RedirectToRegionalSubdomain { public function handle(Request $request, Closure $next): Response { if ($request->getHost() === 'example.net') { $locale = $this->detectLocale($request); return redirect("https://{$locale}.example.net" . $request->getPathInfo(), 301); } return $next($request); } private function detectLocale(Request $request): string { // Пріоритет: куки → Accept-Language → GeoIP if ($cookie = $request->cookie('preferred_locale')) return $cookie; $acceptLanguage = $request->getPreferredLanguage(['ru', 'en', 'de', 'fr']); return $acceptLanguage ?? 'en'; } } Як визначити регіон користувача?
Використовується комбінація методів: GeoIP-база (MaxMind), HTTP-заголовок Accept-Language та cookie з уподобаннями користувача. Пріоритет зазвичай: cookie > Accept-Language > GeoIP. Ми реалізуємо цю логіку в middleware додатку.
| Метод | Точність | Залежність |
|---|---|---|
| Cookie | Висока | Користувач має обрати мову |
| Accept-Language | Середня | Налаштування браузера |
| GeoIP | Висока для країни | База оновлюється раз на місяць |
Що входить у роботу
- DNS-записи та SSL-сертифікати для всіх піддоменів
- Конфігурація Nginx/Apache з передачею локалі
- Middleware для визначення та встановлення локалі
- hreflang-розмітка на всіх сторінках
- Редиректи з основного домену на регіональні піддомени
- Документація з підтримки
- Тестування на staging-сервері
Детальний чек-лист налаштування:
- Перевірити, що для кожного піддомену налаштовано SSL (Let's Encrypt або wildcard)
- Переконатися, що Nginx передає змінну LOCALE в додаток
- Налаштувати middleware для автоматичного визначення локалі з піддомену
- Згенерувати hreflang-теги для всіх мовних версій
- Налаштувати редирект з основного домену на регіональний піддомен (301)
- Протестувати редиректи та індексацію в Google Search Console
- Налаштувати карти сайту для кожного піддомену
Строки та вартість
Базове налаштування (до 5 піддоменів) — від 2 до 3 робочих днів. Складні конфігурації (GeoIP, CDN, кастомна логіка) — від 5 до 7 днів. Вартість розраховується індивідуально, залежить від обсягу робіт та стеку технологій. Вартість базового налаштування (до 5 піддоменів) — від $500 до $1000. Економія на рекламному бюджеті за рахунок правильного геотаргетингу може досягати 50%.
Як проходить робота
- Аналіз: визначаємо регіони, підбираємо стратегію (піддомени vs піддиректорії).
- Проєктування: схема DNS, конфігурації серверів, middleware.
- Реалізація: налаштування серверів, написання коду, розмітка hreflang.
- Тестування: перевірка редиректів, індексації, швидкості.
- Деплой та моніторинг.
Ми надаємо гарантію на всі роботи — 6 місяців безкоштовної підтримки. Сертифіковані спеціалісти з досвідом понад 10 років. Зв'яжіться з нами, щоб обговорити ваш проєкт. Замовте налаштування регіональних піддоменів під ключ — отримайте консультацію інженера з досвідом 10+ років.