SiteGuard4 ноября 202615 мин чтения

Что такое поддомен и как создать его для сайта

Поддомен — это доменное имя внутри другого домена, например shop.example.com внутри example.com. На нём можно разместить магазин, личный кабинет, справочный центр или тестовую версию сайта. Чтобы создать работающий поддомен, обычно нужно добавить имя на хостинге или в приложении, настроить DNS и подключить HTTPS. Одна запись в DNS ещё не создаёт страницы и не устанавливает CMS.

Для владельца бизнеса поддомен полезен, когда отдельному сервису нужны собственная платформа, команда или порядок работы. Однако каждый новый адрес требует обслуживания: доступа к настройкам, актуального сертификата, контроля доступности и понятного ответственного. Ниже разберём, когда такое разделение оправдано, как его настроить и что проверить до передачи адреса клиентам.

Что такое поддомен простыми словами

Доменное имя имеет иерархию. В адресе shop.example.com часть shop добавлена слева от example.com и обозначает имя внутри него. Владелец или администратор родительского домена управляет созданием таких имён через настройки DNS либо передаёт соответствующие полномочия другим специалистам.

Поддомен может вести на тот же сервер, что и основной сайт, на другой хостинг или во внешний сервис. Например, корпоративный сайт работает на одной CMS, а help.example.com — в отдельной системе поддержки. Для посетителя оба адреса связаны общим именем компании, но технически у них могут быть разные приложения, настройки и точки отказа.

Адрес	Что это	На что обратить внимание
`example.com`	Основное зарегистрированное имя в примере	Управление регистрацией и DNS определяет основу работы адресов внутри него
`www.example.com`	Поддомен с именем www	Может показывать основной сайт или перенаправлять на выбранный главный адрес
`shop.example.com`	Поддомен магазина	Ему нужны собственные корректные настройки подключения
`test.shop.example.com`	Более глубокое имя внутри shop.example.com	Для него отдельно проверяют DNS, приложение и покрытие сертификатом
`example.com/shop/`	Путь на сайте, обычно называемый подпапкой или разделом	Часть после слеша не является поддоменом

Почему поддомен не всегда означает домен третьего уровня

Для распространённого примера shop.example.com выражение «домен третьего уровня» подходит. Но считать уровень только по привычной схеме «имя плюс зона» нельзя. Например, в shop.example.co.uk зарегистрированным именем может быть example.co.uk, а магазин расположен уровнем ниже.

Public Suffix List приводит com и co.uk как примеры публичных суффиксов, под которыми регистрируют имена. Поэтому в рабочем обсуждении удобнее указывать полный адрес и родительский домен. Так специалист не перепутает регистрацию нового имени с добавлением адреса внутри уже существующего.

Когда бизнесу нужен отдельный поддомен

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

Задача	Пример адреса	Что продумать до запуска
Магазин на отдельной платформе	`shop.example.com`	Каталог, оплату, аналитику и переход между магазином и корпоративным сайтом
Личный кабинет	`account.example.com`	Авторизацию, права пользователей и связь с основным приложением
Справка и поддержка	`help.example.com`	Управление статьями, поиск, приём обращений и ответственного за содержание
API или другой технический сервис	`api.example.com`	Правила доступа, клиентские подключения и обслуживание версий
Тестовая среда	`staging.example.com`	Закрытый доступ, тестовые данные и отсутствие реальных оплат и рассылок
Отдельное направление компании	`academy.example.com`	Понятную роль сервиса и достаточные ресурсы для его развития

Например, компания может оставить основной сайт на привычной CMS, а обучение разместить в специализированной платформе на academy.example.com. Это осмысленное разделение, если платформе нужны отдельные аккаунты, платежи и личные кабинеты. Само наличие красивого адреса не решит эти вопросы: нужно заранее согласовать работу сервиса и путь пользователя.

Поддомен или подпапка: как выбрать, в том числе для SEO

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

В ответах Google о сканировании и индексировании прямо сказано, что поисковая система не предпочитает поддомены подпапкам или наоборот. Это не делает любые реализации равноценными: ошибки доступа, дубли, слабое содержание или неработающие ссылки остаются проблемами при любой структуре.

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

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

Что подготовить перед созданием поддомена

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

Уточните управление DNS. Найдите действующего DNS-провайдера основного домена. Он может отличаться от регистратора и хостинга.
Получите параметры подключения. Нужны IP-адрес сервера или имя, которое выдал внешний сервис, а также его инструкция по подтверждению домена.
Проверьте возможности платформы. Убедитесь, что выбранный тариф разрешает нужное число сайтов, поддоменов или пользовательских адресов.
Выберите имя. Используйте понятное назначение: help для справки, account для кабинета. Убедитесь, что имя ещё не используется другим сервисом.
Определите режим доступа. Публичный сайт, кабинет с авторизацией и закрытая тестовая среда настраиваются по-разному.
Сохраните текущие параметры. Перед изменениями запишите существующие настройки затрагиваемого имени и проверьте связанные интеграции.

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

Как создать поддомен: пошаговая инструкция

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

Шаг 1. Добавьте имя в панели хостинга или приложения

Откройте раздел управления сайтами, доменами или адресами проекта и добавьте полное имя, например help.example.com. Если создаётся отдельный сайт, выберите предназначенную для него папку или приложение. Не указывайте каталог рабочего основного сайта по привычке: иначе новый адрес может показать его копию или попасть под неподходящие настройки.

У внешнего сервиса вместо папки будет привязка пользовательского домена к вашему проекту. Выполните предусмотренное подтверждение владения. Подключение имени в аккаунте поставщика важно: запись DNS должна вести к тому проекту, которым вы управляете, а платформа должна принять именно этот адрес.

На VPS без панели веб-серверу или обратному прокси нужна настройка, которая связывает новое имя с приложением. Размещения файлов в произвольной папке недостаточно. Изменение должен проверить специалист, отвечающий за сервер.

Шаг 2. Добавьте нужную запись в действующей DNS-зоне

Скопируйте параметры из инструкции вашего хостинга или внешнего сервиса. Документация Cloudflare описывает базовый выбор: A направляет имя на IPv4, AAAA — на IPv6, а CNAME связывает его с другим доменным именем. A и AAAA могут использоваться вместе, если сайт работает по обоим протоколам. Но CNAME не совмещают с A или AAAA у того же имени. Не добавляйте конфликтующие записи «на всякий случай».

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

Что выдал поставщик	Возможная запись	Пример заполнения
IPv4-адрес сервера	A	Имя `help`, адрес `192.0.2.10`
IPv6-адрес работающего сервера	AAAA	Имя `help`, адрес `2001:db8::10`
Доменное имя сервиса	CNAME	Имя `help`, цель `project.host.example.net`

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

В IP-поле не вписывают протокол, путь страницы и порт. В цель CNAME не нужно вставлять адрес вида https://service.example.net/page/: это другой тип значения. Если сервис просит несколько записей для подключения и проверки владения, добавляйте именно указанные им записи и не заменяйте их случайным примером из чужой инструкции.

Шаг 3. Настройте сайт и его рабочий адрес

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

Шаг 4. Подключите HTTPS и проверьте результат

Убедитесь, что сертификат включает точное имя поддомена и установлен там, где завершается соединение посетителя. Это может быть сервер, хостинг или CDN. Выпуск сертификата и появление DNS-записи — разные действия; отметка «домен добавлен» в одной панели ещё не подтверждает готовность HTTPS.

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

Какой SSL-сертификат нужен поддомену и что означает wildcard

Для отдельного поддомена можно использовать сертификат на конкретное имя либо сертификат, в котором перечислено несколько нужных имён. Wildcard-сертификат удобен в некоторых проектах с большим числом одноуровневых поддоменов, но его возможности нужно понимать точно.

Let’s Encrypt поясняет: шаблон *.example.com покрывает shop.example.com и help.example.com, но не example.com и не test.shop.example.com. Если основной домен тоже нужен в сертификате, он должен быть включён отдельно. Для более глубокого имени также требуется подходящее покрытие.

Проверьте не только список имён, но и установку сертификата для нужного сайта, срок действия и последующее обновление. Даже подходящий сертификат не поможет, если сервер при обращении к поддомену выдаёт сертификат другого проекта. У CDN и сервера за ним могут быть отдельные TLS-настройки: проверьте используемую схему у поставщика.

Wildcard в DNS и wildcard в сертификате — разные настройки

DNS-запись со звёздочкой задаёт ответ для подходящих имён без отдельной записи. Она не создаёт автоматически разделы, учётные записи пользователей, содержимое и сертификаты. Сервер или платформа также должны понимать, что делать с поступившим именем.

Не переносите ограничения сертификата на DNS. В документации Cloudflare о wildcard DNS показано, что соответствие может распространяться и на более глубокие имена, а конкретные записи и делегирование меняют результат. Для обычного сайта с несколькими сервисами явные записи проще проверять: видно, какие адреса действительно запущены и куда они ведут.

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

Как проверить поддомен перед публикацией

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

Сверьте полное имя. Проверьте написание в DNS, панели хостинга, приложении и сертификате.
Проверьте направление. Полученный адрес или цепочка CNAME должны соответствовать выбранной схеме. При использовании CDN учитывайте адреса посредника.
Откройте HTTPS. Убедитесь, что нет предупреждения о сертификате и нежелательных переходов на технический адрес.
Проверьте несколько страниц. Главная, вход, форма, изображения и важные ссылки должны открываться ожидаемым образом.
Выполните целевой сценарий. Создайте согласованную тестовую заявку или войдите в тестовый аккаунт и проверьте результат на принимающей стороне.
Проверьте доступ с другой сети. Сравнение обычного подключения и мобильной сети помогает заметить различия наблюдаемого состояния.
Проверьте режим публикации. Публичный сервис должен быть готов к посетителям, закрытая среда — запрашивать нужную авторизацию.

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

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

Почему поддомен не открывается или показывает другой сайт

Тип проблемы обычно становится понятнее, если разделить DNS, подключение к платформе и поведение приложения. Не меняйте одновременно имя, IP, папку сайта и настройки HTTPS: после такого набора изменений трудно понять, какое из них помогло и что могло сломаться дополнительно.

Симптом	Что проверить	Следующий шаг
Имя не находится	Точное написание и запись у действующего DNS-провайдера	Убедиться, что редактируется используемая зона
Открывается заглушка хостинга	Привязку полного имени к сайту или приложению	Добавить имя в правильный проект и проверить его настройки
Открывается основной сайт	Выбранную папку, настройки виртуального хоста и перенаправления	Проверить, куда платформа направляет запросы этого имени
Браузер показывает предупреждение HTTPS	Покрытие имени, установку сертификата и конфигурацию TLS	Исправить сертификат или его назначение нужному сайту
Происходит переход на старый адрес	Основной URL в CMS и правила перенаправления	Согласовать адрес приложения с новым именем
Страницы доступны, но вход или форма не работают	Настройки приложения, интеграций и разрешённых адресов	Проверить полный сценарий и журнал ошибки
Сбой виден только в части сетей	Различие DNS-ответов, IPv4/IPv6 и состояние кэша	Сопоставить наблюдения и передать данные ответственному специалисту

Не удаляйте записи работающего основного сайта ради эксперимента с поддоменом. Сначала определите, какие настройки относятся именно к проблемному имени.

Как использовать поддомен для тестового сайта и закрытого кабинета

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

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

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

Как удалить поддомен и не оставить забытые подключения

Удаление начинается с инвентаризации. Проверьте, кто ещё пользуется адресом: посетители по старым ссылкам, приложение, рекламная кампания, интеграция или почтовое уведомление. Решите, нужно ли сохранить переход на актуальную страницу, закрыть сервис с понятным сообщением или полностью прекратить его работу.

Особенно внимательно отключайте внешние платформы. Microsoft описывает риск забытых DNS-записей, которые продолжают указывать на удалённый облачный ресурс. В определённых конфигурациях такой адрес может оказаться связан с ресурсом другого владельца. Это не свойство любого CNAME, но достаточная причина согласовать удаление сервиса и его DNS-привязки.

Сохраните нужные данные. Выгрузите материалы, настройки и информацию, которая понадобится после закрытия.
Обновите действующие ссылки и интеграции. Уберите адрес из навигации, уведомлений, рекламы и подключений приложений.
Подготовьте поведение старого адреса. Если нужен редирект, его должны обслуживать DNS, веб-сервер и HTTPS; одной удалённой записи для этого недостаточно.
Уберите ненужную DNS-связь до освобождения внешнего ресурса. Учтите сохраняющиеся ответы и порядок отключения, рекомендованный поставщиком.
Удалите проект и лишние доступы. Завершите обслуживание внешней платформы после согласованных технических действий.
Проверьте итог и обновите список сервисов. Зафиксируйте дату отключения и ответственного.

Удаляя один сервис, сохраните нужные другим проектам DNS-записи и общие сертификаты. После изменения проверьте соседние работающие поддомены.

Как поддерживать поддомены после запуска

В общем списке поддоменов храните назначение, DNS-провайдера, место размещения, ответственного и порядок проверки. Передавайте эти сведения вместе с проектом: по одному основному сайту нельзя восстановить все подключения компании.

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

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

Частые вопросы о поддоменах

Нужно ли покупать поддомен отдельно?

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

Сколько поддоменов можно создать?

Для практической задачи смотрите ограничения DNS-провайдера, панели хостинга и выбранной платформы. Число доступных записей, сайтов и подключённых адресов — разные лимиты. Обещание «безлимитные поддомены» в одном сервисе ещё не гарантирует неограниченное число отдельных приложений в другом.

Можно ли направить поддомен на другой хостинг?

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

Станет ли поддомен независимым от основного домена?

У него может быть отдельное приложение, хостинг и даже делегированное управление DNS. Но он остаётся внутри родительского доменного имени. Потеря контроля над основным доменом или изменение его делегирования способны затронуть сервисы на поддоменах, поэтому ответственность за родительское имя сохраняется.

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

Это зависит от возможностей почтового провайдера. Адрес вида user@team.example.com требует подключения соответствующего почтового домена и его настроек. Добавление веб-страницы на team.example.com автоматически почтовые ящики не создаёт.

Нужно ли создавать отдельную DNS-зону?

Для обычного адреса вроде help.example.com часто достаточно записи в зоне основного домена. Отдельное делегирование бывает полезно, когда управление поддоменом передают другой команде или DNS-провайдеру. Выбирайте его при понятной необходимости: это дополнительная часть инфраструктуры, которую придётся поддерживать.