Чтобы перенести интернет-магазин на новую CMS, сначала зафиксируйте требования и состав данных, затем подготовьте новую платформу, настройте интеграции, перенесите каталог и пользователей, сохраните URL или настройте 301-редиректы, протестируйте оформление заказа и только после этого переключайте домен. Перенос нельзя сводить к копированию товаров: необходимо учесть SEO, платежи, доставку, аналитику, личные кабинеты и обмен данными с внешними системами.
В статье — пошаговая схема миграции, критерии готовности к запуску, список SEO-проверок и типичные ошибки. Инструкция поможет владельцу бизнеса или маркетологу определить объём работ, поставить задачу разработчикам и принять результат без потери критичных функций.
Что входит в перенос интернет-магазина на новую CMS
Миграция интернет-магазина — это перенос данных, функций и поисковых настроек со старой платформы на новую. Состав работ зависит от масштаба каталога, количества интеграций, логики ценообразования, устройства личного кабинета и требований к дизайну.
Обычно необходимо перенести или заново настроить:
- категории, товары, торговые предложения, характеристики, изображения и файлы;
- цены, остатки, скидки, промокоды и правила расчёта стоимости;
- клиентов, адреса, заказы и статусы заказов;
- оплату, доставку, уведомления и кассовое оборудование;
- обмен данными с CRM, ERP, складской или учётной системой;
- контентные страницы, статьи, отзывы и вопросы к товарам;
- URL, метатеги, заголовки, тексты, микроразметку и другие SEO-элементы;
- веб-аналитику, рекламные пиксели, товарные фиды и коллтрекинг.
Переход на другую CMS оправдан, если действующая система ограничивает развитие магазина, плохо поддерживается, не справляется с нагрузкой или делает доработки неоправданно сложными. Менять платформу только ради нового дизайна необязательно: иногда безопаснее обновить интерфейс в рамках текущей системы.
До начала проекта определите измеримую цель миграции. Например, ускорить обновление каталога, автоматизировать обмен заказами, поддержать несколько типов цен или упростить управление контентом. Цель помогает отличить обязательные функции от пожеланий, которые можно реализовать после запуска.
Шаг 1. Проведите аудит действующего магазина
Аудит нужен, чтобы не потерять функции и данные, которые незаметны на витрине, но важны для продаж и работы сотрудников. Результатом должен стать перечень сущностей, интеграций, шаблонов страниц и сценариев пользователей.
Зафиксируйте данные и бизнес-логику
Составьте таблицу объектов: поля товара, типы цен, свойства вариантов, статусы заказов, группы клиентов, бонусы и правила скидок. Для каждого объекта укажите источник данных, место назначения на новой CMS и способ переноса.
Отдельно опишите нестандартную логику. К ней относятся минимальная сумма заказа, ограничения доставки по регионам, разные цены для групп покупателей, комплекты, подписки, предзаказы и автоматические уведомления. Если такую логику не задокументировать, команда может обнаружить её уже после запуска.
Соберите список интеграций
Проверьте не только очевидные подключения к оплате и доставке. Интернет-магазин может отправлять данные в CRM, получать остатки из учётной системы, формировать фиды для рекламных площадок, использовать сервисы рекомендаций и передавать события в аналитику.
Для каждой интеграции зафиксируйте направление обмена, формат, расписание, ответственного и поведение при ошибке. Секретные ключи и пароли не следует переносить в общую документацию: для них нужен защищённый способ передачи.
Снимите SEO-показатели до миграции
Выгрузите список индексируемых URL, страницы с поисковым трафиком, метатеги, заголовки, canonical, директивы индексации и входящие ссылки. Сохраните данные о видимости, органическом трафике, заказах и ошибках сканирования. Исходные показатели понадобятся для сравнения после запуска.
Автоматический краулинг стоит дополнить данными аналитики и панелей для вебмастеров. Страница может отсутствовать во внутренней навигации, но получать переходы из поиска или иметь внешние ссылки.
Шаг 2. Подготовьте требования и архитектуру новой CMS
Выбор CMS должен опираться на процессы магазина, а не на популярность платформы. До разработки проверьте, поддерживает ли система необходимый объём каталога, структуру торговых предложений, роли сотрудников, мультирегиональность, интеграции и SEO-настройки.
Полезно разделить требования на три группы:
- обязательные к запуску — без них магазин не может принимать и обрабатывать заказы;
- важные — влияют на эффективность продаж, но допускают временный обходной процесс;
- последующие улучшения — могут быть выпущены отдельными итерациями после стабилизации.
На этом этапе проектируют структуру каталога, фильтры, карточку товара, оформление заказа и личный кабинет. Одновременно определяют, какие URL останутся прежними. Сохранение адресов обычно безопаснее для SEO, чем полная смена структуры.
Разработку и загрузку данных проводите на закрытом тестовом контуре. Одного запрета в robots.txt недостаточно для защиты служебной версии от случайного доступа. Используйте авторизацию или сетевые ограничения и дополнительно запретите индексацию тестовых страниц.
Заранее подготовьте резервное копирование и план отката. План должен описывать, при каких ошибках запуск отменяется, как возвращается прежняя версия и что происходит с заказами, поступившими во время переключения.
Шаг 3. Перенесите данные и восстановите функции
Перед массовой миграцией выполните пробный перенос небольшой выборки. В неё должны входить простой товар, товар с вариантами, несколько типов цен, изображения, заказ, клиент и записи с нестандартными символами. Пробная загрузка выявляет несовпадение полей и форматов до работы со всем массивом.
Составьте карту соответствия полей
Карта показывает, куда попадёт каждое значение из старой системы. Например, артикул может храниться в отдельном поле, а не в названии варианта; производитель — в справочнике, а не в текстовом свойстве. Для обязательных полей задайте правила на случай пустых значений.
Желательно сохранить стабильные идентификаторы товаров и заказов либо создать таблицу соответствий старых и новых ID. Такая таблица упрощает обмен с внешними системами, проверку ошибок и поддержку старых ссылок из писем или CRM.
Определите очерёдность
Справочники и категории переносят раньше товаров, товары — раньше заказов, клиентов — до привязанных к ним заказов. После импорта проверяют не только количество записей, но и связи: варианты должны относиться к правильным товарам, изображения — открываться, а заказы — содержать корректные позиции и суммы.
Пароли пользователей требуют отдельного решения. Хеши из старой CMS могут быть несовместимы с механизмом авторизации новой системы. В таком случае безопаснее предусмотреть восстановление пароля, чем пытаться переносить пароли в открытом виде.
Спланируйте финальную синхронизацию
Между первой выгрузкой и запуском на старом сайте появляются новые заказы, клиенты и изменения остатков. Поэтому нужна дельта-миграция — повторный перенос данных, изменившихся после контрольной даты. Альтернативный вариант — короткий режим обслуживания, если бизнес может временно остановить оформление заказов.
Способ переключения выбирают с учётом допустимого простоя и сложности синхронизации. Независимо от схемы важно исключить ситуацию, когда часть заказов попала в старую CMS, а сотрудники уже работают только в новой.
Шаг 4. Сохраните SEO при смене платформы
Основной SEO-риск миграции — исчезновение доступных поиску страниц или изменение их адресов без корректной переадресации. Даже технически исправный магазин может потерять органический трафик, если новая CMS создаёт другие URL, закрывает разделы от индексации или меняет внутренние ссылки.
Для каждой старой страницы определите действие:
- оставить прежний URL и перенести содержание;
- настроить 301-редирект на максимально близкую по смыслу новую страницу;
- вернуть корректный код 404 или 410, если равноценной замены нет;
- объединить дубли и указать основную версию страницы.
Не перенаправляйте все удалённые товары на главную страницу. Для недоступного товара можно сохранить карточку с альтернативами либо поставить редирект на релевантную модель или категорию. Решение зависит от ассортимента, спроса и вероятности возвращения товара.
Проверьте коды ответа, отсутствие цепочек редиректов, canonical, пагинацию, страницы фильтров, sitemap.xml и правила сканирования. Внутренние ссылки должны сразу вести на конечные URL, а не проходить через переадресацию. Если магазин использует региональные или языковые версии, отдельно проверьте связи между ними.
Перенесите уникальные метатеги, заголовки, описания категорий, тексты карточек и микроразметку. Шаблонные правила генерации метаданных нужно проверить на товарах с пустыми или необычными полями: новая CMS не должна создавать пустые заголовки или бессмысленные повторы.
SEO-сопровождение не заканчивается в момент переключения домена. После запуска потребуется контролировать индексацию и спрос, а дальнейшее продвижение интернет-магазина планировать уже с учётом новой структуры и технических возможностей платформы.
Шаг 5. Протестируйте магазин и выполните запуск
Приёмка должна охватывать реальные пользовательские и рабочие сценарии, а не только внешний вид страниц. Тестируйте магазин на разных типах устройств и с разными ролями: гость, зарегистрированный покупатель, менеджер, контент-редактор и администратор.
До запуска проверьте:
- поиск, фильтры, сортировки, категории и карточки товаров;
- варианты товаров, цены, остатки, скидки и промокоды;
- корзину, регистрацию, авторизацию и восстановление пароля;
- оформление заказа для всех способов оплаты и доставки;
- создание заказа в CMS и передачу данных во внешние системы;
- уведомления покупателю и менеджеру;
- возврат после успешной, отменённой и неудачной оплаты;
- работу аналитики, электронной торговли, целей и рекламных событий;
- скорость ключевых шаблонов и поведение при высокой нагрузке;
- коды ответа, редиректы, метатеги и доступность страниц для роботов.
Оплату лучше проверять штатным тестовым режимом платёжного сервиса, если такой режим доступен. Также полезен ограниченный реальный заказ с последующей отменой или возвратом по установленной процедуре.
Запуск выполняйте в период прогнозируемо низкой активности, но только когда доступны специалисты, способные устранить ошибку. Перед переключением сделайте актуальные резервные копии, проведите финальную синхронизацию и зафиксируйте время изменения DNS или конфигурации сервера.
Сразу после запуска вручную пройдите критический путь от входа на главную страницу до получения заказа менеджером. Затем проверьте журналы ошибок, очереди обмена, отправку писем, платежи и заказы, созданные в первые часы.
Шаг 6. Контролируйте результат после миграции
Первые проверки должны быть техническими: доступность сайта, ошибки сервера, корректность редиректов, обмен остатками, оплата и доставка. Затем оценивают поисковые и коммерческие показатели. Период наблюдения зависит от частоты обхода сайта роботами, объёма каталога и сезонности спроса.
Сравнивайте показатели с периодом до миграции, учитывая рекламную активность, праздники и изменение ассортимента. Важны не только посещения, но и доля страниц в индексе, поисковые запросы, конверсия, ошибки оформления заказа и расхождения между CMS и учётной системой.
Падение трафика нельзя автоматически объяснять сменой платформы. Сначала проверьте доступность посадочных страниц, robots.txt, noindex, canonical, коды ответа, редиректы и внутреннюю перелинковку. Если технических ошибок нет, анализируйте изменения контента, спроса и поисковой выдачи.
Чек-лист приёмки переноса
- Все обязательные данные перенесены, их количество и связи проверены.
- Новые заказы, оплаты и статусы корректно попадают во все связанные системы.
- Цены, остатки, скидки, доставка и налоги рассчитываются по утверждённым правилам.
- Старые ценные URL сохранены или перенаправлены на релевантные страницы.
- Тестовый контур закрыт, а рабочий сайт открыт для индексации.
- Счётчики аналитики и события электронной торговли получают данные без дублей.
- Подготовлены резервная копия, инструкция отката и контакты ответственных.
- После запуска назначен мониторинг технических, поисковых и коммерческих показателей.
Перенос можно считать завершённым не после публикации новой версии, а после подтверждения стабильной работы заказов, интеграций и поисковых страниц. Некритичные улучшения лучше вынести в отдельный список, чтобы не смешивать исправление ошибок с развитием продукта.
Частые вопросы
Можно ли перенести магазин без потери позиций?
Полностью исключить колебания нельзя, но риск снижают сохранение URL, корректные 301-редиректы, перенос контента и метаданных, проверка индексации и мониторинг после запуска. Чем сильнее меняются структура и содержание, тем выше вероятность заметной переоценки страниц поисковыми системами.
Нужно ли переносить все старые товары?
Нет. Архивные товары без спроса, трафика и полезных ссылок можно не переносить. Для каждой удаляемой карточки нужно определить подходящий ответ сервера или релевантную замену, а не автоматически отправлять посетителя на главную страницу.
Можно ли одновременно сменить CMS, дизайн и структуру каталога?
Можно, но одновременные изменения повышают сложность тестирования и затрудняют поиск причины возможного падения показателей. При большом или зависимом от органического трафика магазине безопаснее разделять изменения на управляемые этапы.
Сколько времени занимает перенос?
Срок зависит от объёма каталога, качества исходных данных, числа интеграций, объёма индивидуальной разработки и требований к тестированию. Оценку следует делать после аудита, карты данных и фиксации функций, обязательных к запуску.
Кто должен участвовать в миграции?
Минимальный состав включает владельца бизнес-требований, разработчика, специалиста по данным или интеграциям, тестировщика и SEO-специалиста. Для сложного проекта также могут потребоваться аналитик, дизайнер, системный администратор и представители учётных систем.
Когда стоит привлекать SEO-специалиста?
SEO-специалиста следует подключать до утверждения структуры и разработки шаблонов. Исправление URL, индексируемых фильтров, метатегов и перелинковки после запуска обычно сложнее, чем включение этих требований в проект заранее.
