Услуги по миграции сайтов на 1С-Битрикс

Миграция сайтов на 1С-Битрикс

Первое, что ломается при переезде — URL-структура. WordPress генерит /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, Битрикс по умолчанию хочет /catalog/section/element/. Если не проставить 301-редирект на каждый проиндексированный адрес — поисковики фиксируют массовые 404, и через две недели трафик проседает на 50-80%. Мы начинаем любую миграцию со сканирования старого сайта через Screaming Frog и формирования полной карты редиректов ещё до написания первой строчки кода.

С каких платформ мигрируем

За годы работы переносили проекты с десятков систем:

CMS:

• WordPress / WooCommerce → 1С-Битрикс. Таблицы wp_posts, wp_postmeta, wp_wc_product_meta_lookup → инфоблоки и highload-блоки. Вариации товаров (WC Variable Product) маппятся в торговые предложения (b_catalog_product).
• OpenCart / ocStore → 1С-Битрикс. Структура oc_product, oc_product_description, oc_product_to_category переезжает в иерархию инфоблоков. Мультиязычность OpenCart → языковые версии свойств.
• Joomla / VirtueMart → 1С-Битрикс
• MODX Revolution → 1С-Битрикс. Ресурсы MODX с TV-переменными → элементы инфоблоков со свойствами.
• Drupal, PrestaShop → 1С-Битрикс

SaaS:

• Tilda → 1С-Битрикс (бизнес перерос конструктор, нужна 1С-интеграция)
• InSales, Shopify → 1С-Битрикс
• Wix / Squarespace → 1С-Битрикс

Самописные движки — переносим даже если документации нет. Реверсим структуру БД, восстанавливаем бизнес-логику по коду.

Что переносится

Контент: страницы, статьи, новости → информационные инфоблоки. Каталог: категории → разделы инфоблока, товары → элементы с привязкой к b_catalog_product, свойства → свойства инфоблока или highload-справочники. Изображения, отзывы, FAQ.

E-commerce: товары с вариациями (торговые предложения в Битрикс), цены в b_catalog_price (мультивалютные через b_catalog_currency), остатки по складам b_catalog_store_product, скидки через b_sale_discount, история заказов из b_sale_order + b_sale_basket.

Пользователи: клиентская база — b_user + UF-поля. Пароли в каждой CMS хешируются по-своему: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. Мы пишем кастомный CUser::LoginByHash с fallback на старый алгоритм — клиент вводит пароль один раз после переезда, система тут же перехеширует в bcrypt Битрикса.

SEO-данные: мета-теги (title, description), alt-теги, URL-структура. Главная задача — сохранить все URL или проставить корректные 301.

Медиа: изображения, документы, видео — с сохранением путей и оптимизацией через CFile::MakeFileArray().

Процесс миграции

1. Аудит (1-3 дня). Сканируем Screaming Frog: все URL, статус-коды, мета-теги, изображения. Разбираем структуру БД, кастомные доработки, интеграции. На выходе — подробная карта: что, куда, как переезжает. Именно здесь выясняется, что «простой магазин на WooCommerce» имеет 47 плагинов и кастомную логику ценообразования.

2. Проектирование архитектуры (2-5 дней). Маппинг: типы контента → инфоблоки, поля → свойства, справочники → highload-блоки. Архитектура не просто вмещает старые данные — она делает их удобными для работы в Битрикс.

3. Скрипты миграции (3-10 дней). Никакого ручного копирования. PHP-скрипты читают из старой БД (или API), трансформируют и пишут через API Битрикс (CIBlockElement::Add, \Bitrix\Sale\Order::create). Автоматизация позволяет запускать миграцию повторно — критично для тестирования.

4. Staging (1-2 дня). Полный перенос на тестовый сервер. Проверяем целостность: количество товаров, сохранность свойств, корректность URL, работу фильтров. Прогоняем чеклист из 50+ пунктов.

5. Дизайн/шаблоны (1-4 недели). Редизайн — новые шаблоны. Без редизайна — адаптация вёрстки под шаблонизатор Битрикс (template.php, result_modifier.php).

6. 301-редиректы. Полная карта в .htaccess или nginx.conf. Каждый проиндексированный URL старого сайта → соответствующая страница нового. Пропустить один — потерять страницу из индекса. Генерируем автоматически, проверяем скриптом после переключения.

7. Финальная миграция (1 день). Дельта-импорт свежих данных (заказы и контент, появившиеся после тестовой миграции), переключение DNS, мониторинг в реалтайме. Обычно ночью — минимум влияния на посетителей.

8. Пост-миграционный контроль (2-4 недели). Мониторим Google Search Console и Яндекс.Вебмастер: индексация, позиции, crawl errors. Следим за трафиком и конверсиями в Метрике/GA. Любые отклонения — реагируем немедленно.

Сохранение SEO-позиций

Потеря органического трафика — главный страх, и обоснованный.

• 1:1 маппинг URL — где возможно, через CUrlRewriter и ЧПУ-настройки инфоблока сохраняем точную структуру. Где нельзя — 301.
• Автогенерация карты — парсим Screaming Frog экспорт, сопоставляем со slugs новых элементов, генерируем конфиг nginx. Каждый редирект проверяется curl -I после переключения.
• Мета-теги — title, description, h1 переносятся как есть в свойства ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION.
• Canonical — rel="canonical" через настройки SEO-компонента Битрикс. Дубли отсекаем: www/без www, http/https, параметры сортировки.
• Sitemap — новая sitemap.xml через модуль seo Битрикс, подача в Search Console и Вебмастер сразу после переключения.

Миграция интеграций

Внешние интеграции — отдельный пласт:

• Платёжные системы — переподключение sale.paysystem с сохранением истории транзакций
• Доставка — настройка sale.delivery.handler
• CRM — привязка к Битрикс24 или сохранение текущей через REST API
• 1С — настройка обмена через CommerceML. Часто это главная причина миграции на Битрикс.
• Email-маркетинг — миграция подписчиков, шаблонов. Переподключение вебхуков.
• Аналитика — e-commerce tracking под новую структуру dataLayer

Сроки

Типичные ошибки

Каждая — потерянные позиции и клиенты. Вот что видим чаще всего.

Потеря URL без редиректов. Самый разрушительный промах. /product/123 вместо /catalog/item-name.html — без 301 это массовые 404 и обвал трафика. Генерируем карту автоматически, проверяем каждый после переключения.

Дублирование контента. Один товар доступен с www и без, по HTTP и HTTPS, с GET-параметрами фильтрации — пять URL вместо одного. SEO-вес размывается. Настраиваем canonical, 301 для вариаций, robots.txt с Disallow для параметров.

Битые изображения. Абсолютные URL в контенте (src="https://old-site.ru/img/photo.jpg"), потеря качества при пережатии. Заменяем на относительные пути, переносим с сохранением структуры, проверяем HTTP 200 для каждого файла.

Потеря мета-тегов и микроразметки. Title, description, Schema.org — может не перенестись или перенестись криво. Полный маппинг и проверка на staging до переключения.

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

Мобильная версия. Старый m.site.ru → адаптивный Битрикс. Без редиректа мобильных URL — 404 для мобильных пользователей. Учитываем в карте редиректов.

Чек-лист

1. Полное сканирование: Screaming Frog / Sitebulb — все URL, изображения, PDF
2. Экспорт SEO: title, description, h1, canonical, hreflang
3. Фиксация позиций по ключевым запросам — без этого не поймёте, что изменилось
4. Бэкап файлов и БД. Проверить, что восстановим — на практике, не в теории
5. Реестр интеграций: платёжки, доставка, CRM, аналитика, рассылки, коллтрекинг
6. Карта редиректов: старый URL → новый для каждой проиндексированной страницы
7. Тестовая миграция на staging с полной проверкой
8. Мобильная версия: все страницы корректны, мобильные URL в редиректах
9. Новая sitemap.xml готова к подаче
10. План отката: DNS сохранены, конфиг задокументирован, доступ к старому хостингу есть