Перенос Тильды на Битрикс: карта миграции, проверка и приёмка

Перенос Тильды на Битрикс — это управляемый переезд, а не копирование страниц. Сначала фиксируют границы задачи и собирают карту миграции, затем переносят контент, формы и аналитику, проверяют новые адреса на тестовом контуре и только после приёмки меняют основной домен. Ниже — порядок действий, развилки, критерии проверки, учебный пример и чек-лист приёмки.

Задача бизнеса и границы переноса Тильды на Битрикс

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

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

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

Карта миграции: главный рабочий документ

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

Правила ведения простые, но их стоит зафиксировать сразу.

• Одна строка — один объект: страница, форма, файл, счётчик. Не объединяйте несколько страниц в строку «раздел».
• Статусы ограничены и понятны: не начато, в работе, на проверке, принято, отклонено с причиной.
• У каждой строки есть ответственный с обеих сторон, а не «команда».
• Изменения вносятся в карту, а не в личные заметки; версия карты датируется.
• Для спорных блоков заводится отдельная строка с пометкой «решение не принято» и вопросом к заказчику.

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

Инвентаризация: что собрать на стороне Тильды

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

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

Способ проверки полноты — обход сайта по карте и сверка с фактическим содержимым. Полезно пройтись по меню, подвалу, всплывающим окнам и страницам, на которые ведут ссылки из писем и рекламных материалов. Часто именно там обнаруживаются забытые формы и устаревшие документы.

Платформа Тильда не предоставляет полноценного экспорта и импорта проекта, поэтому при переносе приходится работать с разметкой страниц. Это наблюдение участника, а не официальное правило: перед началом работ стоит самостоятельно проверить, какие способы выгрузки доступны в вашей версии платформы и что именно они отдают на выходе.

Развилка: перенести шаблон, контент или собрать заново

На этом шаге принимается решение, определяющее трудоёмкость. Вариантов три, и они не равнозначны.

Перенести разметку как есть

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

Перенести контент в новую структуру

Самый частый вариант. Тексты, изображения и документы переносятся в типовые шаблоны и компоненты, а внешний вид собирается заново по макетам. Плюсы: страницы становятся управляемыми, появляется единообразие, проще подключать каталог и формы. Минусы: нужны макеты или хотя бы согласованные правила оформления.

Собрать заново

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

Карта URL и правила адресов

Адреса — самая чувствительная часть переезда. Внешние ссылки, закладки, рекламные объявления и письма ведут на старые адреса, и они должны продолжать работать. Поэтому карта URL составляется до сборки, а не после.

Порядок действий:

1. Выгрузите полный список текущих адресов и отметьте, какие из них живые, а какие уже отдают ошибку. 2. Для каждого живого адреса определите новый адрес. Если структура сохраняется, адрес может совпасть. 3. Для адресов, у которых нет прямого соответствия, решите заранее: вести на ближайший по смыслу раздел или на главную. 4. Отдельно отметьте адреса с параметрами — они часто используются в рекламных кампаниях. 5. Проверьте, что адреса не дублируются и не конфликтуют между собой.

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

Контент, медиа и структура страниц

Перенос контента — самая объёмная часть работы, и её нельзя оценить «на глазок». Практичнее идти по типам блоков, а не по страницам: сначала описать, как выглядит типовой текстовый блок, типовой блок с карточками, типовой блок с таблицей, а затем применять это решение ко всем страницам.

Что требует отдельного решения:

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

Отдельно фиксируется, кто отвечает за вычитку текстов после переноса. Автоматический перенос часто ломает переносы строк, списки и специальные символы, поэтому каждая страница просматривается человеком.

Формы, заявки и интеграции

Формы — то, что напрямую влияет на выручку, поэтому их проверяют в первую очередь. По каждой форме нужно знать: набор полей, какие обязательны, какой текст согласия показывается, куда уходит заявка, кто получатель, есть ли автоответ отправителю, подключена ли защита от автоматических отправок.

Порядок работы:

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

Тестовая отправка делается на реальный адрес получателя, но с пометкой в теме письма, чтобы её не спутали с настоящей заявкой. Если заявки уходят в CRM или другую систему, проверяют не только факт доставки, но и корректность полей: имя, телефон, комментарий, источник. Доступы и настройки получателей удобно свести в одном месте — об этом подробнее в материале про Администрирование сайта на Битрикс — доступы, данные и настройки.

Аналитика и цели: что фиксировать до и после

До переезда нужно зафиксировать, какие счётчики установлены и какие цели настроены. Это делается скриншотами или выгрузкой отчётов за период, чтобы после переезда было с чем сравнивать. Без такой фиксации невозможно понять, работает ли новая разметка событий.

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

• коды счётчиков на всех страницах, включая страницы, которых нет в меню;
• цели на отправку форм, звонки, переходы в мессенджеры;
• разметка событий на кнопках и ссылках;
• параметры рекламных кампаний, если они используются в ссылках.

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

Сборка и проверка на тестовом контуре

Работы ведутся на отдельном контуре, а не на рабочем сайте. Порядок такой: делается резервная копия текущего сайта, разворачивается тестовая среда, на неё переносится контент и структура, и только после проверок выполняется переключение. О том, как организовать хранение копий и восстановление, читайте в материале про Резервное копирование сайта на Битрикс — хранение и восстановление.

Тестовый контур закрывают от внешних посетителей, чтобы промежуточные версии не попадали в выдачу и не путали клиентов. На нём проверяют:

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

Документация и рекомендации 1С-Битрикс указывают на перенос нештатными средствами, настройки окружения и многосайтовые конфигурации как на возможные источники проблем при переносе. Это ориентир для проверки: если сайт переносится нестандартным способом или на одном управлении живёт несколько доменов, список проверок расширяется, а работы планируются с запасом по времени.

Учебный пример: перенос сайта с тильды на битрикс

Учебный пример. Данные условные и приведены только для иллюстрации порядка работ. Все числа в примере вымышлены.

Входные условия. Условная компания «Условный Сервис» держит на Тильде сайт из 40 страниц: главная, 8 разделов услуг, страница команды, блог из 20 материалов, контакты и несколько служебных страниц. Есть 12 форм: заявка на главной, формы в разделах услуг, подписка и обратный звонок. Подключены два счётчика и четыре цели. Домен один, поддоменов нет. Каталога и онлайн-оплаты нет. Задача — перенести сайт на Битрикс без изменения структуры разделов и без потери заявок.

Ход работ. Сначала собрали карту миграции: 40 строк по страницам, 12 строк по формам и 4 строки по целям. Затем выгрузили тексты и изображения, сверили их с фактическим содержимым страниц и обнаружили три страницы, которых не было в меню, и одну форму, оставшуюся от старой акции. По каждой форме уточнили получателя: две формы отправляли заявки на адрес уволившегося сотрудника. Составили карту URL: 36 адресов сохранили структуру, 4 старых адреса решили вести на ближайшие по смыслу разделы. Собрали тестовый контур, перенесли контент, настроили формы и счётчики.

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

Что показал пример. Основное время ушло не на вёрстку, а на инвентаризацию и сверку: забытые страницы, устаревшие формы и неактуальные получатели нашлись именно на этом этапе. Если бы проверка форм осталась на конец, заявки после переключения домена уходили бы в никуда.

Как принять работу

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

• Карта миграции заполнена полностью: по каждой строке есть статус и ответственный.
• Все страницы из списка открываются и содержат корректный контент.
• Старые адреса отвечают так, как записано в карте URL; обход выполнен и зафиксирован.
• Каждая форма протестирована, заявка дошла до получателя, автоответ отправлен.
• Состав полей и тексты согласий совпадают с исходными.
• Счётчики установлены, цели срабатывают при тестовых действиях.
• Сайт проверен на телефоне, планшете и настольном компьютере.
• Медиафайлы и документы открываются с нового домена, битых ссылок нет.
• Доступы к панели управления, домену и внешним сервисам переданы заказчику.
• Резервная копия рабочей версии сделана и проверена на восстановление.
• Назначены ответственные за наблюдение после переключения и срок наблюдения.
• Зафиксирован порядок действий, если после переключения обнаружится ошибка.

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

Ограничения, ошибки и исходные данные для оценки

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

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

Ограничения

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

Какие исходные данные подготовить для оценки

Чтобы получить внятную оценку объёма, подготовьте:

• список страниц с адресами и кратким описанием содержимого;
• перечень форм с полями и получателями;
• список внешних сервисов и интеграций;
• перечень счётчиков и целей;
• список доменов и поддоменов;
• описание того, что меняется по сравнению с текущим сайтом;
• доступы к панели управления, домену и почте;
• контакт ответственного за решения по контенту.

Чем точнее этот список, тем меньше допущений в оценке и тем ниже риск, что объём работ вырастет в процессе.