Поддомен — это приставка слева от основного домена, которая образует отдельный адрес внутри того же домена, например blog.site.ru. Он позволяет запускать отдельные разделы, сервисы или версии сайта без покупки нового домена. Типовые примеры: m.site.ru для мобильной версии, ru.site.com для языковой версии, api.site.com для API.
Поддомены Яндекса
У Яндекса десятки поддоменов, каждый из которых — отдельный сервис внутри единой экосистемы:
| Поддомен | Сервис | Назначение |
|---|---|---|
direct.yandex.ru | Яндекс Директ | Контекстная реклама и продвижение в поиске |
metrika.yandex.ru | Яндекс Метрика | Веб-аналитика сайтов |
webmaster.yandex.ru | Яндекс Вебмастер | SEO-инструменты и мониторинг индексации |
business.yandex.ru | Яндекс Бизнес | Добавление компании в сервисы Яндекса |
market.yandex.ru | Яндекс Маркет | Маркетплейс товаров |
lavka.yandex.ru | Яндекс Лавка | Доставка продуктов и товаров |
eda.yandex.ru | Яндекс Еда | Доставка готовой еды |
travel.yandex.ru | Яндекс Путешествия | Поиск билетов и бронирование отелей |
music.yandex.ru | Яндекс Музыка | Музыкальный стриминг |
praktikum.yandex.ru | Яндекс Практикум | Онлайн-образование и курсы |
partner.yandex.ru | Рекламная сеть Яндекса | Монетизация сайтов-партнеров |
surveys.yandex.ru | Яндекс Взгляд | Платформа для онлайн-опросов |
afisha.yandex.ru | Яндекс Афиша | События, кино и развлечения |
Поддомены российских компаний и маркетплейсов
| Поддомен | Компания | Назначение |
|---|---|---|
moscow.tiu.ru, spb.tiu.ru | Тiu.ru | Региональные поддомены для разных городов с локальными ценами и поставщиками |
calculator.ozon.ru | Ozon | Калькулятор доходов для продавцов маркетплейса, вынесенный на отдельный поддомен |
kemerovo.site.ru, nsk.site.ru, spb.site.ru | Типовой шаблон | Региональные версии сайтов для геозависимого SEO-продвижения |
Типовые паттерны поддоменов (универсальные примеры)
| Префикс поддомена | Назначение | Пример |
|---|---|---|
blog. | Корпоративный блог, контент-маркетинг | blog.shopify.com |
shop. / store. | Интернет-магазин, отделенный от основного сайта | shop.bbc.com |
support. / help. | Служба поддержки и база знаний | support.apple.com |
api. | API-документация и endpoint-ы для разработчиков | api.github.com |
docs. / developers. | Документация для разработчиков | developers.google.com |
m. | Мобильная версия сайта (устаревший паттерн) | m.vk.com |
en. / de. / fr. | Языковые версии сайта для разных стран | en.wikipedia.org |
status. | Страница статуса сервисов (работает/не работает) | status.github.com |
careers. | Вакансии и раздел для соискателей | careers.google.com |
academy. | Образовательная платформа | academy.hubspot.com |
beta. / staging. | Тестовая версия продукта | beta.example.com |
Поддомены международных компаний
| Поддомен | Компания | Назначение |
|---|---|---|
mail.google.com | Веб-клиент электронной почты Gmail | |
drive.google.com | Облачное хранилище файлов Google Drive | |
maps.google.com | Карты и навигация Google Maps | |
translate.google.com | Сервис перевода Google Translate | |
developer.apple.com | Apple | Портал для разработчиков приложений |
support.apple.com | Apple | Техническая поддержка и инструкции |
music.apple.com | Apple | Музыкальный стриминг Apple Music |
github.com поддомены | Microsoft/GitHub | gist.github.com (сниппеты кода), pages.github.com (хостинг статических сайтов) |
Категории использования поддоменов
Реальные примеры показывают, что поддомены используют для 6 основных задач:
- Региональная локализация — отдельные версии для городов и стран с местными контактами, ценами и контентом
- Бизнес-сегментация — разделение B2B и B2C направлений или разных продуктовых линеек
- Технические сервисы — API, документация, статус-страницы, работающие на отдельных серверах
- Мобильная оптимизация — адаптированная версия для мобильных устройств (устаревший, но еще встречающийся паттерн)
- Тестирование — бета-версии и staging-окружения без риска для основного сайта
- Тематическое деление — крупные разделы (блог, магазин, обучение) как самостоятельные проекты
Чем отличается поддомен от домена, субдомена и алиаса
Поддомен и субдомен (subdomain) — это одно и то же: оба термина обозначают приставку перед основным доменом, например blog.site.ru. Домен — это основное зарегистрированное имя сайта, например site.ru. Алиас — это другое доменное имя, которое может показывать тот же контент, но не является частью исходного домена, например site.com и site.ru как алиасы одного проекта.
Примеры:
- домен:
site.ru; - поддомен:
shop.site.ru; - алиас:
site.com, указывающий на тот же сайт.
Поддомен или подпапка (каталог): что лучше для SEO
В большинстве случаев для SEO лучше использовать подпапку, например site.ru/blog/, так как она передает ссылочный вес и накапливает общий авторитет для всего домена. Поддомен, например blog.site.ru, чаще воспринимается поисковыми системами как самостоятельный сайт и требует отдельной стратегии продвижения. Подпапка подходит для блогов и внутренних разделов, поддомен — для крупных независимых проектов, региональных представительств или отдельных сервисов.
Подпапка site.ru/catalog/:
- плюсы: весь ссылочный и поведенческий вес работает на единый главный домен; проще и быстрее запускать, не нужно настраивать отдельные SSL-сертификаты и следить за склейкой; идеально подходит для блогов, интернет-магазинов и внутренних разделов;
- минусы: сложнее изолировать тематику, если разделы кардинально отличаются; меньше свободы при техническом разделении крупных проектов.
Поддомен catalog.site.ru:
- плюсы: поисковые системы воспринимают его как самостоятельный сайт, что удобно для крупных региональных представительств, отдельных сервисов, форумов или языковых версий; легко перенести на другой сервер или отдать под управление другой команде;
- минусы: продвигается медленнее, так как вес от основного домена передается слабо или вообще не учитывается; требует отдельной стратегии продвижения и наращивания ссылочной массы с нуля.
Что выбрать:
- выбирайте подпапку, если развиваете основной бренд, создаете блог, добавляете категории товаров или услуг;
- выбирайте поддомен, если запускаете независимый проект, крупное медиа, форум, личный кабинет или делаете полноценные геозависимые поддомены для разных городов с уникальным контентом.
Как сделать региональные поддомены для Яндекса
Региональные поддомены в Яндексе — это способ продвигать сайт в нескольких городах, когда возможностей одного региона в Яндекс.Вебмастере недостаточно. Обычно их используют, если у компании больше 7 регионов присутствия или офисов/филиалов и нужно собирать локальный трафик по геозависимым запросам, например «купить бетон [город]». Каждый городской поддомен нужно добавлять как отдельный сайт в Яндекс.Вебмастер и привязывать к своему региону.
Главные правила настройки:
- уникальный контент: замените на поддоменах контактные данные, адреса, телефоны, время работы, цены, условия доставки и отзывы; тексты на главных страницах и в разделах должны отличаться хотя бы локальными вкраплениями;
- привязка в Вебмастере: добавьте каждый поддомен как отдельный сайт в Яндекс.Вебмастер и укажите для него свой регион;
- техническая оптимизация: настройте корректные
robots.txtи индивидуальные файлыsitemap.xmlдля каждого поддомена; пропишите правильные теги H1, Title, Description с упоминанием конкретного города; - перелинковка и навигация: добавьте на сайт удобный региональный переключатель, чтобы пользователь мог вручную сменить город, если робот определил его некорректно.
Как создать и настроить поддомен в DNS и на хостинге пошагово
Поддомен создается в панели управления доменом или хостингом: сначала задают имя поддомена, затем создают DNS-запись и привязывают поддомен к папке или серверу. Чаще всего используется A-запись, указывающая на IP-адрес сервера, или CNAME-запись, указывающая на другой адрес. После этого нужно дождаться обновления кэша DNS.
Пошаговая схема:
- Добавить поддомен в панели домена или хостинга.
- Создать DNS-запись:
Aс именем поддомена и IP сервера илиCNAMEс именем поддомена и целевым адресом. - Привязать поддомен к нужной папке на сервере или к другому хостингу.
- Дождаться распространения изменений и проверить доступность поддомена.
Типовые сроки обновления DNS
TTL (Time To Live) определяет, как долго DNS-записи хранятся в кэше перед обновлением. Стандартные значения:
| Тип записи | TTL (секунды) | Время распространения |
|---|---|---|
| A / AAAA | 3600–14400 | 1–4 часа |
| CNAME | 3600–86400 | 1–24 часа |
| MX | 43200–86400 | 12–24 часа |
| TXT | 3600–43200 | 1–12 часов |
Время распространения DNS-изменений:
- При смене DNS-серверов: до 24–72 часов
- При добавлении записи на текущих DNS: 15 минут – 4 часа (зависит от TTL)
- Минимальное время (TTL = 300 сек): 5–15 минут
- Стандартное время (TTL = 3600 сек): 1–2 часа
Совет: Перед миграцией или изменением записей установите TTL = 300 секунд (5 минут) за сутки до изменений, чтобы ускорить распространение.
Примеры интерфейсов популярных хостингов
Timeweb
Пошаговая инструкция:
- Перейдите в раздел «Домены и SSL» в панели управления
- Кликните на нужный домен и перейдите на вкладку «Поддомены»
- Нажмите кнопку «Создать» или «Добавить»
- Укажите имя поддомена (например,
blog) - Выберите IP-адрес из списка сервисов или введите вручную
- Нажмите «Добавить»
- Подождите 15 минут – 1 час для применения изменений
Beget
Пошаговая инструкция:
- Перейдите в раздел «Домены и поддомены»
- Найдите основной домен в списке
- Нажмите зеленый «+» (добавить поддомен) рядом с доменом
- Во всплывающем окне укажите имя поддомена
- Выберите основной домен из выпадающего списка
- Можно указать маску
*для создания wildcard-поддомена (например,*.site.ru) - Сохраните изменения
Reg.ru
Пошаговая инструкция (два этапа):
Этап 1: Добавление в панели хостинга
- Войдите в панель управления хостингом
- Выберите один из способов:
- Как самостоятельный домен — поддомен добавляется как отдельный сайт (учитывается в лимитах тарифа)
- Как автоподдомен — неограниченное количество, корневая папка создается в директории WWW или поддиректории основного домена
Этап 2: Добавление DNS-записи
- Если DNS-серверы
ns1.hosting.reg.ruиns2.hosting.reg.ru→ запись добавляется автоматически, подождите 15 минут - Если DNS-серверы
ns1.reg.ruиns2.reg.ru→ добавьте A-запись вручную в личном кабинете:- Кликните по имени домена
- Перейдите на вкладку «Управление» → «DNS-серверы и зона»
- Нажмите «Добавить запись», выберите тип A
- Заполните поля:
subdomain— имя поддомена, IP-адрес вашего хостинга - Подождите 15 минут для обновления зоны
- Если используются другие DNS-серверы → обновление может занять до 24 часов
Универсальная схема для любого хостинга
Если DNS-серверы вашего регистратора домена:
- Войдите в панель управления доменом у регистратора
- Перейдите в раздел «DNS-записи» или «Управление зоной»
- Добавьте A-запись:
- Имя/Host:
имя_поддомена(например,blog) - Тип:
A - Значение/Value: IP-адрес вашего сервера
- TTL: 3600 (по умолчанию)
- Имя/Host:
- Сохраните изменения
Если DNS-серверы вашего хостинга:
- Войдите в панель управления хостингом
- Найдите раздел «Поддомены» или «Домены»
- Создайте поддомен через интерфейс (обычно достаточно указать имя)
- Хостинг автоматически создаст нужные DNS-записи
Привязка к папке на сервере:
- В панели хостинга укажите корневую директорию для поддомена
- Обычно путь:
/home/username/subdomain.site.ru/public_html/или/var/www/subdomain/ - Загрузите файлы сайта в эту директорию через FTP или файловый менеджер
Проверка доступности:
- Используйте сервисы проверки DNS (например,
whatsmydns.net) - Выполните команду
ping subdomain.site.ruв терминале - Откройте поддомен в браузере после распространения записей
Влияет ли поддомен на траст и вес основного домена
Влияние поддомена на траст основного домена обычно одностороннее: авторитет главного сайта помогает поддомену, но проблемы на поддомене редко способны сильно навредить основному ресурсу. Поисковые системы могут передавать часть общего веса и показателей доверия, например ИКС, на новые поддомены, особенно если тематики ресурсов схожи. При этом поддомен часто воспринимается как самостоятельный сайт, поэтому санкции или технические ошибки на нем обычно не переносятся напрямую на главный домен.
Как основной домен влияет на поддомен:
- наследование метрик: поисковые системы, особенно Яндекс, могут передавать часть общего веса и показателей доверия на новые поддомены;
- быстрый старт: сайт на поддомене начинает продвигаться не с «нуля», так как поисковики уже знают основной домен и его историю;
- передача веса: ссылки и авторитет главного сайта облегчают индексацию и ранжирование страниц на поддомене, если тематики ресурсов схожи.
Как поддомен влияет на основной домен:
- автономность: поисковые системы в большинстве случаев воспринимают поддомен как отдельный сайт; если на поддомене упал трафик, допущены технические ошибки или наложены санкции, на главный домен это напрямую не переносится;
- косвенные риски: серьезный вред возможен только при грубых нарушениях, например если создать сеть поддоменов-спамопомоек с запрещенным контентом или если пользователи начнут массово оставлять негативные отзывы на бренд из-за низкого качества услуг на поддомене;
- риск каннибализации: дублирование контента, пересечение смыслов или конфликт брендовых запросов между основным сайтом и поддоменом может ухудшить общую видимость страниц в поиске.
Настройка Wildcard SSL для поддоменов
Wildcard SSL — это один сертификат, который защищает основной домен и все поддомены первого уровня, например *.site.ru. Он упрощает поддержку, потому что не нужно выпускать отдельный сертификат для каждого поддомена. Сертификат должен быть установлен на сервере, который обслуживает поддомены, и покрывать нужную маску домена.
Особенности Wildcard-сертификатов
Что защищает Wildcard:
*.site.ru— все поддомены первого уровня:blog.site.ru,shop.site.ru,api.site.ru- Автоматически добавляемые поддомены (новые поддомены получают защиту без перевыпуска сертификата)
Что НЕ защищает Wildcard:
- Основной домен
site.ru(нужен отдельный сертификат или SAN-расширение) - Поддомены второго уровня:
*.sub.site.ru(требуется отдельный Wildcard) - Несколько разных доменов:
*.site.comи*.site.ru(нужен Multi-Domain Wildcard)
Важно: Wildcard-сертификат *.site.ru защищает blog.site.ru, но не site.ru. Для полного покрытия нужно выпустить два сертификата или использовать SAN (Subject Alternative Name).
Бесплатный Wildcard через Let’s Encrypt
Let’s Encrypt выпускает бесплатные Wildcard-сертификаты, но с обязательным условием — DNS-01 challenge (подтверждение через TXT-запись в DNS).
Пошаговая инструкция через acme.sh (рекомендуемый способ)
Шаг 1: Установка acme.sh на сервер
curl https://get.acme.sh | shШаг 2: Запрос Wildcard-сертификата
cd .acme.sh
./acme.sh --issue -d *.site.ru --dnsШаг 3: Добавление TXT-записи в DNS
acme.sh выведет сообщение вида:
Create DNS TXT record:
_acme-challenge.site.ru TXT "Q1b4d3J9BwRqQ-Z3qlu6soL4YuF9BG1Y212QI3ie3K4"Зайдите в панель управления доменом и добавьте:
- Тип записи:
TXT - Хост/Имя:
_acme-challenge - Значение: скопированная строка из acme.sh
- TTL: 300 секунд (5 минут)
Шаг 4: Подтверждение и выпуск
После добавления TXT-записи подождите 2–5 минут и выполните:
./acme.sh --renew -d *.site.ruШаг 5: Выпуск сертификата для основного домена
Wildcard не покрывает site.ru, поэтому нужен отдельный сертификат:
./acme.sh --issue -d site.ru --dnsИли выпустите сразу два одной командой:
./acme.sh --issue -d *.site.ru -d site.ru --dnsШаг 6: Установка на веб-сервер
Скопируйте файлы сертификата в нужную директорию:
./acme.sh --install-cert -d *.site.ru \
--cert-file /etc/ssl/site.ru.cer \
--key-file /etc/ssl/site.ru.key \
--fullchain-file /etc/ssl/fullchain.cerПример конфигурации Nginx:
server {
listen 443 ssl;
ssl_certificate /etc/ssl/fullchain.cer;
ssl_certificate_key /etc/ssl/site.ru.key;
server_name *.site.ru;
location / {
root /var/www/html;
index index.html;
}
}Автоматическое продление
Let’s Encrypt сертификаты действуют 90 дней. Настройте cron для автоматического продления:
# Добавьте в crontab
0 0 * * * /root/.acme.sh/acme.sh --cron --home /root/.acme.sh > /dev/nullПошаговые инструкции для популярных хостингов
Timeweb Cloud (через ispmanager)
Автоматический способ (через панель):
- Войдите в панель ispmanager под пользователем с правами SSL
- Перейдите в раздел «SSL-сертификаты» → «Добавить сертификат» → «Let’s Encrypt»
- Отметьте пункт «Wildcard сертификат» и выберите домен
- Нажмите «Выпустить»
- Дождитесь уведомления о необходимости добавить TXT-записи (до 10 минут)
- Скопируйте записи вида:
_acme-challenge.site.ru. TXT "KoZ26MJmum64Wevjg-xh23pqymt5W7sN-xGF0BXdo4g"- Добавьте TXT-записи в панели Timeweb Cloud:
- Раздел «Домены и SSL» → кликните на шестеренку у домена
- «Добавить запись» → тип
TXT - Хост:
_acme-challenge(вручную) - Значение: из уведомления ispmanager
- Подождите проверки (панель проверяет каждые 30 минут, до 40 минут)
- После успешной проверки сертификат выпустится и будет продлеваться автоматически
Ручной способ (через SSH):
certbot certonly --agree-tos --manual --preferred-challenges dns \
--server https://acme-v02.api.letsencrypt.org/directory \
-d *.site.ru -d site.ruСледуйте инструкциям certbot и добавьте TXT-записи в DNS.
Важно: Если домен на собственных NS-серверах на том же сервере, автоматическое продление работать не будет.
Beget
Пошаговая инструкция:
- Перейдите в раздел «Домены и поддомены»
- Нажмите на иконку «SSL» напротив нужного домена
- Выберите «Wildcard-поддомен»
- Нажмите «Установить»
- Дождитесь письма на email о подаче заявки
- Получите второе письмо с подтверждением установки
Особенности Beget:
- Стандартный сертификат защищает домен и до 39 поддоменов
- Wildcard подходит для сайтов с большим количеством поддоменов
- Если домен на DNS Beget, A-запись изменится автоматически
- Если используете сторонние DNS, нужно вручную прописать IP-адрес из письма
Для VPS (ручная установка):
# Установка acme.sh
curl https://get.acme.sh | sh
# Выпуск сертификата
./acme.sh --issue -d *.site.ru --dns dns_begetReg.ru
Пошаговая инструкция:
Этап 1: Генерация CSR-запроса
- В личном кабинете перейдите в раздел «SSL-сертификаты»
- Выберите тип сертификата: Wildcard SSL
- Сгенерируйте CSR-запрос (Certificate Signing Request)
- Укажите домен в формате
*.site.ru
Этап 2: Подтверждение владения доменом
Для Wildcard-сертификатов доступно только подтверждение через DNS:
- Добавьте TXT-запись в DNS:
- Имя:
_acme-challenge.site.ru - Значение: код из инструкции Reg.ru
- Имя:
- Дождитесь обновления DNS (до 24 часов)
Этап 3: Установка сертификата
- Получите файлы сертификата на email (после выпуска)
- В личном кабинете перейдите в карточку хостинга
- На вкладке «Операции» нажмите «Установить SSL-сертификат»
- Загрузите файлы:
- Сертификат (
.crtили.cer) - Приватный ключ (
.key) - Цепочка сертификатов (
.ca-bundle)
- Сертификат (
Для Let’s Encrypt через ispmanager:
- В разделе «Сайты» выберите домен и нажмите «Изменить»
- В открывшемся окне выберите «Let’s Encrypt»
- Отметьте «Wildcard сертификат»
- Следуйте инструкциям по добавлению TXT-записей
Сравнение методов выпуска Wildcard
| Метод | Стоимость | Сложность | Автоматическое продление | Срок действия |
|---|---|---|---|---|
| Let’s Encrypt + acme.sh | Бесплатно | Средняя | Да (cron) | 90 дней |
| Let’s Encrypt через панель хостинга | Бесплатно | Низкая | Да | 90 дней |
| Платный Wildcard (Reg.ru и т.д.) | от 5 000 ₽/год | Низкая | Нет (ручное продление) | 1 год |
| Certbot CLI | Бесплатно | Высокая | Да | 90 дней |
Типичные ошибки и их решение
Ошибка: DNS-01 challenge не проходит
- Проверьте, что TXT-запись добавилась корректно:
dig TXT _acme-challenge.site.ru - Уменьшите TTL до 300 секунд и подождите 5–10 минут
- Убедитесь, что домен делегирован на правильные NS-серверы
Ошибка: Wildcard не защищает основной домен
- Это нормальное поведение:
*.site.ruне включаетsite.ru - Выпустите отдельный сертификат для основного домена или используйте SAN
Ошибка: Сертификат не продлевается автоматически
- Проверьте cron-задачу:
crontab -l - Убедитесь, что acme.sh имеет права на запись в директорию сертификатов
- Проверьте логи:
/root/.acme.sh/acme.sh.log
Ошибка: Браузер показывает предупреждение о безопасности
- Убедитесь, что установлена полная цепочка сертификатов (fullchain)
- Проверьте конфигурацию веб-сервера:
ssl_certificateдолжен указывать на fullchain, а не на отдельный сертификат
Рекомендации по использованию
- Для тестовых проектов и небольших сайтов используйте бесплатный Let’s Encrypt через acme.sh
- Для коммерческих проектов с критичной доступностью рассмотрите платные Wildcard-сертификаты с поддержкой и гарантией
- Настройте мониторинг истечения сертификатов (например, через UptimeRobot или Checkmk)
- Используйте автоматизацию через Ansible или Terraform для управления сертификатами на нескольких серверах
- Документируйте процесс выпуска и продления для команды
Уязвимость Subdomain Takeover и как от нее защититься
Subdomain Takeover — это перехват поддомена злоумышленником, когда DNS-запись поддомена все еще указывает на внешний сервис, а сам ресурс в этом сервисе удален или доступен для регистрации. Основная причина — неиспользуемые или старые DNS-записи, которые не удалили после отключения сервиса. Защита состоит в регулярной инвентаризации DNS-записей и удалении нерабочих ссылок.
Сколько стоит создание поддоменов и ограничения хостингов
Создание поддомена обычно не требует отдельной регистрации: поддомены создаются в рамках уже зарегистрированного домена и чаще всего бесплатны в панели хостинга. Ограничения связаны не с самим фактом создания, а с тарифом хостинга, панелью управления и возможностями сервера.
Стоимость создания поддоменов
В большинстве случаев создание поддоменов бесплатно. Поддомен — это не отдельное доменное имя, а запись в DNS существующего домена, поэтому регистраторы и хостинг-провайдеры не взимают плату за их создание.
| Операция | Стоимость | Комментарий |
|---|---|---|
| Создание поддомена | Бесплатно | Поддомен создается в рамках существующего домена без дополнительной регистрации |
| Регистрация основного домена | от 199 ₽/год | Нужен зарегистрированный домен, в рамках которого создаются поддомены |
| Продление домена | от 199 ₽/год | Ежегодная плата за основной домен (поддомены не требуют отдельного продления) |
| Хостинг для поддомена | от 0 ₽/мес | Зависит от тарифа хостинга и количества сайтов/поддоменов |
| SSL-сертификат для поддомена | Бесплатно (Let’s Encrypt) | Бесплатные сертификаты доступны на большинстве хостингов |
Ограничения хостингов по количеству поддоменов
Ограничения зависят от тарифного плана хостинга и используемой панели управления. Ниже приведены данные по популярным российским хостингам.
Reg.ru
Количество поддоменов не ограничено на всех тарифных планах, включая бесплатный хостинг для HTML-сайтов.
Важный нюанс:
- Если на хостинге установлена панель ispmanager и вы добавляете поддомен как самостоятельный домен в разделе «Сайты», он будет считаться отдельным сайтом и учитываться в ограничениях тарифного плана.
- Чтобы избежать ограничений, используйте функцию «Автоподдомены» — автоподдомены можно добавлять в неограниченном количестве.
Два способа создания поддомена на Reg.ru:
- Как самостоятельный домен — поддомен не зависит от основного домена и добавляется как отдельный сайт (количество возможных доменов зависит от тарифа).
- Как автоподдомен — функция «Автоподдомен» позволяет автоматически создавать поддомены для основного домена в неограниченном количестве. Удобно, если нужно добавить много поддоменов или по тарифу уже добавлено максимальное количество доменов.
Обратите внимание: некоторые CMS (например, 1С-Битрикс) некорректно работают с автоподдоменами.
Timeweb
Количество поддоменов ограничено тарифом хостинга.
Общая информация:
- Поддомены создаются в разделе «Домены и SSL» → «Поддомены»
- Каждому поддомену можно присвоить отдельный регион для SEO
- Для каждого поддомена можно выпустить отдельный SSL-сертификат (или использовать Wildcard)
Beget
Количество поддоменов зависит от тарифа.
Общая информация:
- Поддомены создаются в разделе «Домены и поддомены»
- Можно создать wildcard-поддомен (например,
*.site.ru) для автоматического создания всех поддоменов - Стандартный SSL-сертификат защищает домен и до 39 поддоменов
- Wildcard SSL подходит для сайтов с большим количеством поддоменов
Как закрыть поддомен от индексации через robots.txt
Поддомен имеет собственный файл robots.txt в корне, поэтому закрыть его от индексации можно, создав отдельный robots.txt именно на поддомене. Для полного запрета индексирования используют правило:
User-agent: *
Disallow: /Важно: Запрет в robots.txt не гарантирует полного удаления страниц из поискового индекса. Если на страницы поддомена есть внешние ссылки, они могут остаться в выдаче без описания и контента. Для надежного закрытия используйте комбинацию методов.
Особенности обработки Яндекс и Гуглом
| Параметр | Яндекс | |
|---|---|---|
| Обработка robots.txt | Соблюдает директивы Disallow, но может индексировать страницы, если на них есть внешние ссылки | Соблюдает директивы Disallow, но страницы могут попадать в индекс без контента при наличии внешних ссылок |
| Отдельный файл для поддомена | Да, каждый поддомен требует отдельного файла в корне | Да, каждый поддомен требует отдельного файла в корне |
| Crawl-delay | Поддерживает (указывается в секундах) | Не поддерживает с 2019 года |
| Удаление из индекса | Через Яндекс.Вебмастер (инструмент «Удаление страниц») или мета-тег noindex | Через Google Search Console (инструмент «Удаление контента») или мета-тег noindex |
| Проверка файла | Яндекс.Вебмастер → «Настройки индексирования» → «Файлы robots.txt» | Google Search Console → «Настройки» → «Файл robots.txt» |
| Скорость применения | От нескольких дней до 2-4 недель | От нескольких часов до 2-3 недель |
Почему robots.txt недостаточно для полного закрытия
Файл robots.txt запрещает сканирование, но не индексирование. Это означает:
- Поисковый робот не будет заходить на страницы поддомена и сканировать их контент
- Если на страницы поддомена есть внешние ссылки с других сайтов, поисковик может добавить их в индекс без контента (только URL)
- В выдаче такие страницы отображаются с пометкой «Описание недоступно» или без сниппета
Пример: Если вы закрыли поддомен test.site.ru через robots.txt, но на странице test.site.ru/promo есть ссылка с внешнего форума, эта страница может появиться в поиске с текстом «Описание недоступно из-за файла robots.txt».
Надежные способы закрытия поддомена от индексации
Способ 1: Комбинация robots.txt + мета-тег noindex (рекомендуемый)
Шаг 1: Создайте файл robots.txt в корне поддомена:
User-agent: *
Disallow: /Шаг 2: Добавьте мета-тег на все страницы поддомена:
<meta name="robots" content="noindex, nofollow">Важно: Если страницы закрыты в robots.txt, поисковый робот не увидит мета-тег noindex, потому что не сможет зайти на страницу. Поэтому для надежного закрытия нужно:
- Сначала убрать запрет из
robots.txt(разрешить сканирование) - Дождаться, пока робот проиндексирует страницы и увидит мета-тег
noindex - После удаления из индекса можно вернуть запрет в
robots.txt
Альтернатива: Используйте HTTP-заголовок вместо мета-тега:
X-Robots-Tag: noindex, nofollowНастройка в Nginx:
server {
server_name test.site.ru;
location / {
add_header X-Robots-Tag "noindex, nofollow";
}
}Настройка в Apache (.htaccess):
<IfModule mod_headers.c>
Header set X-Robots-Tag "noindex, nofollow"
</IfModule>Способ 2: Защита паролем (базовая аутентификация)
Если поддомен не должен быть доступен никому, кроме разработчиков, используйте HTTP Basic Authentication:
В Nginx:
server {
server_name test.site.ru;
location / {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}В Apache (.htaccess):
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/.htpasswd
Require valid-userПоисковые роботы не смогут пройти аутентификацию и не будут индексировать поддомен.
Способ 3: Закрытие через конфигурацию сервера (403 Forbidden)
Если поддомен вообще не должен отвечать на запросы:
В Nginx:
server {
server_name test.site.ru;
location / {
return 403;
}
}В Apache:
<VirtualHost *:80>
ServerName test.site.ru
<Directory /var/www/test>
Require all denied
</Directory>
</VirtualHost>Дополнительные инструменты вебмастера
Яндекс.Вебмастер
Для полного контроля над индексацией поддомена в Яндексе:
- Добавьте поддомен как отдельный сайт в Яндекс.Вебмастер:
- Перейдите на webmaster.yandex.ru
- Нажмите «Добавить сайт»
- Укажите адрес поддомена, например
test.site.ru - Подтвердите права на поддомен (через мета-тег, TXT-запись или файл)
- Проверьте файл robots.txt:
- Раздел «Настройки индексирования» → «Файлы robots.txt»
- Убедитесь, что Яндекс видит правильный файл для поддомена
- Запросите удаление страниц из поиска:
- Раздел «Индексирование» → «Удаление страниц»
- Введите адреса страниц поддомена, которые нужно удалить
- Дождитесь обработки запроса (обычно 1-3 дня)
- Проверьте статус индексации:
- Раздел «Индексирование» → «Страницы в поиске»
- Убедитесь, что страницы поддомена исключены из индекса
Google Search Console
Для контроля индексации поддомена в Google:
- Добавьте поддомен как отдельный ресурс в Google Search Console:
- Перейдите на search.google.com/search-console
- Выберите тип «Домен» и укажите поддомен, например
test.site.ru - Подтвердите права через DNS-запись (TXT)
- Проверьте файл robots.txt:
- Раздел «Настройки» → «Файл robots.txt»
- Убедитесь, что Google видит правильный файл для поддомена
- Используйте инструмент «Удаление контента»:
- Раздел «Индексирование» → «Удаление контента»
- Выберите «Временное удаление» для быстрого исключения из поиска (на 6 месяцев)
- Для постоянного удаления используйте мета-тег
noindex
- Проверьте индексацию страницы:
- Введите URL поддомена в строку поиска в Search Console
- Нажмите «Проверить индексирование»
- Убедитесь, что страница не проиндексирована
Пошаговая инструкция: закрытие поддомена от индексации
Сценарий: У вас есть тестовый поддомен test.site.ru, который нужно полностью исключить из поиска Яндекс и Гугл.
Шаг 1: Разрешите сканирование (временно)
Удалите или закомментируйте запрет в robots.txt поддомена:
# User-agent: *
# Disallow: /Шаг 2: Добавьте мета-тег noindex на все страницы
В шаблоне сайта на поддомене добавьте в секцию <head>:
<meta name="robots" content="noindex, nofollow">Или настройте заголовок X-Robots-Tag на сервере (см. выше).
Шаг 3: Дождитесь сканирования
Подождите 3-7 дней, пока роботы Яндекс и Гугл просканируют страницы и увидят мета-тег.
Шаг 4: Проверьте удаление из индекса
Используйте операторы поиска:
site:test.site.ruЕсли страницы еще в индексе, запросите удаление через вебмастер:
- Яндекс: «Индексирование» → «Удаление страниц»
- Гугл: «Индексирование» → «Удаление контента»
Шаг 5: Верните запрет в robots.txt
После удаления из индекса можно снова закрыть поддомен от сканирования:
User-agent: *
Disallow: /Шаг 6: Мониторинг
Периодически проверяйте, не появились ли страницы поддомена в индексе снова:
site:test.site.ruЧастые ошибки при закрытии поддомена
| Ошибка | Причина | Решение |
|---|---|---|
| Файл размещен в корне основного домена | robots.txt создан для site.ru, а не для test.site.ru | Создайте отдельный файл в корневой директории поддомена |
| Страницы остаются в индексе | На страницы есть внешние ссылки, и поисковик индексирует их без контента | Используйте мета-тег noindex или запросите удаление через вебмастер |
| Мета-тег не работает | Страницы закрыты в robots.txt, и робот не видит мета-тег | Временно разрешите сканирование, дождитесь обработки мета-тега, затем верните запрет |
| Поддомен не добавлен в вебмастер | Инструменты удаления работают только для подтвержденных сайтов | Добавьте поддомен как отдельный сайт в Яндекс.Вебмастер и Google Search Console |
| Использован только Disallow без noindex | Disallow запрещает сканирование, но не индексирование | Комбинируйте Disallow с мета-тегом noindex или заголовком X-Robots-Tag |
| Забыли удалить запрет после тестирования | Поддомен закрыт от индексации, хотя должен быть доступен | Проверьте robots.txt после завершения работ |
Альтернативные методы закрытия поддомена
Если вам нужно закрыть поддомен не от индексации, а от доступа пользователей, используйте:
1. Защита паролем (базовая аутентификация)
Подходит для тестовых и внутренних поддоменов. Поисковые роботы не смогут пройти аутентификацию.
2. Ограничение по IP
Разрешите доступ только с определенных IP-адресов (офис, разработчики):
# Nginx
allow 192.168.1.0/24;
deny all;3. Закрытие через 403 или 404
Верните ошибку «Доступ запрещен» или «Не найдено» для всех запросов к поддомену.
4. Удаление DNS-записи
Если поддомен больше не нужен, удалите A-запись или CNAME в панели управления доменом. Поддомен перестанет отвечать на запросы.
Итоговая таблица методов закрытия
| Метод | Запрещает сканирование | Удаляет из индекса | Скрывает контент от пользователей | Сложность |
|---|---|---|---|---|
| robots.txt (Disallow) | Да | Нет (только если нет внешних ссылок) | Нет | Низкая |
| Мета-тег noindex | Нет | Да | Нет | Низкая |
| X-Robots-Tag | Нет | Да | Нет | Средняя |
| Защита паролем | Да | Да | Да | Средняя |
| Ограничение по IP | Да | Да | Да | Средняя |
| Удаление через вебмастер | Нет | Да (временно или постоянно) | Нет | Низкая |
| Удаление DNS-записи | Да | Да (постепенно) | Да | Низкая |
Рекомендации
- Для временного закрытия (тестовый поддомен, разработка): используйте защиту паролем или ограничение по IP.
- Для постоянного закрытия (архивный поддомен, старый проект): используйте комбинацию
noindex+ удаление через вебмастер +Disallowвrobots.txt. - Если поддомен больше не нужен: удалите DNS-запись и файлы с сервера. Это самый надежный способ.
- Не полагайтесь только на
robots.txt, если нужно гарантированное удаление из поиска. - Добавьте поддомен в вебмастер перед закрытием, чтобы иметь доступ к инструментам удаления и мониторинга.
Поддомен для мобильной версии сайта (m.site.ru)
Поддомен вида m.site.ru используется для отдельной мобильной версии сайта, когда мобильный контент и дизайн отличаются от десктопной версии. Эта архитектура называется Separate URLs (раздельные URL). Чтобы поисковики корректно понимали, что это версии одного и того же сайта, а не дубли, нужно связывать их специальными тегами, редиректами и HTTP-заголовками.
Сейчас Google и Яндекс настоятельно рекомендуют использовать адаптивный дизайн (Responsive Web Design) вместо отдельного мобильного поддомена. Однако если поддомен m. уже существует и используется, важно строго соблюдать официальные рекомендации поисковых систем, чтобы избежать потери трафика и склейки страниц.
Официальные рекомендации Google (Separate URLs)
Google рассматривает десктопную и мобильную версии на разных URL как две отдельные страницы с одинаковым содержанием. Чтобы избежать проблем с дублями и правильно передать вес, необходимо выполнить следующие настройки:
1. Связывание страниц через теги (Annotations)
Это самое важное требование. На каждой десктопной странице должен быть указан её мобильный аналог, и наоборот.
В коде десктопной страницы (site.ru/page) добавьте в секцию <head>:
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.site.ru/page">В коде мобильной страницы (m.site.ru/page) добавьте в секцию <head>:
<link rel="canonical" href="https://site.ru/page">2. HTTP-заголовок Vary
Если ваш сервер автоматически делает редирект пользователей с десктопной версии на мобильную на основе определения устройства (User-Agent), сервер должен отдавать HTTP-заголовок:
Vary: User-AgentЭто указывает кэширующим провайдерам и поисковым роботам, что контент страницы зависит от типа устройства.
3. Избегание ошибочных редиректов (Faulty Redirects)
Google строго наказывает за некорректные редиректы. Типичные ошибки:
- Редирект на главную: Если пользователь заходит со смартфона на внутреннюю страницу
site.ru/blog/article, его нельзя перенаправлять на главнуюm.site.ru. Редирект должен вести на соответствующую мобильную страницуm.site.ru/blog/article. - Отсутствие ссылки на полную версию: На мобильной версии обязательно должна быть кликабельная ссылка «Полная версия сайта», которая переопределяет автоматический редирект (обычно через сохранение cookie).
Официальные рекомендации Яндекса
Яндекс придерживается похожей логики, но имеет свои нюансы в инструментах вебмастера и обработке роботов.
1. Настройка тегов canonical и alternate
Яндекс использует те же теги rel="canonical" и rel="alternate" для склейки десктопной и мобильной версий. Мобильная версия должна указывать на десктопную как на первоисточник (canonical).
2. Настройка robots.txt
У мобильного поддомена должен быть свой собственный файл robots.txt в корне (m.site.ru/robots.txt). Важно не блокировать мобильного робота Яндекса:
- Убедитесь, что в
robots.txtмобильной версии нет запрета дляYandexMobileBot. - Основной робот
YandexBotтакже должен иметь доступ к мобильной версии, но благодаря тегуcanonicalон поймет, что индексировать нужно десктопную.
3. Добавление в Яндекс.Вебмастер
Мобильный поддомен нужно добавить в Яндекс.Вебмастер как отдельный сайт и подтвердить на него права. Это позволит отслеживать индексацию мобильной версии отдельно и видеть специфические ошибки (например, проблемы с мобильной удобностью).
4. Требования к контенту
Яндекс допускает, что мобильная версия может быть технически упрощена (меньше тяжелых скриптов, урезанный дизайн), но основной текст, цены, ассортимент и смысл страницы должны совпадать с десктопной версией. Если мобильная версия содержит значительно меньше полезного контента, это может негативно сказаться на ранжировании в мобильной выдаче.
5. Обработка редиректов
Яндекс корректно распознает стандартные HTTP-редиректы (301, 302), выполненные на основе User-Agent. Использование 302 (временного) редиректа для перенаправления мобильных пользователей является допустимой и стандартной практикой.
Mobile-First Indexing: почему поддомен m. устаревает
Начиная с 2018–2019 годов, Google полностью перешел на Mobile-First Indexing. Это означает, что поисковый робот теперь в первую очередь сканирует и оценивает именно мобильную версию сайта для формирования позиций в выдаче (как для мобильных, так и для десктопных пользователей).
Проблемы использования m.site.ru в современных реалиях:
- Двойные затраты на разработку и поддержку: Любое изменение в дизайне или функционале нужно вносить в две разные кодовые базы.
- SEO-риски: Ошибка в тегах
canonical/alternateили неправильный редирект моментально приводит к выпадению страниц из индекса или склейке с другими страницами. - Разделение поведенческих факторов: Хотя поисковики пытаются склеить поведенческие метрики, на практике часть пользователей уходит с неудобной мобильной версии, что может косвенно влиять на общие показатели.
- Сложности с аналитикой: Требуется настройка кросс-доменного отслеживания в GA4 и Яндекс.Метрике.
Официальная позиция поисковиков: Google и Яндекс рекомендуют использовать адаптивный дизайн (Responsive Web Design), когда и десктопная, и мобильная версии доступны по одному и тому же URL (site.ru/page), а изменение верстки происходит динамически через CSS (media queries). Это полностью исключает проблемы с дублями, редиректами и тегами.
Что делать, если мобильный поддомен уже работает?
Если ваш сайт исторически работает на архитектуре Separate URLs и приносит стабильный трафик, срочного переезда на адаптив не требуется, при условии идеальной технической настройки:
- Регулярно проверяйте наличие парных тегов
canonicalиalternateна всех страницах обеих версий. - Используйте инструменты проверки мобильной удобности в Google Search Console и Яндекс.Вебмастере.
- Проверяйте сайт на наличие «ошибочных редиректов» (Faulty Redirects).
- Убедитесь, что мобильная версия не отдает 404 ошибки для страниц, которые существуют на десктопе.
Если же вы планируете редизайн или глобальное обновление сайта, лучшим решением будет отказ от поддомена m.site.ru в пользу адаптивной верстки на основном домене с настройкой 301-редиректов со всех старых мобильных URL на соответствующие десктопные.
