Перенос контента — это не только копирование текста в новую CMS. Нужно решить, какие материалы сохраняются, как старые поля становятся новыми, куда переходят файлы и кто проверяет результат. Одинаковое количество записей до и после импорта ещё не доказывает, что содержание перенесено правильно.
Сначала составьте реестр и правила преобразования. Затем проведите пробный импорт в тестовую среду, устраните расхождения и согласуйте итоговую сверку. Ниже — порядок, который можно использовать при смене CMS, редизайне или объединении разделов.
Зафиксируйте исходный набор материалов
Соберите страницы, статьи, товары, документы и изображения по типам. Для каждой записи сохраните исходный идентификатор, адрес, название, язык, статус публикации и дату изменения. Отдельно отметьте вложения, связи с другими материалами и владельца содержания.
Используйте доступный экспорт CMS и перечень опубликованных URL. Один обход публичного сайта не покажет черновики и закрытые записи, а выгрузка базы может содержать устаревшие или служебные материалы. Согласуйте, что входит в перенос, прежде чем сравнивать количества.
Выберите решение для каждой записи: перенести, переработать, объединить, оставить в архиве или исключить с основанием. Если две старые статьи становятся одной, это должно быть видно в реестре. Не считайте согласованное объединение потерей, но и не скрывайте пропуск за общим словом «оптимизация».
Сопоставьте поля и связи
Укажите, куда попадает каждое исходное поле. Текст может разделиться на вводный абзац и блоки; старый список изображений — превратиться в галерею. Для отсутствующих значений определите правило: оставить пустым, запросить редактора или применить согласованное значение. Дату публикации не заменяйте датой импорта автоматически.
Проверьте категории, авторство, языковые версии, связанные товары и внутренние ссылки. Если связи построены на старых идентификаторах, сохраните таблицу соответствия новым. Переименование заголовка не должно разрывать связь с нужной записью.
Для сложного типа сначала перенесите несколько разных примеров: обычный материал, длинную статью с таблицей, запись без картинки, черновик и материал со связанными объектами. Такой набор выявляет больше ошибок модели, чем несколько одинаковых коротких текстов.
Очистите содержание по согласованным правилам
Удалите служебную разметку старого редактора, если она не нужна новой системе. Проверьте заголовки, списки, таблицы, сноски и специальные символы. Не очищайте всё форматирование одним действием: вместе со стилями можно потерять значимую структуру.
Правки смысла отделяйте от технического преобразования. Исправление устаревших условий, характеристик или контактов требует ответственного за содержание. Редактор должен понимать, где текст изменился намеренно, а где возникла ошибка переноса.
Подготовку недостающих материалов можно организовать по чек-листу контента. Для каждого пробела назначьте ответственного и решение для выпуска; незаполненный блок не становится готовым после импорта.
Перенесите медиа и документы
Сохраните связь файла с материалом, подпись, альтернативный текст там, где он нужен, и исходное назначение. Проверьте права использования, версии документов и доступность файлов получателю. Не публикуйте закрытые вложения только потому, что они попали в общую выгрузку.
Проверьте обрезку изображений на новых шаблонах, качество после обработки и открытие документов. Старые адреса файлов тоже могут использоваться во внешних ссылках. Решение по их переносу согласуйте вместе с картой URL, а не оставляйте до отключения старого хранилища.
Сверьте результат импорта
Используйте таблицу расхождений. В ней нужны исходный объект, ожидаемый результат, фактический результат, объяснение, ответственный и статус проверки. Пример ниже учебный: это не данные клиентского проекта CoreWeb.
| Исходный объект | Ожидается | Получено при проверке | Решение / ответственный | Статус |
|---|---|---|---|---|
| Статья A, опубликована | Один материал, прежняя дата, таблица | Материал есть, таблица потеряла заголовки | Исправить преобразование; разработчик | Открыто |
| Статьи B и C | Одна согласованная объединённая статья | Одна статья и две связи старых URL | Редактор сверяет полноту обоих источников | На проверке |
| Товар D с вариантами | Карточка и связанные варианты | Карточка есть, один вариант не связан | Проверить таблицу идентификаторов; разработчик | Открыто |
| Черновик E | Черновик, недоступный посетителю | Статус сохранён, публичный URL не открывается | Зафиксировать результат; проверяющий | Проверено |
| Документ F | Актуальная версия у нужного материала | Открывается предыдущая редакция файла | Заменить источник; владелец содержания | Открыто |
Количество сверяйте по типам, языкам и статусам. Для каждой исходной записи должно быть объяснение результата: создана, объединена, исключена по решению или не перенесена из-за ошибки. Пропущенные и неизвестные записи не объединяйте с согласованными исключениями.
Автоматически можно проверить наличие обязательных полей, файлов, связей и повторяющихся идентификаторов. Вручную проверьте смысл, отображение и сложные преобразования. Критичные страницы и известные проблемные записи проверяйте полностью; для остального согласуйте выборку по типам. Если ошибка системная, исправьте правило и пересверьте весь затронутый набор, а не только найденный пример.
Учтите изменения во время переноса
Сайт может продолжать обновляться после первой выгрузки. Назначьте дату исходного снимка и способ учёта последующих правок: ограниченное окно без изменений или повторная выгрузка различий. Кто-то должен отвечать за материал, изменённый между пробным импортом и выпуском.
Повторный импорт должен обновлять нужные записи по устойчивому идентификатору. Заранее определите, какие ручные правки на новой стороне можно перезаписывать. Перед повтором сохраните проверяемую копию данных в разрешённом месте и понятный порядок восстановления.
Принимайте контент и переходы отдельно
Принятый импорт означает, что согласованные материалы и связи сверены, а расхождения устранены или явно приняты ответственным. Он не доказывает корректность редиректов, форм и индексации. Для смены адресов нужна отдельная карта и проверка маршрутов.
Google рекомендует сопоставлять старые и новые URL, обновлять внутренние ссылки и проверять canonical после переезда. Подробности — в официальном руководстве Google по переносу сайта. Это отдельный этап от сверки записей CMS; позиции после переезда не гарантируются.
Перед выпуском сохраните итоговый реестр, версии выгрузки и правил, результат проверки и список открытых вопросов. Техническую часть можно дополнить чек-листом редизайна и SEO. Если перенос входит в обновление сайта, обсудим его состав в рамках редизайна сайта.
Для общего состава проекта используйте термин «Миграция сайта»: он разделяет приёмку данных, адресов и инфраструктуры, включая учёт изменений перед переключением.