Перенос сайта на новую платформу: контент, URL, формы и аналитика

Сначала докажите, что перенос действительно нужен

Фраза «старая CMS больше не подходит» слишком широка для постановки задачи. Она не объясняет, что именно должно измениться после переезда и почему это нельзя исправить на действующей платформе. Я начинаю с текущего ограничения и задаю пять вопросов:

1. Какое действие бизнеса или пользователя сейчас затруднено?
2. Где возникает ограничение: в контенте, интерфейсе, интеграции, данных, скорости изменений или правах команды?
3. Как будет выглядеть рабочее состояние после переноса?
4. Какая часть сайта действительно должна измениться ради этого результата?
5. По какому сценарию команда примет новую систему?

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

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

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

Опишите сайт как набор обязательств перед бизнесом

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

Я делю объект переноса на шесть слоев:

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

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

Соберите единый реестр миграции

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

Минимальная строка реестра отвечает на три вопроса.

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

Разделите сохранение и улучшение

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

Я предлагаю назначить каждому объекту одно из четырех решений:

1. Сохранить. перенести без смыслового изменения, потому что объект выполняет задачу.
2. Адаптировать. изменить формат под новую модель, сохранив назначение и сопоставимость.
3. Улучшить после запуска. перенести рабочую версию, а гипотезу развития поставить в отдельный план.
4. Не переносить. удалить или объединить только после решения владельца и определения нового состояния.

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

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

Переносите модель контента, а не готовую верстку

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

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

Затем старые поля сопоставляют с новыми:

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

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

URL не обязаны меняться вместе с CMS

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

Google рекомендует готовить карту соответствий старых и новых URL, использовать постоянные серверные перенаправления и обновлять внутренние ссылки. Яндекс при смене структуры также рекомендует 301 на новый релевантный адрес, доступность новой страницы с ответом 200, обновленные навигацию и Sitemap (Google о миграции сайта, Яндекс о смене структуры).

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

Проверяйте формы до конечного получателя

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

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

Сохраните смысл аналитики

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

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

Например, в Google Analytics для отправки формы или запроса предусмотрено рекомендованное событие generate_lead, а Яндекс Метрика позволяет передавать целевые события с сайта методом reachGoal (рекомендованные события GA4, целевые события Яндекс Метрики). Конкретная реализация зависит от действующей схемы измерения. Для приемки важнее проверить момент события: оно не должно считаться лидом при простом клике, если форма фактически не отправилась.

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

«Перенести счетчик недостаточно. Команде нужно сохранить смысл показателя: какое действие произошло, в какой момент оно подтверждено и какое решение принимается по этому числу».

Проведите пробный перенос на ограниченной выборке

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

Выборка должна включать разные типы риска:

1. простую информационную страницу;
2. страницу услуги с формой;
3. материал со связанным автором, изображениями и внутренними ссылками;
4. объект со сложными полями или вложенными сущностями;
5. сценарий с CRM, почтой или другой внешней системой;
6. страницу, для которой меняется URL;
7. действие, участвующее в аналитическом отчете.

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

Назначьте роли и период фиксации изменений

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

У каждого контура должен быть владелец решения:

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

Слово «команда» не заменяет ответственного. Если два человека могут закрыть строку реестра независимо, у них быстро появятся разные критерии готовности.

Принимайте миграцию по сценариям

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

Для каждого критичного сценария фиксируют:

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

До переключения проведите отдельный go/no-go: владельцы подтверждают критичные сценарии, открытые риски, окно запуска, канал связи и порядок отката. Такое решение лучше длинного общего статуса «почти готово», потому что отделяет допустимые доработки от ошибок, которые лишают сайт основной функции.

Подготовьте откат до запуска

Откат - это не обещание «вернуть все назад при проблеме». Нужно заранее знать, какая версия считается рабочей, кто принимает решение, как сохраняются новые данные после переключения и какие действия нельзя потерять при возврате.

План включает:

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

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

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

Ошибки, которые делают перенос дороже

Считать объем только по страницам

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

Выбрать новую модель данных после начала импорта

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

Проверить форму только на экране

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

Установить счетчики без словаря событий

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

Совместить миграцию со всеми улучшениями

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

Оставить спорные решения разработчику на этапе загрузки

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

Выключить старую систему сразу после релиза

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

Чек-лист готовности к переносу

• Названо ограничение, которое должна снять новая платформа.
• Результат переведен в проверяемые изменения бизнеса и команды.
• Собран единый реестр контента, URL, действий, интеграций, аналитики и управления.
• Каждому объекту назначено решение: сохранить, адаптировать, улучшить позже или не переносить.
• Приняты типы контента, поля, связи и правила преобразования.
• URL и поисковые действия согласованы до импорта.
• Формы проверены до CRM или другого конечного получателя.
• Словарь событий сохраняет смысл бизнес-показателей.
• Пробная партия прошла полный путь без ручной маскировки ошибок.
• Назначены владельцы решений и блокирующих проверок.
• Зафиксирован порядок учета изменений после финального экспорта.
• Проведена сценарная приемка критичных маршрутов.
• Приняты условия запуска, остановки и отката.
• Старая система сохраняется до завершения стабилизации.

Следующий шаг

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