Смена домена и SEO: как переехать без потери страниц и заявок

Короткий ответ: при смене домена нужно перенести не только сайт, но и назначение каждого ценного URL. Сначала соберите старые адреса и исходные метрики, затем подготовьте новый домен, составьте карту соответствий и настройте прямые постоянные редиректы. После запуска обновите canonical, внутренние ссылки, sitemap.xml, аналитику и внешние профили. Старый домен продолжайте оплачивать и использовать для редиректов. Основные потери возникают, когда страницы исчезают, все адреса ведут на главную, на новом сайте остаётся noindex или команда не проверяет заявки после переключения.

Когда смена домена оправдана

Домен обычно меняют из-за ребрендинга, объединения проектов или перехода на более понятный адрес. Это оправдано, если новый адрес нужен бизнесу.

До старта ответьте на три вопроса:

1. Новый адрес будет понятнее клиентам и соответствует бренду?
2. Компания готова сохранять старый домен и редиректы длительное время?
3. Есть человек, который проверит сайт не только в день запуска, но и в следующие недели?

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

Что собрать до переезда

Полный список URL

Одного sitemap.xml недостаточно. В нём могут не оказаться старые статьи, рекламные посадочные, документы и страницы, на которые ведут внешние ссылки. Соберите адреса из:

• sitemap.xml и базы CMS;
• аналитики и поисковых кабинетов;
• серверных логов;
• результатов обхода сайта;
• списка страниц с внешними ссылками.

Для каждого URL зафиксируйте код ответа, canonical, индексируемость, тип страницы, поисковые входы и известные ссылки.

Трафик и обращения

Сохраните данные по страницам входа, органическому трафику, формам и звонкам. Сравнивайте одинаковые периоды с учётом сезонности и рекламы. Общая посещаемость может расти, пока важная услуга теряет заявки.

До переезда отправьте тестовую форму и проверьте путь до CRM или почты. Иначе после запуска сравнение может оказаться недостоверным.

Технические настройки и интеграции

Сохраните robots.txt, sitemap.xml, canonical, hreflang, микроразметку и правила редиректов. Выпишите счётчики, подтверждения прав, DNS- и почтовые записи, callback-адреса, вебхуки и разрешённые домены сторонних сервисов.

Если базовые сигналы противоречат друг другу, сначала разберите sitemap.xml, robots.txt и canonical. Переносить старую ошибку на новый адрес не имеет смысла.

Карта переноса: какой старый URL куда ведёт

Карта переноса - это таблица, где у каждого старого адреса есть одно понятное решение. Самый простой вариант - сохранить пути:

old.ru/services/audit/ -> new.ru/services/audit/

Если структура меняется, сопоставляйте страницы по назначению: статью с её новой версией, услугу с аналогичной услугой, документ с актуальной копией. Массовый редирект на главную не сохраняет пользовательский маршрут.

Если точной замены нет, выберите один вариант:

1. Создайте полезную новую страницу, если тема и спрос остаются актуальными.
2. Перенаправьте на близкий материал, который решает ту же задачу.
3. Верните честный 404 или 410, если материал удалён без замены.

В таблице достаточно колонок: старый URL, новая цель, основание решения, ответственный, статус проверки. Для приоритетных страниц добавьте ожидаемый H1 и контрольное действие, например отправку формы.

Как подготовить новый домен

HTTPS и основная версия адреса

Сертификат должен работать для нужных вариантов домена. Выберите основной хост с www или без него. Любая альтернативная версия должна за один переход приводить на итоговый HTTPS-адрес.

Индексация и доступность

На тестовом сайте часто включают запреты для роботов. Перед открытием проверьте сразу три уровня: robots.txt, meta robots и HTTP-заголовок X-Robots-Tag. Удалённый Disallow не поможет, если шаблон продолжает отдавать noindex.

Откройте сайт без авторизации. Проверьте главную, услуги, статьи, контакты, мобильную версию, изображения и формы. Новый домен должен работать самостоятельно до включения редиректов.

Canonical, ссылки и разметка

Canonical должен указывать на новый URL, а не на тестовый хост или старый домен. Обновите адреса в schema.org, Open Graph, manifest, хлебных крошках и ссылках на изображения. Внутренние ссылки сразу направляйте на новый домен.

Ищите старое имя в коде и базе, но не заменяйте его вслепую: оно может законно оставаться в истории компании, договоре или цитате.

Как настроить редиректы

Для постоянного переезда обычно используют серверный 301. Важны правильная цель, один переход и одинаковый результат для браузера и робота.

Параметры сохраняйте только там, где они нужны. Рекламные метки можно передавать, а старые фильтры и сессии не должны создавать дубли. Протестируйте главную, услугу, статью, файл, пагинацию, URL с параметром и несуществующую страницу.

Надёжная последовательность такая: сначала конкретные соответствия для изменившихся страниц, затем общее правило для путей, которые остались прежними. Подробные примеры есть в руководстве по редиректам при переезде сайта.

Порядок действий в день запуска

1. Остановите несогласованные правки контента и структуры.
2. Сделайте резервную копию файлов, базы и серверных правил.
3. Разверните проверенную версию на новом домене.
4. Включите редиректы по карте URL.
5. Обновите canonical, hreflang, внутренние ссылки, robots.txt и sitemap.xml.
6. Проверьте аналитику, формы, телефонию, CRM, почту и интеграции.
7. Подтвердите новый домен в поисковых кабинетах и отправьте новый sitemap.
8. Используйте инструмент смены адреса, если он доступен и подходит для такого переезда.
9. Повторно обойдите контрольный набор URL и исправьте найденные ошибки.

Не планируйте переключение перед выходными или крупной рекламной кампанией. После запуска команда должна быстро реагировать на ошибки.

Что проверять после запуска

Каждый контрольный URL должен одним переходом вести на ожидаемую страницу. Итоговый ответ - 200, содержание соответствует назначению, canonical указывает на новый адрес. Удалённые страницы должны возвращать 404 или 410, а не открывать главную.

На новом сайте проверьте H1, title, description, текст, изображения и навигацию. Посмотрите исходный HTML: ошибки canonical и разметки могут быть незаметны на странице. Убедитесь, что CSS, JavaScript, шрифты и API не блокируются.

Пройдите путь посетителя от посадочной до отправки формы. Проверьте уведомление, запись в CRM, источник обращения и согласие на обработку данных. Переезд с неработающей формой остаётся неудачным.

В первые дни ежедневно смотрите:

• 5xx, тайм-ауты, ошибки DNS и сертификата;
• запросы к старым URL, неожиданные параметры и 404;
• обработку sitemap и выбранные поиском canonical;
• органические входы, формы, звонки и квалифицированные обращения.

Не делайте вывод по одному дню: поиску нужно время для повторного обхода, а спрос зависит от сезона. Контрольные условия понятнее: приоритетные страницы доступны, редиректы прямые, число ошибок снижается, обращения измеряются. Используйте чек-лист еженедельного SEO-мониторинга вместе со списком старых URL.

Пример: переезд сайта услуг после ребрендинга

У компании есть главная, восемь страниц услуг, блог и контакты. Бренд меняется, но сами услуги остаются. Команда решает не переделывать дизайн и структуру одновременно с доменом.

Сначала она собирает адреса из sitemap.xml, аналитики и CMS. Для услуг и статей сохраняет прежние пути. Две устаревшие страницы объединяет с актуальными материалами и назначает близкие по смыслу цели. Акционную страницу без замены закрывает корректным ответом удаления, а не отправляет на главную.

До запуска проверяют HTTPS, canonical, формы, почту и мобильное меню. Затем включают редиректы, меняют внутренние ссылки и отправляют sitemap. В первый день тестируют услуги и статьи с заметным трафиком, затем разбирают 404 и старые адреса по логам.

Этот сценарий не гарантирует сохранение каждой позиции. Зато у каждого важного URL есть назначение, а у команды - понятный порядок исправления.

Ошибки, которые чаще всего вредят переезду

Все страницы ведут на главную

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

На новом сайте остался noindex

Запрет может находиться в robots.txt, meta robots или HTTP-заголовке. Проверяйте публичный ответ каждого уровня, а не только настройки CMS.

Возникли цепочки редиректов

Исторический URL проходит через несколько версий домена и протокола. Перепишите правила так, чтобы он сразу вёл на текущую конечную страницу.

Canonical остался старым

Редирект сообщает о новом адресе, а шаблон - о старом. Проверьте canonical на разных типах страниц, а не только на главной.

Одновременно изменили всё

При смене домена, CMS, структуры и текстов трудно найти причину просадки. Разделите работы на этапы или ведите точный журнал изменений и контрольных проверок.

Старый домен перестали продлевать

Пока на него ведут ссылки и приходят люди, он остаётся частью инфраструктуры. Контролируйте регистрацию, DNS, HTTPS и редиректы. Универсального срока отключения нет: решение принимают по логам, трафику и ценности ссылок.

Чек-лист миграции

До запуска

• определена деловая причина переезда и назначен ответственный;
• URL собраны из нескольких источников;
• сохранены метрики трафика и заявок;
• у важных старых страниц есть осмысленные новые цели;
• HTTPS работает, основной хост выбран;
• сняты тестовые запреты индексации;
• canonical, разметка и внутренние ссылки используют новый домен;
• формы, CRM, почта, аналитика и интеграции проверены;
• подготовлены резервная копия и способ вернуть прежнюю конфигурацию.

После запуска

• старые важные URL ведут прямо на правильные страницы;
• конечные страницы отвечают 200 и содержат ожидаемый материал;
• sitemap.xml включает только новые канонические адреса;
• robots.txt не закрывает рабочие разделы;
• новый домен подтверждён в поисковых кабинетах;
• внутренних ссылок через старый домен не осталось;
• тестовые обращения доходят до конечной системы;
• 404, 5xx и цепочки редиректов отслеживаются;
• старый домен, DNS и сертификат остаются под контролем.

FAQ

Можно ли сменить домен совсем без просадки?

Гарантировать это нельзя. Риск можно снизить, если сохранить содержание и структуру, настроить прямые редиректы, согласовать технические сигналы и быстро исправлять ошибки по данным обхода и аналитики.

Нужно ли сохранять старый домен?

Да, пока он участвует в редиректах, получает переходы или имеет ценные внешние ссылки. Поддерживайте регистрацию, DNS, HTTPS и мониторинг. Срок определяйте по фактическим обращениям, а не по календарю.

Можно ли одновременно перейти на новую CMS?

Можно, но риск выше. Если этапы нельзя разделить, сохраните URL, подготовьте контрольный набор страниц и документируйте изменения шаблонов, контента и ответов сервера.

Нужно ли менять все внешние ссылки?

В первую очередь обновите управляемые профили, рекламу, рассылки и важные партнёрские страницы. Остальные переходы должен корректно принимать редирект со старого домена.

Что делать со страницей без новой копии?

Перенаправьте её на близкий материал только тогда, когда он решает ту же задачу. Если подходящей замены нет, используйте 404 или 410. Редирект на главную не создаёт полезной цели.

Когда обновлять sitemap.xml?

Новый sitemap должен быть готов к публичному запуску и содержать только доступные канонические URL нового домена. Старые и новые адреса не нужно смешивать в актуальной карте.

Как понять, что переезд завершён?

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

Если хотите проверить карту URL и технические сигналы до переключения, напишите в Telegram Alextram. Для подготовки структуры, инструкций и первичной проверки контента можно использовать нейросеть XelaGroup, но редиректы, формы и пользовательские сценарии всё равно нужно тестировать на реальном сайте.