Перенос сайта на другую CMS: как сохранить адреса и проверить переезд

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

Сначала определите, что изменится при переносе

Разделите проект на шесть частей: CMS, размещение, домен, структура адресов, содержание и обработка формы. Для каждой части запишите изменение и владельца решения. Например, подрядчик может отвечать за шаблоны и правила перенаправлений, владелец сайта — за судьбу материалов, а владелец процесса продаж — за маршрут обращения.

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

Получаются две основные ветки:

1. Адрес сохраняется — проверить ответ, содержание, ссылки, canonical и рабочее действие на прежнем URL.
2. Адрес меняется — выбрать соответствующую новую страницу и настроить прямой переход на неё.

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

Соберите инвентарь важных страниц и рабочих сценариев

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

Инвентарь можно представить как объединение множеств:

I = CMS ∪ sitemap ∪ навигация ∪ разрешённые данные посещений и ссылок ∪ значимые параметры ∪ формы и медиа.

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

Для каждой страницы зафиксируйте:

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

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

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

Составьте карту старых и новых адресов

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

Ниже — учебная карта условного сайта, а не реальный клиентский переезд и не выполненные GET. Домен example.invalid служит только обозначением примера; запросы к нему не выполнялись.

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

В карте три старых пути: один сохраняется, один меняется, один удаляется. Это контроль полноты примера, а не статистика реального сайта.

Порядок работы с картой:

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

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

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

Фактическая проверка примера не выполнялась. Все пути и коды в таблице — ожидаемые учебные условия, а не ответы сайта Switch On AI.

Согласуйте прямые редиректы, ссылки и canonical

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

/catalog/remont-pvh.html → 301 → /services/remont-pvh/ → ожидаемый 200.

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

На новой версии обновите внутренние ссылки, sitemap и canonical до согласованных конечных URL. Для конечной страницы услуги canonical указывает на /services/remont-pvh/. Для сохранённого адреса внутренние ссылки продолжают вести на него.

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

Проверьте новую версию до переключения

До открытия новой версии сопоставьте её с инвентарём. Для каждой важной страницы проверьте:

• содержание, title и description;
• внутренние ссылки и навигацию;
• изображения, документы и другие нужные посетителю файлы;
• форму и весь согласованный маршрут обращения;
• ожидаемый URL и canonical;
• рабочие правила robots и noindex.

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

До переключения назначьте тех, кто:

1. меняет версию сайта или настройки размещения;
2. проходит карту и формы;
3. принимает решение об исправлении или возврате при неудаче.

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

После переключения пройдите старые входы и формы

Не ограничивайтесь главной страницей. Пройдите каждый важный старый адрес из карты и отдельно зафиксируйте:

• ожидаемый и фактический HTTP;
• ожидаемый и фактический конечный URL;
• Location для редиректа;
• соответствие содержания назначению страницы;
• canonical в HTML.

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

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

На собственном сайте Switch On AI приём обращения и доставка уведомления разделены. Это пример устройства процесса, а не подтверждение выполненного переноса CMS.

Фактические результаты вносят в журнал только после проверки:

Фактическая проверка трёх учебных строк не выполнялась. Это не оценка качества переноса: журнал нужно заполнить после переключения по реальным ответам сайта и данным поисковых инструментов.

Отделяйте проверку HTTP от состояния в поиске

В журнале нужны три разных слоя:

1. Фактический ответ сайта: HTTP, Location, конечный URL, содержание и canonical.
2. Последние доступные данные обхода и индексации с датой получения.
3. Наблюдение за поисковыми показателями после изменения.

Google URL Inspection показывает разные данные для известной Google индексной версии и live test текущей страницы. Положительный live test означает лишь то, что проверяемая версия может быть доступна при указанных условиях; он не гарантирует индексацию. Выбранный Google canonical можно увидеть в индексных данных, но его нельзя предсказать одним live-тестом.

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

Для одной страницы полезно сделать две записи с датами: результат проверки живого URL и данные поискового инструмента. Не переносите старое состояние индекса в колонку фактического HTTP. Инструмент Google Change of Address относится к смене домена или поддомена; при замене CMS или путей внутри прежнего домена его не назначают автоматически.

Зафиксируйте отклонения и период наблюдения

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

Назначьте отдельных владельцев для трёх типов отклонений:

• ошибки карты, редиректов, содержания и canonical;
• ошибки формы и конечного маршрута обращения;
• проблемы обхода и поисковой доступности.

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

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