Миграция с другой CMS на 1С-Битрикс: пошаговый план

Смена CMS — это не косметическое обновление сайта, а операция на живом организме: неверный шаг может стоить компании накопленного трафика, позиций в поиске и части заказов. При этом миграция с WordPress, OpenCart, Tilda, Joomla или самописного движка на 1С-Битрикс — одна из самых частых задач, с которой к нам приходят интернет-магазины и корпоративные сайты, упершиеся в потолок возможностей текущей платформы. За более чем 15 лет и 250+ проектов мы в TRUWEB (Алматы) провели десятки таких переездов и выработали пошаговый план, который сводит риски к минимуму. В этой статье — обновлённая и расширенная версия нашего практического руководства: когда миграция оправдана, как она отличается для магазина и для корпоративного сайта, чем перенос с разных платформ отличается технически, и что делать, если после переезда трафик всё-таки просел.

Когда миграция оправдана, а когда стоит повременить

Первый и самый важный вопрос — не «как мигрировать», а «нужно ли мигрировать вообще». Смена CMS — это всегда бюджет, время команды и риск временной просадки метрик, поэтому решение должно быть осознанным, а не эмоциональным.

Миграция на 1С-Битрикс оправдана, если:

• текущая CMS физически не может закрыть бизнес-задачи — нет нормального каталога с вложенными свойствами, нет гибких инфоблоков, невозможно построить сложную структуру скидок и торговых предложений;
• компании нужна полноценная интеграция с 1С: обмен номенклатурой, остатками, ценами, заказами в обе стороны, а текущая платформа поддерживает это только через костыли и сторонние синхронизаторы с постоянными сбоями;
• сайт растёт быстрее, чем масштабируется платформа — на Tilda или конструкторе невозможно вести каталог из нескольких тысяч товаров, на OpenCart не хватает производительности и модулей под текущие объёмы;
• нужна глубокая интеграция с Битрикс24 — сквозная воронка «сайт → CRM → сделка → повторные продажи» на других CMS реализуется хуже или требует дорогих сторонних коннекторов;
• текущий подрядчик по факту недоступен, техподдержки нет, а самописный или редкий движок больше никто не берётся сопровождать.

Стоит повременить с миграцией, если:

• проблема не в платформе, а в реализации — сайт на Битриксе тоже может тормозить, если написан криво, и сайт на WordPress тоже может быть быстрым и удобным, если сделан профессионально;
• задача решается точечными доработками — например, ускорением сайта, исправлением критичных ошибок или SEO-оптимизацией без смены движка;
• бюджета хватает только на «переезд ради переезда» без последующей поддержки — в таком случае риск выше потенциальной выгоды.

Прежде чем принимать решение, разумно заказать аудит сайта — независимая техническая и SEO-диагностика часто показывает, что 70% проблем можно закрыть без миграции, точечной доработкой текущего решения. Подробнее о том, как выглядит такой аудит и что он выявляет, — в статье «Технический аудит сайта: что проверяют и зачем».

Миграция интернет-магазина и миграция корпоративного сайта — в чём разница по сложности

Клиенты часто ставят задачу общими словами: «перенесите сайт на Битрикс», не разделяя два принципиально разных по трудоёмкости сценария.

Миграция корпоративного сайта

Корпоративный сайт — визитка, каталог услуг, блог, несколько лендингов — переносится относительно предсказуемо. Основной объём работы — это контент (тексты, изображения, документы), структура разделов и формы обратной связи. Интеграций обычно немного: CRM или Битрикс24, форма заявки, иногда чат. Риски по трафику концентрируются вокруг URL-структуры и метатегов. Такой проект, как правило, укладывается в разумные для клиента сроки, и если вы разрабатываете сайт с нуля именно на этой платформе, полезно также посмотреть материал про создание корпоративного сайта на Битрикс — многие принципы структуры пересекаются с миграцией.

Миграция интернет-магазина

Интернет-магазин — совсем другой уровень сложности. Помимо контента нужно перенести и корректно смоделировать: каталог с иерархией разделов, торговые предложения (цвет/размер/объём и т. д.), остатки и цены по складам, историю заказов (если требуется), отзывы и рейтинги, накопленные посадочные страницы под товарные и категорийные запросы, фильтры и характеристики для «умного» поиска. Добавляется интеграция с 1С (обмен номенклатурой и заказами), платёжными системами, службами доставки, а нередко и с маркетплейсами. Ошибка в мэппинге хотя бы одного типа данных — например, потеря значений фильтра «материал» — может обрушить не только SEO-трафик по товарным карточкам, но и удобство навигации для покупателей. Именно поэтому миграция магазина занимает в разы больше времени, чем перенос корпоративного сайта аналогичного объёма страниц, и требует более плотного тестирования. Если результатом миграции должен стать полноценный e-commerce на Битриксе, имеет смысл сразу сверяться со стандартным набором возможностей, который должен быть в магазине «на старте» — мы разбирали это в статье про базовый функционал интернет-магазина.

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

Специфика переноса с разных платформ: сравнительная таблица

Технически «миграция» — это разные задачи в зависимости от того, откуда переезжает сайт. У каждой платформы своя структура данных, свои особенности URL и свои подводные камни.

Общий вывод из таблицы: чем более «конструкторной» и закрытой была исходная платформа (Tilda, различные SaaS-решения), тем больше работы приходится на проектирование структуры заново, а не на технический перенос данных. Если исходная платформа — WordPress, полезно заранее посмотреть на предметное сравнение в статье «Битрикс vs Tilda и WordPress: что выбрать» — она помогает объяснить команде и руководству, почему функциональность на новой платформе местами будет реализована иначе.

Пошаговый план миграции на 1С-Битрикс

Шаг 1. Аудит текущего сайта и данных

Любая миграция начинается не с новой CMS, а с полной инвентаризации того, что есть. На этом шаге собираются:

• Полный список URL сайта — через выгрузку из систем аналитики, Search Console/Вебмастера и обход краулером (например, Screaming Frog), чтобы не полагаться только на карту сайта, которая может быть неполной;
• Трафик и позиции по каждому значимому URL и ключевым запросам — это будущая точка отсчёта, с которой сравнивается ситуация после переезда;
• Типы контента — статьи блога, карточки товаров, категории, лендинги, статичные страницы, документы для скачивания;
• Метатеги и микроразметка — title, description, Open Graph, Schema.org (для товаров, отзывов, хлебных крошек, организации);
• Профиль внешних ссылок — какие страницы получают наибольшее количество обратных ссылок, чтобы гарантированно сохранить их URL или корректно перенаправить.

Итог шага — таблица-реестр (обычно это Excel/Google Таблица) со всеми URL, их метриками, типом контента и статусом переноса. Именно с этим реестром команда будет сверяться на всех следующих этапах. Этот же шаг по сути дублирует логику технического аудита — если он не проводился в последние несколько месяцев, есть смысл заказать аудит сайта отдельно, чтобы не упустить проблемы, которые не связаны с миграцией напрямую, но повлияют на её результат.

Шаг 2. Планирование структуры на новой CMS

1С-Битрикс устроен через инфоблоки — гибкие структуры данных, которые нужно спроектировать под задачу, а не «включить по умолчанию». На этом шаге определяются:

• иерархия каталога — разделы, подразделы, глубина вложенности;
• инфоблоки и их типы — товары, услуги, статьи блога, отзывы, портфолио, вакансии и т. д.;
• свойства товаров и их тип (справочник, число, привязка к другому инфоблоку) — от этого зависит, как будут работать фильтры и «умный» поиск;
• стратегия ЧПУ — по возможности URL сохраняются идентичными исходным, чтобы избежать необходимости в редиректах там, где это не обязательно;
• структура шаблонов страниц — какие типы вывода нужны для каждого типа контента.

Хорошее планирование структуры на этом шаге экономит десятки часов доработок после запуска — переделывать инфоблоки «на живую», когда сайт уже наполнен данными, значительно дороже, чем продумать модель заранее. Если требуется не просто перенос, а более глубокая доработка каталога и логики под новую бизнес-модель, стоит сразу закладывать это в ТЗ на этапе переноса сайта на Битрикс, а не откладывать на потом.

Шаг 3. Перенос контента и настройка 301-редиректов

Это самый трудоёмкий и одновременно самый рискованный для SEO этап. Ключевое правило: редиректы настраиваются постранично, а не «всё на главную». Каждый старый URL должен вести на максимально близкий по смыслу новый URL — старая карточка товара на новую карточку того же товара, старая категория на новую аналогичную категорию, старая статья блога на её новый аналог. Если точного соответствия нет (товар снят с продажи, раздел упразднён), редирект настраивается на ближайшую по смыслу категорию, а не на главную страницу сайта — поисковые системы и пользователи одинаково плохо реагируют на «редирект в никуда».

Практический процесс:

1. из реестра URL (шаг 1) формируется таблица-мэппинг «старый URL → новый URL»;
2. контент переносится с сохранением текстов, изображений (с alt-атрибутами), метатегов и микроразметки — вручную это делать долго, поэтому для больших объёмов пишутся скрипты импорта под структуру данных, определённую на шаге 2;
3. 301-редиректы настраиваются массово по таблице мэппинга, а не вручную по одному правилу — на объёме в сотни и тысячи URL это единственный жизнеспособный подход;
4. отдельно проверяются редиректы для страниц пагинации, фильтров и служебных URL (например, страницы «Корзина», «Личный кабинет»), которые часто забывают при ручном планировании.

Именно потеря метатегов и микроразметки на этом шаге — одна из главных причин просадки позиций после миграции, поэтому есть смысл заранее ознакомиться с тем, как микроразметка Schema.org работает применительно к AI-поиску и обычным сниппетам — этому посвящена статья «Schema.org и AI-поиск».

Шаг 4. Перенос функциональности и интеграций

Контент — это половина миграции. Вторая половина — работающие бизнес-процессы. На этом шаге переносятся и настраиваются:

• Обмен с 1С — номенклатура, остатки, цены, заказы; для интернет-магазинов это критичный узел, от которого зависит корректность цен и наличия на сайте — подробнее о принципах такой интеграции в статье «Интеграция сайта с 1С»;
• Платёжные системы — эквайринг, электронные кошельки, счета для юрлиц;
• Службы доставки — расчёт стоимости, интеграция с трек-номерами, пункты выдачи;
• Битрикс24 или другая CRM — передача заявок, лидов, статусов заказов; если цель — выстроить сквозную воронку, полезно заранее посмотреть, зачем и как интегрируется Битрикс24 с сайтом, и рассмотреть отдельную услугу интеграции с Битрикс24;
• Формы обратной связи и калькуляторы — с сохранением логики валидации и уведомлений;
• Прочие интеграции — виджеты чатов, системы аналитики, сервисы email-рассылок, маркетплейсы.

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

Шаг 5. Тестирование и постепенный запуск

Финальный этап — не «нажать кнопку и переключить домен», а контролируемый переход:

• новая версия сайта разворачивается на staging-окружении, закрытом от индексации поисковыми системами (через meta robots и/или защиту паролем — важно не оставить это на «после запуска», так как проиндексированный дубль на staging способен создать техническую SEO-проблему);
• проводится полное тестирование интеграций — оформление тестового заказа, проверка обмена с 1С, проверка форм, проверка оплаты в тестовом или боевом режиме с минимальной суммой;
• проверяется корректность 301-редиректов на реальных примерах — не выборочно «на глаз», а по всей таблице мэппинга или её репрезентативной выборке;
• только после этого домен переключается на новый сайт, и в первые часы после запуска в Search Console/Вебмастере отправляется актуальный sitemap.xml;
• запускается усиленный мониторинг трафика, индексации и позиций — в первые 2-4 недели после переезда это должно происходить чаще, чем в штатном режиме.

Сколько времени занимает миграция и от чего это зависит

Универсального срока не существует — реалистичная оценка появляется только после аудита. На длительность влияют:

• объём каталога и контента — счёт на десятки страниц и счёт на тысячи товарных карточек с уникальными свойствами дают совершенно разную трудоёмкость;
• количество и сложность интеграций — простая форма заявки и полноценный двусторонний обмен с 1С с историей заказов — разный объём работ;
• состояние исходных данных — если метаданные, изображения и структура на старой платформе в порядке, перенос быстрее; если данные разрознены или частично утрачены, добавляется этап их восстановления;
• готовность заказчика — насколько быстро предоставляется доступ к системам, утверждаются макеты и мэппинг URL, тестируются черновые версии;
• объём индивидуальной доработки — миграция «как есть» быстрее, чем миграция с одновременным редизайном или расширением функциональности.

Как ориентир: корпоративный сайт на 10-30 страниц без сложных интеграций обычно переносится быстрее, чем интернет-магазин на несколько тысяч SKU с обменом 1С, оплатой, доставкой и Битрикс24 — там счёт идёт на совсем другой порядок трудозатрат. Точный срок и стоимость для конкретного случая можно оценить только после диагностики — ориентир по бюджету на разработку и доработку сайтов на Битриксе в целом разобран в статье «Сколько стоит сайт на Битрикс».

Кто должен участвовать со стороны заказчика

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

• Ответственного за проверку данных — человека, который знает каталог, услуги или контент изнутри и может подтвердить, что перенесённые карточки товаров, цены и тексты соответствуют действительности, а не просто «выглядят похоже»;
• Специалиста по 1С на связи — если есть обмен с учётной системой, на стороне заказчика должен быть человек (штатный или подрядчик), способный оперативно отвечать на вопросы по структуре справочников 1С и участвовать в тестировании обмена;
• Человека, принимающего решения по контенту и структуре — на шаге планирования структуры и мэппинга URL нужно быстро согласовывать решения, иначе сроки растягиваются не по вине подрядчика.

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

Практический чек-лист перед началом миграции

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

• Выгружен и сохранён полный список URL сайта (краулером, а не только по карте сайта).
• Зафиксированы текущие показатели трафика и позиций по ключевым страницам — есть с чем сравнивать после переезда.
• Собран список всех интеграций: 1С, платёжные системы, службы доставки, CRM, виджеты, аналитика.
• Проверено, есть ли доступ к учётным записям систем аналитики, поисковых консолей, хостинга и текущей CMS.
• Определён ответственный за проверку данных со стороны заказчика.
• Определён специалист по 1С, доступный для консультаций на этапе интеграции.
• Согласована стратегия URL — что переносится «как есть», а что меняется осознанно.
• Запланировано staging-окружение, закрытое от индексации.
• Согласован план тестирования интеграций перед запуском (включая тестовые заказы и оплату).
• Подготовлен актуальный sitemap.xml для отправки сразу после запуска.
• Назначен период усиленного мониторинга после переезда (минимум 2-4 недели).
• Есть договорённость с подрядчиком о технической поддержке в первые недели после запуска — на случай непредвиденных ошибок.

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

Типичные ошибки при миграции на 1С-Битрикс

Большинство проблем с трафиком после миграции повторяются от проекта к проекту. Вот самые частые:

• Редирект всего сайта на главную страницу. Самая грубая и при этом до сих пор распространённая ошибка. Поисковые системы теряют доверие к каждой отдельной странице, а пользователи, переходящие по старым ссылкам из закладок или поисковой выдачи, не находят нужный контент.
• Ненужная смена URL без технической необходимости. Если старый адрес страницы можно сохранить на новой CMS — его нужно сохранять. Смена ЧПУ «просто потому что так красивее» без крайней необходимости обнуляет накопленный вес страницы даже при правильно настроенном редиректе.
• Потеря метатегов и микроразметки. Title, description, Open Graph и Schema.org часто выпадают при автоматическом переносе, если процесс не был спроектирован заранее — итог: снижение CTR в выдаче и потеря расширенных сниппетов.
• Запуск без тестирования интеграций. Необмен с 1С, невозможность оформить заказ из-за сбоя оплаты или доставки — обнаруживаются в проде, а не на этапе тестирования, что бьёт по продажам напрямую и одновременно повышает показатель отказов, что вредит и SEO.
• Отсутствие мониторинга после запуска. Проблема, которую не заметили в первые дни (например, часть страниц закрыта от индексации по ошибке), может стоить недель восстановления позиций, если её обнаружить только через месяц.
• Индексация staging-окружения. Тестовая версия сайта, случайно попавшая в индекс, создаёт дубли контента и может конкурировать с боевым сайтом в выдаче.
• Игнорирование хлебных крошек и внутренней перелинковки. При смене структуры каталога легко забыть настроить внутренние ссылки заново — это ухудшает индексацию новых страниц.

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

Что делать, если трафик просел после переезда

Кратковременная просадка трафика на 5-15% в первые одну-две недели после миграции — во многих случаях нормальная реакция поисковых систем на смену адресов и переиндексацию. Тревожный сигнал — это просадка, которая не восстанавливается за 3-4 недели или превышает 20-30%. В этом случае стоит последовательно проверить:

1. Корректность 301-редиректов. Выборочно и массово (через краулер) проверить, что старые URL действительно ведут на релевантные новые страницы, а не на 404 или главную.
2. robots.txt. Частая техническая причина обвала индексации — файл robots.txt, скопированный со staging-окружения и случайно запрещающий индексацию всего сайта или ключевых разделов.
3. Совпадение контента. Убедиться, что тексты, title и description на новых страницах действительно соответствуют тому, что было проиндексировано ранее, а не урезаны или заменены шаблонными заглушками.
4. Статус в Search Console / Вебмастере. Проверить отчёты по индексации и покрытию — часто там сразу видна причина (ошибки сканирования, страницы, исключённые из индекса, дубли).
5. Скорость загрузки и Core Web Vitals. Резкое ухудшение технических показателей после миграции тоже влияет на ранжирование — контекст по метрикам разобран в статье «Core Web Vitals простыми словами».
6. Микроразметку. Проверить через инструменты проверки структурированных данных, что Schema.org для товаров, отзывов и хлебных крошек не потерялась при переносе.

Если самостоятельная диагностика не даёт ясности, разумнее не тратить недели на догадки, а заказать точечный технический аудит — он быстро локализует причину и даёт конкретный список исправлений, а дальнейшее продвижение можно строить на восстановленной базе с помощью услуги SEO-продвижения.

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

TruWeb работает на рынке с 2011 года — это больше 15 лет практики именно с 1С-Битрикс, за плечами свыше 250 реализованных проектов, включая полные переезды с других CMS. 97% наших клиентов возвращаются повторно или приходят по рекомендации — для проекта миграции, где на кону накопленный трафик и работающие бизнес-процессы, это не менее важный показатель, чем формальное портфолио. Мы работаем по договору, как юридическое лицо, что даёт заказчику официальные гарантии на каждом этапе — от аудита до постмиграционного мониторинга. Если после переноса потребуется не разовая правка, а системное сопровождение, у нас есть отдельная услуга поддержки и развития сайта — с ней возврат к состоянию «сайт снова кто-то поддерживает» не откладывается на неопределённый срок. Полный обзор того, как устроена разработка и поддержка сайтов на этой платформе в целом, — в нашем большом гиде «Разработка и поддержка 1С-Битрикс».