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

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

Что именно меняется при переезде

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

Сформулируйте границу проекта. Меняется только домен при сохранении содержания? Одновременно меняются система управления, дизайн, каталог и тексты? Google в инструкции по переносу URL советует по возможности разносить крупные изменения по этапам, чтобы проще было обнаружить причину проблемы. Если разделить работы нельзя, сохраните отдельный список каждого изменения и расширьте проверку. Так падение входов на страницу услуги не будет автоматически приписано редиректу, когда сама услуга исчезла из новой версии.

Назначьте ответственных: кто владеет обоими доменами, кто управляет сервером и системой доменных имён (DNS), кто проверяет формы, кто смотрит поисковые инструменты и кто принимает решение об откате. У нового домена должна быть возможность работать по защищённому протоколу HTTPS с корректным сертификатом. Старый домен нужен и после запуска: именно через него продолжают проходить переходы по прежним адресам.

Как собрать все старые адреса, которые нужно учесть

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

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

Удалённый товар и новая категория не всегда имеют эквивалент. Если близкой замены нет, осмысленный ответ об отсутствии страницы лучше, чем принудительное перенаправление на главную. Если несколько старых дублей объединяются в один полезный материал, запишите причину. Не пытайтесь «сохранить позиции» произвольным назначением адреса: пользователь и робот увидят несоответствие содержания.

Какая резервная копия нужна до переключения

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

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

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

Что проверить на новом домене до публичного запуска

Откройте список важных страниц на тестовой версии. Сверьте заголовки, основной текст, изображения, документы, внутренние ссылки, формы, каталог и поиск. Проверьте мобильный путь: открыть услугу, отправить контакт, увидеть подтверждение, найти запись у принимающей стороны. Интеграции могут зависеть от разрешённого домена: платёжный сервис, система учёта клиентов (CRM), почта, программные интерфейсы (API) и сторонние виджеты требуют проверки отдельно.

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

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

Как настроить и проверить перенаправления

При постоянной смене адреса применяют серверные постоянные перенаправления, обычно HTTP 301 или 308. Google рекомендует постоянные ответы для такого переезда. В инструкции Яндекса для его процедуры названы 301 или 302; при плановом постоянном переносе выбирайте постоянный статус и проверяйте фактическое поведение обеих поисковых систем. Перенаправление должно вести со старой страницы к содержательно соответствующей новой.

Проверьте не только главную. Возьмите адреса услуг, статей, товаров, файлов PDF (скачиваемых документов) и старые варианты с HTTP, HTTPS и www, которые реально существовали. Для каждого запишите первый статус, конечный адрес и его статус. Цикл, ошибка 404 на конечной странице, временная заглушка или переход на чужую услугу требуют исправления. Google советует вести сразу к конечному URL, чтобы избежать цепочек. При одновременной смене домена и путей инструкция Яндекса для инструмента переезда отдельно показывает двойной редирект через прежний путь на новом домене. Если меняются оба компонента адреса, согласуйте схему с условиями Вебмастера и проверьте фактическую цепочку для обеих систем; универсальное правило одного перехода здесь неверно. Если структура адресов меняется, проверьте карту адресов вручную на приоритетных страницах и автоматически на полном списке.

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

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

Как сообщить о переезде Яндексу и Google

Добавьте старый и новый сайты в Яндекс Вебмастер, подтвердите права и проверьте доступность обеих версий. После включения соответствующих перенаправлений используйте инструмент «Переезд сайта» со старого адреса на новый по текущей инструкции сервиса. Наличие отправленной заявки ещё не означает завершение обработки. Смотрите статус и конкретные страницы. Вебмастер может показывать старые URL, пока система обновляет данные; это не доказательство, что настройка не работает.

В Google Search Console подтвердите права на оба домена и используйте Change of Address, когда меняется домен или поддомен и функция применима к вашему случаю. Отправьте карту сайта с новыми адресами. Для отдельных приоритетных URL используйте проверку страницы. Google рекомендует собственный canonical на новых страницах. Проверьте, что канонические ссылки, карта сайта и внутренние ссылки не ведут обратно на старый домен; если Яндекс отклоняет заявку, сверьте canonical на новом сайте с его отдельной инструкцией по ошибкам переезда. Инструменты помогают учёту переезда, но не заменяют работающие перенаправления и доступность контента.

Запишите, какие свойства консоли вы проверили: префикс www, без него, протоколы и поддомены при их наличии. Ошибка часто скрывается в старом варианте адреса, который не виден при проверке только главной страницы. Не выдавайте период «несколько недель» из справки за обещанный срок для своего проекта: скорость обхода и объём сайта различаются, а фактический результат проверяется в интерфейсах и выдаче позже.

Почему старый домен нельзя выключить сразу

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

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

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

Контроль в день запуска

Запустите проверку по заранее согласованному списку. Сначала DNS и сертификат, затем главная, услуги и формы, после этого документы, каталог, статьи и старые ссылки. Проверьте статус ответа сервера и конечный адрес каждого приоритетного URL. Отправьте контрольное обращение с нового домена и найдите его в системе; уведомление проверьте отдельно. Покупательский путь важнее картинки главной страницы.

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

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

Что отслеживать после переключения

Начните с журнала ошибок и отчётов по адресам. Смотрите старые URL, для которых не нашлось правила; новые страницы с ошибками; циклы; обращения к отсутствующим изображениям; ошибки форм. Затем проверяйте индексацию приоритетных страниц в Яндексе и Google. Сводный счётчик страниц полезен как сигнал, но он не показывает, исчезла ли одна важная услуга.

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

Удобный журнал наблюдения содержит дату, URL, наблюдение, источник данных, действие и результат повторной проверки. Если поисковая консоль временно недоступна, запишите недоступность и проверяйте доступными средствами, но не пишите «страница не индексируется» без факта. Рост показов на новом домене при сохранении старых адресов в интерфейсе возможен в переходный период; оценивайте конкретные страницы и связанные цели.

Что проверить в DNS, почте и сервисах с привязкой к домену

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

Если адреса электронной почты также меняются, планируйте это отдельно. Формы могут отправлять уведомление на старый ящик; сотрудники могут отвечать с адреса, который больше не работает. Укажите, какие входящие и исходящие адреса нужны, кто проверит доставку и что увидит клиент при ответе. Если почта остаётся на старом домене, не меняйте её записи вместе с сайтом по инерции. Владелец должен понимать, какие действия относятся к веб-сайту, а какие к почте.

Проверьте привязки сторонних сервисов: разрешённый домен платёжной страницы, адрес возврата после оплаты, источники запросов API, адреса уведомлений, ссылки из CRM, виджет карты и вход через внешнюю систему. Состав зависит от проекта. Составьте короткий протокол для каждого: «старое значение», «новое значение», «тест», «ответственный». Это предупреждает ситуацию, когда страницы доступны, но действие пользователя перестало завершаться.

Когда полезен пробный перенос и что он проверяет

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

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

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

Четыре ошибки, которые видно в первые проверки

Первая: старые адреса услуг ведут на новую главную. Проверка карты покажет, какие задачи потеряли ответ. Исправление требует содержательного соответствия. Одного ответа 200 недостаточно. Вторая: новый сайт открыт людям, но содержит noindex или старый canonical. Сравните HTML и заголовки именно на конечных страницах, включая внутренние страницы.

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

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

Какие результаты запросить у исполнителя

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

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

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

Проверенные исключения приложите к карте, чтобы следующая команда не направила их на главную автоматически.

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

На приёмке должны быть исходный список URL, карта соответствий и обоснованных удалений, протокол проверок перенаправлений, список исправленных внутренних ссылок, состояние поисковых инструментов, резервная копия и порядок её восстановления. Попросите показать контрольную заявку и её запись, вместе с сообщением «форма работает». Укажите, кто обслуживает старый домен и кто замечает новые 404.

Если вместе с доменом меняется дизайн или система управления, включите эти работы в ТЗ и критерии приёмки. Для общей технической проверки существующего сайта используйте план SEO-аудита, сохраняя задачу этой статьи: контролировать именно соответствие старых и новых URL. При проекте с обновлением интерфейса на странице редизайна сайта можно обсудить перенос как отдельный проверяемый этап.

Документация и источники

• Яндекс Вебмастер: переезд на новый домен
• Google Search Central: перенос сайта с изменением URL

Редакция Webclub. Опубликовано 2026-10-03, обновлено 20.10.2026.

Обсудим задачу вашего сайта?

Пришлите адрес и опишите, что хотите исправить. Согласуем состав работ и порядок проверки.

ПОСМОТРЕТЬ СОСТАВ РАБОТ