# General Translation Knowledge Base: Подкаталог, поддомен или ccTLD для многоязычного SEO URL: https://generaltranslation.com/ru/kb/multilingual-url-structure.mdx Docs index: https://generaltranslation.com/llms.txt Description: Используйте подкаталоги вида example.com/de/, если один продукт работает на общем сайте с единым процессом релизов. На страну указывает только ccTLD, поддомены позволяют размещать версии на отдельном хостинге, параметры ?lang= Google не рекомендует, а «имиджевые» домены вроде .io и .ai считает общими. Category: Многоязычное SEO Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Любая из этих структур даёт каждому языку собственный URL, а [руководство Google по многорегиональным и многоязычным сайтам](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) сравнивает их по таргетингу и сложности поддержки, не отдавая предпочтения ни одной. Поэтому выбор сводится к двум вопросам: на что вы ориентируетесь — на языки или на страны, и сколько сайтов готовы поддерживать? ## Сравнение четырёх структур URL Плюсы и минусы ниже — пересказ таблицы самого Google. Последний вариант, параметр URL, Google помечает как нерекомендуемый. | Структура | Пример | Плюсы по версии Google | Минусы по версии Google | | -------------------------------------------- | --------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Домен верхнего уровня с кодом страны (ccTLD) | `example.de` | Чёткий геотаргетинг; расположение сервера не имеет значения; сайты легко разделить | Дорого, и нужный домен не всегда доступен; больше инфраструктуры; в некоторых странах строгие требования к ccTLD; таргетинг только на одну страну | | Поддомен | `de.example.com` | Легко настроить; серверы можно размещать в разных местах; сайты легко разделить | По URL пользователи не могут понять, что означает `de` — язык или страну | | Подкаталог | `example.com/de/` | Легко настроить; простое обслуживание (один хост) | Пользователи могут не понять таргетинг по URL; сервер только в одном месте; сайты сложнее разделить | | Параметр URL | `example.com?lang=de` | Не указаны (не рекомендуется) | Сложно сегментировать по URL; пользователи могут не понять таргетинг | Две детали из рекомендаций Google сглаживают разницу: * **Из всех форм URL только ccTLD указывает на страну.** В [рекомендациях Google по локализованным версиям](https://developers.google.com/search/docs/specialty/international/localized-versions) сказано, что языковые поддомены вроде `en` или `de` не используются для определения аудитории страницы: это соответствие нужно задавать явно с помощью [hreflang](/kb/what-is-hreflang). Про папки Google отдельно ничего не говорит, но нет оснований считать, что путь `/de/` обрабатывается иначе, поэтому для них тоже используйте hreflang. * **Некоторые ccTLD считаются общими.** Google рассматривает `.io`, `.ai`, `.co`, `.me`, `.tv` и другие «имиджевые» ccTLD, а также региональные домены вроде `.eu` как общие домены верхнего уровня. Стартап на `example.io` вовсе не нацелен на Британскую территорию в Индийском океане. Google также отмечает, что расположение сервера — «не решающий сигнал», ведь сайты используют CDN. Это смягчает минус подкаталогов, связанный с размещением сервера в одном месте. Есть и пятый вариант: оставить один URL и менять язык в зависимости от cookie-файла или заголовка браузера. Google не советует так делать, поскольку его поисковый робот может найти не все версии. Подробнее о компромиссах — в статье [о том, как сайту выбирать язык отображения](/kb/locale-routing-seo). ## Во что обходится поддержка каждой структуры Таблица Google ограничивается формулировкой «больше инфраструктуры». На практике структуры различаются тем, сколько отдельных компонентов вам приходится поддерживать: * **Национальные домены:** для каждой страны нужно купить и регулярно продлевать отдельный домен, а в некоторых странах действуют местные правила регистрации. Каждый хост должен быть покрыт TLS; один сертификат может охватывать несколько имён. Заранее продумайте, кто владеет этими доменами, как настроены перенаправления и как ведётся мониторинг. * **Поддомены:** домен один, но для каждого поддомена нужны своя DNS-запись и покрытие сертификатом. В [рекомендациях Google по канонизации](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) указано, что сертификат должен соответствовать полному имени хоста или быть wildcard-сертификатом, иначе Google может отдать предпочтение HTTP-версии. * **Подкаталоги:** у разных языков могут быть общие хост, конфигурация TLS, приложение и конвейер развёртывания. Это распространённая практика, а не обязательное требование: обратный прокси может направлять пути в отдельные приложения, а аналитику можно организовать независимо от структуры URL. Не стоит полагать, что подкаталоги получают преимущество в ранжировании или что каждый новый поддомен начинает с нуля, без полезных сигналов. Сравнение Google не подтверждает ни то, ни другое. Оцените, какой объём работ по хостингу, владению доменами и релизам действительно требует ваше развёртывание. ## Ориентироваться на языки или на страны? Google различает **многоязычный** сайт (одно и то же предложение на нескольких языках, как у канадской компании, работающей на английском и французском) и **многорегиональный** (разные предложения для разных стран, как у производителя, который поставляет товары в Канаду и США). Структура URL должна соответствовать вашему случаю: * **Ориентируйтесь на язык**, если контент одинаков для всех носителей. Один раздел `/es/` с аннотацией `es` подходит для испаноговорящих пользователей в Мексике, Испании и Аргентине. * **Ориентируйтесь на страну**, если что-то различается в зависимости от страны: цены и валюта, доставка, правовые условия или каталог товаров. Используйте `/es-mx/` и `/es-es/` или `example.mx` и укажите для них аннотации `es-MX` и `es-ES`. У ориентации на страны есть обратная сторона. По словам Google, геотаргетинг может улучшить позиции в целевой стране «в ущерб результатам в других локалях или на других языках», а ccTLD позволяет ориентироваться только на одну страну. Если вы всё же разделяете контент по странам, Google [рекомендует](https://developers.google.com/search/docs/specialty/international/localized-versions) дополнительно предоставить страницу с указанием только языка (`es`) для носителей во всех остальных странах. О том, как выбрать между кодами вроде `es` и `es-MX`, читайте в разделе [Какие коды локалей использовать](/docs/platform/core/guides/locale-codes). ## Локализованные слаги Префикс локали показывает версию прямо в URL, но перевести можно и остальную часть пути: например, `/de/ueber-uns` вместо `/de/about-us`. По словам Google, локализованные слова в URL допустимы, как и интернационализированные доменные имена, — при условии, что URL используют кодировку UTF-8 и корректно экранируются в ссылках. Слаг с не-ASCII-символами, например `/de/über-uns`, передаётся как `/de/%C3%BCber-uns`, поэтому в hreflang и картах сайта следует указывать именно эту закодированную форму. Переведённые слаги естественно смотрятся в результатах поиска, но требуют отдельной таблицы слагов для каждой локали, а если перевод слага меняется, со старого URL нужно настроить перенаправление. Команды, которые обходятся без локализованных слагов, оставляют `/de/about-us` и всё равно получают отдельный индексируемый URL для каждого языка. ## Какую структуру выбрать? Начните с **подкаталогов**, если один продукт обслуживает несколько языков на общем сайте с единым процессом релизов. Как правило, они позволяют повторно использовать конфигурацию маршрутизации и хостинга. При этом раздельные развёртывания всё равно возможны, а CDN может отдавать один и тот же хост из нескольких локаций. Выбирайте **национальные домены**, если каждая страна фактически представляет собой отдельный бизнес — с собственными юридическими лицами, каталогами или маркетинговыми командами, — и вам нужен максимально сильный сигнал о стране, а затраты на поддержку вас не смущают. Используйте **поддомены**, если для локали требуется другой хостинг или инфраструктура — например, когда рынок необходимо обслуживать с серверов, расположенных в этой стране. Не используйте **URL-параметры** в качестве основной языковой структуры: Google их не рекомендует. Сами по себе они не препятствуют индексации; то, как будут работать отчёты и кеширование, зависит от того, как ваши системы обрабатывают эти параметры. Что бы вы ни выбрали, используйте стабильные URL и размечайте эквивалентные опубликованные версии с помощью hreflang. (См. [Что такое hreflang](/kb/what-is-hreflang)). ## Как General Translation поддерживает каждую структуру `gt-next` от General Translation поддерживает подкаталоги. В App Router [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) размещает каждую локаль под префиксом пути, например `/es/about`; получает ли такой префикс локаль по умолчанию, описано в статье [маршрутизация по локалям и SEO](/kb/locale-routing-seo). Опция `pathConfig` того же промежуточного ПО сопоставляет общий путь с локализованным слагом для каждой локали, например `/de/ueber-uns` для `/about`, а `customMapping` в `gt.config.json` позволяет использовать в маршруте алиас, например `/cn`, тогда как в переводах используется канонический код `zh`. (См. [руководство по SEO для алиасов локалей](/docs/react/nextjs/locale-alias-seo)). Документация `gt-next` описывает маршрутизацию на основе путей, а не по имени хоста. Для поддоменов или национальных доменов сопоставьте каждый хост с локалью в собственном коде и передайте её библиотеке — например, с помощью пользовательской функции определения локали, заданной через [`getLocalePath`](/docs/react/nextjs/config#request-function-paths), или с помощью [`withGT`](/docs/node/reference/functions/with-gt) в `gt-node`. О канонических тегах, hreflang и карте сайта читайте в статье [Как настроить SEO для многоязычного приложения Next.js?](/kb/multilingual-nextjs-seo). ## Основные выводы * Google сравнивает ccTLD, поддомены и подкаталоги с точки зрения таргетинга и сопровождения, а не ранжирования, и не рекомендует указывать язык в параметрах URL. * ccTLD сообщает о стране; поддомены и пути, похожие на языковые, сами по себе такого сигнала не дают. Для явного таргетинга по языку или региону используйте hreflang. Google считает `.io`, `.ai` и `.co` общими доменами. * Начните с подкаталогов (`example.com/de/`), если у ваших локалей общий сайт и общий процесс релиза; при этом структура URL не требует единого развёртывания или единого ресурса аналитики. * Разделяйте по странам (`es-MX`), только если различаются цены, доставка, правовые условия или каталоги; в остальных случаях ориентируйтесь на язык (`es`). * `gt-next` поддерживает маршрутизацию с префиксом в пути, необязательные префиксы для локали по умолчанию и локализованные слаги через `pathConfig`. ## Related questions - [Что такое hreflang и как его настроить?](https://generaltranslation.com/ru/kb/what-is-hreflang.mdx): Hreflang сообщает Google, какие URL являются языковыми или региональными версиями одной и той же страницы, чтобы в результатах поиска показывалась нужная. Добавьте его с помощью HTML-тегов link, HTTP-заголовков Link или карты сайта, сделайте все ссылки взаимными и используйте корректные коды, например en-GB, а не en-UK. - [Языковые перенаправления и SEO: URL, cookie-файл или Accept-Language?](https://generaltranslation.com/ru/kb/locale-routing-seo.mdx): Язык каждой страницы, которую вы хотите видеть в индексе, должен определять URL, ведь Googlebot не отправляет заголовок Accept-Language и сканирует сайты в основном с американских адресов. Сохранённый в cookie-файле выбор, а за ним Accept-Language используйте только для того, чтобы решить, куда перенаправлять с нейтрального корневого пути вроде /, причём временным перенаправлением 302 или 307. - [Как настроить SEO для многоязычного приложения Next.js?](https://generaltranslation.com/ru/kb/multilingual-nextjs-seo.mdx): Выделите каждому языку собственный URL с префиксом, например /en/about и /es/about, а затем укажите для каждого опубликованного языка html lang, канонический URL, ссылающийся на саму страницу, альтернативные версии hreflang с x-default, переведённые заголовок и описание, а также запись в карте сайта. Неопубликованные версии пометьте noindex. gt-next от General Translation направляет каждый язык на собственный URL и переводит заголовки с помощью getGT. - [Как сделать сайт многоязычным?](https://generaltranslation.com/ru/kb/make-website-multilingual.mdx): Выберите, где будут храниться переводы — в прокси, плагине CMS, конструкторе сайтов или в вашем собственном коде, — а затем выделите каждому языку собственный URL, как рекомендует Google. Переводите страницы целиком, включая заголовки и метаописания, связывайте языковые версии с помощью hreflang и предлагайте переключатель языка вместо автоматического перенаправления посетителей. ## Previous and next questions - Previous question: [Переключатель языка: лучшие практики UX, SEO и доступности](https://generaltranslation.com/ru/kb/language-switcher.mdx) - Next question: [Что такое hreflang и как его настроить?](https://generaltranslation.com/ru/kb/what-is-hreflang.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.