блог

Справочник Shopify

Переезд на Shopify начинается не с импорта: как перенести работающий магазин, а не набор товаров

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

Когда клиент говорит: «Нужно перенести магазин на Shopify», задача часто звучит почти технически: выгрузить товары, загрузить покупателей, подключить домен и открыть новую витрину.

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

Именно поэтому мы в IceStoreGroup начинаем миграцию не с кнопки «Импорт» (Import), а с карты магазина. Нужно понять, что существует сегодня, что действительно используется, что обязано сохраниться и что разумнее заменить. Такая подготовка занимает время. Но она обходится дешевле, чем искать после запуска, почему часть вариантов исчезла, старые ссылки ведут на ошибку, а склад, доставка или аналитика начали расходиться с реальностью.

Сначала ответьте на неудобный вопрос: зачем переходить

Shopify имеет объективные преимущества для бизнеса, которому важна предсказуемость эксплуатации. Это управляемая платформа с единым административным интерфейсом, стандартизированным оформлением заказа и развитой экосистемой приложений. Владельцу не нужно самостоятельно поддерживать сервер WordPress, обновлять его системные компоненты и разбирать конфликты между ядром, темой и десятками расширений. Для команды это часто означает меньше инфраструктурной рутины и понятнее ответственность за работу магазина.

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

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

Товар переносится строкой. Каталог — системой

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

На практике мы проверяем несколько уровней.

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

Официальная инструкция Shopify по миграции из WooCommerce отдельно предупреждает: данные перед импортом нужно сопоставить с форматом Shopify, а затем проверить цены, вес, остатки, изображения, варианты и поисковые описания. Для товаров с более чем тремя опциями может понадобиться другая модель — например, метаполя, приложение или индивидуальная логика. Порядок миграции из WooCommerce в Shopify.

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

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

«Импорт завершён» не означает «данные перенесены правильно»

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

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

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

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

Покупатели и история заказов требуют отдельного решения

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

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

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

Здесь мы заранее принимаем бизнес-решение: что должно жить в Shopify, что остаётся в архиве старой системы, а что доступно сотрудникам через внешнее хранилище. Переносить всё «на всякий случай» не всегда разумно. Но потерять данные, которые нужны поддержке и бухгалтерии, ещё дороже.

Витрину нельзя скопировать вместе с базой

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

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

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

Расширения WooCommerce нужно разложить на бизнес-функции

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

Поэтому мы составляем не список «чем заменить расширение», а реестр функций:

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

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

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

Поисковая видимость сохраняется до переключения домена, а не после

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

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

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

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

Как мы организуем безопасный переход

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

1. Обследование

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

2. Проектирование

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

3. Пробная миграция

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

4. Сборка и приёмка

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

5. Финальная синхронизация и запуск

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

6. Усиленный контроль после запуска

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

Когда помощь эксперта действительно оправданна

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

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

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

Переезд считается завершённым не тогда, когда открылся сайт

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

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

Мы выполняем её именно так: сохраняем доказуемо нужное, заменяем устаревшее осознанно и проверяем результат по данным и сценариям. Даже после качественного запуска никто не застрахован от будущих изменений приложений, интеграций или требований бизнеса. Поэтому защита строится не на обещании «проблем не будет», а на понятной архитектуре, документации, контрольных выгрузках и регулярной проверке. Подход к поиску таких изменений мы описали в статье о скрытых регрессиях Shopify.

Если вы планируете перенос действующего магазина из WooCommerce или другой платформы, обсудите проект с IceStoreGroup до того, как импорт станет необратимым набором ручных исправлений.

Bob Saylor

IceStoreGroup