Переезд интернет-магазина на новую платформу пугает предсказуемо: за старым сайтом стоят годы работы, накопленный поисковый трафик, база клиентов и история заказов, и любой владелец бизнеса больше всего боится «проснуться» после запуска без позиций и без продаж. Этот страх обоснован ровно наполовину: миграция действительно способна обрушить трафик — но только если сделана небрежно. Аккуратный переезд сохраняет и SEO, и данные, и клиентов, а нередко ещё и ускоряет магазин за счёт более правильной технической платформы.
Эта статья — практическое руководство по миграции на Битрикс с другой платформы: OpenCart, WooCommerce, MODX, Tilda, Insales или самописного движка. Разберём, почему бизнес решается на перенос магазина на Битрикс, что именно переносится и как, и главное — как выполнить смену платформы без потери SEO: составить карту соответствия старых адресов новым, настроить 301-редиректы, сохранить метатеги и не растерять позиции. Материал основан на нашей практике услуги переезда и миграции сайтов на 1С-Битрикс — без выдуманных цифр и обещаний «перенесём за один вечер без последствий».
Коротко
- Миграция — это перенос двух вещей: данных (каталог, клиенты, заказы, контент) и SEO-сигналов (адреса, метатеги, структура).
- Главный риск переезда — потеря трафика. Снимается он картой редиректов и постраничными 301 со старых URL на новые.
- Переносят по-разному: экспорт/импорт через Excel/CSV/XML для типовых CMS и скриптовую миграцию из базы для самописа и MODX.
- Новый магазин собирают и тестируют на копии, а переключают трафик сменой DNS — без простоя, пока обе версии рабочие.
- После запуска проверяют редиректы, индексацию, аналитику, работу заказа и скорость — и держат сайт под усиленным мониторингом.
Почему магазины переезжают на 1С-Битрикс
Миграция — всегда следствие боли, а не каприза: переносить работающий магазин на новую платформу дорого и рискованно, поэтому на это решаются, когда старая платформа начинает мешать бизнесу расти. Понимание своей причины важно не ради формальности: именно она определяет, что критично сохранить при переезде, а чем можно пожертвовать. Разберём типичные мотивы.
Упёрлись в потолок платформы. Самая частая причина. Магазин вырос, а движок не тянет новые задачи: нет нормальных типов цен для опта, не сделать личные кабинеты дилеров, нельзя гибко настроить фильтр или скидки, каждая доработка превращается в борьбу с архитектурой. Конструкторы вроде Tilda прекрасны для старта, но у них есть жёсткий предел сложности каталога и бизнес-логики — и в этот предел рано или поздно упирается любой растущий магазин.
Нужен полноценный обмен с 1С. Для российского бизнеса это часто решающий довод. Когда учёт ведётся в 1С, а сайт живёт «своей жизнью», расхождения в остатках и ценах становятся ежедневной проблемой. 1С-Битрикс изначально проектировался под тесную интеграцию с 1С, и штатный обмен по CommerceML работает предсказуемее, чем сторонние коннекторы на других платформах. Ради нормального обмена нередко и затевают весь переезд.
Нагрузка и скорость. Магазин, который «ложится» в пик распродажи или медленно грузится на большом каталоге, теряет деньги напрямую. Иногда проблема в самой платформе, которая не рассчитана на такой объём данных и трафика. Битрикс с его композитным кэшем и инструментами оптимизации способен держать серьёзную нагрузку — и это становится аргументом для миграции с движка, который «задыхается».
Разрозненный зоопарк систем. Сайт на одной платформе, CRM на другой, учёт в третьей, и всё это склеено костылями. Экосистема 1С-Битрикс (сайт, Битрикс24, обмен с 1С) позволяет свести это в единый согласованный контур, и желание навести порядок в данных тоже толкает к переезду.
Безопасность и поддержка. Самописный движок, который поддерживал один ушедший разработчик, или заброшенная CMS без обновлений — это мина. Битрикс регулярно выпускает обновления безопасности и имеет большой рынок специалистов, поэтому переезд на него снижает риск «остаться один на один с непонятным кодом».
С каких платформ переносят чаще всего
Технически миграция на Битрикс возможна с любой платформы — отличается только способ извлечения данных и сложность сохранения URL. Но у каждого источника своя специфика, которую полезно знать заранее, потому что она определяет и трудоёмкость, и подводные камни. Пройдёмся по типичным «донорам».
| Откуда переносят | Как обычно выгружают данные | Особенность миграции |
|---|---|---|
| OpenCart | Экспорт в CSV/Excel, выгрузка из MySQL | Понятная структура БД, но много кастомных модулей и своя схема ЧПУ |
| WooCommerce / WordPress | Экспорт товаров и заказов, доступ к БД | Данные размазаны по метаполям, важен перенос блога и его URL |
| MODX | Скрипт по базе, парсинг | Гибкая, но нестандартная структура — почти всегда скриптовая миграция |
| Tilda | Экспорт каталога, парсинг витрины | Ограниченный доступ к данным, каталог и контент часто собирают вручную |
| InSales | Экспорт товаров и заказов, API | Есть выгрузки, но своя схема URL — нужна тщательная карта редиректов |
| Самописный движок | Прямой доступ к БД, скриптовая миграция | Непредсказуемая структура, каждый проект уникален |
OpenCart и WooCommerce — самые «удобные» доноры: у них открытая база и понятная структура, каталог, клиентов и заказы можно выгрузить и модулями, и напрямую из MySQL. Главная забота здесь — кастомные модули и своя схема ЧПУ, которую нужно аккуратно переложить в карту редиректов. У WooCommerce отдельное внимание — блогу на WordPress: часто именно статьи приводят большую часть трафика, и их адреса нельзя терять.
MODX и самопис — самые трудоёмкие: у них нет типовой структуры, поэтому данные почти всегда тянут скриптом напрямую из базы, разбираясь в конкретной схеме таблиц. Тут невозможно «нажать экспорт» — миграция становится инженерной задачей, зато скрипт можно прогнать многократно, отлаживая результат на копии.
Tilda и InSales — обратная крайность: платформы закрытые, к базе доступа почти нет. Переносят то, что отдаёт штатный экспорт (товары, заказы), а остальное собирают парсингом витрины и ручным переносом. Именно с конструкторов чаще всего и мигрируют, упёршись в их предел, — про сравнение возможностей мы писали в материале о выборе между полноценной CMS и конструктором. Если вы двигаетесь именно этим маршрутом, полезно заранее прикинуть критерии выбора платформы на 2026 год.
Что переносится при миграции: общая карта
Прежде чем нырять в детали, полезно увидеть всю картину целиком. Миграция магазина — это перенос двух больших пластов: данных (то, чем наполнен магазин) и SEO-наследия (то, за счёт чего он находится в поиске). Ошибка новичков — думать только о данных: «перенесли товары, значит переехали». На деле именно SEO-пласт определяет, сохранит магазин трафик или начнёт с нуля.
Вот что входит в каждый пласт:
- Каталог и категории. Дерево разделов и подкатегорий — скелет магазина, от которого зависят и навигация, и URL, и фильтры.
- Товары со свойствами и картинками. Карточки с характеристиками, ценами, остатками, фотографиями и, если есть, торговыми предложениями (размеры, цвета).
- Клиенты. База зарегистрированных покупателей с контактами, адресами, историей — то, на чём строится повторные продажи.
- Заказы. История покупок: важна и для клиентов (их «мои заказы»), и для аналитики, и для бухгалтерии.
- Контент. Страницы «О компании», «Доставка», «Оплата», статьи блога, посадочные страницы, отзывы.
- SEO-сигналы. Адреса страниц (или карта редиректов), метатеги, заголовки, микроразметка, robots.txt, sitemap, внешние ссылки.
При этом не всё нужно тащить в новый магазин механически. Старый неоптимальный код, кривую вёрстку, устаревшие плагины и «мусорные» страницы переносить не стоит — переезд как раз удобный повод от них избавиться. Что именно взять с собой, а что оставить в архиве, решается на аудите; об этом дальше.
Аудит: с чего начинается переезд
Ни одна миграция не начинается с переноса данных. Она начинается с аудита — инвентаризации того, что есть на старом сайте, и решения, что и как переносить. Пропустить этот этап — значит гарантированно что-то потерять: страницу, редирект, кусок базы. Аудит превращает расплывчатое «перенесите магазин» в понятный список работ и снимает большую часть рисков ещё до первой строчки кода.
Что выясняют на аудите:
- Инвентаризация данных. Сколько товаров, категорий, свойств, есть ли вариации, сколько клиентов и заказов, какие типы цен. Это определяет объём работы по переносу.
- Полная выгрузка URL. Собирают все адреса старого сайта из sitemap, серверных логов, панелей вебмастеров и краулером. Это основа будущей карты редиректов.
- Оценка SEO-наследия. Какие страницы приносят трафик, по каким запросам, где стоят внешние ссылки. Эти страницы переносят с особой аккуратностью.
- Ревизия интеграций. Что подключено на старом сайте: 1С, CRM, оплата, доставка, кассы, аналитика. Всё это придётся воспроизвести на новом.
- Оценка качества данных. Насколько чистая база: нет ли дублей товаров, битых картинок, пустых свойств. Грязные данные — главный пожиратель времени миграции.
- Решение «что не переносим». Устаревшие страницы, снятые с продажи товары, мусорные URL — часть данных сознательно оставляют в архиве или сводят редиректами к живым разделам.
Результат аудита — не отчёт «для галочки», а рабочие документы: реестр данных к переносу, черновик карты редиректов, список интеграций и перечень рисков. С ними миграция перестаёт быть прыжком в неизвестность и становится управляемым проектом с понятными этапами. Именно на аудите чаще всего выясняется, что «просто перенести» не получится — и лучше узнать это в начале, чем в день запуска.
Перенос каталога и структуры категорий
Каталог — скелет магазина, и с него обычно начинают перенос данных. Задача — воспроизвести в Битриксе дерево разделов и подкатегорий, а затем разложить по нему товары. Звучит просто, но здесь закладывается фундамент и для навигации, и для URL, и для фильтров, поэтому спешить нельзя.
Ключевые решения на этом этапе:
- Сохранять или перестраивать структуру. Если старое дерево категорий логично и приносит трафик, его повторяют один в один — так проще с редиректами. Если структура была хаотичной, переезд — повод её причесать, но тогда обязательно продумать редиректы со старых разделов.
- Глубина вложенности. В Битриксе разделы инфоблока — это иерархия, и её проектируют осознанно: слишком глубокое дерево неудобно и людям, и SEO.
- ЧПУ разделов. Адреса категорий стараются сохранить или свести к аккуратным ЧПУ, потому что именно категории часто ранжируются по коммерческим запросам.
- Привязка товаров к нескольким разделам. Если товар на старом сайте был в нескольких категориях, решают, как это отразить в Битриксе (основной раздел плюс дополнительные привязки).
Технически структуру переносят либо импортом (если старый сайт отдаёт дерево категорий в выгрузке), либо скриптом, который читает разделы из старой базы и создаёт разделы инфоблока. Важно на этом шаге сразу фиксировать соответствие «старый ID категории → новый ID раздела» — оно понадобится и для раскладки товаров, и для карты редиректов. Аккуратно перенесённая структура — половина успеха: на неё дальше «нанизывается» всё остальное.
Перенос товаров: свойства, картинки, вариации
Товары — самая объёмная часть переноса, и здесь дьявол в деталях. Перенести «название и цену» умеет любой скрипт; сложность в том, чтобы сохранить всё богатство карточки: характеристики, фотографии, вариации, SEO-поля. Именно на товарах чаще всего вылезают потери, которые замечают уже после запуска.
Что переносится в карточке товара:
| Элемент карточки | Куда ложится в Битриксе | На что обратить внимание |
|---|---|---|
| Название, описание, анонс | Поля элемента инфоблока | Сохранить форматирование и внутренние ссылки |
| Свойства и характеристики | Свойства инфоблока | Нормализовать значения, свести дубли («Синий»/«синий») |
| Цены и остатки | Модуль торгового каталога | Типы цен, валюта, учёт остатков |
| Фотографии | Детальная, анонс, доп. картинки | Перенести файлы, а не только ссылки; проверить битые |
| Вариации (размер, цвет) | Торговые предложения (SKU) | Связать вариации с родителем, сохранить артикулы |
| SEO-поля товара | title, description, H1 карточки | Перенести или сгенерировать по шаблону |
| Артикул, штрихкод | Поля торгового каталога | Уникальность, совпадение с 1С |
Картинки и медиа
Отдельная тема — картинки. Их переносят как файлы, а не как ссылки на старый домен: если оставить пути на старый сервер, после его отключения все фото «отвалятся». Заодно проверяют битые изображения и по возможности пережимают тяжёлые файлы — переезд удобный момент навести порядок в медиатеке.
Товары с вариациями
Если у товаров есть вариации, их раскладывают в торговые предложения Битрикса — отдельный инфоблок офферов, связанный с товарами. Это чувствительная часть: важно сохранить связь вариации с родителем и уникальные артикулы, иначе каталог «рассыплется». Как устроены торговые предложения, мы подробно разбирали в материале про торговые предложения (SKU) в 1С-Битрикс. А сам механизм загрузки каталога из таблиц — в статье про импорт каталога из Excel и CSV в Битрикс.
Перенос клиентов и заказов
Каталог виден всем, а вот клиенты и заказы — это то, что нельзя восстановить, если потеряешь. База покупателей и история продаж — актив бизнеса, и переносить их нужно с особой аккуратностью, потому что здесь замешаны и повторные продажи, и персональные данные, и бухгалтерия.
База клиентов
Клиенты. Зарегистрированных покупателей переносят в пользователей Битрикса с их контактами, адресами доставки и, где возможно, историей. Тонкий момент — пароли: их из старой базы обычно не переносят в открытом виде (да и хранятся они хэшами), поэтому клиентам либо предлагают восстановить пароль при первом входе, либо настраивают бесшовный вход. Об этом важно предупредить покупателей письмом заранее, чтобы вход в личный кабинет после переезда не стал сюрпризом.
История заказов
Заказы. Историю заказов переносят, чтобы клиенты видели свои прошлые покупки, а бизнес не терял аналитику и данные для бухгалтерии. Заказы связывают с перенесёнными клиентами и товарами — и здесь снова важна карта соответствия ID, которую вели с самого начала. Иногда всю историю не тащат в живую базу, а часть старых заказов оставляют в архиве — это решение принимают на аудите, взвешивая пользу и объём.
Отдельно держите в голове юридическую сторону: клиентская база — это персональные данные, и обращаться с ними при переносе нужно по правилам, с защищённым каналом передачи и без утечек через промежуточные файлы. Выгрузку клиентов не стоит гонять по почте незашифрованной — это и риск, и нарушение.
Перенос контента: страницы, блог, отзывы
Про товары помнят все, а вот контент при миграции нередко теряют — и зря, потому что именно он часто приносит информационный трафик и работает на доверие. К контенту относятся служебные страницы, блог и пользовательский контент вроде отзывов, и у каждого типа своя специфика переноса.
- Служебные страницы. «О компании», «Доставка и оплата», «Гарантия», «Контакты», «Политика конфиденциальности» — их переносят с сохранением адресов, потому что на них часто ведут ссылки и из меню, и извне.
- Блог и статьи. Если на старом сайте был блог (особенно на WooCommerce/WordPress), статьи могут давать заметную долю трафика. Их переносят как отдельный инфоблок с сохранением или редиректами URL — терять адреса статей нельзя.
- Отзывы. Пользовательские отзывы к товарам — это и контент для SEO, и социальное доказательство. Их переносят и привязывают к соответствующим товарам, иначе карточки после переезда «оголятся».
- Посадочные и акционные страницы. SEO-страницы под запросы, лендинги под акции — их инвентаризируют отдельно и решают судьбу каждой: перенести, обновить или свести редиректом.
Контент коварен тем, что его легко «забыть»: в фокусе внимания каталог, а десяток информационных страниц выпадает из плана — и после запуска обнаруживается, что статья, годами приводившая трафик, теперь отдаёт 404. Поэтому контентные URL включают в общую карту редиректов наравне с товарами и категориями. Никакой адрес, у которого есть история или входящие ссылки, не должен «повиснуть» после переезда.
Способы переноса: импорт против скриптовой миграции
Технически перенести данные можно двумя принципиально разными путями, и выбор между ними определяет и трудоёмкость, и точность миграции. Оба рабочие; вопрос в том, что отдаёт старая платформа и насколько сложны данные.
Экспорт/импорт через файлы. Старый сайт выгружает данные в Excel, CSV или XML, а Битрикс их импортирует. Подходит, когда платформа умеет отдавать структурированную выгрузку (OpenCart, WooCommerce, InSales, Tilda в пределах возможного). Плюсы — прозрачность (файл можно открыть, проверить, почистить) и относительная простота. Минусы — форматы не всегда совпадают, сложные связи (вариации, множественные свойства) в плоской таблице передаются тяжело, а ручные шаги повышают риск ошибки.
Скриптовая миграция. Пишут скрипт, который читает данные напрямую из старой базы и создаёт элементы в Битриксе через его API. Это единственный путь для MODX, самописа и любых нестандартных схем. Плюсы — полный контроль, перенос любых связей и полей, повторяемость (скрипт гоняют многократно, отлаживая результат). Минусы — это разработка: дороже и требует доступа к базе и понимания её структуры.
| Критерий | Экспорт/импорт (файлы) | Скриптовая миграция |
|---|---|---|
| Когда подходит | Типовые CMS с выгрузкой | Самопис, MODX, сложные связи |
| Прозрачность | Высокая — файл видно | Средняя — логика в коде |
| Сложные данные (вариации) | Передаются тяжело | Передаются точно |
| Повторяемость прогона | Ручные шаги | Запуск скрипта многократно |
| Стоимость | Ниже | Выше (разработка) |
На практике часто комбинируют: каталог и товары везут скриптом из базы, а справочники или мелкие данные — файлом. Что важнее выбора инструмента — это прогонять миграцию на копии столько раз, сколько нужно, пока результат не совпадёт с оригиналом. Именно повторяемость отличает надёжную миграцию от «перенесли один раз и надеемся, что всё на месте». Подробно про табличный импорт каталога — в отдельном разборе импорта каталога из Excel и CSV.
Главное — сохранение SEO при переезде
Мы подошли к сердцу всей статьи. Перенести данные — задача решаемая; по-настоящему рискованна именно смена платформы без потери SEO. Поисковый трафик — это годами накопленный актив: позиции, вес страниц, поведенческие сигналы, внешние ссылки. Небрежный переезд способен обнулить его за один день, и восстанавливаться потом придётся месяцами.
Почему миграция угрожает SEO? Потому что поисковик знает ваш сайт как набор адресов с определённым содержимым, метатегами и весом. Когда вы меняете платформу, потенциально меняется всё это сразу: адреса становятся другими, вёрстка и метатеги — новыми, структура — иной. Если поисковик приходит и находит на привычном адресе 404 или совсем другую страницу, он воспринимает это как исчезновение страницы — и трафик уходит.
Задача сохранения SEO сводится к тому, чтобы для поисковика переезд был максимально бесшовным. В идеале робот вообще не должен «заметить» смену платформы: те же адреса (или честные 301 на новые), те же метатеги, та же структура, то же или лучшее содержимое. Три кита SEO-безопасной миграции:
- Адреса. Сохранить URL один в один либо настроить постраничные 301-редиректы со старых на новые. Это самый важный пункт.
- Метатеги и содержимое. Перенести title, description, заголовки H1, тексты и микроразметку, чтобы страница осталась релевантной тем же запросам.
- Техническое SEO. Корректные robots.txt и sitemap, канонические адреса, отсутствие дублей, скорость не хуже прежней.
Всё остальное в SEO-части миграции — производные этих трёх пунктов. Дальше разберём каждый подробно, начиная с самого критичного — работы с адресами. Общая тема редиректов и склейки URL глубоко раскрыта в отдельном материале про 301-редиректы, 404 и склейку URL в Битриксе — рекомендуем прочитать его в связке с этой статьёй.
Маппинг старых URL на новые
Маппинг URL — это ядро SEO-безопасной миграции. Суть проста: нужно для каждого адреса старого сайта определить, какому адресу нового он соответствует. Результат этой работы — таблица соответствия, из которой потом рождаются 301-редиректы. Без маппинга редиректы настраивать не из чего, а без редиректов теряется трафик — поэтому эта работа неизбежна.
Начинается всё с полного списка старых URL. Собирают его из нескольких источников, потому что ни один по отдельности не даёт полной картины:
- Sitemap.xml старого сайта — основной перечень страниц, которые сайт сам считает важными.
- Панели вебмастеров (Яндекс.Вебмастер, Google Search Console) — реально проиндексированные адреса и те, что приводят трафик.
- Серверные логи и аналитика — какие URL реально посещаются, включая те, что не попали в sitemap.
- Краулер (сканер сайта) — обходит сайт по ссылкам и находит всё, до чего дотягивается робот.
Дальше каждому старому URL сопоставляют новый. Категорий соответствий обычно три: адрес сохраняется без изменений (тогда редирект не нужен), адрес меняется (нужен 301 на новый), страница исчезает (её сводят редиректом на ближайший подходящий раздел, а не бросают на 404). Именно последний случай требует головы: для снятого товара логично вести на его категорию, для устаревшей акции — на актуальный раздел, для склеенного дубля — на канонический адрес.
Хороший маппинг — это не разовая таблица, а выверенный документ, где нет «повисших» строк: у каждого значимого старого URL есть назначение. Именно полнота маппинга определяет, сохраните вы трафик или потеряете его кусками. Экономить время на этом этапе — самая дорогая ошибка миграции.
301-редиректы и карта редиректов
Когда маппинг готов, он превращается в карту редиректов — набор правил переадресации, которые сообщают браузеру и поисковику: «страница переехала навсегда, вот новый адрес». Ключевое слово — «навсегда»: для миграции используют именно постоянный редирект 301, а не временный 302. Разница принципиальна: 301 передаёт новому адресу накопленный вес старого, а 302 — нет, поэтому ошибка с типом редиректа тихо «съедает» SEO.
Что важно в настройке редиректов при переезде:
- Постраничность. Редиректы делают адрес-в-адрес, а не «всё старое на главную». Массовый редирект на главную поисковик считает мягкой ошибкой 404, и вес не передаётся. Каждая страница ведёт на свой аналог.
- Тип 301. Только постоянный редирект. Временные 302/307 при миграции — ошибка.
- Без цепочек. Старый URL должен вести на конечный новый за один шаг, а не через цепочку промежуточных редиректов, которые замедляют и размывают вес.
- Без циклов и на живые страницы. Редирект не должен вести на другой редирект, на 404 или зацикливаться.
- Учёт протокола и www. Заодно приводят в порядок http→https и склейку www/без-www, чтобы не плодить дубли.
В 1С-Битрикс редиректы настраивают на уровне сервера (правила веб-сервера) для больших массивов и штатными инструментами для точечных случаев. Технически массовую карту редиректов удобно держать таблицей и генерировать из неё правила — так её проще поддерживать и проверять. Механику склейки, разбор 404 и настройку редиректов именно в Битриксе мы детально разбираем в статье про редиректы, 404 и склейку URL.
Метатеги, микроразметка и техническое SEO
Адреса — половина SEO-переезда; вторая половина — сохранить релевантность страниц, чтобы после переадресации поисковик увидел на новом адресе ту же (или лучшую) страницу по тем же запросам. Здесь работают метатеги, содержимое и техническая обвязка.
Метатеги и заголовки. title и description накапливались и подбирались годами — терять их нельзя. Их переносят вместе с товарами и страницами либо, если на старом сайте они генерировались по шаблону, воспроизводят тот же шаблон в Битриксе. Заголовки H1 тоже сохраняют: смена H1 меняет восприятие релевантности страницы.
Микроразметка. Schema.org для товаров (цена, наличие, рейтинг), хлебные крошки, организация — всё, что давало расширенные сниппеты, воспроизводят на новом сайте. Потеря микроразметки не роняет позиции напрямую, но ухудшает вид сниппета и кликабельность.
robots.txt и sitemap. Новый robots.txt настраивают так, чтобы не закрыть лишнего и не открыть мусор; свежий sitemap.xml генерируют по новой структуре и отправляют в панели вебмастеров сразу после запуска, чтобы ускорить переиндексацию.
Канонические адреса и дубли. Переезд — повод навести порядок: настроить canonical, закрыть от индексации технические параметры, избавиться от дублей, которые тянулись со старого сайта. Про генерацию SEO-страниц из фильтра и борьбу с дублями полезен материал про склейку URL.
Скорость. Один из смыслов переезда часто — ускорить магазин. Если новый сайт грузится медленнее старого, часть выигрыша теряется, а скорость влияет и на ранжирование, и на конверсию. Поэтому скорость нового магазина замеряют ещё до запуска и добиваются, чтобы она была не хуже, а лучше прежней.
Тестирование на копии перед запуском
Ни одна миграция не переключается «сразу в бой». Новый магазин собирают, наполняют и вылизывают на копии — отдельной технической площадке или тестовом домене, закрытом от индексации и посторонних глаз. Пока копия отлаживается, старый сайт продолжает работать и продавать, а значит переезд идёт без давления и без потери заказов.
Что проверяют на копии перед запуском:
- Полнота данных. Число товаров, категорий, клиентов и заказов совпадает со старым сайтом; выборочно сверяют карточки и заказы вручную.
- Целостность каталога. Свойства, картинки, вариации, цены и остатки на месте; фильтр работает; нет битых изображений.
- Оформление заказа. Корзина, оформление, оплата и доставка проходят до конца в тестовом режиме; письма уходят.
- Интеграции. Обмен с 1С идёт, CRM принимает заявки, касса формирует чеки, аналитика собирает данные.
- Редиректы. Карту редиректов прогоняют краулером: старые адреса ведут на правильные новые, 404 нет.
- Скорость и адаптив. Замеряют скорость, проверяют отображение на мобильных и в разных браузерах.
- SEO-обвязка. Метатеги, canonical, sitemap, robots.txt, микроразметка проверены и корректны.
Тестирование на копии — это страховка, которая окупается всегда. Именно здесь вскрываются расхождения, которые в «боевом» запуске стали бы катастрофой: потерянные картинки, съехавшие вариации, неработающая оплата, дыры в карте редиректов. Дешевле найти и починить это на закрытой копии, чем на глазах у клиентов и поисковиков. Копию держат закрытой от индексации (robots и пароль), чтобы поисковик случайно не проиндексировал тестовый домен как дубль.
План запуска и переключение DNS без простоя
Когда копия проверена, наступает самый нервный момент — переключение. Задача сформулирована жёстко: перевести трафик на новый магазин так, чтобы клиенты не увидели простоя, а заказы не потерялись в переходный период. Достигается это правильным планом и аккуратной работой с DNS.
Механика переключения обычно такая. Новый магазин уже работает на своём сервере; старый пока принимает трафик. В момент запуска меняют DNS-запись домена, чтобы она указывала на новый сервер. Но DNS обновляется у провайдеров не мгновенно: какое-то время (зависит от TTL записи) часть посетителей ещё попадает на старый сервер, часть — уже на новый. Этот период «двоевластия» и нужно пройти без потерь.
Как это делают без простоя:
- Снижают TTL заранее. За день-два до переезда уменьшают время жизни DNS-записи, чтобы после переключения адрес обновился у всех быстрее.
- Финальная синхронизация данных. Прямо перед переключением догоняют свежие заказы и изменения, накопившиеся на старом сайте с момента снятия копии, чтобы новый магазин стартовал с актуальной базой.
- Держат обе версии рабочими. В период распространения DNS и старый, и новый сервер отвечают, поэтому клиент не видит «заглушку», куда бы ни попал.
- Выбирают тихое время. Переключают в часы низкой нагрузки (ночь, начало недели), чтобы даже мелкие шероховатости затронули минимум людей.
- Готовят откат. На случай серьёзной проблемы держат возможность быстро вернуть DNS на старый сервер — старую версию не удаляют сразу.
Отдельная тонкость — заказы, оформленные на старом сайте в период распространения DNS. Чтобы они не потерялись, либо синхронизируют базы, либо на старом сайте на время оставляют приём заказов с последующим переносом, либо аккуратно направляют оформление на новый сервер. Конкретный сценарий выбирают под проект, но принцип один: ни один заказ, сделанный во время переезда, не должен пропасть.
Что проверить после запуска
Запуск — не финиш, а начало самого ответственного периода. Первые дни и недели после переключения решают, удержит магазин трафик и продажи или нет. Поэтому сразу после запуска идут по чек-листу проверок и держат сайт под усиленным мониторингом.
| Что проверяем | Как | Почему критично |
|---|---|---|
| Редиректы | Прогон карты краулером: старые URL → 301 → живые страницы | Потерянный редирект = потерянный трафик страницы |
| Индексация | Отправить sitemap, проверить robots.txt, доступность страниц роботам | Ускоряет переиндексацию нового сайта |
| Аналитика | Счётчики стоят, цели и e-commerce считаются | Без данных не увидеть проблем и не измерить результат |
| Оформление заказа | Сквозной тест: корзина → оплата → доставка → письмо | Сломанный заказ = прямые потери денег |
| Интеграции | Обмен с 1С, CRM, касса работают в бою | Расхождения в остатках и заказах бьют по операциям |
| Скорость | Замер до/после, метрики загрузки | Медленный сайт съедает выигрыш от переезда |
| Битые ссылки и 404 | Скан сайта, отчёты вебмастеров | Внутренние 404 роняют и юзабилити, и SEO |
Отдельно — наблюдение за трафиком и позициями в первые недели. Небольшая просадка сразу после переезда — нормальное явление: поисковики переиндексируют сайт и «переваривают» редиректы. Паниковать и что-то срочно менять в этот момент не нужно — важно отличать естественную временную флуктуацию от реальной проблемы (например, массовых 404 или закрытого от индексации сайта). Если через разумный срок трафик не восстанавливается, ищут причину — и почти всегда находят её в редиректах, индексации или скорости.
Риски миграции и как их снизить
Честный разговор о переезде невозможен без разговора о рисках. Миграция — операция с высокими ставками: на кону трафик, заказы и данные. Но почти каждый риск управляем, если знать о нём заранее и подстелить соломку. Разберём главные.
| Риск | Чем грозит | Как снизить |
|---|---|---|
| Потеря трафика | Падение позиций и продаж | Полная карта редиректов, перенос метатегов, контроль индексации |
| Потеря данных | Пропавшие товары, клиенты, заказы | Сверка на копии, бэкапы, повторяемая скриптовая миграция |
| Простой магазина | Упущенные заказы в момент переезда | Тестирование на копии, снижение TTL, обе версии рабочие |
| Сломанные интеграции | Расхождения с 1С, потеря заявок | Воспроизвести и протестировать интеграции до запуска |
| Грязные данные | Дубли, битые картинки, хаос в каталоге | Чистка перед импортом, нормализация свойств |
| Медленный новый сайт | Падение конверсии и позиций | Оптимизация и замер скорости до запуска, кэширование |
| Утечка персональных данных | Юридические и репутационные потери | Защищённая передача базы, без открытых промежуточных файлов |
Общий принцип снижения рисков один: ничего не делать вслепую и вживую. Всё, что можно проверить на копии — проверяют на копии. Всё, что можно откатить — держат откатываемым. Всё, что можно измерить (данные, скорость, редиректы) — измеряют до и после. Миграция становится опасной ровно тогда, когда её делают наспех, без тестового прогона и без плана отката. С аудитом, копией, картой редиректов и мониторингом переезд превращается из прыжка в пропасть в контролируемую инженерную операцию.
Этапы проекта миграции
Сведём всё сказанное в единую последовательность. Проект миграции проходит через предсказуемые этапы, и понимание этой дорожной карты помогает и планировать сроки, и контролировать подрядчика, и не пропустить критичный шаг.
- Аудит и планирование. Инвентаризация данных и URL, оценка SEO и интеграций, черновик карты редиректов, план проекта и список рисков.
- Разработка и настройка нового магазина. Сборка витрины на Битриксе (готовое решение или разработка), структура каталога, дизайн, интеграции.
- Перенос данных. Каталог, товары со свойствами и картинками, вариации, клиенты, заказы, контент — импортом или скриптом, с прогоном на копии.
- SEO-перенос. Маппинг URL, карта 301-редиректов, перенос метатегов и микроразметки, robots.txt, sitemap, canonical.
- Тестирование на копии. Сверка данных, проверка заказа, интеграций, редиректов, скорости и адаптива на закрытой площадке.
- Запуск и переключение. Финальная синхронизация, снижение TTL, переключение DNS в тихое время, обе версии рабочие, готовый откат.
- Пост-запуск. Проверка редиректов и индексации, мониторинг трафика и заказов, устранение мелких расхождений, доводка.
Сроки каждого этапа зависят от объёма и «чистоты» данных, числа интеграций и сложности старого сайта — заочно точные цифры называть некорректно. Но структура этапов остаётся неизменной от проекта к проекту, и именно она делает миграцию управляемой.
Роль подрядчика
Миграция — тот случай, где цена ошибки высока, а самих ошибок легко наделать по незнанию. Поэтому переезд редко делают силами штатного контент-менеджера: слишком много инженерных нюансов, от структуры редиректов до синхронизации DNS. Хороший подрядчик закрывает именно те риски, которые дороже всего обходятся при самостоятельном переезде.
Что берёт на себя подрядчик:
- Аудит и план. Полная инвентаризация данных и URL, чтобы ничего не потерялось, и реалистичный план с оценкой рисков.
- Технический перенос. Скриптовая миграция сложных данных, перенос картинок как файлов, корректная раскладка вариаций и заказов.
- SEO-безопасность. Полная карта редиректов, перенос метатегов, контроль индексации — то, от чего зависит сохранение трафика.
- Тестирование и запуск. Прогон на копии, безопасное переключение DNS без простоя, готовый откат.
- Сопровождение после запуска. Мониторинг, устранение расхождений, доводка — самый важный период, который нельзя бросать.
При выборе подрядчика на миграцию стоит спрашивать не «сколько стоит перенести», а «как вы сохраняете SEO и что делаете, если что-то пойдёт не так». Ответы про карту редиректов, тестирование на копии, план отката и мониторинг после запуска — признак того, что переезд будет управляемым. Отсутствие этих ответов — красный флаг. Сам новый магазин при этом можно собрать по-разному: и на готовом решении, и индивидуально — как интернет-магазин на 1С-Битрикс под ваши процессы. А если переезд совмещается с редизайном и пересборкой структуры, полезна услуга сайта с продуманной SEO-структурой.
Частые ошибки
Эти ошибки повторяются из переезда в переезд и стоят бизнесу трафика и денег. Зная их заранее, вы либо избежите их сами, либо проконтролируете подрядчика.
- Переезд без карты редиректов. Самая дорогая ошибка. Смена адресов без 301 обнуляет накопленный вес страниц и роняет трафик.
- Массовый редирект на главную. «Всё старое на главную» поисковик считает мягкой 404 — вес не передаётся. Редиректы делают постранично.
- Использование 302 вместо 301. Временный редирект не передаёт вес. Для переезда нужен только постоянный 301.
- Забыли про контент и блог. В фокусе каталог, а статьи и служебные страницы выпадают из карты редиректов — и теряют свой трафик.
- Перенос без тестирования на копии. «Боевой» запуск без прогона на копии — гарантированные сюрпризы на глазах у клиентов.
- Картинки перенесены ссылками на старый домен. После отключения старого сервера все фото «отваливаются».
- Не снизили TTL DNS заранее. Переключение затягивается, переходный период растёт, риск потерять заказы выше.
- Старый сайт удалили сразу. Не осталось ни отката, ни источника данных, если что-то забыли перенести.
- Тестовую копию не закрыли от индексации. Поисковик индексирует тестовый домен как дубль основного — лишняя головная боль.
- Перенесли грязные данные как есть. Дубли, битые карточки и мусорные URL переехали в новый магазин вместе с проблемами.
- Не следили за трафиком после запуска. Реальную проблему (массовые 404, закрытый сайт) заметили поздно, когда потери уже накопились.
Чек-лист миграции
Сведём весь переезд в практический чек-лист, по которому удобно принимать готовность миграции и ничего не упустить.
- Аудит проведён. Данные инвентаризированы, полный список старых URL собран из sitemap, вебмастеров, логов и краулера.
- Решено, что не переносим. Устаревшие страницы и мусорные URL помечены для редиректа на живые разделы или архива.
- Данные перенесены и сверены. Каталог, товары, свойства, картинки, вариации, клиенты, заказы, контент на месте; числа совпадают со старым сайтом.
- Картинки перенесены файлами. Не ссылками на старый домен; битые изображения найдены и исправлены.
- Маппинг URL готов. Каждому значимому старому адресу сопоставлен новый; «повисших» строк нет.
- Карта 301-редиректов настроена. Постранично, тип 301, без цепочек и циклов, на живые страницы.
- Метатеги и SEO перенесены. title, description, H1, микроразметка, canonical; robots.txt и sitemap готовы.
- Интеграции воспроизведены. Обмен с 1С, CRM, оплата, доставка, касса, аналитика проверены на копии.
- Тестирование на копии пройдено. Заказ проходит до конца, редиректы прогнаны краулером, скорость и адаптив в норме.
- План запуска готов. TTL снижен, финальная синхронизация продумана, тихое время выбрано, откат подготовлен.
- После запуска — контроль. Редиректы, индексация, аналитика, заказы и скорость проверены; сайт под мониторингом; старый сервер не удалён.
Вывод
Миграция интернет-магазина на 1С-Битрикс — это не «перенос товаров», а перенос двух пластов сразу: данных (каталог, клиенты, заказы, контент) и SEO-наследия (адреса, метатеги, структура). Данные переносятся импортом или скриптовой миграцией, и это решаемая инженерная задача. По-настоящему определяет успех переезда работа с SEO: полная карта соответствия старых URL новым, постраничные 301-редиректы, сохранение метатегов и контроль индексации. Именно здесь чаще всего теряют трафик — и именно здесь его можно полностью сохранить.
Безопасная миграция строится на четырёх опорах: аудит в начале, перенос и отладка на копии, полная карта редиректов и переключение DNS без простоя, а затем мониторинг после запуска. Ничего вслепую и вживую: всё, что можно проверить на копии — проверяют, всё, что можно откатить — держат откатываемым. Сделанный так переезд не только сохраняет позиции и заказы, но и даёт магазину более быструю, управляемую и масштабируемую платформу для роста. А значит, смена платформы из риска превращается в инвестицию, которая окупается. Обсудить перенос вашего магазина и оценить объём работ можно на странице услуги переезда на 1С-Битрикс или в рубрике «Бизнес и стратегия», где мы разбираем и другие вопросы запуска и развития e-commerce.
