Сайт вырос на Tilda или WordPress, подрядчик обещает "перенести за неделю", но никто не показал карту старых адресов. После прошлого переезда пропали позиции, формы перестали слать заявки, а в выдаче путают облачную CRM с CMS на хостинге. Ниже - план миграции на "1С-Битрикс: Управление сайтом" в августе 2026: два сценария, staging, карта 301-редиректов и переключение DNS в последнюю очередь. Вы получите чек-лист переезда без просадки органики и потери заявок.
Перенос сайта на 1С-Битрикс - это не копирование файлов конструктора, а пересборка на CMS с картой URL, 301 на staging и переключением DNS в последнюю очередь; перенос уже работающего Bitrix между хостингами - через резервную копию и restore.php или rsync/mysqldump. Сегодня разведите сценарий A (Tilda/WP) и B (Bitrix на другом хостинге), соберите таблицу old URL → new URL и поднимите тестовый поддомен - без этого переезд почти всегда дает 404 и потерю заявок.
Типичная ошибка: владелец магазина на Tilda переключил DNS в пятницу вечером без редиректов. В понедельник в Яндекс.Вебмастере - сотни 404, реклама вела на битые посадочные, менеджеры не видели заявки из старых форм. Форма "Заказать звонок" на старом домене еще открывалась, а заявки в CRM уже не попадали.
Речь про CMS "1С-Битрикс: Управление сайтом" на вашем домене и хостинге - не про облачную CRM-портал для команды. Если выбираете между конструктором и CMS - смотрите сравнение Битрикс и конструктора для бизнеса.
Что такое перенос сайта на 1С-Битрикс
Перенос сайта на 1С-Битрикс - это пересборка проекта на PHP-CMS с вашим доменом: контент, каталог, формы и SEO-адреса заново собирают на хостинге, а старые URL закрывают постоянными редиректами 301 (это сигнал поисковику: "страница навсегда переехала"). Отдельный случай - когда Bitrix уже работает и нужно сменить только хостинг: тогда копируют файлы и базу, URL обычно не меняются.
Когда нужно: каталог с обменом 1С, сложные фильтры, несколько языков, свои интеграции с оплатой и CRM. Когда не нужно: достаточно обновить дизайн на Tilda или WordPress - проще доработать текущую платформу, чем менять CMS.
Разведите два сценария: Tilda/WP и Bitrix на другом хостинге
Главная путаница - смешать "пересборку с нуля" и "копирование готового Bitrix". Это разные работы, разные сроки и разный SEO-риск.
| Сценарий | Что происходит | Инструмент | SEO-риск |
|---|---|---|---|
| A: Tilda / WordPress → Bitrix | Пересборка шаблона, контента, каталога | CSV, CommerceML, ручной импорт | Высокий без карты 301 |
| B: Bitrix → другой хостинг | Копирование готового сайта | restore.php или rsync + mysqldump | Низкий при сохранении URL |
| DNS без staging | Переключение "в пятницу вечером" | Нет | 404, потеря заявок |
Делайте: зафиксируйте сценарий A или B письменно до сметы. Не делайте: ждите "кнопку экспорта" с Tilda - контент не переезжает файлами, нужна новая верстка на CMS.
Подготовьте аудит URL, бэкап и staging до первой строки кода
До разработки соберите инвентарь: все URL, title, H1, страницы с трафиком из Яндекс.Метрики и Вебмастера, формы, счетчики, CRM, оплату, обмен с 1С. Краулер вроде Screaming Frog выгрузит карту за один прогон.
- Выгрузите все URL краулером и из sitemap старого сайта; отметьте страницы с трафиком - для них 301 обязателен по одному адресу.
- Сделайте полный бэкап старого сайта по инструкции по бэкапу на Bitrix - файлы и база, если есть доступ.
- Проверьте хостинг по гайду по хостингу для Bitrix; тариф можно заказать на Beget.
- Поднимите staging на тестовом поддомене (например test.domain.ru) с закрытием от индексации в robots.txt.
- Запишите интеграции - куда уходят заявки, какие webhook и ключи API нужно перенести.
Workflow подготовки:
Аудит URL → таблица old → new → staging → разработка → тест форм → 301 на staging → DNS
Делайте: staging с robots noindex до переключения. Не делайте: правьте редиректы уже после DNS - в первые часы поисковик и реклама получат 404.
Перенесите Bitrix на другой хостинг: restore.php или rsync
Сценарий B - сайт уже на CMS, меняется только сервер. По умолчанию используйте штатный бэкап и restore.php из официального курса dev.1c-bitrix.ru.
| Способ | Когда выбирать | Кратко |
|---|---|---|
| restore.php + архив | Типовой перенос, архив влезает в лимиты хостинга | Бэкап в админке → загрузка tar.gz в корень → мастер restore.php → удалить архив и скрипт |
| rsync + mysqldump | Очень большой upload, бэкап не скачивается целиком | rsync -avz файлов + дамп БД; правка bitrix/.settings.php; .sql не в webroot |
Способ 1 - restore.php: в админке создайте резервную копию (файлы + база), скачайте архив, загрузите на новый хостинг в корень сайта вместе со скриптом restore.php. Откройте restore.php в браузере, пройдите мастер восстановления. На Nginx проверьте, что для restore.php задан отдельный location и достаточный лимит размера загрузки - иначе большой архив оборвется на полпути. После успеха удалите restore.php, архив и служебные скрипты с сервера - иначе их могут использовать злоумышленники. Модули из Marketplace после restore иногда просят переустановки под новую лицензию - заложите на это отдельный день тестов.
Способ 2 - rsync и mysqldump: если архив слишком большой, синхронизируйте файлы командой rsync -avz (флаг -a сохраняет права, -v показывает прогресс, -z сжимает трафик), базу выгрузите через mysqldump и импортируйте на новом сервере. Обновите логин, пароль и имя базы в bitrix/.settings.php - это главный конфиг подключения к MySQL после ручного переноса. Файл .sql не храните в корне сайта - из web он доступен посторонним. Если после переноса сломались ЧПУ (человекопонятные адреса), переименуйте .htaccess.restore в .htaccess по подсказке официального курса; на Nginx сверьте правило try_files с urlrewrite.php.
Делайте: тестируйте формы и оплату на staging до DNS. Не делайте: оставляйте restore.php на боевом домене "на всякий случай".
Соберите сайт при переезде с Tilda или WordPress
Сценарий A - это разработка, а не копирование. На staging ставите CMS, настраиваете шаблон, переносите тексты и медиа. Каталог - через профили импорта CSV или CommerceML по курсу dev.1c-bitrix.ru. Товары с Tilda "кнопкой" не переезжают: выгрузите данные в таблицу, сопоставьте поля (название, артикул, цена, фото), импортируйте тестовую партию и только потом полный каталог. WordPress часто отдает экспорт записей - его используют как черновик текстов, но верстку и URL все равно собирают заново на Bitrix.
- Сопоставьте URL один к одному, где возможно; где адрес меняется - строка в таблице old → new.
- Импортируйте каталог тестовой партией на staging, проверьте цены, остатки и картинки.
- Перенесите формы и проверьте тестовую заявку: письмо, CRM, webhook.
- Настройте счетчики Метрики на тестовом домене с фильтром, чтобы не смешать статистику.
Делайте: сохраняйте структуру важных посадочных для рекламы. Не делайте: натягивайте неоптимизированный HTML старого сайта - бьет по скорости и SEO.
Настройте карту 301 на staging до переключения DNS
Таблица old URL → new URL - главный артефакт миграции. Для каждой страницы с трафиком - постоянный редирект 301, не 302 и не "все на главную". 301 на staging проверяют до DNS блоками по 10-15 правил, затем краулером: код 301, целевой URL совпадает с таблицей.
Где настраивать в Bitrix: SEO-модуль, массив $arUrlRewrite в urlrewrite.php, .htaccess на Apache или конфиг Nginx. Подробные способы - в гайде по 301-редиректам на Bitrix; здесь только правило: сначала staging и карта, потом DNS.
На staging проверяйте редиректы пакетами: добавили 10-15 правил - прогнали краулером или вручную открыли старые URL из Метрики. Так проще поймать опечатку в таблице, чем искать одну ошибку среди сотен правил в день переключения DNS. Для посадочных из Директа и email-рассылок заведите отдельную колонку "источник трафика" - эти URL проверяют в первую очередь.
Делайте: проверьте каждый URL из топ-50 Метрики вручную на staging. Не делайте: оставляйте 404 "потом поправим" - поисковик индексирует ошибки за часы. Обновите sitemap.xml и подготовьте отправку в Вебмастер после DNS.
Примите сайт после DNS по чек-листу и мониторьте 404
DNS переключают в последнюю очередь - в окно низкого трафика, не в пятницу вечером. После переключения 48-72 часа смотрите Вебмастер на всплеск 404, Метрику на цели, почту на заявки.
- Переключите DNS на новый хостинг, дождитесь TTL.
- Проверьте SSL и редирект http → https.
- Прогоните топ-URL из таблицы 301 - код 301, не 404.
- Отправьте тестовую заявку с каждой формы на боевом домене.
- Мониторьте 404 и трафик 2-4 недели по ключевым страницам.
Полный чек-лист приемки - в материале после запуска сайта. Держите старый хостинг включенным неделю после переезда - откат DNS возможен только при сохраненном старом сервере.
Делайте: отправьте обновленный sitemap в Яндекс.Вебмастер. Не делайте: удаляйте бэкап до стабильного трафика.
Что дальше
- Зафиксируйте сценарий A или B и бизнес-причины переезда.
- Соберите карту URL, бэкап и staging до разработки.
- Для Bitrix на новом хостинге выберите restore.php или rsync/mysqldump.
- Настройте 301 на staging, переключите DNS в тихое окно.
- Пройдите чек-лист B05 и мониторьте 404 две недели.
Сложная миграция с каталогом и 1С - обсудите на mvmolkov.ru: сверим карту URL и план до переключения DNS.
Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: перенос продукта (restore.php), urlrewrite.php, документация backup/restore.
Частые вопросы
Можно ли перенести сайт с Tilda на Bitrix самому?
Технически - только как пересборку: новый шаблон, ручной или CSV-импорт контента и каталога. Tilda не отдает "готовый Bitrix". SEO-критичны таблица 301 и тест на staging. Без опыта CMS разумнее делегировать верстку и импорт, а карту URL и приемку контролировать самому.
restore.php или rsync - что выбрать при переносе Bitrix на другой хостинг?
По умолчанию - бэкап в админке и restore.php: проще и совпадает с официальным курсом. rsync -avz плюс mysqldump выбирайте, если архив слишком большой для скачивания или загрузки. После rsync обязательно обновите bitrix/.settings.php и не кладите дамп .sql в корень сайта.
Как сохранить позиции при переезде на Bitrix?
Составьте таблицу old URL → new URL, настройте 301 на каждую страницу с трафиком на staging до DNS, не используйте 302 и редирект "все на главную". Отправьте sitemap в Вебмастер, мониторьте 404 2-4 недели. Без покарточных правил органика часто проседает сильно.
Нужен ли staging при миграции на Bitrix?
Да. На тестовом поддомене проверяют формы, оплату, редиректы и верстку до DNS. Staging закрывают от индексации robots.txt. Переключение DNS без staging - главная причина битых заявок и 404 в первый рабочий день.
Чем отличается перенос Bitrix на другой хостинг от миграции с Tilda?
Bitrix между хостингами - резервная копия, restore.php или rsync, те же URL. С Tilda - пересборка сайта с нуля на CMS, новые адреса и обязательная карта 301. Путать сценарии - значит ждать "копирование папки" там, где нужна разработка.
Bitrix24 и CMS "Управление сайтом" - это одно и то же?
Нет. Bitrix24 - облачная CRM и портал для команды. CMS "Управление сайтом" - PHP-сайт на вашем хостинге и домене. Статья про перенос сайта на CMS, не про настройку облачной CRM.
