Переезд сайта на новый домен: чек-лист без потери страниц

Короткий ответ: домен переезжает постранично

Безопасный переезд строится на соответствии каждого ценного старого URL новому эквиваленту. Постоянный редирект, canonical, внутренняя ссылка, Sitemap и сигнал в Вебмастере должны указывать в одну сторону. Массовый редирект всего сайта на главную не переносит смысл страниц и создаёт плохой путь для пользователя.

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

• один старый URL получает один наиболее близкий новый адрес;
• новый сайт полностью проверяется до подачи сигнала;
• старый домен и редиректы сохраняются длительное время;
• для критической ошибки заранее определён сценарий отката.

Когда переезд оправдан, а когда его лучше отложить

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

Не объединяйте без необходимости смену домена, CMS, дизайна, структуры URL и содержания. Иногда это неизбежно, но тогда нужны отдельные карты изменений и более длинный контрольный период. Чем меньше переменных меняется одновременно, тем проще найти причину ошибки и восстановить конкретный маршрут.

Инвентаризация до переключения

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

Зафиксируйте текущие позиции, органический трафик, цели и ошибки обхода. Эта база поможет отличить обычную перестройку индекса от технической проблемы.

Подготовка новой версии

Проверьте HTTPS, заголовки, canonical, robots.txt, Sitemap, внутренние ссылки, изображения, формы и счетчики. Новый сайт не должен быть закрыт от индексации после запуска. Тестовый запрет нужно снять до отправки сигнала о переезде.

Обновите абсолютные ссылки, Open Graph, почтовые шаблоны, профили организаций и рекламные объявления. Сохраните UTM-метки и проверьте, что редиректы не теряют параметры.

• карта соответствий URL;
• постраничные постоянные редиректы;
• самоканонические адреса нового домена;
• новый Sitemap и рабочие формы.

День запуска

Включите редиректы, обновите внутренние ссылки и Sitemap, проверьте ключевые маршруты вручную. Добавьте обе версии в Яндекс Вебмастер, подтвердите права и отправьте заявку на переезд по официальной инструкции.

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

Мониторинг после переезда

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

Сохраняйте старый домен и редиректы длительное время. Пользователи, закладки и внешние ссылки обновляются не одновременно. Завершение переезда определяется данными, а не датой в календаре.

Инвентаризация и карта соответствий URL

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

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

Редиректы без цепочек и неожиданных разворотов

Сгенерируйте правила из карты URL и протестируйте их на тестовом окружении. Каждый старый адрес должен отвечать одним постоянным переходом на конечный HTTPS-URL. Проверьте варианты со слешем, регистром, параметрами, www, http и распространёнными ошибочными адресами. Нельзя допускать петель, длинных цепочек и возврата на старый домен.

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

• один переход до конечного URL;
• нет редиректа всех ошибок на главную;
• HTTPS и выбранный вариант хоста едины;
• ключевые параметры не теряются без причины.

Согласованные canonical, ссылки, robots и Sitemap

На новом домене используйте самоканонические адреса, если нет обоснованной причины указать другой URL. Обновите меню, хлебные крошки, ссылки в статьях, hreflang при его наличии, Open Graph и структурированные данные. Внутренние ссылки не должны проходить через старый домен или редирект: робот и пользователь сразу получают конечный адрес.

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

Аналитика, реклама, формы и внешние сервисы

Добавьте новый домен в разрешённые адреса счётчиков и интеграций, проверьте цели, вебхуки, CAPTCHA, отправку почты, колл-трекинг и передачу рекламного идентификатора. Тестовая заявка должна пройти от новой страницы до менеджера с источником и единым ID. Отдельно проверьте кросс-доменный сценарий, если часть воронки остаётся на другом хосте.

Обновите финальные URL в Директе, карточках Яндекс Бизнеса, социальных сетях, почтовых шаблонах и важных каталогах. Не полагайтесь только на редирект: рекламная система и пользователь должны получать конечную страницу без дополнительного перехода. Проверьте сертификаты, SPF/DKIM для новой почты и адреса отправителя, если меняется корпоративный email.

Сценарий дня запуска

Назначьте окно, ответственных и канал связи. Зафиксируйте последнюю резервную копию, включите новый сайт, примените редиректы и выполните контрольный набор запросов. Проверьте главную, услуги, статьи, 404, формы, поиск, изображения и мобильную версию. Только после технического подтверждения обновляйте Sitemap и используйте инструмент переезда в Вебмастере.

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

• резервная копия и способ возврата доступны;
• ответственные находятся на связи;
• критические URL и формы проверены;
• сигнал в Вебмастере подан после проверки сайта.

Мониторинг, критерии отката и завершение

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

Откат определяется заранее: недоступность ключевых страниц, потеря заявок, критическая ошибка данных или невозможность исправить конфигурацию в установленное окно. После исправления повторите полный чек-лист, а не только сломанный пункт. Старый домен и редиректы сохраняйте длительно; внешние ссылки, закладки и документы обновляются не одновременно.

• ежедневно: доступность, формы, реклама и серверные ошибки;
• еженедельно: индексация, запросы, страницы и конверсии;
• ежемесячно: старые входы и актуальность внешних ссылок;
• завершение: стабильные данные и отсутствие критических потерь.

Минимальный пакет документов переезда

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

После запуска добавьте журнал проверок и изменений. В нём фиксируются время, URL или контур, ожидаемый результат, фактический ответ и выполненное действие. Такой журнал особенно важен при нестабильной проблеме: команда видит последовательность событий и не повторяет исправление, которое уже оказалось безрезультатным.

DNS, TLS и инфраструктурный runbook

До переключения уменьшите TTL в разумный срок, подготовьте DNS-записи и убедитесь, что сертификат нового домена выпущен и обновляется автоматически. Проверьте CDN, объектное хранилище, балансировщик, origin, IPv4 и IPv6, если они используются. Запишите текущее состояние, целевую конфигурацию и человека, который имеет права на каждую систему.

В runbook укажите порядок изменений и ожидаемый ответ после каждого шага. DNS может обновляться не одновременно у разных провайдеров, поэтому проверяйте несколько резолверов, но не меняйте записи хаотично. Сертификат, редирект и доступность origin проверяются до публичного сигнала о переезде. Критические секреты и ключи не помещаются в общий документ.

• TTL изменён заранее, а не в минуту запуска;
• сертификат покрывает выбранные варианты домена;
• origin не раскрывает тестовую или закрытую версию;
• владелец DNS и сценарий возврата известны команде.

Тестовая матрица URL и кодов ответа

Не ограничивайтесь десятью главными страницами. Сформируйте выборку по типам: главная, услуги, категории, статьи, изображения, параметры, удалённые URL, http, www и адреса со слешем. Для каждого случая задайте ожидаемый код, конечный URL, canonical, доступность в robots и присутствие в Sitemap. Тест выполняется до и после переключения.

Отдельно проверяются ошибки. Несуществующий URL не должен возвращать 200 с шаблоном ошибки или уходить на главную. Удалённая страница без замены получает корректный ответ, а сохранённая проходит одним редиректом. Автоматический отчёт показывает массовую картину, ручной проход подтверждает, что конечный материал действительно соответствует намерению.

Почта, документы и брендовые точки входа

Смена домена затрагивает не только сайт. Проверьте корпоративную почту, SPF, DKIM, DMARC, подписи, автоответы и адреса отправителей. Старые почтовые ящики должны принимать сообщения в переходный период. Обновите договоры, презентации, QR-коды, шаблоны счетов, вакансии и инструкции, где адрес используется как контакт или доказательство бренда.

Составьте реестр внешних точек по влиянию. Сначала меняются рекламные кабинеты, Яндекс Бизнес, профили компании, основные каталоги и письма с большим объёмом переходов. Затем партнёрские страницы и архивные документы. Редирект страхует старые ссылки, но не заменяет обновление там, где пользователь видит устаревшее название или отправляет данные на старую почту.

• почта принимает сообщения на старые и новые адреса;
• аутентификация домена подтверждена;
• ключевые профили ведут сразу на новый URL;
• QR-коды и документы проверены на реальном устройстве.

Панель наблюдения за переездом

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

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

Частые вопросы перед переключением домена

Нужно ли сохранять старый домен? Да, редиректы и почтовые входы остаются полезными длительное время. Когда подавать сигнал в Вебмастере? После проверки нового сайта, прав на оба ресурса и работающих постраничных редиректов. Можно ли одновременно удалить половину страниц? Технически можно, но риск и диагностика усложняются; для каждого удаления нужно отдельное решение.

Сколько длится перенос видимости? Единого гарантированного срока нет, поэтому команда наблюдает за типами страниц и ошибками несколько недель. Что делать при падении трафика? Сначала проверить доступность, редиректы, canonical, robots, Sitemap и конкретные потерянные URL, а не немедленно отменять домен. Когда выполнять откат? По заранее согласованным техническим критериям, а не по одному изменившемуся запросу. Решение фиксируется в журнале проекта.