Перенос интернет-магазина с Тильды на Битрикс: каталог, заказы и SEO
Магазин на Тильде уже продаёт. Но менеджер вручную проверяет остатки, для нового сценария заказа приходится искать обходное решение, а обслуживание каталога занимает всё больше времени. В этот момент возникает запрос: «перенесите всё на Битрикс, сохранив дизайн и позиции».
Сначала нужно определить, что скрывается за словом «всё». Товары, их варианты, фотографии, адреса страниц, заказы, доступы покупателей и связи с учётной системой — разные объекты. Они переносятся разными способами. Архив страниц и выгрузка каталога покрывают лишь часть работы.
В статье разберём перенос действующего интернет-магазина с Тильды на 1С-Битрикс: когда он оправдан, что запросить до оценки, как проверить каталог и как переключить торговлю. Для примеров используем официальные экраны Тильды. Числа и таблицы сопоставления ниже учебные, а не результаты клиентского переезда.
Сначала проверьте, нужна ли смена платформы
Запишите конкретное ограничение и желаемое поведение. «Нужна более серьёзная CMS» нельзя проверить на приёмке. «Заказ должен попадать в 1С с выбранным складом и единицей продажи» уже можно. После этого выясните, чего именно не хватает: настройки, интеграции, изменения процесса или самостоятельной разработки.
У Тильды есть товарный каталог, варианты товаров, личный кабинет магазина и интеграции. Нельзя обосновывать переезд общим утверждением, будто всего этого на платформе нет. Актуальный состав возможностей описан в официальной справке о каталоге. Для вашего магазина важен конкретный сценарий и ограничения его реализации.
| Причина обращения | Что проверить до переезда |
|---|---|
| Остатки обновляются вручную | Есть ли подходящий обмен и почему не используется сейчас |
| Не хватает удобного фильтра | Заполнены ли свойства товаров и какое поведение требуется |
| Нужны дилерские условия | Организации, договоры, права, прайсы и повторные закупки |
| Хотим улучшить поисковый трафик | Какие страницы и запросы проседают, что мешает их развивать |
| Нужен собственный процесс оформления | Правила цены, доставки, подтверждения и работы менеджеров |
Если проблема решается небольшой доработкой и магазин устраивает команду, сначала оцените этот путь. Переезд приносит дополнительную работу даже при сохранении внешнего вида. Он оправдан, когда новая система позволяет реализовать нужный процесс и компания готова его обслуживать.
Разделите требования на обязательные для запуска и желательные. Собственная логика согласования заказа может быть обязательной; новая анимация каталога — нет. Такой список помогает не превратить техническую миграцию в бесконечный редизайн.
Перенос данных, экспорт ZIP и плагин — разные варианты работы
Для товаров Тильда предоставляет импорт и экспорт CSV и YML. Эти файлы подходят для работы с товарными данными, но не являются копией всей торговли: отдельно остаются страницы, процессы заказов и подключённые сервисы.
Выгрузка HTML-страниц решает другую задачу. В справке об экспорте кода перечислены ограничения: вместе с архивом не появляется независимая панель управления каталогом, а Tilda CRM и личный кабинет не экспортируются. Поэтому ZIP нельзя считать готовым магазином на Битриксе.
Есть и плагин для размещения страниц Тильды в Битриксе. Он подключает проект и выбранную страницу; в инструкции требуется доступ к API на тарифе Business. Такой вариант может подходить для отдельных промостраниц. По самому факту подключения нельзя заключить, что товары, покупатели и заказы теперь работают как объекты Битрикса.
На этом официальном снимке видны выбор проекта, выбор страницы и очистка кеша компонента. Это иллюстрация из действующей инструкции, а не экран установленной у нас версии модуля. Совместимость и актуальные настройки проверяют перед внедрением.
В предложении подрядчика должно быть прямо написано, какой вариант выполняется. Для самостоятельного магазина обычно нужны реализация шаблонов и торговых компонентов в Битриксе, перенос принадлежащего компании контента и настройка интеграций. Условия использования исходного кода, шрифтов, фотографий и других материалов учитываются отдельно; наличие архива не отменяет их.
Что собрать до расчёта стоимости
Начните с инвентаризации. Важно найти не только страницы в меню, но и адреса из поиска, рекламы, товарных фидов, рассылок и внешних ссылок. Проверьте, где сейчас хранятся заказы: в CRM, учётной системе, подключённом сервисе или нескольких местах одновременно.
| Что подготовить | Какой вопрос это закрывает |
|---|---|
| Список страниц и товарных адресов | Что сохраняется и для чего нужна переадресация |
| Выгрузка каталога с вариантами | Как устроены товары, связи, свойства и идентификаторы |
| Примеры обычного и сложного заказа | Что должна поддержать новая корзина и обработка |
| Перечень платёжных и доставочных интеграций | Что требуется подключить и испытать заново |
| Описание обмена с 1С или другой системой | Где источник цен, остатков, номенклатуры и статусов |
| Доступная статистика по страницам | Какие адреса и сценарии проверить в первую очередь |
Для предварительной оценки обычно полезнее обезличенная выборка сложных товаров, чем архив всех доступов. Включите позицию с несколькими вариантами, товар с длинным описанием и позицию без остатка. Пароли, секретные ключи и данные покупателей в такой выборке не нужны.
Отдельно проверьте право компании управлять доменом, хостингом и подключёнными сервисами. Перенос сайта не должен зависеть от единственного человека, у которого на личном аккаунте зарегистрирован домен. До переключения также выясняют, какие DNS-записи обслуживают почту: они не должны случайно измениться вместе с адресом сайта.
Каталог проверяют по вариантам, а не только по числу карточек
Рассмотрим учебный каталог: 240 карточек и 930 продаваемых вариантов. После импорта на новом сайте появилось 240 красивых страниц. Этого недостаточно для приёмки. У кресла могли исчезнуть размеры, у одежды — цвета, а у комплекта — отдельная цена. Для покупателя такой товар уже другой.
Сначала составьте таблицу связей между источником и новой системой. Ниже показана рабочая таблица проекта, а не готовый формат стандартного импорта Тильды или Битрикса.
| Объект | Идентификатор в источнике | Родитель | Объект в новой системе |
|---|---|---|---|
| Кресло «Линия» | product-018 | — | Товар P-018 |
| Кресло, серое, размер M | variant-018-gray-m | product-018 | Предложение S-018-01 |
| Кресло, серое, размер L | variant-018-gray-l | product-018 | Предложение S-018-02 |
В документации Тильды для вариантов показана связь идентификатора основного товара с дочерними строками. Для переноса важно сохранить саму связь и проверить её в своей выгрузке. Нельзя выбирать родителя по похожему названию, если есть устойчивый идентификатор.
Название, артикул и внешний идентификатор выполняют разные задачи. Название можно отредактировать; артикул иногда повторяется у вариантов или поставщиков. Идентификатор обмена связывает объект с учётной системой. Если свести всё к одному полю, последующий импорт может создать дубли вместо обновления.
Проверьте значения с ведущими нулями. Артикул «00127» не должен незаметно превратиться в «127» после открытия таблицы. Также проверьте перенос строк, разделители, кавычки и кодировку на небольшой выборке. Ошибка в одной такой операции иногда затрагивает весь каталог, хотя первые три карточки выглядят правильно.
После повторного импорта той же выборки количество объектов не должно увеличиваться без причины. Затем измените один вариант в источнике и убедитесь, что обновился именно он. Это проверяет не только одноразовый перенос, но и будущую поддержку данных.
Описания, фотографии и вкладки принимаются отдельно
Откройте несколько карточек, на которых есть материал за пределами короткого описания: характеристики, инструкция, условия ухода, таблица размеров. При переносе легко сохранить название и цену, но потерять сведения, по которым человек выбирал товар.
У экспорта CSV в Тильде есть дополнительные настройки, в том числе выгрузка табов. Проверьте состав полученного файла до оценки переноса: какие сведения в нём есть, а какие нужно получать отдельно. Сам установленный флажок не доказывает, что новая система правильно распределила содержимое по нужным вкладкам.
Для изображений нужен отдельный список соответствий: товар, вариант, файл, порядок и назначение. Обложка карточки, галерея и фотография конкретного цвета могут различаться. Не стоит считать фотографии успешно перенесёнными, пока новый сайт продолжает зависеть от незапланированных ссылок на старый проект.
Проверяйте и исходное качество, и вывод на телефоне. Миниатюра из каталога не всегда подходит для галереи. Высокое разрешение само по себе тоже не гарантирует хороший результат: важные детали могут исчезнуть из-за обрезки. В приёмку полезно включить вертикальный снимок, широкий интерьер и фотографию с предметом у края.
Как сохранить адреса страниц и не обещать неизменные позиции
Составьте карту «старый адрес → действие → новый адрес». Где возможно, сохраните существующий путь. Если он меняется, назначьте постоянную переадресацию на соответствующую страницу. Не отправляйте все исчезнувшие товары на главную: посетитель должен попасть в ожидаемый контекст, а не начинать поиск заново.
Например, для учебного адреса /chairs/line-gray можно сохранить тот же путь. Если ассортимент перестроен, в карте указывают новый адрес и причину. Для снятого с продажи товара отдельно решают, нужна ли информационная карточка, реальная замена или страница отсутствующего товара. Это редакционное решение по конкретной позиции, а не единое правило для всех URL.
У Яндекса переезд сайта связан с изменением адреса. Смена CMS при сохранении домена не является автоматическим основанием менять основной адрес в Вебмастере. При изменении отдельных путей проверяют именно эти URL, их ответы и переадресации.
В новой системе сверьте заголовки, описания, основной текст, внутренние ссылки и указанный канонический адрес. Canonical и перенаправление выполняют разные задачи. Нельзя оставлять рабочую карточку со ссылкой на старый основной адрес и считать это законченным переносом.
Для приёмки удобно сохранить набор важных страниц: входы из поиска, категории с продажами и несколько сложных товаров. После запуска проверяйте их отдельно от общего числа посещений. Колебания спроса, изменения рекламы и технические визиты не следует выдавать за эффект миграции. Обещание «позиции гарантированно останутся прежними» не заменяет карту URL и наблюдение после запуска.
Заказы и покупатели не переезжают вместе с товарным CSV
Определите, какие исторические данные нужны в новой системе. Иногда достаточно оставить менеджерам доступ к прежней CRM и перенести активные заказы. В другом проекте покупатель должен видеть всю историю в личном кабинете. Это разный объём работ и разные проверки.
Не обещайте сохранить вход по прежнему паролю до проверки доступного механизма переноса аккаунтов. При невозможности безопасного переноса нужен согласованный способ восстановления доступа. Адрес электронной почты в таблице ещё не подтверждает правильность связи человека с заказами.
Для каждого активного заказа нужны как минимум источник, номер, состав, текущий статус и место дальнейшей обработки. Сохраните связи с платёжной операцией и доставкой. Если деньги поступят после переключения сайта, уведомление должно обновить правильный заказ, а не создать новый или остаться без обработки.
Новую интеграцию с 1С проверяйте на ограниченной выборке. Сначала один товар, его вариант, изменение цены и остатка; затем заказ и обратное обновление статуса. Одноразово импортировать каталог и наладить рабочий двусторонний процесс — разные результаты. Подробный разбор есть в статье об обмене магазина с 1С.
Переключение торговли: что происходит с заказом между двумя версиями
Пока новый магазин готовится на закрытом тестовом адресе, старый продолжает получать изменения. После первой выгрузки появились товары, фотографии и заказы. Поэтому перед запуском нужен дополнительный перенос изменений, а не просто повтор старого файла целиком.
Назначьте источник каждого типа данных в момент переключения. Кто вносит последние изменения в каталог? Где принимаются новые заказы? Кто сверяет оплаты? Нельзя допускать, чтобы две команды одновременно считали свою базу единственной актуальной.
- Подготовить новую версию. Каталог, адреса, формы, доставка и оплата проверены на тестовых сценариях.
- Зафиксировать исходное состояние. Сохранены резервные копии, список активных заказов и момент последней синхронизации.
- Перенести изменения. Догружены согласованные данные, появившиеся после первоначальной выгрузки.
- Переключить сайт. Проверены домен, сертификат и доступность нужных маршрутов; ответственный наблюдает за поступлением заказов.
- Сверить торговые операции. Заказы и оплаты из обеих версий сопоставлены по идентификаторам, пропуски и дубли разобраны.
- Подтвердить завершение. Старые сервисы отключаются после проверки зависимостей и согласованного периода наблюдения.
План возврата должен учитывать уже принятые новые заказы. Простое восстановление старой базы может их потерять. До запуска определите, где операции сохраняются независимо от версии витрины и как будут перенесены обратно при возврате. Архив файлов без такого сценария не является достаточным планом отката торговли.
Не отключайте обработку уведомлений старых оплат только потому, что главная страница уже открывается на новом сервере. Сначала требуется завершить или корректно перенести связанные операции. Конкретная схема зависит от используемых сервисов; её проверяют вместе с интеграцией.
За что платить в смете и как принять перенос
Просите оценку по результатам, которые можно проверить. В одной строке «перенос на Битрикс» могут скрываться только страницы или полноценный магазин с торговыми предложениями, заказами и интеграциями. Пока состав не назван, сравнение двух итоговых цен мало что говорит.
| Часть работ | Подтверждение результата |
|---|---|
| Каталог | Сопоставлены товары и варианты; повторный импорт не создаёт дубли |
| Контент | Сохранены описания, вкладки, документы и привязки изображений |
| Интерфейс | Проверены реальные товары, ошибки и оформление на телефоне |
| Поисковые адреса | Есть карта URL; проверены переходы и конечные страницы |
| Торговые интеграции | Подтверждён путь заказа, оплаты, доставки и обмена |
| Запуск | Определены ответственные, сверка операций и возврат с сохранением новых данных |
Отдельно укажите покупку лицензий, готовых решений, хостинг и дальнейшее сопровождение. Срок зависит не только от количества страниц: сложные варианты товаров, неописанные правила доставки и исторические заказы могут оказаться важнее внешнего объёма сайта.
Для предварительной проверки используйте таблицу приёмки переноса. Её стоит заполнить до старта, затем дополнить особенностями своего магазина. Важен ожидаемый результат каждого сценария, а не только отметка, что разработчик открыл страницу.
С чего начать обсуждение проекта
Пришлите ссылку на действующий магазин, пример сложного товара и короткий список причин переезда. Если есть выгрузка публичного каталога, приложите обезличенный фрагмент без доступов и данных покупателей. На первом обсуждении нужно определить, что сохраняется, что перестраивается и какие условия необходимо выяснить для оценки.
В CAPS мы занимаемся разработкой магазинов на 1С-Битрикс и интеграциями с учётными системами. В проекте Primula выполняли полный цикл разработки магазина и подключение 1С. Это подтверждённый пример нашей работы с торговым процессом, а не заявление, что этот магазин переносился с Тильды.
Предметный результат оценки — перечень переносимых данных, карта важных страниц, состав новой торговли и план переключения. С ним можно принимать решение о переезде и сравнивать предложения подрядчиков на одном объёме.
Источники и примеры интерфейсов
Проверено 21 октября 2026 года. Изображения интерфейса взяты из официальных инструкций Тильды; это не скриншоты клиентских кабинетов CAPS. Снимок компонента Битрикс является исторической иллюстрацией в текущей инструкции, установленную версию нужно проверять отдельно. Учебные идентификаторы и объёмы каталога придуманы для объяснения процесса.
