Экспорт страниц Тильды на свой сервер не переносит туда весь сервис конструктора. Для встроенного приема заявок на экспортированном сайте нужна активная подписка; при отказе от нее потребуется собственный обработчик — это указано в документации форм. Поэтому переезд стоит начинать со списка функций и способа будущего редактирования, а уже затем выбирать хостинг.
Домен, файлы и управление — три разные задачи
Домен — адрес сайта, хостинг — место, откуда посетитель получает страницы, а редактор — инструмент для их изменения. Эти части могут обслуживаться разными компаниями. Смена одной части не означает автоматической замены остальных.
Подключить домен к Тильде — значит настроить его для открытия уже подготовленного проекта. Платформа описывает два способа: через свои NS-серверы или A-записи у регистратора. Ни один из них не переносит содержимое прежнего сайта; это настройка адреса, а не загрузка страниц.
Экспорт решает другую задачу: готовые страницы размещают на собственном сервере. Пересборка нужна, когда требуется поменять сам способ управления — например, получить другой редактор и собственную обработку данных. До обсуждения стоимости полезно записать результат одной фразой: «храним страницы у своего провайдера» или «полностью меняем платформу и обслуживание».
Возможности экспорта и оставшиеся зависимости
Перенести сайт с Тильды на другой хостинг можно через экспорт на тарифе Business. Выгрузка дает архив файлов проекта. В ограничениях экспорта указано, что CRM и личные кабинеты Тильды не экспортируются, а Каталог товаров и Потоки остаются сервисами платформы. Защита страниц паролем после экспорта отключается; для шрифтов ParaType / type.today требуется оплаченная подписка.
Практический вывод: одинаковый вид главной страницы еще не означает одинаковую работу сайта. До выгрузки составьте перечень того, что посетитель может сделать: отправить запрос, найти товар, открыть материал, войти в кабинет, оплатить заказ. Напротив каждого действия запишите, какой сервис его обеспечивает и что с ним будет после переезда.
У каждой функции должен появиться понятный статус: сохраняем с нынешним сервисом, заменяем или убираем по согласованию. Если важная функция остается без решения, срок переключения домена назначать рано. Перечень покажет, какие работы действительно входят в переезд.
Сервер, HTTPS и маршрут заявки
На новом хостинге заранее готовят размещение файлов, резервные копии и доступ для человека, который будет выпускать обновления. HTTPS настраивают отдельно: сертификат Тильды на экспортированный проект не переносится. Также документация предупреждает, что правила адресов для серверов, отличных от Apache, нужно настроить самостоятельно. Эти условия приведены в инструкции экспорта.
У форм есть два разных маршрута. Можно оставить сервисы приема данных Тильды с активной подпиской либо подключить собственный скрипт обработки до экспорта. Встроенные формы экспортированного проекта работают только на домене и поддоменах, указанных в настройках сайта; условия описаны в справке по формам.
Собственный обработчик — отдельная часть работ. Для него определяют получателей заявок, проверку полей, защиту от спама, сообщения об ошибках и способ заметить сбой доставки. Если обращение должно попадать в CRM, недостаточно получить письмо разработчику: проверять надо именно согласованный конечный маршрут.
В смете стоит разделить размещение страниц и обслуживание заявок. Экономия на подписке сама по себе ничего не говорит о полной стоимости: у другого обработчика тоже будут настройка, поддержка и ответственный. Выбирать схему удобнее по тому, кто сможет восстановить прием обращений, если он остановится.
Редактирование после выгрузки: договоритесь до переезда
Экспорт не устанавливает визуальный редактор Тильды на ваш сервер. Правила платформы запрещают изменять выгруженный код вне Тильды и размещать его на домене, не указанном в настройках. Поэтому рабочую схему обновления строят вокруг исходного проекта и повторной выгрузки, а не ручной правки архива. Основание — правила использования экспортированного кода.
До начала работ согласуйте простой бытовой сценарий: завтра нужно поменять номер телефона. Кто вносит правку, кто размещает обновленные файлы, кто проверяет результат и сколько времени это занимает? Если ответ не определен, сайт формально переедет, но каждое небольшое изменение станет отдельным поиском исполнителя.
Для обновлений храните предыдущую рабочую выгрузку и журнал публикаций. Если две правки готовят одновременно, договоритесь, кто объединяет их перед размещением файлов.
Если цель — редактировать сайт независимо от Тильды, обсуждать нужно самостоятельную пересборку с собственным кодом и выбранной системой управления. При этом заново оценивают шаблоны, формы и интеграции, а не обещают тот же объем работ, что у загрузки архива. Вопросы исходных материалов и доступа разобраны в статье о правах на сайт и исходники.
Обратный переход на Тильду — сборка из контента
Перенос сайта с хостинга на Тильду стоит планировать как создание проекта на платформе. Ее обычная модель работы — собрать страницы из блоков, наполнить их и опубликовать; она описана в знакомстве с редактором. Закладывать в план универсальный импорт чужого сайта с сохранением всей логики нельзя.
Со старого сайта готовят тексты, изображения, файлы для скачивания, список страниц и требования к формам. Затем выбирают, как представить это в новых блоках. Сложный калькулятор, личный кабинет или связь с учетной системой требуют отдельной оценки: перенос текста рядом с ними еще не решает задачу переноса функции.
До массового наполнения разумно собрать одну типовую страницу и проверить ее на телефоне. Это помогает согласовать, что сохраняется из прежнего сайта и какие элементы придется устроить иначе. Для каталога или журнала проверяют путь от списка до отдельного товара или материала.
Чтобы разместить сайт на хостинге Тильды, страницы проекта публикуют, после чего подключают домен. Само подключение домена не загружает старые файлы. Для каждого прежнего адреса заранее выбирают соответствующую новую страницу, чтобы переход из поиска или сохраненной ссылки вел к ожидаемому содержимому.
Проверка перед переключением домена
Приемка нужна в обоих направлениях. Сначала проверяют подготовленную версию, затем согласуют момент переключения и план возврата на прежнее размещение. Старую рабочую копию и ее настройки сохраняют до окончания проверки; иначе небольшой недочет может оставить владельца без понятного способа восстановить сайт.
Проверку удобнее вести по заранее собранному списку:
- страницы открываются по ожидаемым адресам, изображения и файлы доступны;
- меню, кнопки, всплывающие окна и мобильная версия работают;
- тестовая заявка доходит до нужного получателя со всеми полями;
- HTTPS работает, а старые адреса ведут на подходящие страницы;
- счетчики фиксируют нужные события, если они входят в состав сайта.
Для форм проверяют не только сообщение об успешной отправке, но и получение обращения. Если тестовый адрес отличается от согласованного домена, учитывают описанное выше ограничение встроенных форм и повторяют проверку после переключения. У каждой проверки должен быть результат, а у каждой неисправности — ответственный за исправление.
Адреса особенно легко потерять при пересборке: внешне страница выглядит знакомо, но старая ссылка на нее уже не работает. Список соответствий и правила перенаправлений лучше подготовить до запуска; подробнее — в материале о переносе сайта без потери SEO.
Пришлите список функций сайта и желаемый способ редактирования — определим, подходит ли экспорт или нужна пересборка сайта.