Что такое субдомен и как его создать?

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

Например, если основной сайт работает по адресу example.com, блог можно разместить на blog.example.com, магазин — на shop.example.com, а личный кабинет — на account.example.com. Каждое такое имя может иметь собственные DNS-настройки, серверную конфигурацию и даже работать на отдельной инфраструктуре.

Чтобы лучше понять, что такое субдомен, сначала важно разобраться со структурой доменного имени. DNS имеет иерархическое строение: домен может содержать другие домены более низкого уровня. В практическом веб-контексте под субдоменом обычно понимают дополнительное имя, созданное внутри уже существующего доменного пространства. Подробнее о структуре адреса сайта и принципе работы доменов можно прочитать в материале Hostpark «Доменное имя простыми словами: что это и как оно работает?».

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

Что такое субдомен?

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

Проще всего увидеть структуру на примере. Для адреса blog.example.com домен example.com является родительским по отношению к blog.example.com, а label blog образует дополнительный уровень. Аналогично shop.example.com можно использовать для магазина, support.example.com — для центра поддержки, а dev.example.com — для среды разработки.

Основной домен и субдомен связаны в иерархии DNS, но не обязаны работать как один сайт. Основной ресурс example.com может быть создан на WordPress и работать на одном сервере, тогда как app.example.com может быть отдельным веб-приложением на другой инфраструктуре. DNS позволяет независимо направлять такие имена на нужные ресурсы.

Ключевое практическое различие между зарегистрированным доменом и созданным внутри него субдоменом заключается в том, что для example.com сначала нужно получить право использования доменного имени через регистратора. После этого можно управлять DNS-зоной и создавать внутри домена дополнительные имена. Если домен еще не зарегистрирован, сначала можно зарегистрировать доменное имя в Hostpark, а уже затем настраивать его DNS.

Отдельно регистрировать blog.example.com или shop.example.com как новые независимые домены обычно не требуется. Для нужного имени настраивают DNS и, если речь идет о веб-сайте или приложении, соответствующую конфигурацию на хостинге, веб-сервере, reverse proxy, CDN или внешней платформе. В некоторых архитектурах для субдомена создается отдельная DNS-запись, в других может использоваться wildcard или отдельная делегированная DNS-зона.

Иногда blog.example.com называют доменом третьего уровня: .com является доменом верхнего уровня, example — следующим уровнем, а blog — еще одним. Однако такая нумерация не всегда удобна. Например, для example.com.ua структура уже содержит дополнительный уровень. Поэтому в практической работе полезнее ориентироваться на родительский домен и конкретное имя, созданное внутри него.

Субдомен также не следует путать с отдельной страницей или папкой сайта. Адрес example.com/blog/ является URL-путем внутри hostname example.com, тогда как blog.example.com имеет другой hostname. Эта разница влияет на DNS, конфигурацию веб-сервера, SSL/TLS, аналитику и другие технические настройки.

Итак, если объяснять максимально просто, субдомен — это способ создать дополнительный адрес в пределах уже существующего доменного пространства. Он полезен, когда часть проекта нужно логически или технически отделить без регистрации нового независимого домена.

Для чего нужны субдомены?

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

Наиболее распространенные сценарии использования субдоменов следующие:

• Блог. Адрес blog.example.com может использоваться, если блог работает отдельно от корпоративного сайта, например на другой CMS или платформе. Если технического разделения нет, блог также можно организовать как example.com/blog/.
• Интернет-магазин. Shop.example.com целесообразен, когда ecommerce-часть работает на отдельной платформе или требует собственной серверной конфигурации.
• Личный кабинет или приложение. Account.example.com или app.example.com можно использовать для отдельной продуктовой части, где пользователь авторизуется и работает со своими данными или настройками.
• Тестовая среда. Dev.example.com, test.example.com или staging.example.com можно использовать для проверки изменений до их развертывания на production. Такую среду нужно защищать реальным контролем доступа, если она не предназначена для публичного использования.
• Отдельный технический сервис. Api.example.com, docs.example.com, support.example.com или files.example.com могут использоваться для API, документации, базы знаний, файлового сервиса или другого независимого компонента.
• Языковая или региональная версия. En.example.com, pl.example.com или de.example.com могут использоваться для локализованных версий. Альтернативный подход — подкаталоги example.com/en/, example.com/pl/ и т. д.

В каждом случае субдомен создает отдельный hostname и позволяет независимо управлять соответствующей частью инфраструктуры. Например, app.example.com можно обновлять отдельно от корпоративного сайта, а docs.example.com направить через DNS на внешнюю платформу документации.

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

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

Субдомен или подкаталог: что выбрать?

Субдомен и подкаталог могут использоваться для логического разделения одного проекта, но технически это разные конструкции. Субдомен имеет формат blog.example.com, а подкаталог — example.com/blog/. В первом случае речь идет об отдельном hostname, во втором — о пути внутри того же hostname.

Подкаталог обычно удобен, если контент непосредственно относится к основному сайту. Новости компании, статьи, кейсы, категории или страницы услуг на одной CMS часто нет технической причины выносить на отдельный hostname.

Субдомен целесообразен, когда требуется техническая автономность. Например, основной сайт работает на WordPress, а клиентский кабинет создан как отдельное приложение. В такой ситуации app.example.com можно направить на другой сервер или платформу и поддерживать независимо.

Аналогичный сценарий возможен с документацией. Если она работает на специализированной SaaS-платформе, docs.example.com часто можно подключить через DNS, не изменяя архитектуру основного сайта.

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

При этом субдомен является отдельным hostname, поэтому для него нужно отдельно контролировать технические SEO-параметры: доступность для поисковых роботов, sitemap, robots.txt, canonical, hreflang при необходимости, внутреннюю перелинковку и отсутствие нежелательных дублей.

Если структура уже стабильно работает, переносить большой раздел из подкаталога на субдомен или наоборот только ради предположения о SEO-преимуществе не стоит. Такое изменение фактически меняет URL и требует корректной миграции, перенаправлений и повторной обработки адресов поисковыми системами.

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

Как создать субдомен?

Для запуска веб-ресурса на субдомене нужно решить две задачи: настроить DNS так, чтобы имя приводило пользователя к нужной инфраструктуре, и настроить сервер или внешнюю платформу так, чтобы они распознавали этот hostname.

Если ресурс работает на хостинге с панелью управления, часть операций можно выполнить через графический интерфейс. Если субдомен должен вести на другой сервер, CDN или SaaS, обычно отдельно настраивается DNS.

Перед началом нужно определить название и назначение адреса. Для блога это может быть blog.example.com, для приложения — app.example.com, для staging — staging.example.com. Для публичных адресов лучше использовать короткие и стабильные названия, поскольку они могут попасть в документацию, поисковую индексацию и внешние ссылки.

Создание субдомена через панель хостинга

Многие панели управления сервером или веб-хостингом имеют инструменты для работы с доменами и поддоменами. Конкретный интерфейс зависит от программного обеспечения и конфигурации сервиса. Общий принцип работы таких систем можно посмотреть в материале Hostpark о панелях управления хостингом.

Типичная последовательность действий выглядит так:

1. Войдите в панель управления. Нужен аккаунт, в котором уже подключен основной домен или настроен соответствующий сервер.
2. Откройте управление доменами или сайтами. Название раздела зависит от панели: Domains, Websites & Domains, Subdomains или другой аналогичный пункт.
3. Выберите нужный домен. Если на сервере работает несколько проектов, убедитесь, что новое имя создается в правильном доменном пространстве.
4. Укажите имя субдомена. Для blog.example.com во многих панелях достаточно ввести blog, после чего система сформирует полное имя.
5. Настройте каталог или приложение. Если ресурс работает на этом же сервере, для отдельного сайта обычно определяют собственный document root или соответствующую серверную конфигурацию.
6. Проверьте DNS. Некоторые панели могут создать запись автоматически, но только если они фактически управляют нужной DNS-зоной. В противном случае запись нужно создать у DNS-провайдера отдельно.
7. Подключите сайт или сервис. После настройки hostname можно разместить файлы, установить CMS, настроить reverse proxy или подключить нужное приложение.

Панель сервера и авторитетный DNS могут управляться разными системами. Например, сайт может работать на одном сервере, а DNS-зона — у регистратора или специализированного DNS-провайдера. Тогда создание hostname на сервере не изменит DNS автоматически.

Возможна и обратная ситуация: DNS уже направляет blog.example.com на правильный IP-адрес, но веб-сервер не имеет virtual host или другой конфигурации для этого имени. Тогда вместо нужного сайта может открыться стандартный host, другой проект или ошибка.

Если проект работает на общем хостинге, возможность добавлять домены и субдомены зависит от конкретного провайдера и тарифного плана. На VDS или выделенном сервере администратор обычно имеет больше контроля, но также сам отвечает за настройку веб-сервера, DNS и SSL, если иное не предусмотрено услугой.

Как создать субдомен через DNS?

DNS-настройка нужна, чтобы связать hostname с сервером или другой платформой. Перед внесением изменений нужно определить, где фактически обслуживается авторитетная DNS-зона домена. Это может быть регистратор, DNS-провайдер, CDN или другая платформа. Подробнее принцип работы записей описан в статье Hostpark «DNS для новичков: как работают записи и почему без них не обойтись».

Для типичного веб-субдомена чаще всего используются A, AAAA или CNAME.

A-запись связывает имя с IPv4-адресом. Например, для blog.example.com можно создать A-запись, значением которой будет IPv4-адрес сервера. После этого сервер должен быть настроен принимать HTTP/HTTPS-запросы именно для blog.example.com.

AAAA-запись выполняет аналогичную функцию для IPv6. Если сервис корректно доступен и через IPv4, и через IPv6, для одного hostname одновременно могут существовать A и AAAA.

CNAME используется, когда имя должно быть DNS-псевдонимом другого доменного имени. Например, SaaS-платформа может предоставить технический hostname и попросить создать для docs.example.com CNAME на этот адрес.

Важно: CNAME не является HTTP-редиректом. Браузер не переходит через него на другой URL. DNS-резолвер находит каноническое имя и продолжает DNS-резолюцию, а пользователь в браузере по-прежнему может видеть docs.example.com.

Тип записи нужно выбирать в соответствии с архитектурой и инструкцией целевого сервиса. Если платформа прямо требует CNAME, не стоит заменять его A-записью на IP, который удалось найти самостоятельно: провайдер может изменить собственную инфраструктуру.

В разных DNS-панелях поле Name или Host заполняется по-разному. Где-то нужно ввести только blog, а интерфейс сам добавит example.com, где-то — полное имя. Перед сохранением стоит проверить, какое FQDN фактически сформирует панель.

DNS-запись сама по себе не создает сайт. Она лишь помогает найти нужный сетевой ресурс. На сервере, CDN или SaaS-платформе hostname также нужно добавить в конфигурацию, а для HTTPS — обеспечить соответствующий сертификат.

Что нужно учесть после создания субдомена?

После настройки нужно проверить не только открытие адреса в браузере. Для корректной работы DNS должен возвращать нужный ресурс, сервер — правильно обрабатывать hostname, а HTTPS — использовать сертификат, действительный для этого имени.

Сначала проверьте DNS. Для A-записи должен возвращаться правильный IPv4-адрес, для AAAA — IPv6, для CNAME — ожидаемое каноническое доменное имя. Если DNS ведет не туда, изменения конфигурации веб-сервера не устранят проблему.

Далее откройте ресурс и убедитесь, что сервер отдает именно нужный сайт или приложение. Если blog.example.com показывает основной сайт, стандартную страницу сервера или другой virtual host, нужно проверить server name, document root, reverse proxy или конфигурацию платформы.

Отдельно проверьте HTTPS. Сертификат должен содержать конкретное имя blog.example.com или wildcard соответствующего уровня. Сертификат, выданный только для example.com, автоматически не становится действительным для blog.example.com.

Wildcard вида *.example.com может охватывать имена первого уровня, например blog.example.com, shop.example.com или app.example.com. Сам домен example.com и более глубокие имена вроде api.dev.example.com такой wildcard автоматически не охватываются — для них нужны соответствующие дополнительные имена или другой сертификат.

Подробнее принцип работы TLS и сертификатов рассмотрен в материале Hostpark об SSL-сертификатах и HTTPS.

Также проверьте перенаправление с HTTP на HTTPS. Для публичного веб-ресурса после корректной настройки TLS HTTP-версию обычно переводят на HTTPS. При этом нужно избегать redirect loop из-за противоречивых правил на веб-сервере, CDN и в CMS.

Если DNS-запись была только что изменена, часть пользователей некоторое время может получать старый ответ из кеша. Причина заключается в TTL предыдущей записи и поведении кеширующих DNS-резолверов. Поэтому ситуация, когда в одной сети уже виден новый IP-адрес, а в другой еще старый, в течение некоторого времени может быть нормальной.

Для staging или dev-субдомена нужно отдельно настроить контроль доступа. Незнание адреса не является средством защиты. Если тестовый ресурс не предназначен для публичного доступа, лучше использовать аутентификацию, VPN, IP-фильтрацию или другой подходящий механизм. Настройка robots.txt или noindex может использоваться для управления индексацией, но не заменяет контроль доступа.

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

Типичные ошибки при создании субдомена

Неправильная DNS-запись. A или AAAA может содержать неактуальный IP-адрес, а CNAME — неправильное имя целевого сервиса. Диагностику стоит начинать с проверки фактического DNS-ответа.

Запись добавлена не в ту DNS-зону. Домен может быть зарегистрирован у одной компании, сервер находиться у другой, а DNS работать через третий сервис. Изменять записи нужно там, где размещена авторитетная зона для домена.

Субдомен направлен не на тот сервер. Если A или AAAA содержит неправильный адрес, может открываться другой сайт, стандартный virtual host или вообще возникать ошибка соединения.

На сервере не добавлен hostname. Даже правильный DNS не гарантирует правильный ответ веб-сервера. Для blog.example.com нужно создать соответствующий virtual host, server block, reverse proxy route или добавить custom domain на внешней платформе.

Неправильно выбран каталог. Если новый hostname случайно направлен в document root основного сайта, два разных адреса могут показывать одинаковый контент. Для отдельного ресурса нужно правильно определить каталог или серверную маршрутизацию.

Отсутствует или неправильно настроен SSL-сертификат. HTTP может работать, а HTTPS — показывать ошибку, если сертификат не содержит нужный hostname или установлен не на том endpoint, который завершает TLS-соединение.

Кеш DNS после изменения записи. Если предыдущий DNS-ответ еще находится в кеше рекурсивного резолвера, часть пользователей может временно получать старое значение до завершения TTL.

Неправильная настройка CDN или reverse proxy. Если перед origin-сервером используется промежуточная платформа, новый hostname часто нужно добавить и в нее, настроить TLS и указать правильный origin.

Незащищенный staging. Тестовая копия может содержать внутреннюю информацию, тестовые аккаунты или незавершенные функции. Если она не предназначена для публичного доступа, ее нужно закрыть реальным механизмом доступа, а после завершения работ — удалить или деактивировать, если она больше не нужна.

Удаление субдомена без проверки зависимостей. Старый hostname могут использовать API, webhook, интеграции, документация, внешние ссылки или пользователи. Перед удалением DNS-записи нужно проверить зависимости, а для публичных URL при необходимости настроить перенаправление на актуальный адрес.

Вывод

Субдомен — это доменное имя, расположенное ниже другого домена в DNS-иерархии. Для example.com можно создать blog.example.com, app.example.com, staging.example.com и другие адреса. На практике это позволяет логически и технически отделять различные компоненты проекта без регистрации для каждого из них отдельного независимого домена.

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

Для типичного веб-субдомена нужно настроить DNS и серверную часть. A-запись используется для IPv4, AAAA — для IPv6, CNAME — когда имя должно быть DNS-псевдонимом другого hostname. После этого нужно проверить, принимает ли сервер новое имя, работает ли HTTPS и действителен ли сертификат именно для этого hostname.

Если домен для проекта еще не зарегистрирован, Hostpark предоставляет услуги регистрации доменных имен. Для размещения отдельных сайтов и приложений компания также предлагает серверные и облачные решения, а конкретную схему DNS, веб-сервера и субдоменов нужно подбирать в соответствии с архитектурой самого проекта.