Если один и тот же сайт открывается на site.ru и site.com с одинаковым содержимым и кодом 200, поисковая система получает два набора URL. Ей приходится решать, какие страницы считать основными, какие — дублями и какой домен показывать в поиске.
Сама схема «разные домены — один сайт» не является автоматической санкцией. Риск возникает, когда у проекта нет явно выбранного главного адреса, технические сигналы противоречат друг другу или staging-копия случайно становится доступна для индексирования.
Разные домены — один сайт: что видит поисковик
Для сервера два домена могут вести в одну директорию и отдавать те же файлы. Для поисковой системы https://site.ru/catalog/ и https://site.com/catalog/ — разные URL. Если основной контент совпадает, Google может объединить такие страницы в группу дублей и выбрать каноническую версию. Само наличие дублей Google не считает нарушением.
Проблема для владельца сайта — потеря контроля над выбором адреса. Если оба домена отвечают 200, встречаются во внутренних ссылках, попадают в sitemap и имеют противоречивые canonical, поисковику приходится самостоятельно определять предпочтительную версию.
| Сценарий | Что лучше сделать | Почему |
|---|---|---|
| Второй домен для защиты бренда | Постоянный редирект на основной | Пользователь и робот всегда приходят к одному адресу |
| Переезд на новый домен | Постраничная карта URL + постоянные редиректы | Сохраняется соответствие старых и новых страниц |
| Отдельные региональные версии | Оставлять только при реальных различиях и корректной региональной логике | Это уже отдельная архитектура, а не технический дубль |
| Staging-домен | Закрыть авторизацией или другим ограничением | Техническая копия не должна участвовать в поиске |
Google относит редиректы и rel="canonical" к сильным сигналам каноникализации, а sitemap — к более слабому. Но cross-domain canonical не стоит считать универсальной заменой редиректу: Яндекс указывает, что canonical на другой домен или поддомен может не учитываться. Если второй домен не должен жить как самостоятельный сайт, редирект надёжнее и понятнее обеим поисковым системам.
Где SEO-риски возникают на практике
Типичная ошибка — подключить новый домен как alias к тому же virtual host и остановиться на этом. В браузере всё работает, но каждая страница становится доступна в двух версиях.
Дальше обычно появляются такие проблемы:
- sitemap содержит один домен, а внутренние ссылки частично ведут на другой;
- canonical строится из текущего
Hostи на каждом домене указывает сам на себя; - внешние ссылки приходят на обе версии;
- Search Console, Вебмастер и аналитика показывают разные наборы URL;
- после изменений трудно понять, какой адрес поисковая система считает главным.
Корректнее говорить не о «штрафе за два домена», а о дублях, каноникализации и расходящихся технических сигналах. Яндекс рассматривает разные адреса сайта как отдельные сущности и при переезде рекомендует перенаправлять старые страницы на соответствующие новые.
Staging-сайт и SEO: отдельный риск
Тестовая копия часто создаётся из production-базы вместе с реальными title, canonical, текстами и sitemap. Google прямо приводит случайно доступную demo-версию сайта как пример источника дублей.
Для staging лучше не рассчитывать только на robots.txt. Если копия не должна быть доступна поисковым роботам и посторонним пользователям, надёжнее HTTP-аутентификация, VPN или ограничение по IP. Если страница остаётся публичной, но не должна попадать в Google, используется noindex; при этом робот должен загрузить страницу и увидеть директиву. Поэтому сочетание «запретить обход в robots.txt и поставить noindex» для Google ненадёжно.
Как проверить текущую конфигурацию
Возьмите главную страницу и несколько внутренних URL разных типов: услугу, статью, категорию, карточку товара. Для каждого проверьте оба домена.
Для резервного домена нормальная картина выглядит так: любой дополнительный URL получает постоянный редирект сразу на эквивалентную страницу основного домена, без перехода через главную и без длинной цепочки.
Проверьте четыре уровня:
- HTTP-ответ: дополнительный домен не должен отдавать копию страницы с
200, если он не предназначен для самостоятельной индексации. - Canonical: на основном домене страницы должны ссылаться на корректные канонические URL без смешения хостов.
- Внутренние сигналы: меню, хлебные крошки, sitemap, hreflang и абсолютные ссылки используют выбранный домен.
- Поисковые панели: в Search Console и Яндекс Вебмастере видно, какие версии URL обнаружены и какие адреса считаются основными.
Если меняется сам домен проекта, это уже миграция. Google рекомендует сопоставить старые URL с новыми, настроить серверные постоянные редиректы, обновить внутренние ссылки и sitemap, а затем контролировать обе версии сайта. Для смены домена используется Change of Address в Search Console; в Яндекс Вебмастере — «Переезд сайта».
Если новый адрес куплен на вторичном рынке, до переноса полезно отдельно проверить как история домена влияет на SEO. Так проще не смешивать последствия миграции с проблемами, которые могли существовать у адреса раньше.
Как исправить два домена без лишней перестройки
Если бизнесу не нужны два самостоятельных сайта, выберите один главный домен. Критерии: бренд, уже накопленный поиск и ссылки, узнаваемость, история использования, юридическая или региональная задача. Не стоит менять основной адрес только потому, что новый домен короче.
После выбора логика должна быть однозначной: дополнительный URL ведёт на соответствующий URL основного домена, а основной отвечает 200. Не перенаправляйте все внутренние страницы второго домена на главную — при миграции это разрушает соответствие страниц.
После переключения проверьте:
- в sitemap присутствуют только канонические URL;
- внутренние ссылки не возвращают на старый домен;
- canonical и hreflang не конфликтуют с редиректами;
- HTTPS работает на доменах, с которых выполняется редирект;
- нет цепочек
старый → промежуточный → основной.
При полноценном переезде возможны временные колебания видимости: Google предупреждает, что поисковику нужно переобойти и переиндексировать URL. Это не означает обязательного падения, но миграцию нельзя планировать как мгновенную замену адреса.
Если проблема затрагивает десятки шаблонов, старые зеркала, sitemap и историю миграций, уместно SEO-продвижение сайта с техническим внедрением: здесь важны инвентаризация URL, устранение конфликтующих сигналов и контроль результата после переобхода.
Практический сценарий: брендовый домен и основной сайт
Компания работает на brand.ru, а затем регистрирует brand.com для защиты названия. Ошибка — направить оба домена на одну WordPress-установку и оставить их доступными с кодом 200.
Рабочая схема: brand.ru остаётся основным, а каждый URL на brand.com перенаправляется на страницу с тем же путём на brand.ru. В sitemap остаются только URL основного домена; внутренние ссылки и canonical также используют brand.ru.
После изменения проверяются несколько шаблонов страниц и данные Search Console и Вебмастера. Успешный результат — дополнительный домен перестаёт существовать как отдельный набор индексируемых страниц, а пользователи и роботы всегда приходят на выбранный основной адрес.
Что делать на практике
Если два домена показывают один сайт, сначала решите, оба ли адреса действительно должны самостоятельно участвовать в поиске. В брендовых, резервных и миграционных сценариях чаще всего ответ — нет.
Тогда задача сводится к выбору одного главного адреса и согласованию всех сигналов вокруг него: HTTP-редиректов, canonical, внутренних ссылок, sitemap и поисковых панелей. Staging при этом лучше вообще не оставлять публичной копией production-сайта.
FAQ
Как понять, какой домен должен остаться главным
Технически можно, но если оба домена отдают одинаковые страницы с 200, поисковым системам приходится выбирать основную версию URL. Для брендового, резервного или старого домена обычно лучше настроить перенаправление на один главный адрес. Сам факт дублей Google не относит автоматически к нарушениям.
Если второй домен больше не должен существовать как самостоятельный сайт, постоянный серверный редирект обычно однозначнее. Google считает и редирект, и rel="canonical" сильными сигналами каноникализации, но Яндекс указывает случаи, когда canonical на другой домен или поддомен может не учитываться. Поэтому cross-domain canonical не стоит использовать как универсальную замену переадресации.
Да, если это техническая копия production-сайта. Предпочтительно ограничить сам доступ — например, HTTP-аутентификацией, VPN или IP-фильтрацией. Для Google одного robots.txt недостаточно, если задача именно не допустить URL в индекс.
Да, временные колебания возможны, пока поисковая система переобходит старые и новые URL и обрабатывает перенаправления. Это не гарантированное падение, но миграцию нужно контролировать как отдельный процесс, а не считать завершённой сразу после изменения DNS или редиректов.
Нет. Старые URL следует сопоставлять с максимально соответствующими новыми страницами. Массовый редирект всех адресов на главную ухудшает пользовательский путь и теряет смысл исходных URL.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.
