Що таке субдомен і як його створити?

Коли сайт розвивається, його структура часто стає складнішою: з’являється блог, інтернет-магазин, особистий кабінет, тестове середовище, окремий сервіс або мовна версія. Один зі способів логічно й технічно відокремити такі частини – створити субдомен. Він дозволяє використовувати основне доменне ім’я, але водночас отримати окрему адресу для певного розділу або сервісу.

Наприклад, якщо основний сайт працює за адресою 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, вебсервера та субдоменів потрібно підбирати відповідно до архітектури самого проєкту.