Как перенести сайт с Tilda на кастомную разработку: пошаговый план
Переезд с Tilda на кастомную разработку редко делают «на всякий случай». Обычно повод уже накопился: нужная интеграция не влезает в логику конструктора, карточка товара тормозит от лишних блоков, а редакторам приходится обходить ограничения через костыли. И если в проекте больше 20 страниц, то вопрос уже не про вкус, а про контроль.
1. Когда переход с Tilda на кастомную разработку действительно нужен
Первый сигнал — функционал. Если у вас сложный личный кабинет, нестандартные фильтры, многоступенчатые калькуляторы или своя логика тарифов, Tilda быстро упирается в потолок. Это не плохо, просто у конструктора другая задача. Ему не до сложных сценариев.
Второй сигнал — интеграции. Когда сайт должен жить с CRM, ERP, складом, телефонией, несколькими источниками лидов и разными формами, ручные доработки начинают расползаться. В один момент один модуль ломает другой, а в отчётах появляются дыры. Для e-commerce это особенно заметно: заказ пришёл, но статус не обновился, а менеджер узнал об этом только через час.
Третий повод — SEO и производительность. Если страницы собираются из слишком тяжёлых блоков, а структура URL не поддаётся нормальной логике, сайт теряет устойчивость. Иногда проблема не в трафике, а в том, что у проекта нет запаса на рост. И это видно даже на небольшом каталоге из 50 позиций.
Четвёртый повод — управление проектом. Когда над сайтом работает не один маркетолог, а команда из редактора, аналитика, продаж и разработчика, кастомная разработка даёт понятные правила. На Tilda часть решений живёт в интерфейсе, часть — в сторонних сервисах, часть — в комментариях в чате. Потом это трудно поддерживать.
2. Подготовка к переносу: аудит сайта и сбор требований
Перед стартом нужен аудит. Не поверхностный, а с перечнем страниц, форм, сценариев и зависимостей. Полезно выписать структуру сайта: главная, посадочные, карточки, блог, служебные страницы, формы заявки, квизы, попапы. Если проект большой, без таблицы уже не обойтись.
Отдельно проверьте контент. На каких страницах тексты менялись за последний год? Какие блоки реально читают, а какие держатся «для вида»? Если на странице есть 8 экранов, но конверсию приносит один, переносить все 8 один в один не всегда разумно. Иногда лучше упростить.
Соберите список интеграций. Формы, CRM, почта, мессенджеры, аналитика, пиксели, онлайн-оплата, календари, чат-виджеты, отзывы. Если у вас уже есть безопасность сайта как отдельный процесс, включите в аудит и её: доступы, хостинг, токены, резервные копии, ответственных. Потерять доступ к почте на этапе переезда — банальная, но дорогая ошибка.
На этом же шаге нужно зафиксировать метрики. Сколько заявок идёт с конкретной посадочной, какие страницы приносят трафик, где люди отваливаются, какие события уже настроены в аналитике. Без этих цифр будет трудно понять, что перенос сработал, а что сломал воронку. И да, «кажется, стало лучше» — слабый аргумент.
3. Составление карты переноса и приоритизация страниц
Карта переноса отвечает на простой вопрос: что переезжает в первую очередь. Обычно в начале идут деньги и трафик. Это главная, коммерческие посадочные, страницы услуг, каталог, ключевые статьи, формы и всё, что уже даёт лиды.
Второй эшелон — страницы, которые можно объединить. Если на Tilda было 12 почти одинаковых лендингов под разные запросы, на кастомной версии часть из них можно собрать в одну более сильную структуру. В SEO это часто лучше, чем распылять вес на дубли. Но только после проверки спроса и внутренней логики.
Третий слой — временные и устаревшие страницы. Акции прошлых лет, старые события, архивные публикации, тестовые посадочные. Их не всегда стоит переносить. Иногда разумнее оставить редирект на ближайший релевантный раздел. Так вы не тащите мусор в новую систему.
Полезно разметить страницы по приоритету в таблице: трафик, конверсия, сложность переноса, риск для SEO, зависимые сервисы. У одной страницы может быть высокий трафик, но почти нулевая ценность для продаж. У другой — наоборот. Тогда переносить её надо не раньше первой, а аккуратнее.
Именно на этом шаге вы начнёте видеть, как перенести сайт с Tilda на кастомную разработку без хаотичной гонки за «всем сразу». Порядок снижает ошибки. А ошибки на переезде стоят дороже, чем ещё один день планирования.
4. Выбор архитектуры и стека для кастомной разработки
Архитектуру выбирают не по моде, а по задаче. Если сайт небольшой и команда хочет редактировать контент без разработчика, часто достаточно CMS с аккуратной темой и модульной версткой. Если проект завязан на сложные интерфейсы, фронтенд-фреймворк и API-связи дают больше свободы. Для контентного продукта с несколькими каналами публикации подходит headless-подход.
Здесь важен не бренд технологии, а сценарий работы. Кто будет добавлять страницы? Сколько языков нужно? Нужна ли мультирегиональность? Будут ли у проекта личные кабинеты, фильтры, подписки, внутренние роли? Эти вопросы лучше закрыть до первой строки кода, иначе потом архитектура начнёт подстраиваться под чужие решения.
Если у команды уже есть опыт с конкретной CMS, это плюс. Но слепо повторять старую схему не стоит. Tilda часто прячет сложность, а кастомная разработка эту сложность показывает сразу. Тут и полезно сравнить подходы на уровне структуры, а не «любимая платформа / нелюбимая платформа».
Для проектов с повышенными требованиями к доступности и защите часто отдельно смотрят на инфраструктуру и журналы событий; в похожих задачах помогает и приватная сетевая инфраструктура, если сайт связан с внутренними сервисами или закрытыми данными. Такой выбор не про красоту, а про эксплуатацию. Когда через год понадобится подключить новый сервис, переписывать половину сайта уже не хочется.
5. Перенос дизайна, контента и SEO-элементов
Дизайн лучше переносить не «пиксель в пиксель», а по системе. На Tilda блоки часто выглядят цельно только внутри конструктора, а на кастомной версии их можно собрать чище: сократить повторяющиеся элементы, выровнять отступы, убрать лишние анимации, оставить только то, что помогает продавать. Иногда старый дизайн нужно не переносить, а разобрать на смысловые части.
Контент переносится по списку: тексты, фото, видео, схемы, прайс-блоки, FAQ, отзывы, документы. Здесь важна аккуратность. У страницы может быть одна фраза, на которой держится конверсия, и её нельзя потерять в процессе редактуры. Точно так же нельзя сломать ссылку на PDF или номер телефона в шапке.
SEO-часть требует дисциплины. Переносите заголовки, мета-теги, ALT-атрибуты, canonical, robots, карту сайта, старые URL и цепочки редиректов. Если у страницы уже есть история в поиске, адреса лучше сохранять либо переводить через 301 без промежуточных прыжков. Один лишний редирект — и поисковая система начинает сомневаться, куда вести пользователя.
Если на сайте есть важные текстовые шаблоны, проверьте их до публикации вместе с как выбрать между готовым шаблоном. Это пригодится как ориентир: где шаблон ещё уместен, а где кастомная сетка даст больше контроля. Визуальная целостность без SEO-хаоса — редкая, но достижимая комбинация.
Ещё один практический момент: не тащите в новую версию мусорные UTM-ссылки, старые заглушки и скрытые блоки, которые уже не участвуют в продажах. Иначе через месяц вы будете чинить не сайт, а его прошлое.
6. Настройка интеграций, форм и аналитики
Формы — первое, что ломается при переезде, если к ним относятся как к мелочи. Проверьте поля, маски телефонов, согласия, маршрутизацию заявок, автоответы, копии менеджерам, webhook’и и обработку ошибок. У формы должен быть понятный путь: отправка, попадание в CRM, уведомление, статус.
CRM и почта тоже требуют отдельной проверки. Если лиды уходили в разные воронки, на новой платформе это надо воспроизвести без потерь. Нельзя допустить, чтобы часть заявок попадала в одну сделку, а часть — в архив. Такие расхождения всплывают не сразу.
Для аналитики переносите не только счётчики, но и события: клики по телефонам, отправки форм, просмотр видео, скачивание файлов, переходы к оплате, выбор тарифов. Если у вас есть привязка к внешним отчётам, заранее проверьте, что названия событий не поменялись. Иначе сравнить старый и новый сайт будет почти невозможно.
Отдельно проверьте cookie-баннеры, Consent Mode и рекламные пиксели, если они есть. В похожих задачах полезно заранее разобрать что нового в cookie consent после, чтобы не потерять часть сигналов в рекламных кабинетах. Это скучная работа, но именно она спасает статистику после запуска.
Если у сайта есть виджеты, чаты или отзывы, перенесите их в новой версии только после теста на мобильных устройствах. Виджет, который закрывает кнопку заявки на экране 375 px, может испортить конверсию быстрее любой ошибки в тексте.
7. Тестирование, запуск и контроль после релиза
Перед запуском нужна проверка в несколько слоёв. Сначала верстка: одинаково ли выглядят страницы в Chrome, Safari и на мобильном? Потом формы: уходят ли заявки, приходят ли письма, не ломаются ли маски? Затем редиректы: ведут ли старые адреса на правильные новые страницы. И только после этого — скорость, индексация и поведение аналитики.
Полезно пройтись по 10–15 критичным сценариям вручную. Открыть главную, отправить форму, перейти в каталог, отфильтровать товары, скачать прайс, открыть блог, проверить 404. Если проект большой, список сценариев будет длиннее, но логика та же: не смотреть на сайт как на картинку, а пройти по пользовательскому пути.
Мобильная версия требует отдельного внимания. На Tilda многие блоки выглядят неплохо только до первого сложного экрана. В кастомной разработке есть шанс сделать лучше, но и испортить проще. Один неудачный отступ способен скрыть CTA, а один тяжёлый слайдер — замедлить первые секунды загрузки.
После релиза не исчезайте на 2 недели. Первые дни нужны для контроля: 404, резкий рост отказов, просадка лидов, ошибки в аналитике, проблемы с индексацией. Если у проекта есть мониторинг, настройте отслеживание критичных страниц и форм. Для сложных сайтов полезно сверяться с подходом ручная проверка репутации сайта vs автоматический: ручной просмотр ловит мелочи, автоматический не спит ночью.
8. Что делать после запуска: поддержка и развитие
После запуска сайт только начинает жить. В первые 30 дней обычно всплывают мелкие ошибки: не тот заголовок, забытый alt, лишний пробел в карточке, некорректный переход в CRM. Если оставить это без контроля, сайт быстро начнёт терять аккуратность. И доверие тоже.
Хорошая практика — завести список улучшений по приоритету. Сначала исправить то, что влияет на заявки и навигацию. Потом доработать UX: сократить форму, убрать лишний шаг, уточнить подсказки, добавить сравнение тарифов, улучшить поиск. Уже после этого можно расширять функциональность: личные кабинеты, подборки, калькуляторы, новые языковые версии.
Поддержка на кастомной основе отличается от поддержки конструктора тем, что здесь у вас есть маршрут развития. Не надо ждать, пока очередной плагин перестанет работать. Можно планировать доработки спринтами, привязывать их к задачам продаж и смотреть на конкретный эффект. Для этого пригодится и поддержка сайта после запуска, если нужен режим, а не разовые правки.
Ещё один рабочий шаг — раз в месяц сверять логику сайта с тем, как им пользуются люди. Где кликают, где путаются, где уходят. Иногда одно изменение в первом экране даёт больше, чем большой редизайн. И это тот случай, когда спокойная доработка лучше громкого перезапуска.
Если перенести сайт с Tilda на кастомную разработку без спешки, вы получите не просто новую оболочку, а управляемый проект с понятной структурой, редактируемым контентом и запасом под рост. А дальше уже задача не в том, чтобы «закончить перенос», а в том, чтобы развивать сайт без возврата к старым ограничениям.
