Что происходит при экспорте сайта с Tilda на свой сервер

Меня зовут Марков Вадим, я представляю студию marmelad.digital. Мы много работаем с Tilda, в том числе с проектами, где стандартной публикации на серверах платформы уже недостаточно и возникает задача вынести сайт на собственную инфраструктуру.

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

Но здесь важно понимать главное: экспорт сайта с Tilda — это не перенос самой Tilda на ваш сервер.

Вы переносите сгенерированный клиентский слой проекта. Часть функций продолжает зависеть от инфраструктуры платформы, часть требует отдельной настройки, а некоторые возможности после экспорта работают иначе или перестают работать совсем.

Разберём, что происходит на самом деле.

Что именно экспортирует Tilda

Экспорт доступен на тарифах линейки Business. После формирования архива Tilda отдаёт файлы проекта, которые можно разместить на собственном веб-сервере. Для изображений, CSS и JavaScript можно заранее задать отдельные пути — например, если статика должна находиться на собственном CDN.

Упрощённо структура выглядит так:

Tilda

↓

1. HTML страниц 
2. CSS 
3. JavaScript 
4. изображения и другие ресурсы

↓

ваш веб-сервер

↓

браузер пользователя

Именно поэтому экспортированный сайт внешне может вообще не отличаться от версии, опубликованной непосредственно на Tilda.

Zero Block не превращается в SVG-картинку, стандартные блоки не становятся скриншотами. Браузер получает HTML, стили, JavaScript и ресурсы, необходимые для отображения страниц.

Но редактор Tilda вместе с этим кодом никуда не переезжает.

Это принципиальная разница.

Экспорт — это снимок проекта

Если скачать ZIP сегодня, а завтра изменить заголовок в редакторе Tilda, файл на вашем сервере сам по себе не обновится.

Есть две основные модели работы.

Первая — периодический ручной экспорт:

изменили проект в Tilda → опубликовали → сформировали новый экспорт → загрузили новые файлы на сервер

Вторая — собственная синхронизация через Tilda API.

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

API предназначен именно для синхронизации, а не для генерации страницы при каждом посещении пользователя.

То есть схема:

пользователь → ваш сервер → запрос в Tilda API → HTML

не является правильной.

Правильная схема:

Tilda API → синхронизация → файлы на вашем сервере → пользователь

Для API действует лимит 150 запросов в час, а полученные страницы и ресурсы должны сохраняться на стороне вашего сервера.

Фактически Tilda в такой архитектуре начинает играть роль визуального редактора и источника контента, а публикацией уже управляет ваша инфраструктура.

Формы — первый момент, который часто понимают неправильно

Наличие HTML формы в экспортированной странице ещё не означает, что весь механизм обработки заявок теперь находится на вашем сервере.

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

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

Тогда архитектура уже выглядит так:

форма → POST ваш backend → CRM / email / Telegram / ERP / другая система

И здесь начинается обычная серверная разработка: валидация данных, защита от спама, логирование ошибок, повторная отправка при сбоях, хранение персональных данных.

Иными словами, экспорт HTML не экспортирует серверную инфраструктуру формы.

С Каталогом всё ещё интереснее

Обычная страница Tilda довольно естественно переносится в виде HTML.

Каталог — уже динамическая система.

Панель управления товарами при экспорте не переносится. Добавление и редактирование товаров по-прежнему выполняется внутри аккаунта Tilda.

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

Это особенно важно для крупных SEO-каталогов.

В стандартной публикации Tilda умеет автоматически создавать отдельный sitemap-store.xml, а страницы товаров получают разметку Schema.org.

Поэтому перенос интернет-магазина нельзя рассматривать как обычную операцию «скачать файлы и залить на сервер». Перед миграцией необходимо отдельно проверить архитектуру товарных URL, индексируемость карточек, sitemap, микроразметку и сценарии открытия товаров.

Для сайта из пяти обычных страниц экспорт и экспорт интернет-магазина — технически совершенно разные задачи.

Потоки тоже не превращаются в автономную CMS

С Потоками действует похожий принцип.

Контент можно вывести на экспортированный сайт, но сама панель управления остаётся в Tilda.

Более того, Tilda указывает ограничение на прямое открытие отдельных публикаций в экспортированной версии: посты доступны при переходе из общего списка, а нормальная работа прямых URL ограничена.

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

Если нужна действительно независимая CMS, то одного штатного экспорта недостаточно.

SSL тоже становится вашей задачей

Пока сайт находится на серверах Tilda, сертификатом и значительной частью HTTPS-конфигурации занимается платформа.

После экспорта этот сертификат не переносится.

HTTPS нужно настраивать уже на собственном сервере: через сертификат хостинга, Let's Encrypt или другую инфраструктуру. 

А вместе с сервером на владельца проекта переходят и другие инфраструктурные задачи:

1. HTTP → HTTPS;
2. www → без www или наоборот;
3. обработка 404;
4. редиректы;
5. кэширование;
6. gzip или Brotli;
7. HTTP-заголовки;
8. CDN;
9. резервное копирование;
10. мониторинг доступности.

На Tilda значительная часть этого слоя скрыта от пользователя. На собственном сервере он становится вашей ответственностью.

Apache и Nginx 

В экспортируемом проекте Tilda предоставляет htaccess, который после загрузки нужно переименовать в .htaccess.

Но .htaccess относится к Apache.

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

Для API Tilda умеет отдавать пример конфигурации сервера через параметр webconfig.

Это мелкая деталь ровно до момента, когда после миграции:

/ работает, а /services /catalog /about начинают отдавать неожиданные 404.

Поэтому перенос заканчивается не тогда, когда открылся первый экран главной страницы.

Экспорт не гарантирует ускорение сайта

Есть ещё один распространённый миф: если вынести Tilda на собственный сервер, сайт автоматически станет быстрее.

Не обязательно.

У Tilda уже есть собственная серверная инфраструктура, CDN и оптимизация доставки ресурсов.

Если проект экспортирован, производительность теперь зависит от качества настройки вашего веб-сервера.

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

Результат зависит уже от конкретной архитектуры:

сервер + география + CDN + HTTP/2 или HTTP/3 + Brotli + cache-control + сторонний JavaScript + изображения + шрифты

Сам факт экспорта ничего из этого автоматически не оптимизирует.

Есть ещё одна неочевидная деталь — правила использования экспортированного кода

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

Это не совсем так.

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

Поэтому экспорт стоит воспринимать именно как механизм размещения проекта, созданного в Tilda, на собственной инфраструктуре, а не как конвертер Tilda-проекта в полностью независимую самописную CMS.

Что в итоге

После экспорта на свой сервер сайт перестаёт зависеть от хостинга Tilda, но не обязательно перестаёт зависеть от самой экосистемы Tilda.

Условно проект можно разделить на три слоя:

1. Представление HTML + CSS + JS + изображения → переносится

2. Управление контентом редактор, Каталог, Потоки → полностью не переносится

3. Инфраструктурные сервисы формы, CRM, личный кабинет, SSL и часть динамических функций → либо остаются связаны с Tilda, либо требуют собственной реализации

И это тот случай, когда ZIP-архив получить легко.

Гораздо важнее заранее понимать, что именно должно произойти с сайтом после того, как этот архив окажется на вашем сервере.