Краткий вывод
Что важно понять до чтения деталей
- Проверяют матрицу, а не одну главную
- HTTPS-зеркалам нужны сертификаты
- Редирект сохраняет путь
- Тестовый стенд закрывают авторизацией
01
Составьте матрицу всех доступных версий
Начните с четырех базовых сочетаний: `http://domain`, `https://domain`, `http://www.domain`, `https://www.domain`. Добавьте старые домены, кириллические варианты, технические поддомены, адреса хостинга, CDN и тестовые стенды. Для каждого проверьте главную, внутреннюю страницу, несуществующий путь и URL с параметром. Одна главная может перенаправляться правильно, пока каталог на HTTP продолжает отвечать 200.
Соберите источники адресов: DNS, панель хостинга, сертификаты, Search Console, Яндекс Вебмастер, Метрика, рекламные кабинеты, CRM, почтовые шаблоны и внешние каталоги. Цель — не найти только то, что уже в индексе, а увидеть все точки входа пользователя и робота. Результат оформляют таблицей: исходный URL, код ответа, конечный адрес, число переходов, canonical и доступность сертификата.
02
HTTPS должен работать до перенаправления
Браузер устанавливает защищенное соединение раньше, чем получает HTTP-редирект. Поэтому старый или второстепенный HTTPS-хост обязан иметь действующий сертификат. Иначе пользователь увидит предупреждение безопасности и не дойдет до основного сайта. Сертификат проверяют по имени, сроку, цепочке доверия и автоматическому продлению. Для нескольких доменов используют SAN или отдельные сертификаты по инфраструктуре.
Смешанный контент тоже нарушает единообразие: HTTPS-страница не должна загружать скрипты, формы или изображения по HTTP. Такие ресурсы блокируются браузером или снижают доверие. Проверьте абсолютные ссылки в HTML, CSS, JavaScript, JSON-LD и письмах. После перехода на HTTPS протокол должен быть единым во всех пользовательских и поисковых сигналах.
03
Настройте один прямой постоянный редирект
Каждая второстепенная комбинация ведет одним 301-переходом на соответствующий путь основной версии. Запрос к `http://www.domain/catalog/item` должен сразу оказаться на `https://domain/catalog/item`, если именно он выбран главным. Цепочка из двух-трех редиректов работает медленнее, усложняет диагностику и повышает риск циклов. Массовое перенаправление всех старых страниц на главную не сохраняет их смысл.
Правило настраивают на сервере или балансировщике до CMS, чтобы оно действовало и при сбое приложения. Исключения документируют: служебный health-check, API или отдельный поддомен могут иметь собственную роль, но не должны случайно отдавать копию сайта. После изменения автоматический тест проходит по списку ключевых путей и сравнивает конечные адреса.
04
Согласуйте canonical, sitemap и внутренние ссылки
Редирект — сильный сигнал, но сайт не должен одновременно советовать другую версию. Canonical на страницах указывает конечный HTTPS-адрес, sitemap содержит только его, а внутренние ссылки ведут сразу без переходов. Структурированные данные, hreflang, Open Graph и RSS тоже обновляют. Если старый домен остается в шаблоне, робот продолжит регулярно ходить по лишнему маршруту.
Проверьте формы: endpoint отправки и политика обработки данных не должны оставаться на HTTP или тестовом хосте. В Метрике и CRM должен сохраняться исходный источник после редиректа. Корректная консолидация важна не только для индекса: она предотвращает потерю UTM, ошибки callback и разрыв пользовательской сессии между доменами.
05
Что делать со старым доменом и тестовым стендом
Старый домен после переезда поддерживают с постраничными редиректами достаточно долго, особенно если на него есть ссылки и постоянные посетители. Его сертификат и DNS не отключают сразу. Новый домен должен иметь эквивалентные страницы, а не отправлять весь архив на главную. В инструментах поисковиков отслеживают перенос и ошибки обхода обеих сторон.
Тестовый стенд, наоборот, не должен становиться зеркалом в поиске. Его закрывают авторизацией или сетевым ограничением, а не надеются только на noindex. Если стенд уже проиндексирован, сначала прекращают публичный доступ и разбирают найденные URL. Копия продакшена на доступном поддомене способна конкурировать с оригиналом и раскрывать незавершенный контент.
06
Контроль после консолидации
Проверяйте не только главную. Возьмите страницы услуг, категорий, карточек, статьи, файлы и 404. Для каждой комбинации хоста и протокола зафиксируйте сертификат, код, конечный URL и canonical. Краулер должен находить только основную версию во внутренних ссылках. В sitemap не остается старых доменов, а серверные логи показывают постепенное снижение обхода зеркал.
В Вебмастере и Search Console старые URL могут отображаться до повторного обхода — это нормально. Тревожный сигнал — новые страницы на второстепенной версии или рост показов по ней после релиза. Тогда ищут источник: шаблон, внешний фид, мобильное приложение, партнерские ссылки или неверное правило прокси. Консолидация считается завершенной, когда новые противоречия больше не возникают.
Практика
Что проверить на своем сайте
- Собрать домены и поддомены
- Проверить четыре базовые версии
- Проверить сертификаты
- Убрать цепочки редиректов
- Согласовать все сигналы
- Мониторить новые дубли
Применить к проекту
Что можно сделать после статьи
Если тема похожа на вашу ситуацию, следующий шаг простой: проверить сайт на спрос, структуру, технические ограничения и точки, где пользователь не доходит до заявки.
Источники
Какие источники использовали
Типы перенаправлений и рекомендации для постоянной смены адреса страницы.
Google: как указать канонический URLОфициальные рекомендации по редиректам, rel=canonical, sitemap и согласованности сигналов.
Яндекс Вебмастер: главное зеркало сайтаКак Яндекс определяет главное зеркало и обрабатывает версии адреса сайта.
