Переезд на новый домен проверяют по всему набору значимых адресов. Открытие главной и один успешный переход подтверждают только одно правило. В это же время старые карточки могут вести в новый каталог без сохранения пути, мобильный поддомен — возвращать ошибку сертификата, а URL с параметрами — попадать в цикл.
Цель проверки состоит в том, чтобы каждый значимый старый адрес получил предсказуемый результат: эквивалентная страница на новом домене, осознанный ответ об удалении либо сохранённый технический URL. Для этого контроль начинают до переключения домена и продолжают после него.
Подготовьте полный набор исходных URL
Основой служит не один sitemap. Соберите адреса из карты сайта, аналитики, отчётов поисковых систем, базы данных или CMS, серверных журналов и списка страниц с внешними ссылками. Добавьте URL рекламных кампаний, документов, изображений и поддоменов, если они меняются вместе с основным сайтом.
Затем нормализуйте данные, но не удаляйте варианты слишком рано. Отдельные строки с HTTP и HTTPS, www и без него, разным регистром или завершающим слешем помогают увидеть, какие входные варианты реально обслуживает старый сервер. При большой выборке разделите адреса по шаблонам: категории, карточки, статьи, фильтры, пагинация, служебные разделы.
Приоритет присваивают по сочетанию ценности и риска. Сначала проверяют страницы с органическими переходами, конверсиями и внешними ссылками, затем массовые шаблоны, потом длинный хвост. Полезный подход к поиску источников битых адресов описан в статье про влияние неработающих ссылок на SEO.
Постройте карту соответствий старых и новых URL
Если на новом домене полностью сохранены пути, базовое правило замены хоста может покрыть большую часть URL. Но его необходимо проверить на исключениях: изменившихся разделах, объединённых материалах, удалённых товарах и страницах с другой локализацией.
В рабочей таблице достаточно пяти обязательных полей:
| Старый URL | Ожидаемый результат | Новый URL | Причина | Проверено |
|---|---|---|---|---|
/catalog/model-a | 301 | /products/model-a | Перенос карточки | Да/нет |
/promo-2024 | 410 | — | Кампания закрыта, замены нет | Да/нет |
/support | 301 | /help | Переименование раздела | Да/нет |
Соответствие должно сохранять намерение страницы. Старую карточку ведут на её новую версию; главная или верхний уровень каталога для неё слишком общие. Если подходящей замены нет, честный 404 или 410 обычно понятнее, чем перенаправление в нерелевантный раздел. Массовые решения проверяют с владельцем контента: похожие URL не всегда означают одинаковый смысл.
Протестируйте правила до переключения DNS
Проверять перенаправления впервые после запуска поздно. На тестовой конфигурации можно направить запрос к будущему серверу через локальное сопоставление домена или явное указание IP, не меняя публичный DNS. Так команда увидит поведение виртуального хоста, HTTPS и правил веб-сервера заранее.
Для каждого URL фиксируйте всю цепочку: начальный адрес, каждый промежуточный статус, заголовок Location, конечный код и конечный URL. Нужен один переход со старого адреса на окончательный новый. Схема http://old → https://old → https://new технически работает, но добавляет лишний шаг; лучше сразу направлять все старые варианты к каноническому адресу нового домена.
Проверьте как минимум несколько представителей каждого шаблона и все исключения. Для регулярных выражений полезны граничные случаи: пустой путь, вложенный каталог, URL с точкой, кириллицей, кодированными символами, query-параметрами. Общая методика чтения цепочек есть в руководстве по проверке редиректов.
Проверьте DNS, HTTPS и все варианты хоста
Редирект существует только тогда, когда запрос доходит до сервера. Старый домен должен продолжать разрешаться в DNS, принимать соединения и отдавать действующий сертификат. Если TLS завершается ошибкой, браузер не получит HTTP-ответ и правило 301 не сработает.
Составьте матрицу из протокола и хоста: http://old, https://old, варианты с www, прежние поддомены. Для каждого нужен определённый результат. Если старый сайт использовал IPv6, проверьте записи AAAA и путь по IPv6 отдельно: разные адреса могут вести на разные серверы.
На новом домене сертификат обязан покрывать фактические имена, а ответы не должны зависеть от случайного виртуального хоста по умолчанию. Практические причины ошибок сертификатов разобраны в статье как исправлять SSL-ошибки. Не удаляйте старую инфраструктуру сразу после успешного запуска: перенаправления должны оставаться доступными для пользователей, роботов и старых ссылок.
Сверьте canonical, ссылки и карту сайта
Перенаправление исправляет вход на старый адрес, но внутренние сигналы нового сайта должны указывать прямо на новый домен. Проверьте canonical, hreflang, Open Graph URL, структурированные данные, ссылки в меню и тексте, sitemap, robots.txt, формы, XML-фиды и ссылки в письмах. Ссылка на старый домен создаёт ненужный переход и затрудняет поиск оставшихся зависимостей.
Особое внимание уделите абсолютным URL, зашитым в шаблоны, CMS-поля и JavaScript-конфигурацию. Поиск строк по базе и репозиторию дополняет обход сайта, но не заменяет его: часть адресов может собираться во время выполнения. Из нового sitemap исключают старый домен и неканонические варианты.
Google рекомендует менять по одному существенному фактору за раз, использовать постоянные серверные перенаправления и отправлять новую карту сайта; актуальная последовательность описана в официальном руководстве о переносе сайта с изменением URL. Это не отменяет собственной таблицы соответствий: поисковая система не может определить бизнес-смысл удалённых страниц за владельца сайта.
Проведите массовую проверку после запуска
Сразу после переключения повторите тест из внешней сети. Проверка с самого сервера может пройти по внутреннему маршруту и не заметить ошибку публичного DNS, CDN или балансировщика. Сначала возьмите небольшой критический набор, чтобы быстро обнаружить системную проблему, затем запустите весь список.
Результаты удобно классифицировать:
- совпадение — ожидаемый статус и конечный URL получены;
- неверная цель — перенаправление работает, но ведёт не туда;
- цепочка — до конечной страницы больше одного перехода;
- цикл — один из адресов повторяется;
- недоступно — DNS, TCP или TLS не позволили получить HTTP-ответ;
- ошибка назначения — новый URL возвращает 4xx/5xx либо контент другого типа.
Не объединяйте эти состояния в общий столбец «не работает». У них разные владельцы: DNS исправляет инфраструктурная команда, соответствие страниц — SEO и редакция, 5xx — разработка или эксплуатация.
Отслеживайте переходный период по нескольким сигналам
После первой проверки работа не заканчивается. Следите за запросами к старому домену, долей 4xx и 5xx, появлением новых цепочек, обходом нового домена и состоянием ключевых страниц. Серверные журналы показывают реальные старые URL, которых не было в исходной выгрузке. Их добавляют в карту и решают отдельно.
Колебания в отчётах поисковых систем во время переноса сами по себе не доказывают техническую ошибку. Основанием для вмешательства служит наблюдаемая причина: важные URL не обходятся, редиректы исчезли, canonical остался старым, sitemap содержит ошибки или новый сервер нестабилен. Сопоставляйте дату изменений с журналом релиза и другими сигналами; одного графика для вывода недостаточно.
Если адресов много, полный аудит сайта reChecker соберёт страницы нового домена из sitemap и внутренних ссылок и покажет их ответы, canonical и технические признаки. Старые URL проверяйте отдельным списком соответствий: именно он хранит ожидаемую цель каждой пары.
Закройте миграцию только после повторной сверки
Миграцию нельзя считать завершённой в день переключения. Установите несколько контрольных дат и повторяйте массовый тест, особенно после изменений веб-сервера, CDN или сертификатов. Новые ошибки часто появляются не из исходного правила, а из последующих «временных» правок.
В финальном протоколе зафиксируйте долю проверенных адресов, все осознанные 404/410, нерешённые исключения и владельцев задач. Сохраните исходную карту и результаты прогонов: они понадобятся, если через месяц обнаружится старый раздел или партнёрская ссылка. Миграцию можно снять с усиленного контроля после двух последовательных проверок без системных ошибок; оставшиеся исключения должны иметь срок и ответственного.