Смена CMS — это не «перенос файлов на новый хостинг». Это смена операционной модели сайта: того, как в компании появляется контент, как он попадает в каталог, как заявки доходят до отдела продаж и кто отвечает за то, чтобы всё это не разваливалось после очередного обновления. Поэтому миграция на 1С-Битрикс почти никогда не проваливается на технике — она проваливается на планировании: не описали, что именно переносим, не договорились о критериях приёмки, не заложили время на редиректы и тестирование.
Ниже — рабочий план, по которому перенос сайта на Битрикс проходит предсказуемо: от честной оценки, нужен ли переезд вообще, до первых двух недель после запуска, когда решается судьба поискового трафика.
Когда переход на 1С-Битрикс действительно оправдан
Начинать стоит не с плана миграции, а с вопроса «зачем». Мы регулярно видим проекты, где переезд был затеян ради самого переезда, и через полгода компания получила ту же самую боль, только на другой платформе и с новым подрядчиком.
Переход обычно оправдан в четырёх ситуациях. Первая — сайт перерос текущую CMS функционально: появился большой каталог со сложной структурой свойств, торговые предложения, несколько складов, персональные цены для разных сегментов клиентов. Вторая — нужна плотная связка с учётной системой: если компания живёт в 1С и хочет, чтобы номенклатура, остатки и заказы ходили между сайтом и учёткой без ручного экспорта, 1С-Битрикс здесь исторически сильнее большинства альтернатив (интеграция с 1С заявлена начиная с редакции «Бизнес»). Третья — требования к поддержке и ответственности: коробочный продукт с официальной лицензией, обновлениями и большим рынком разработчиков проще передать от одного подрядчика другому. Четвёртая — управление несколькими сайтами и языковыми версиями из одной админки.
А вот когда переезд не нужен: если единственная претензия — «сайт медленный» или «дизайн устарел». Скорость и дизайн лечатся на текущей платформе в разы дешевле, чем полной миграцией. Смена CMS ради этого — самый дорогой способ решить задачу, которая решается редизайном и оптимизацией.
Отдельно проговорим неприятное: миграция всегда стоит денег и всегда несёт риск временной просадки трафика. Если бизнес-обоснования нет, риск ничем не компенсируется. Мы в таких случаях честно говорим клиенту, что переезжать рано, — это дешевле, чем через год объяснять, почему заявок стало меньше.
Инвентаризация: что вы переносите на самом деле
Самая частая причина срыва сроков — на старте никто не составил список того, что переносится. «Перенести сайт» — это не техзадание. Техзадание — это таблица, где по строкам перечислены сущности, а по столбцам указано: сколько их, откуда берутся, куда попадают на новой платформе, кто проверяет результат.
Минимальный набор для инвентаризации выглядит так:
- Статические страницы — «О компании», «Контакты», «Доставка и оплата», посадочные под услуги. Их обычно немного, и переносят их руками, попутно вычищая устаревшие тексты.
- Каталог — товары или услуги, их свойства, категории, фильтры, торговые предложения (цвет, размер, объём), цены и типы цен, остатки.
- Медиа — изображения товаров, галереи, документы, прайсы в PDF. Здесь часто вылезает сюрприз: половина картинок лежит на стороннем CDN или в старой галерее, которую никто не помнит.
- Блог и новости — статьи, авторы, теги, даты публикации. Даты важны: если при переносе все статьи получат сегодняшнее число, поисковые системы увидят «новый сайт без истории».
- Пользователи и заказы — если на сайте был личный кабинет. Пароли в чистом виде не переносятся никогда; клиентам придётся пройти восстановление пароля, и это нужно заранее заложить в коммуникацию.
- Формы и точки захвата — все места, где посетитель оставляет контакты, включая всплывающие окна и калькуляторы. Каждая форма должна получить владельца: куда падает заявка после переезда.
- Интеграции — CRM, телефония, платёжные системы, службы доставки, аналитика, чат-виджеты, пиксели рекламных кабинетов.
Отдельным листом сохраните полный список URL текущего сайта. Его удобно собрать из карты сайта, выгрузки из панелей вебмастеров и логов сервера. Этот список — основа для карты редиректов, без которой миграция на 1С-Битрикс превращается в лотерею.
Выбор редакции и подготовка окружения
1С-Битрикс продаётся линейкой редакций — от младшей «Старт» до старших, отличающихся набором модулей. «Старт» подходит для сайта-визитки и корпоративного сайта, «Стандарт» добавляет модуль проактивной защиты, «Малый бизнес» ориентирован на интернет-магазины, «Бизнес» — на магазины с обменом с 1С. Начать можно с младшей редакции и повысить её позже — сайт продолжит работать, просто станет доступен дополнительный функционал. Это снимает необходимость угадывать конфигурацию на старте.
Ошибка, которую мы видим чаще других, — покупка редакции «на вырост» под функции, которые в проекте так и не появятся. Считайте от сценариев: нужен ли обмен с 1С в первый год, будет ли многосайтовость, планируются ли торговые предложения. Если ответ «не знаем» — берите ту редакцию, которая закрывает текущие задачи.
Параллельно решается вопрос хостинга. У 1С-Битрикс есть встроенный инструмент «Проверка системы» — страница /bitrix/admin/site_checker.php в административной части, где система прогоняет тесты конфигурации сервера и прав доступа. До покупки лицензии сервер можно проверить отдельным скриптом bitrix_server_test: он выводит отчёт о несоответствиях и рекомендации. Проверять окружение нужно до начала переноса, а не после того, как половина каталога уже залита.
Практика показывает: дешёвый шаред-хостинг, на котором «раньше всё летало», для Битрикса чаще всего не подходит. Система требовательна к версии PHP, лимитам памяти и доступным функциям. Экономия здесь оборачивается неделями отладки на этапе, когда сроки уже горят.
Заранее разверните три контура: боевой, тестовый и локальный для разработчика. Тестовый обязательно закройте от индексации — забытый открытый тестовый домен с полной копией контента регулярно становится источником дублей в поиске.
Пошаговый план миграции
Дальше — последовательность, по которой мы ведём такие проекты. Шаги можно частично распараллелить, но менять их местами не стоит.
Шаг 1. Зафиксировать «точку до»
До того как что-то трогать, снимите метрики текущего сайта: посещаемость по источникам, позиции по ключевым запросам, количество и стоимость заявок, скорость загрузки основных типов страниц. Без этой фиксации после запуска невозможно отличить сезонный спад от последствий миграции, и любой разговор с подрядчиком превращается в спор о вкусах.
Шаг 2. Спроектировать структуру данных
Это ключевой этап, и его нельзя отдавать «на потом». В Bitrix Framework контент живёт в информационных блоках — универсальных хранилищах, где вы сами описываете набор свойств для каждой сущности. Плохо спроектированные инфоблоки — это ад для контент-менеджера на годы вперёд, а переделывать их после заливки данных дорого.
На этом шаге решается: сколько типов инфоблоков нужно, какие свойства обязательны, какие свойства становятся фильтрами в умном поиске, где хранятся торговые предложения. Полезно взять реальные 10 — 15 карточек товара из текущего каталога и вручную разложить их по будущей структуре — расхождения вылезают сразу.
Шаг 3. Развернуть чистую установку и базовую вёрстку
Новый сайт поднимается на тестовом контуре, натягивается шаблон, настраиваются служебные разделы. Если дизайн не меняется, вёрстка переносится как есть; если меняется — это отдельный подпроект, и совмещать редизайн с миграцией стоит только при запасе времени.
Шаг 4. Подготовить данные к загрузке
Из старой CMS выгружаются данные — чаще всего в CSV или XML. На этом этапе данные чистят: убирают дубли, приводят единицы измерения к одному виду, проверяют кодировку, нормализуют названия категорий. Правило простое: чем чище выгрузка, тем меньше ручной работы после импорта. Учтите, что в 1С-Битрикс разделителем десятичных знаков служит точка — цены с запятой придётся преобразовать.
Шаг 5. Импортировать контент
Для обычных информационных блоков в админке предусмотрен импорт: Контент → Инфоблоки → Импорт → CSV (есть также импорт из XML и RSS). Для товарных каталогов используется другой инструмент — Магазин → Настройки → Импорт данных. Это важное различие: попытка залить товары «обычным» импортом инфоблоков приводит к тому, что часть торговой информации теряется.
Импорт почти никогда не проходит с первого раза начисто. Заложите два-три прогона: залили, проверили выборочно 20 — 30 карточек, откатили, поправили выгрузку, повторили.
Шаг 6. Перенести медиа
Изображения переносятся вместе с данными или отдельным пакетом. На этом шаге вылезают битые ссылки на картинки, которых не было в выгрузке, и файлы с кириллицей в названиях. Заодно имеет смысл прогнать изображения через сжатие — старые сайты обычно тащат за собой гигабайты неоптимизированных фотографий.
Шаг 7. Настроить формы, интеграции и аналитику
Каждая форма подключается к тому же приёмнику, что и раньше: CRM, почта, мессенджер. Здесь критично не «сделать, чтобы отправлялось», а проверить сквозной путь: заполнили форму на тестовом контуре — заявка появилась в CRM с правильным источником и правильным ответственным. Счётчики аналитики и цели переносятся до запуска, иначе первые дни новой жизни сайта окажутся слепой зоной.
Шаг 8. Составить карту редиректов
Это тот шаг, который чаще всего делают в последний вечер перед запуском — и зря. Каждому старому URL должен соответствовать новый; если страницы больше нет, редирект ведёт на ближайший по смыслу раздел, а не на главную. Массовая склейка всего подряд на главную — прямой путь к потере позиций.
Постоянные редиректы (301) настраиваются на уровне веб-сервера. Проверять карту нужно автоматически: прогнать весь список старых адресов и убедиться, что каждый отдаёт 301 и приводит на страницу с кодом 200, а не на цепочку из трёх переходов.
Шаг 9. Тестирование по чек-листу
Тестируют не «сайт вообще», а список сценариев: поиск товара, применение фильтра, добавление в корзину, оформление заказа, оплата, отправка каждой формы, вход в личный кабинет, отображение на мобильных, корректность мета-тегов на всех типах страниц. Отдельно — «Проверка системы» в админке: она должна проходить без критичных замечаний.
Перенос контента, товаров и то, что не переносится автоматически
Полезно заранее развести два разных понятия, которые в разговорах постоянно путают. Перенос сайта на Битрикс с другой CMS — это конвертация данных: выгрузка из одной структуры, преобразование, загрузка в инфоблоки. Перенос уже работающего Битрикс-сайта между хостингами — совсем другая задача: она решается штатным резервным копированием (Настройки → Инструменты → Резервное копирование) и скриптом restore.php, который кладут в корень нового сайта и разворачивают архив. Второй сценарий часто предлагают как «миграцию», но к переезду с чужой CMS он отношения не имеет.
Что почти всегда требует ручной работы:
- Тексты внутри страниц с нестандартной вёрсткой — таблицы, аккордеоны, блоки из конструкторов. Автоматический перенос превращает их в кашу из тегов.
- SEO-мета: заголовки и описания переносятся отдельно, и это хорошая возможность их пересобрать, а не тащить старые дубли.
- Пароли пользователей. Их не переносят — учётные записи создаются заново, клиентам рассылается предложение восстановить пароль. Письмо должно уйти в день переключения, иначе служба поддержки утонет в обращениях.
- История заказов — переносится только при явной необходимости и почти всегда через отдельную разработку.
После заливки данных имеет смысл включить технологию «Композитный сайт» — она доступна на любой из редакций 1С-Битрикс: Управление сайтом и заметно ускоряет отдачу страниц. Но настраивать её лучше уже на стабильном контенте, а не в разгар импорта.
SEO при переезде: как не потерять трафик
Просадка после миграции почти неизбежна — вопрос лишь в её глубине и длительности. Аккуратный переезд даёт колебание в пределах нескольких недель, небрежный превращается в полугодовое восстановление.
Что удерживает трафик на месте:
- Сохранение структуры URL. Если можно оставить адреса прежними — оставьте. Каждое изменение адреса нужно оплачивать редиректом и терпением.
- Полная карта 301-редиректов без цепочек и без склейки в главную.
- Перенос мета-тегов и заголовков H1 для страниц, которые уже приносят трафик. Их переписывают позже, отдельным этапом, когда позиции стабилизировались.
- Корректный robots.txt и карта сайта в день переключения. Классическая катастрофа — тестовый
robots.txtс запретом индексации, уехавший на боевой сервер вместе с релизом. - Сохранение скорости загрузки. Новый сайт не должен оказаться медленнее старого — это единственный технический фактор, который поисковые системы заметят почти сразу.
- Уведомление панелей вебмастеров и загрузка новой карты сайта сразу после запуска, чтобы ускорить переобход.
Первые две недели после переключения — режим ежедневного наблюдения: ошибки сканирования, коды ответа, динамика показов. Большинство проблем в этот период лечится за час, если их заметить вовремя, и стоит месяцы трафика, если заметить через квартал.
Сроки, команда и сколько это стоит по времени
Приведём иллюстративный пример — типовой по структуре проект, каких у нас проходит несколько в год. Оптовая компания с каталогом около 3 500 позиций, сайт на самописной CMS, обновления которой прекратились вместе с уходом прежнего разработчика. Задача: переехать на 1С-Битрикс с сохранением каталога и подготовкой к обмену с 1С.
Как распределилось время: неделя на инвентаризацию и проектирование инфоблоков; две недели на развёртывание и вёрстку; неделя на подготовку выгрузки и три прогона импорта; неделя на формы, интеграции и аналитику; неделя на карту редиректов и тестирование. Итого около шести недель до запуска и ещё две недели активного наблюдения после. Самым долгим оказался не импорт, а согласование структуры каталога внутри компании — три отдела по-разному понимали, что считать категорией.
Отсюда практический вывод: закладывайте на миграцию не «две недели, там же просто перенести», а полтора-два месяца для среднего каталога, и назначайте со стороны бизнеса одного человека с правом принимать решения по структуре. Проект без такого человека растягивается вдвое.
Команда минимальная: разработчик под Битрикс, специалист по данным (он же готовит выгрузки), SEO-специалист на этапах редиректов и мета-тегов, менеджер проекта. Если чего-то из этого нет внутри — это ровно та работа, ради которой существуют наши услуги по разработке сайтов: мы берём на себя проектирование структуры, перенос данных и техническую часть SEO-переезда, оставляя за компанией только решения по бизнес-логике.
Пять ошибок, которые дорого обходятся
Переезд «одним днём» без тестового контура. Попытка собирать новый сайт сразу на боевом домене экономит день на настройке и стоит недели на разгребании последствий.
Редиректы по остаточному принципу. Карта редиректов должна быть готова и проверена до переключения, а не составляться по жалобам в первую неделю.
Совмещение миграции с редизайном и сменой семантики одновременно. Когда меняется всё сразу, при просадке невозможно понять причину. Если редизайн необходим — разнесите этапы хотя бы на месяц.
Игнорирование требований к серверу. Проверка окружения занимает час, а её отсутствие всплывает в самый неподходящий момент — на финальном тестировании.
Отсутствие приёмки со стороны бизнеса. Разработчик проверяет, что «всё работает». Проверить, что менеджер по продажам может за минуту найти нужный товар и выставить счёт, может только сам менеджер.
Миграция на 1С-Битрикс — предсказуемый инженерный проект, если относиться к нему как к проекту: с описанным объёмом, зафиксированными метриками «до», ответственным на стороне заказчика и отдельным этапом на редиректы. Всё остальное — вопрос дисциплины исполнения, а не удачи.
Частые вопросы
Сколько времени занимает перенос сайта на Битрикс?
Для корпоративного сайта без каталога — обычно две-три недели. Для интернет-магазина среднего размера — полтора-два месяца с учётом проектирования структуры, нескольких прогонов импорта и тестирования. Основное время уходит не на техническую заливку данных, а на согласование структуры каталога и подготовку выгрузок.
Потеряет ли сайт позиции в поиске после миграции?
Краткосрочные колебания при смене платформы практически неизбежны. Их глубина зависит от того, насколько полно составлена карта 301-редиректов, сохранены ли мета-теги и заголовки трафиковых страниц и не стал ли новый сайт медленнее старого. При аккуратном переезде показатели обычно возвращаются к прежнему уровню в течение нескольких недель.
Можно ли перенести товары автоматически?
Данные каталога переносятся выгрузкой и импортом: для обычных инфоблоков — через Контент → Инфоблоки → Импорт, для товаров — через Магазин → Настройки → Импорт данных. Но «автоматически» не означает «без участия человека»: выгрузку почти всегда нужно чистить и приводить к структуре новых инфоблоков, а результат импорта — выборочно проверять.
Какую редакцию 1С-Битрикс выбрать при переезде?
Отталкивайтесь от сценариев ближайшего года. Для корпоративного сайта достаточно младших редакций, для интернет-магазина смотрят в сторону «Малого бизнеса», для магазина с обменом с 1С — «Бизнеса». Редакцию можно повысить позже без пересборки сайта, поэтому переплачивать «на вырост» на старте не обязательно.
Что делать с паролями пользователей старого сайта?
Пароли не переносятся — они хранятся в необратимом виде. Учётные записи создаются заново, а клиентам в день переключения отправляется письмо с предложением восстановить пароль. Этот сценарий нужно подготовить заранее: и текст письма, и готовность поддержки к всплеску обращений.
Чем миграция с другой CMS отличается от переноса Битрикс-сайта на новый хостинг?
Это две разные задачи. Перенос между хостингами уже работающего сайта на Битрикс выполняется штатным резервным копированием и скриптом restore.php. Миграция с другой CMS — это конвертация данных в структуру информационных блоков, и штатными средствами резервного копирования она не решается.