Бэкап сайта на Тильде: как сохранить проект и откатить изменения

Бэкап сайта на Тильде - тема, о которой вспоминают обычно постфактум: после того как правка конфликтует с версткой, кастомный скрипт перестает работать после обновления блока, или менеджер случайно удаляет секцию с ценами на проде. Конструктор не хранит полную историю проекта в привычном для разработчика смысле - там нет веток и коммитов, как в git. Если сайт зарабатывает деньги, а не лежит для красоты, копию проекта нужно делать руками и по расписанию. Дальше - как я организую резервное копирование Tilda-проектов на практике: что экспортировать, куда сохранять кастомный код и как быстро вернуться на рабочую версию, если правка все сломала.

Зачем бэкап сайта на Тильде, если это конструктор

Логика «в облаке и так все сохранено» подводит чаще всего в двух случаях: несколько человек редактируют один проект одновременно, или на сайте стоят кастомные интеграции - форма с оплатой через эквайринг Т‑Банка, калькулятор доставки СДЭК, виджет чата, скрипты аналитики. Тильда откатывает на предыдущую версию конкретной страницы, но не восстанавливает вручную вписанный в блок T123 код, если его затерли поверх при следующем сохранении. Я сталкивался с ситуацией, когда клиент за 20 минут до вебинара попросил менеджера «поправить текст на лендинге», а тот случайно снес скрипт с формой захвата заявок вместе с абзацем - и без резервной копии кода пришлось восстанавливать интеграцию по памяти.

Вторая причина - смена исполнителя. Если проект вела студия, а потом передала другому разработчику, без сохраненного архива HTML и списка кастомных скриптов новый подрядчик тратит первые часы просто на то, чтобы понять, что вообще стоит на сайте и откуда берутся данные в форме заказа.

Что Тильда сохраняет сама, а что теряется

Конструктор действительно оставляет подстраховку, но она уже, чем кажется:

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

Что при этом обычно теряется без отдельного бэкапа: кастомные HTML/CSS/JS-блоки, вписанные через Zero Block или код T123, настройки вебхуков и интеграций с CRM, привязка платежных систем, тонкие правки SEO-разметки на конкретных страницах и содержимое попапов, если их удалили вместе с блоком. Тильда хранит это как часть страницы, а не как отдельный версионируемый объект - поэтому при откате назначенной истории правок конкретно эти вещи легко потерять, если они менялись между сохраненными версиями.

Как экспортировать сайт с Тильды: пошаговая инструкция

Я делаю ручной экспорт перед каждым крупным релизом и минимум раз в 3-4 недели для проектов с активной командой редакторов:

1. Захожу в настройки проекта и открываю раздел экспорта.
2. Выбираю выгрузку в статический HTML - архив включает разметку, стили, изображения и подключенные шрифты. Функция доступна начиная с платных тарифов Тильды, на бесплатном плане экспорта нет.
3. Скачиваю zip-архив и распаковываю его в отдельную папку с датой в названии, например site-export-2026-08-04.
4. Кладу архив в приватный git-репозиторий или в отдельное облачное хранилище, чтобы можно было сравнить версии между собой.
5. Отдельно сохраняю список подключенных доменов, DNS-записей и активных интеграций - экспорт HTML их не выгружает.

Важный нюанс: выгруженный HTML - это статический слепок сайта на момент экспорта. Он не превращается обратно в редактируемый Tilda-проект одним кликом, зато отлично работает как страховка на случай, если проект целиком стал недоступен, и как референс для сравнения «было - стало» при спорах с клиентом о том, что именно поменялось на странице.

Резервное копирование кастомных скриптов и интеграций

Самая уязвимая часть Tilda-проекта - не дизайн, а код, вписанный руками. Калькулятор стоимости, форма с интеграцией эквайринга, скрипт для проверки зон доставки, попап с валидацией телефона - все это живет внутри блоков T123 или в настройках проекта «Ещё» → «Вставка кода», и при случайном редактировании блока соседним сотрудником переписывается без предупреждения.

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

Если заявки с сайта уходят дальше через n8n (например, в CRM или Telegram-бот на aiogram), сам workflow тоже стоит выгружать как JSON после каждого изменения маршрута - n8n позволяет экспортировать сценарий одной кнопкой, и это тот же принцип бэкапа, только для автоматизации за пределами Тильды.

Как откатить изменения на Тильде после неудачной правки

Порядок действий, который я использую, когда правка сломала опубликованную страницу:

1. Сначала проверяю историю изменений конкретной страницы в редакторе - в большинстве случаев нужная версия находится там, и откат занимает пару минут.
2. Если история не помогает (например, правка была не в тексте, а в коде блока), сверяю текущую верстку с последним экспортированным архивом HTML и переношу недостающий кусок кода вручную.
3. Если под рукой была дублированная копия страницы перед началом работ - просто публикую копию вместо испорченного оригинала и переименовываю страницы местами.
4. Проверяю интеграции отдельно: форму оплаты, вебхук в CRM, скрипт аналитики - блок мог визуально восстановиться, а код в нем остаться от сломанной версии.

Был случай: у клиента на интернет-магазине с оплатой через эквайринг Т‑Банка после правки менеджера пропала кнопка «Оформить заказ» на мобильной версии. В истории страницы нашлась версия за два дня до правки, откат занял 10 минут, но пришлось отдельно перепроверить, что скрипт расчета доставки СДЭК не откатился вместе с остальным контентом на более старую логику расчета тарифов.

Где и как хранить бэкапы Tilda-проекта

Я придерживаюсь простой схемы: экспортированные архивы HTML и файлы кастомных скриптов - в приватном git-репозитории с понятной структурой папок по датам, крупные релизы помечаю тегами. Скриншоты ключевых страниц перед большими изменениями делаю отдельно - иногда быстрее визуально сверить «было - стало», чем читать код построчно.

Отдельный момент, если сайт собирает контакты клиентов через форму заказа: сами заявки и персональные данные нельзя держать в иностранных облачных таблицах вроде Google Sheets - по 152-ФЗ такие данные должны храниться на серверах в России. Бэкап кода и разметки сайта это ограничение не затрагивает, а вот резервные копии базы клиентов и заказов стоит держать на российском хостинге или в защищенной CRM с российскими серверами.

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

Частые вопросы

Как часто делать бэкап сайта на Тильде?

Для сайта с активными правками нескольких человек - раз в 3-4 недели плюс обязательный экспорт перед каждым крупным релизом или сменой дизайна ключевых страниц. Для статичного лендинга без частых изменений хватает бэкапа раз в квартал и после любой доработки кастомного кода.

Можно ли восстановить удаленную страницу на Тильде?

Если страница была именно удалена из проекта, а не просто изменена, восстановить ее через встроенную историю обычно нельзя - функция откатывает изменения внутри существующей страницы, а не возвращает удаленные объекты. Поэтому важна не только история изменений, но и отдельный экспорт HTML, откуда верстку можно перенести обратно вручную.

Сохраняются ли кастомные скрипты при экспорте сайта?

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

Что делать, если бэкапа нет, а сайт сломался?

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