Техническое SEO
Мультиязычный сайт: подпапки, поддомены, ccTLD и настройка под SEO
Создать мультиязычный или мультирегиональный сайт — не значит просто перевести контент. Архитектурное решение по структуре URL (подпапки, поддомены или отдельные ccTLD-домены) определяет, как Google оценивает геотаргетинг, как передаётся ссылочный вес и во сколько обойдётся поддержка. Разбираем все варианты — от простой мультиязычности до сети региональных ccTLD на одном Next.js-монорепозитории.
Мультиязычный сайт — это не просто набор переведённых страниц. С точки зрения поисковой оптимизации это отдельная архитектурная задача: Google должен понять, какая версия предназначена для какой аудитории, где находится каноническая страница и как распределять ссылочный вес между языковыми версиями. Неправильно выбранная структура превращается в технический долг на годы вперёд.
Три стратегии структуры URL
Google официально поддерживает три подхода к структуре URL для мультиязычных и мультирегиональных сайтов. У каждого — свои сильные стороны, ограничения и требования к инфраструктуре.
Подпапки (subdirectories)
example.com/ru/, example.com/en/, example.com/de/ — всё на одном домене. Весь ссылочный вес концентрируется на одном домене. Простая поддержка: один сайт, один сервер, одна инфраструктура. Минус — Google не воспринимает подпапку как «местный» сайт, потому что домен не привязан к конкретной стране. Лучший вариант для большинства бизнесов с международной аудиторией.
Поддомены (subdomains)
ru.example.com, en.example.com, de.example.com — технически отдельные сайты с общим основным доменом. Google рассматривает поддомен как отдельный сайт, что затрудняет передачу ссылочного веса. Геотаргетинг настраивается через Search Console. Исторически использовался крупными игроками, сегодня считается устаревшим решением для большинства задач мультиязычности.
Отдельные домены / ccTLD
example.ru, example.de, example.fr — отдельные домены, каждый из которых привязан к конкретной стране. Сильнейший сигнал геотаргетинга для Google. Пользователи в России видят .ru и доверяют больше, чем .com. Минус: каждый домен нужно отдельно наращивать ссылочную массу, платить хостинг, поддерживать SSL и контент. Высокие операционные расходы при масштабировании.
Нужна ли геопривязка?
Если бизнес работает по конкретным городам или регионам (услуги в Москве, Киеве, Минске), геотаргетинг — обязательный элемент архитектуры. Для городов и регионов используют подпапки с семантическими слагами: /moskva/, /spb/, /almaty/. Это не то же самое, что мультиязычность — геотаргетинг может быть на одном языке.
По ключевым параметрам: подпапки выигрывают по концентрации ссылочного веса и простоте поддержки. ccTLD — по силе геосигнала. Поддомены не выигрывают ни в одной категории и постепенно уходят в прошлое.
Геотаргетинг: города, регионы и страны
Региональное SEO — самостоятельная дисциплина внутри мультиязычной архитектуры. Когда пользователь ищет «ремонт квартир в Казани», Google хочет показать сайт, который сигнализирует о релевантности именно для этого города. Несколько механизмов работают совместно.
- Геотаргетинг через URL
- Подпапки с кодом региона или города: /moskva/, /spb/, /kzn/. Или ccTLD-домены для стран: .ru для России, .kz для Казахстана, .by для Беларуси. URL-сигнал читается роботом до парсинга контента страницы.
- Геотаргетинг через Search Console
- Для поддоменов и общих TLD (.com, .org) можно указать целевую страну в Google Search Console. Работает как дополнительный сигнал, но слабее ccTLD. Не распространяется на поддиректории — только на домен или поддомен целиком.
- Геотаргетинг через контент и NAP
- Упоминания города, региона, адреса и номера телефона с местным кодом в контенте (NAP — Name, Address, Phone). Важны для локального SEO. Google сопоставляет контентные сигналы с данными Google Maps и профилем Google Business.
Для бизнеса с офисами в нескольких городах оптимальная структура — основной домен с подпапками: site.ru/moscow/, site.ru/spb/. Отдельные страницы для каждого города с уникальным контентом — не просто заменой названия города. Дублированный контент с заменённым городом — один из главных фильтров в локальном SEO.
Выбор платформы: WordPress, MODX, Next.js и headless CMS
Выбор CMS критически влияет на возможности мультиязычности и мультирегиональности. Каждая платформа решает задачу по-своему, с разными trade-off по гибкости, стоимости разработки и масштабируемости.
WordPress + WPML или Polylang
Самое распространённое решение. WPML — мощный коммерческий плагин (~$99/год) с поддержкой любого числа языков, синхронизацией переводов и генератором hreflang. Polylang — бесплатная альтернатива с ограниченными возможностями в базовой версии. Ограничение: WordPress изначально не проектировался под мультиязычность, поэтому любое решение — надстройка, которая усложняет базу данных и замедляет работу со временем.
MODX + Babel
MODX поддерживает мультиязычность через компонент Babel (настройка контекстов). Каждый язык или регион — отдельный контекст со своим деревом ресурсов, настройками и доменом. Гибче, чем WordPress+WPML, но требует опытного MODX-разработчика. Документация скудная, экосистема маленькая. Подходит для проектов, где уже есть MODX-разработчик в команде.
Next.js + next-intl
Нативное решение для современных приложений. next-intl обеспечивает роутинг на основе локали, управление переводами через JSON-файлы и полную поддержку SSR/SSG. Ключевое преимущество: из одного монорепозитория можно обслуживать несколько доменов с разными локалями через Next.js middleware. Нет накладных расходов плагинов, нет конфликтов версий — логика интернационализации встроена в архитектуру.
Headless CMS (Contentful, Sanity, Strapi)
Headless-подход: контент-backend (CMS) отделён от frontend (Next.js, Nuxt, SvelteKit). Один источник контента, несколько фронтендов или доменов на его основе. Contentful и Sanity поддерживают локализацию на уровне полей. Плюс: редакторы работают в удобном интерфейсе, разработчики — в полностью свободном стеке. Минус: добавляет ещё один сервис в инфраструктуру и связанные расходы.
Для простого двуязычного корпоративного сайта WordPress+WPML — разумный выбор. Для сложной региональной сети с десятками доменов — только Next.js. MODX подходит, если команда уже работает с этой платформой и есть соответствующий опыт.
Next.js и мультидомены: один монорепозиторий, несколько ccTLD
Это самая мощная и самая сложная в реализации архитектура. Суть: один код, один репозиторий, один деплой-пайплайн — и несколько независимых ccTLD-доменов для разных стран. Доступно только на Next.js (и Nuxt 3 в похожей парадигме) — WordPress и MODX так не умеют без кардинальной перестройки инфраструктуры.
Как это работает на практике: в next.config.ts описываются домены и соответствующие им локали. Middleware перехватывает запрос, проверяет hostname (seohead.ru → ru, seohead.com → en, seohead.de → de) и проставляет нужный locale. Все компоненты, переводы и SEO-метаданные получают правильную локаль без дублирования кода.
Единое управление контентом
Один набор JSON-файлов или одна headless CMS управляет контентом всех доменов. Обновление статьи, добавление нового продукта или изменение навигации применяется ко всем сайтам через один деплой.
Единый деплой-пайплайн
CI/CD-пайплайн собирает один образ, который обслуживает все домены. Nginx или CDN маршрутизирует трафик с разных доменов на один контейнер. Расходы на инфраструктуру ниже, чем при запуске отдельных сайтов.
Переиспользование компонентов
Header, footer, SEO-метатеги, структурированные данные — написано один раз и работает на всех доменах с правильной локализацией. Обновление компонента применяется везде одновременно без риска рассинхронизации.
Сложность реализации
Архитектура требует опытного Next.js-разработчика. Нужно правильно настроить middleware, hreflang для каждого домена, отдельный sitemap, robots.txt и SEO-метаданные. Ошибки приводят к каннибализации ключевых слов и потере геосигналов.
Для кого это имеет смысл: бизнес в 3+ странах с конкретными ccTLD, команда разработчиков (не один фрилансер), существующий или планируемый Next.js-стек. Для малого бизнеса с одним-двумя языками — избыточная сложность.
Локализация и перевод: как делать правильно
Локализация — это не перевод. Перевод — передача смысла на другом языке. Локализация — адаптация контента под культурный контекст, ожидания аудитории и местные нормы. Для SEO разница критична: машинный перевод создаёт дублированный контент низкого качества, который Google всё лучше умеет определять.
- Машинный перевод (DeepL, Google Translate)
- Быстро и дёшево, но требует обязательной редактуры носителем языка. Голый машинный перевод без пост-редактирования — это не локализация, а риск фильтра за некачественный контент. Используйте как черновик, не как финальный результат.
- Профессиональный перевод с локализацией
- Переводчик-носитель адаптирует не только текст, но и примеры, кейсы, единицы измерения, форматы дат и валют, культурные отсылки. Дорого, но правильно для ключевых страниц: главная, услуги, о компании.
- CAT-инструменты и Translation Memory
- Для больших объёмов контента: Phrase (бывший Memsource), Lokalise, Crowdin. Хранят согласованные переводы терминов, экономят до 40% времени при обновлении контента. Синхронизируются с кодовой базой через CI/CD.
SEO-ключевые слова в целевых языках нужно исследовать отдельно: прямой перевод ключевой фразы часто не совпадает с тем, что реально ищут носители. «Продвижение сайта» → «SEO» на английском — это разные семантические ядра с разными объёмами и конкурентностью.
Настройка под SEO: hreflang, sitemap, canonical
Техническая SEO-настройка мультиязычного сайта состоит из нескольких обязательных элементов. Пропуск любого из них приводит к путанице в индексации и потере трафика.
hreflang
Атрибут hreflang сообщает Google: «Это та же страница, но для другой языковой или региональной аудитории». Реализуется через тег <link rel="alternate" hreflang="ru"> в <head> или через XML sitemap. Обязателен для всех языковых версий, включая x-default (версия по умолчанию). Ошибки в hreflang — одна из самых частых причин неправильного ранжирования языковых версий.
XML sitemap
Для мультиязычного сайта sitemap должен содержать все языковые версии каждой страницы с hreflang-аннотациями. Для мультидоменов — отдельный sitemap для каждого домена. Google не переносит знание о страницах автоматически между доменами, даже если используется один код.
Canonical-теги
Каждая языковая версия — самоканоничная (указывает canonical на себя, а не на главную языковую версию). Не используйте canonical для «объединения» языковых версий — это скажет Google игнорировать переводы. hreflang и canonical — разные инструменты с разными задачами.
Метаданные на правильном языке
Title, description, og:title, og:description — всё должно быть на языке версии страницы. Смешение языков в метаданных снижает CTR и сбивает алгоритм. Для каждой страницы каждой локали — уникальные, оптимизированные метаданные.
Что выбрать: подпапки или мультидомены
Универсальный совет: начинайте с анализа конкурентов в каждом целевом регионе. Если топ-5 ниши в Германии — немецкие ccTLD .de, подпапка example.com/de/ будет работать, но с структурным недостатком. Если конкуренты используют подпапки — нет смысла тратить ресурсы на ccTLD.
- Выбирайте подпапки когда
- Небольшой или средний бизнес без отдельных команд для каждой страны. Бюджет ограничен. Нужна скорость запуска. Конкуренты в целевых регионах также используют подпапки. Хорошо масштабируется: добавить новый язык = добавить папку и переводы.
- Выбирайте ccTLD когда
- Серьёзное присутствие в конкретных странах с высококонкурентным рынком. Конкуренты используют ccTLD. Есть отдельные команды или бюджет на поддержку каждого домена. Важна максимальная локальная доверительность (финансы, e-commerce, юридические услуги).
- Избегайте поддоменов
- Поддомены — худшее из трёх миров: ссылочный вес не передаётся как с подпапок, геосигнал слабее ccTLD, поддержка сложнее подпапок. Используйте только если этого требует техническая архитектура (например, SaaS с кастомными доменами клиентов).
На практике большинство бизнесов начинают с подпапок и мигрируют на ccTLD при росте. Грамотно настроенные 301-редиректы и hreflang обеспечивают безопасную миграцию без потери позиций. Ни один подход не является финальным — архитектуру можно изменить при наличии правильного технического плана.