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

Question

Accepted Answer

Сначала определите тип поддомена

Для SEO есть три принципиально разных сценария.

Тестовый, staging, dev, preview. Такой поддомен вообще не должен быть публично доступен поисковым роботам. Надёжный вариант — серверная авторизация, пароль или ограничение доступа. Google рекомендует парольную защиту для закрытого контента; Яндекс также допускает авторизацию и отдельно предупреждает, что одного robots.txt недостаточно, если URL уже известен поисковику.

Публичный, но не предназначенный для поиска. Например, служебный интерфейс или вспомогательный раздел, который должен открываться пользователям по прямой ссылке. Здесь используется noindex в HTML или X-Robots-Tag: noindex в HTTP-заголовке. При этом робот должен иметь возможность загрузить URL и увидеть запрет.

Публичный SEO-поддомен. Например, региональная или языковая версия, документация либо отдельный каталог. Его, наоборот, нужно открыть для сканирования и индексирования, настроить собственные Sitemap, canonical и внутренние ссылки.

Смешивать эти сценарии нельзя. Типичная авария выглядит так: тестовая копия сначала открыта, попадает в индекс, затем разработчик ставит Disallow: / и считает вопрос закрытым.

robots.txt основного домена не закрывает поддомен

https://example.com/robots.txt действует только для соответствующих хоста, протокола и порта. Он не распространяется на https://test.example.com/. Для поддомена нужен собственный файл https://test.example.com/robots.txt. Это прямо следует из текущей спецификации обработки robots.txt Google.

Более того, robots.txt управляет сканированием, а не гарантированным удалением URL из поиска. Google может знать и показывать URL, который запрещено сканировать, например если нашёл ссылку на него. Яндекс также прямо пишет, что закрытые через robots.txt страницы могут участвовать в поиске.

Поэтому схема:

User-agent: *
Disallow: /

подходит для ограничения обхода, но не является надёжным способом деиндексации уже известных URL.

Не ставьте одновременно Disallow и noindex для удаления страниц

Чтобы Google обработал:

Googlebot должен загрузить страницу. Если URL закрыт через robots.txt, робот не увидит noindex. В результате URL может продолжать фигурировать в поиске, хотя его содержимое Google уже не может загрузить.

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

разрешить роботу загрузку URL;
вернуть noindex;
проверить страницу через Search Console;
дождаться исключения URL из индекса;
только после этого при необходимости ограничивать дальнейший обход.

Для тестовой среды проще не собирать конструктор из нескольких директив, а сразу закрыть доступ авторизацией. Google отдельно рекомендует серверную защиту для staging-среды.

Не оставляйте копию основного сайта индексируемой

Если test.example.com/catalog/... полностью повторяет example.com/catalog/..., это не означает автоматический «штраф» для основного домена. Google обычно объединяет одинаковые или очень похожие страницы в группу дублей и выбирает канонический URL.

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

Если поддомен публичный и дублирование осознанное, задавайте согласованный rel="canonical". Если копия больше не нужна, предпочтительнее постоянный серверный редирект на эквивалентный рабочий URL. Google считает редирект и rel="canonical" сильными сигналами при выборе канонического адреса. Сам canonical при этом остаётся сигналом, а не безусловной директивой.

Проверьте DNS и конфигурацию виртуальных хостов

Отдельная проблема, которую часто не проверяют при запуске, — wildcard DNS вида *.example.com и сервер, который на любом неизвестном имени хоста отдаёт основной сайт с кодом 200.

Тогда abc.example.com, old.example.com, dev123.example.com и любой случайно обнаруженный hostname технически становятся дополнительными URL того же контента.

Это не отдельный «фактор Google», а архитектурная ошибка, создающая новые доступные копии страниц.

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

Сведите все URL-сигналы к одной логике

Для индексируемого поддомена проверьте:

rel="canonical" указывает на правильную версию страницы;
XML Sitemap содержит только URL, которые действительно должны индексироваться;
внутренние ссылки ведут на канонические URL;
hreflang, если он используется, содержит рабочие языковые или региональные версии.

Не должно быть ситуации, когда Sitemap содержит sub.example.com/page, canonical ведёт на example.com/page, а навигация продолжает ссылаться на третью версию. Google рекомендует согласовывать сигналы каноникализации и направлять внутренние ссылки на канонические URL.

Для HTTPS проверьте действительный сертификат именно на поддомен, редирект HTTP → HTTPS и отсутствие canonical обратно на HTTP. Google отдельно указывает, что некорректный TLS/SSL-сертификат и конфликт HTTPS/HTTP могут влиять на выбор канонической версии.

Добавьте поддомен в инструменты вебмастера

В Google Search Console удобно иметь Domain property для example.com: она агрегирует данные основного домена, всех поддоменов и протоколов. Для отдельной диагностики поддомена можно дополнительно создать URL-prefix property.

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

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

Чек-лист перед запуском

Определить, должен ли поддомен вообще индексироваться.
Проверить, нет ли открытой staging/dev-копии.
Проверить отдельный robots.txt именно на поддомене.
Исключить конфликт Disallow и noindex.
Проверить canonical, Sitemap и внутренние ссылки.
Убедиться, что wildcard DNS не создаёт доступные копии сайта.
Оставить один основной HTTPS-вариант и проверить сертификат.
Убрать тестовые URL из Sitemap, hreflang, меню, XML-фидов и шаблонов.
Добавить индексируемый поддомен в Search Console и Яндекс Вебмастер.
Проверить HTTP-ответы нескольких реальных и несуществующих URL поддомена.

Если поддомен уже «утёк» в Google, не ограничивайтесь Disallow: /. Для staging закройте доступ авторизацией; для публичных URL, которые нужно удалить из поиска, дайте роботу увидеть noindex; для устаревшей копии с прямым аналогом настройте постоянный редирект. Именно разделение доступа, сканирования, индексирования и каноникализации снимает основную часть технических рисков.