Английская версия сайта: поддомен, директория или параметры URL

Выбор правильной структуры URL для англоязычной версии сайта — это фундаментальное решение, которое влияет на то, как поисковые системы понимают и ранжируют ваш контент в 2026 году.

Ошибки на этом этапе могут привести к дублированию страниц, размытию ссылочного веса и потере трафика из целевых регионов. Сегодня Google и другие поисковики стали умнее в распознавании сигналов гео- и языковой привязки, но они по-прежнему полагаются на четкие и предсказуемые архитектурные решения. Мы разберем три основных подхода: поддиректорию (example.com/en/), поддомен (en.example.com) и URL-параметры (example.com?lang=en), чтобы вы могли выбрать оптимальный путь с учетом ваших ресурсов и целей.

Директория (example.com/en/): золотой стандарт для большинства проектов

Директория — это папка внутри основного домена, например, site.com/en/.

С точки зрения SEO в 2026 году это самый рекомендуемый вариант для подавляющего большинства сайтов, выходящих на международный рынок.

• Главное преимущество заключается в том, что вся ссылочная масса и авторитетность (domain authority) основного домена автоматически передаются языковым версиям.
• Вам не нужно продвигать отдельный ресурс с нуля — все усилия по линкбилдингу работают на общий «котёл».
• Это особенно критично для молодых сайтов, которым сложно растить несколько площадок параллельно.

С технической точки зрения, поддиректории легко настраивать и обслуживать. Вам нужен один хостинг, один SSL-сертификат и одна консоль Google Search Console, где все языковые версии будут отображаться как разделы основного ресурса. Пользователям также интуитивно понятно, что переключение с /ru/ на /en/ просто меняет язык, оставляя их в знакомом интерфейсе. Для поисковых роботов это четкий сигнал о структуре сайта, который легко считывается и индексируется.

Единственный нюанс: если вы планируете физически размещать серверы в разных странах для ускорения загрузки, поддиректории могут быть привязаны к одной точке, но эта проблема легко решается использованием CDN.

Поддомен (en.site.com): автономия и гибкость

Поддомен создает отдельную площадку в рамках вашего основного бренда, например, en.site.com.

С точки зрения поисковых алгоритмов, поддомен долгое время считался практически отдельным сайтом, что требовало отдельных усилий по его раскрутке.

Однако в 2026 году ситуация изменилась: Google научился лучше распознавать тесную связь между поддоменами и основным доменом, особенно если между ними настроено плотное внутреннее перелинковывание и единая структура навигации. Такие гиганты, как Microsoft (docs.microsoft.com) или Yahoo (finance.yahoo.com), успешно используют поддомены, не теряя в ранжировании.

Когда же стоит выбирать поддомен? Этот вариант идеален для технически сложных или концептуально разных разделов.

Например, если ваша английская версия представляет собой отдельный блог на другой CMS, интернет-магазин с другой базой товаров или форум, который живет своей жизнью. Поддомен позволяет изолировать технические настройки, не трогая основной сайт. Он также дает возможность разместить английскую версию на отдельном хостинге или сервере, близком к целевой аудитории, что критически улучшает Core Web Vitals для западных пользователей.

Однако помните: вам придется развивать ссылочную популярность поддомена отдельно, хотя часть авторитета основного домена все же будет передаваться через брендовые сигналы и внутренние ссылки.

URL-параметры (example.com?lang=en): путь, ведущий в никуда

Использование GET-параметров вроде ?lang=en или &language=ru для переключения языковых версий — это технически самый простой, но с точки зрения SEO самый опасный метод в 2026 году.

Поисковые системы крайне неохотно индексируют такие страницы и часто воспринимают их как дубли или как одну и ту же страницу с разными фильтрами.

• Проблема в том, что для робота example.com/page и example.com/page?lang=en могут выглядеть как один и тот же URL с мусорным параметром, что приводит к игнорированию альтернативной версии.
• Кроме того, такие URL некрасивы и непонятны для пользователей, что снижает кликабельность в поисковой выдаче.

Даже если вы настроите правильные каноникалы и hreflang, параметрические URL создают хаос в аналитике и логике работы сайта. При переходе пользователя с поиска на такой URL есть риск, что сессионные параметры потеряются или будут конфликтовать с настройками кеширования. Google на своих официальных ресурсах и в рекомендациях экспертов прямо указывает, что данный подход следует избегать, отдавая предпочтение чистым структурам.

В 2026 году этот метод можно рассматривать разве что для временных технических решений или для A/B-тестирования, но не для постоянной мультиязычной стратегии.

Если на английском некоторые статьи сайта

В этом случае, когда переводится только часть контента, создавать отдельную CMS или поддомен не нужно и даже вредно.

Самый простой и правильный путь — использовать уже существующую структуру поддиректории, например /en/, но наполнять её только теми материалами, которые вы хотите показать англоязычной аудитории. Остальные страницы сайта (те, что без английской версии) просто не будут иметь аналога в /en/.

Для пользователя это выглядит естественно: если он переключит язык на английский, он увидит доступные переводы, а при попытке зайти на непереведённый раздел можно либо оставить его на русской версии (с уведомлением), либо направить на главную английского раздела.

Технически вы просто добавляете новые URL вида site.com/en/nazvanie-stati и связываете их с русскими оригиналами через hreflang.

Что касается «дублей» (которые боятся дублей создавая 2 статьи на разных языках) — это не совсем верный термин.

Вы создаёте не дубли, а альтернативные языковые версии страниц. Для поисковиков это разные документы, предназначенные для разной аудитории, и при правильной настройке hreflang они не будут считаться копиями. Вам не нужно ставить вторую CMS — все работает на вашей текущей системе, просто в структуру URL добавляется сегмент /en/.

Главное — не использовать автоматический перевод и не пытаться создавать английские версии для всего подряд. Лучше сделать 10 качественных, глубоких статей на английском, которые реально нужны вашей аудитории, чем 100 плохо переведённых страниц, которые навредят репутации сайта.

Техническая магия: hreflang и каноникалы в связке

Независимо от выбранной архитектуры, «клеем», который скрепляет все языковые версии в единую систему для Google, является атрибут hreflang.

Это специальный тег, который указывается в шапке каждой страницы и сообщает поисковику: «Эта страница на английском для США, а вот эта — на английском для Великобритании, а вот эта — на русском для глобальной аудитории». Без hreflang даже идеально структурированный сайт рискует показываться не там и не тем пользователям. В 2026 году корректная реализация hreflang — это не просто рекомендация, а жесткое требование для успешной международной видимости, и ошибки здесь (например, отсутствие обратных ссылок между версиями) могут приводить к полному игнорированию тегов.

Одновременно с hreflang необходимо грамотно настроить канонические ссылки (rel=”canonical”). 3

Для мультиязычного сайта правило простое: каждая языковая версия должна ссылаться сама на себя как на каноническую. Это ключевой момент. Иногда начинающие оптимизаторы ошибочно пытаются сделать каноникал на основную (например, русскую) версию, чтобы «склеить вес», но этим они убивают всю логику hreflang. Поисковик получает противоречивые сигналы: hreflang говорит, что страницы разные и нужны для разных аудиторий, а каноникал утверждает, что главная только одна. Итог — Google может проигнорировать и то, и другое.

Правильная связка: уникальный URL, свой hreflang на все языки и само-каноникал.

Правильный hreflang для русской и английской версий:

У вас есть статья на русском: site.ru/ru/story и её перевод на английском: site.ru/en/story. В head обеих страниц нужно прописать одинаковый блок hreflang:

<link rel="alternate" hreflang="ru" href="https://site.ru/ru/story" />
<link rel="alternate" hreflang="en" href="https://site.ru/en/story" />
<link rel="alternate" hreflang="x-default" href="https://site.ru/ru/story" />

 Этот блок — двустороннее зеркало. Он говорит Google: «У этой русской страницы есть английская сестра, и у английской есть русская сестра». Без такого перекрестного указания связь не работает. Тэг x-default указывает на версию по умолчанию для пользователей, чей язык не определен или не поддерживается (обычно это самая наполненная версия или главная страница).

Правильный каноникал для товара с UTM-метками:

Представьте, что у вас есть страница товара site.ru/kurtka. Вы запустили рекламную кампанию, и ссылки ведут на неё с UTM-метками: site.ru/kurtka?utm_source=google. Для поисковика это два разных URL, хотя содержание одинаковое. В head страницы с UTM-меткой нужно прописать:

<link rel="canonical" href="https://site.ru/kurtka" />

Этот код говорит Google: «Не смотри на мусорные параметры в URL, главная версия этой страницы — site.ru/kurtka. Все ссылочные сигналы и поведенческие факторы приписывай ей». В результате поисковик не будет индексировать дубли с UTM и не накажет вас за повторяющийся контент.

Как не надо делать: копия CMS в отдельной папке

Некоторые администраторы предлагают установить вторую копию CMS (например, WordPress) в папку /en на сервере, с отдельной базой данных, отдельной темой (копией шаблона русской версии сайта) и отдельными настройками.

Английские статьи публиковать только в этой копии (в новой CMS), а на основном сайте (в русской версии) поставить кнопки переключения языка, которые ведут на главную английского раздела site.com/en/.

Русские и английские статьи никак технически не связаны, но такие люди готовы вручную прописывать hreflang через PHP для каждой пары статей (имеется ввиду, что если ID статьи такой-то, прописать в Header такой-то код).

Недостатки этого подхода:

1. Две базы данных и два движка. Вам придется отдельно обновлять WordPress, плагины и тему для каждого сайта. Забыли обновить английскую версию — получили дыру в безопасности.
2. Ручная связка статей. Каждую новую английскую статью нужно вручную привязывать к русской через hreflang в коде. Для 10 статей это терпимо, для 100 — адский труд, для 500 — нереально.
3. Отдельное меню навечно. Меню, виджеты, подвал, настройки темы — всё придется дублировать и поддерживать в двух экземплярах. Добавили новый пункт в русское меню — идите и добавляйте его же в английское.
4. Нет автоматического переключения языка. Кнопка “English” ведет только на главную английской версии, а не на перевод той статьи, которую читает пользователь. Посетителю придется искать нужный материал заново.
5. Потеря SEO-веса. Английский сайт в подпапке /en технически является отдельным ресурсом. Он не наследует авторитет основного домена, и его придется продвигать с нуля.
6. Сложность с регулярными выражениями. Чтобы автоматически определять соответствие статей для hreflang, вам потребуется писать сложные PHP-обработчики или хранить таблицу соответствий ID статей в отдельном файле.
7. Риск санкций за дубли. Если Google обнаружит, что на двух разных URL (site.ru/story и site.ru/en/story) лежит очень похожий контент без четкой hreflang-связки, он может посчитать это дубляжом и исключить одну из страниц из индекса.
8. Усложнение бэкапов. Нужно делать резервные копии двух баз данных и двух наборов файлов. Восстановление после сбоя занимает в два раза больше времени.

В WordPress это решается установкой специальных плагинов. Например, Polylang.

Для большинства малых и средних проектов, которые просто хотят добавить английскую версию к существующему сайту, бесспорным лидером является поддиректория /en/. Это самый быстрый, дешевый и эффективный с точки зрения SEO способ.

Вы сохраняете все накопленные активы основного домена и быстро начинаете получать трафик. Если же ваш бизнес предполагает физическое присутствие в разных странах, отдельные юрлица или сильную культурную адаптацию контента (например, интернет-магазин с разными каталогами для США и Великобритании), стоит рассмотреть национальные домены (ccTLD —.us,.co.uk), но это отдельная большая тема с регистрацией и хостингом в этих странах.

Если вы выбираете поддомен (en.example.com), будьте готовы к тому, что первое время вам придется активнее продвигать его, создавая отдельную ссылочную массу. Однако для крупных порталов с разделенными командами контент-менеджеров или разными техническими стеками это оправданно. В любом случае, забудьте про URL-параметры — этот метод окончательно устарел и может нанести вред. Также критически важно избегать автоматического редиректа пользователей на языковую версию по IP. Дайте людям возможность самим выбрать язык через виджет на сайте — это уважение к пользователю и безопасность для индексации.

Выбор редакции (для CMS WordPress)

Вам не нужен плагин типа Polylang, если вы просто публикуете две отдельные статьи (RU и EN).

Вам нужно только корректно связать их через hreflang.

Решение простое и это делается ОДИН раз.

Шаг 1. В каждой статье добавляешь произвольное поле. Для русской стати это:

en_version

И вставляешь туда URL английской версии.

В английской статье аналогично:

ru_version

Шаг 2. Добавляешь в functions.php:

add_action('wp_head', function() {

if (is_singular()) {

global $post;
$en = get_post_meta($post->ID, 'en_version', true);
$ru = get_post_meta($post->ID, 'ru_version', true);
$current_url = get_permalink();
if ($en) {
echo '<link rel="alternate" hreflang="en" href="'.esc_url($en).'" />' . "\n";
echo '<link rel="alternate" hreflang="ru" href="'.esc_url($current_url).'" />' . "\n";
}
if ($ru) {
echo '<link rel="alternate" hreflang="ru" href="'.esc_url($ru).'" />' . "\n";
echo '<link rel="alternate" hreflang="en" href="'.esc_url($current_url).'" />' . "\n";
}

}

});

Что это даёт ?

• hreflang появляется в <head>

• всё работает постранично

• ничего вручную в head вставлять не нужно

• сервер не нагружается

• не нужен ни один платный плагин

• Google корректно поймёт языковые версии

В данном случае у нас на сайте копия шаблона (на англ) и самой CMS (на англ) размещены в папке https://poznayu.com/en/

• Нужно также добавить sitemap в robots.txt для английской версии сайта (то есть, в корне основного сайта дать ссылку что есть sitemap и для английской версии) и включить генерацию sitemap на том, английском сайте

Итоговые соображения: контент решает всё

Какой бы совершенной ни была ваша архитектура URL, в 2026 году Google оценивает в первую очередь качество и уникальность контента для каждой языковой версии. Машинный перевод без участия человека и адаптации под локальные реалии больше не работает — такие сайты попадают под фильтры низкокачественного контента. Английская версия для США и английская для Австралии должны различаться не только написанием colour/color, но и учитывать местные особенности, метафоры и даже валюту. Только сочетание правильной технической архитектуры, грамотных hreflang и каноникалов, а также глубокой локализации контента позволит вам занять высокие позиции в англоязычном поиске. Вкладывайте ресурсы в создание ценного, человеческого контента для каждой аудитории, и правильная структура URL поможет доставить его адресату без помех.

Итан Картер

Я, Итан Картер – американский разработчик и технический автор с более чем 20-летним опытом в системном и прикладном программировании. Мой основной профиль — низкоуровневая разработка на Assembler: 22 года практики, включая глубокую работу с оптимизацией кода, архитектурой процессоров и производительностью критичных по скорости решений. Я защитил PhD dissertation по Assembler, а также более 18 лет работаю с ASP.NET, создавая корпоративные веб-системы, API и масштабируемые backend-решения.

Дополнительно я имею 9 лет опыта в C++ и C#, а также 7 лет практики программирования микроконтроллеров на Assembler. Благодаря моему сочетанию академической подготовки и прикладного инженерного опыта я могу писать статьи на стыке архитектуры ПО, низкоуровневой оптимизации и современной разработки, делая сложные технические темы понятными для профессиональной аудитории.