Сначала выясните, кто фактически отдаёт редирект: чужой сервер или ваш собственный сервер, на IP которого направлен неизвестный домен. До этой проверки удалять или блокировать что-либо преждевременно.
1. Проверьте, как именно работает редирект
Посмотрите HTTP-ответ неизвестного домена:
curl -I https://example.com/page
Для просмотра всей цепочки:
curl -IL https://example.com/page
Проверьте несколько внутренних URL, а не только главную страницу.
Нужно установить:
- какой код возвращается: 301, 302, 307, 308;
- куда указывает заголовок Location;
- сохраняется ли путь страницы;
- все ли URL перенаправляются одинаково;
- нет ли промежуточных доменов в цепочке.
Например, схема:
old-domain.ru/catalog/item → main-site.ru/catalog/item
похожа на обычный доменный переезд или зеркало.
Схема:
old-domain.ru/любой-url → main-site.ru/
может быть обычным массовым правилом перенаправления и сама по себе ничего не говорит о происхождении домена.
Для Google постоянные 301 и 308 являются сильным сигналом того, что конечный URL следует рассматривать как канонический. Поэтому массовый постоянный редирект технически отличается от простой внешней ссылки. :contentReference[oaicite:0]{index=0}
2. Установите, кому принадлежит домен и куда ведёт его DNS
Проверьте регистрационные данные через RDAP. Для международных доменных зон RDAP сейчас является основным протоколом получения регистрационных данных вместо прежнего WHOIS. В открытых данных обычно можно увидеть регистратора, даты регистрации, статус домена и серверы имён; данные владельца могут быть скрыты. :contentReference[oaicite:1]{index=1}
Затем проверьте DNS:
dig example.com A dig example.com AAAA dig example.com CNAME dig example.com NS
Особенно важно сравнить полученные IP-адреса и DNS-серверы с инфраструктурой основного сайта.
Здесь возможны два принципиально разных случая.
Домен указывает на чужую инфраструктуру
Если неизвестный домен ведёт на другой сервер или CDN и уже этот сервер возвращает 301/302 на ваш сайт, перенаправление настроено с чужой стороны.
Ваш сервер такой редирект отключить не может.
Блокировать IP чужого сервера на основном сайте также бессмысленно: после получения HTTP-редиректа новый запрос к вашему сайту выполняет браузер пользователя или поисковый робот, а не сервер неизвестного домена.
Если редирект необходимо убрать, остаются организационные способы:
- найти владельца или регистратора домена;
- связаться с владельцем;
- при отсутствии реакции обратиться к хостинг-провайдеру или регистратору;
- если присутствует реальное нарушение — например, мошенничество, подмена бренда или другое злоупотребление — подать обращение в соответствующую abuse-службу.
Сам факт того, что чужой домен перенаправляет пользователей на ваш сайт, обычно недостаточен для блокировки домена регистратором.
Домен указывает на ваш сервер
Это более интересный случай.
Любой владелец домена технически может направить DNS-запись своего домена на публичный IP вашего сервера. Если на сервере настроено правило наподобие «все неизвестные домены перенаправлять на основной», редирект будет создавать уже ваша инфраструктура.
То есть внешне выглядит так, будто неизвестный сайт специально редиректит на вас, хотя фактически происходит следующее:
чужой домен → ваш IP → ваш nginx/Apache → редирект на основной домен.
Проверьте:
- конфигурацию nginx или Apache;
- default virtual host;
- ServerAlias;
- доменные алиасы в панели хостинга;
- настройки CDN;
- старые домены проекта;
- настройки CMS;
- wildcard-правила.
Если неизвестные Host должны отклоняться, лучше явно разрешить только используемые домены, а остальные запросы завершать ошибкой вместо автоматического перенаправления на основной сайт.
3. Нужно ли удалять редирект из-за SEO
Неизвестный домен с редиректами сам по себе не означает санкции и не является достаточным основанием для срочного использования Disavow.
Google прямо рекомендует применять Disavow только в исключительных случаях: когда на сайт ведёт значительное количество искусственных или низкокачественных ссылок и они уже привели либо с высокой вероятностью могут привести к ручным мерам. Для большинства сайтов Google рекомендует инструмент не использовать. :contentReference[oaicite:2]{index=2}
У Яндекса позиция аналогичная по смыслу: само появление большого количества некачественных внешних ссылок не должно ухудшать состояние сайта, если владелец не использует методы манипулирования поиском. Для физического удаления таких источников Яндекс рекомендует обращаться к владельцу сайта или его хостинг-провайдеру. :contentReference[oaicite:3]{index=3}
Поэтому один неизвестный домен с массовыми редиректами не нужно автоматически добавлять в Disavow.
Проверьте:
- раздел «Меры, принятые вручную» в Google Search Console;
- динамику внешних ссылок;
- историю самого домена;
- не являлся ли он раньше официальным доменом компании;
- нет ли десятков или сотен аналогичных доменов;
- не появился ли одновременно другой явно искусственный ссылочный спам.
Если ручных мер нет, массовой искусственной ссылочной атаки нет, а обнаружен только один непонятный домен, обычно достаточно выяснить происхождение и наблюдать.
Когда редирект действительно стоит устранять
Убирать его имеет смысл, если:
- неизвестный домен случайно обслуживается вашим сервером;
- это забытый доменный алиас или ошибочная настройка;
- домен используется для мошенничества или имитации вашего бренда;
- редирект является частью большой искусственной ссылочной схемы;
- из-за него поисковая система ошибочно рассматривает сайты как участвующие в переезде;
- появились связанные с искусственными ссылками ручные меры.
Если выяснится, что это старый официальный домен компании после настоящего переезда, удалять корректные постраничные редиректы, наоборот, может быть ошибкой. Google и Яндекс рекомендуют использовать перенаправления со старого домена на соответствующие страницы нового именно при смене адреса сайта. :contentReference[oaicite:4]{index=4}
Главная проверка — не «плохой ли это домен», а где именно возникает перенаправление. Если редирект формирует ваш сервер, исправляется конфигурация Host и виртуальных хостов. Если редирект формирует чужая инфраструктура, технически отключить его со стороны основного сайта нельзя: нужно обращаться к владельцу, хостеру или регистратору и отдельно оценивать, существует ли вообще SEO-проблема.