Поддомен — имя хоста под родительским доменом, например docs.example.com, которое может решать отдельную техническую или контентную задачу и должно планироваться как часть архитектуры сайта.
Решение и его границы
Поддомен — это имя хоста ниже другого доменного имени, например docs.example.com под example.com. Технически у него может быть собственное приложение, маршрутизация, cookie, настройки DNS и присутствие в поиске. Но эта гибкость не решает вопрос об архитектуре информации. Выбор между поддоменом и подкаталогом зависит от того, кто владеет разделом, где проходят границы продукта, какие нужны локализация или платформа и как пользователь проходит путь. Предполагаемый SEO-бонус здесь не аргумент.
Что проверить
Составьте карту всех хостов: назначение, владелец, канонический публичный хост, состояние TLS, правила robots, карту сайта, идентификатор аналитики и пути внутренних ссылок. Просканируйте основные страницы на границе и проверьте, что ссылки ведут сразу на нужные канонические адреса. Во время миграции храните карту по каждому URL и проверяйте каждый адрес назначения, а не полагайтесь на то, что маршрутизация на уровне всего хоста справится сама.
Практический порядок внедрения
Используйте поддомен, когда он создаёт стабильную и понятную границу, например для документации, приложения или отдельной региональной платформы. Дайте ему собственную понятную навигацию и политику индексации, сохранив контекстные ссылки на родительский раздел. Если контент переносится между хостами, настройте прямые постоянные редиректы там, где это уместно, обновите канонические ссылки и карту сайта, а также проверьте рендеринг и отслеживание на обеих сторонах.
Ошибки и ограничения измерений
Рискованный обходной путь — создавать поддомен только для того, чтобы изолировать SEO-работу или дубли контента. Так можно распылить владение и усложнить общесайтовые правки. Не утверждайте, что поддомен автоматически наследует авторитет или теряет его. Оцените реальные ссылки, контент, доступность и реализацию миграции.
Пример архитектуры. Компания может разместить документацию продукта на docs.example.com, потому что её ведёт отдельная платформа и отдельная команда, а клиентское приложение живёт на app.example.com. Это может быть связная граница, если навигация, ожидания от аккаунта, политика поиска и владение понятны. Перенос маркетинговой папки на поддомен только потому, что у неё другой шаблон, — гораздо более слабый довод. Перед выбором имени хоста опишите путь пользователя через хосты.
Критерии проверки. Ведите реестр хостов: назначение, основной владелец, канонический публичный хост, карта сайта, политика robots, охват TLS, охват аналитики и ключевые точки входа. Сканируйте основные страницы от родителя к поддомену и обратно, проверяя прямые внутренние ссылки, поведение редиректов и пути в футере и навигации. При переносе проверяйте пары старых и новых URL, а не только корень хоста. Если затронуты cookie, вход или передача в приложение, проверьте путь в браузере и на мобильных устройствах.
Частые ошибки. Не дублируйте один и тот же контент на корневом хосте и поддомене без явного решения о каноническом адресе или миграции. Не считайте, что поисковые системы воспринимают все хосты как один сайт или как совершенно разные; проверяйте реальную структуру ссылок и URL. Изменение имени хоста влияет на эксплуатацию, аналитику и доверие пользователей, а не только на SEO, поэтому нужен план отката на уровне маршрутов.