Как перенести сайт с Tilda на собственную платформу без потери заявок и SEO

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

Главная опасность миграции с Tilda — сосредоточиться на новом интерфейсе и обнаружить после запуска, что форма не доставляет лид в CRM, рекламная ссылка ведёт на 404, а страница с трафиком из поиска исчезла или сменила адрес без редиректа. Эту статью стоит использовать как рабочий план для собственника, маркетолога и команды разработки. Она актуальна на 17 августа 2026 года. Речь не о типовом SEO-редизайне, а именно о границах Tilda и о контролируемом переходе на собственную платформу.

Ни Google, ни Яндекс не обещают сохранения позиций, трафика или сроков переобхода при переезде. Задача команды — не заявить «миграцию без просадки», а сохранить управляемые элементы воронки, корректно сообщить роботам о перемещении URL и быстро заметить исключения.

План статьи

1. Понять, что именно переносится с Tilda и где экспорт не решает задачу.
2. Собрать инвентарь контента, URL, рекламных точек входа и форм.
3. Спроектировать новую платформу и карту соответствий до разработки.
4. Перенести контент, лидогенерацию и аналитику как отдельные поставки.
5. Запустить сайт с адресными редиректами и проверить приёмку.
6. Наблюдать за заявками, индексированием и ошибками после релиза.

Когда перенос с Tilda оправдан

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

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

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

Сначала оцените, что можно забрать из Tilda, а что нужно пересобрать

Экспорт кода Tilda — полезный способ сохранить визуальный слепок и часть статических ресурсов, но не готовая собственная CMS. По справке Tilda, экспорт доступен подписчикам Business Plan; после экспорта отдельные сервисы платформы имеют ограничения. В частности, Tilda CRM, Tilda Members, Product Catalog и Feeds не экспортируются как самостоятельные сервисы. Для экспортированного проекта также потребуется самостоятельно организовать SSL на своём сервере. Это нужно проверить до обещаний о сроках и объёме работ.

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

Составьте таблицу активов до выбора технологии:

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

Инвентаризация: собирайте не только страницы из меню

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

• XML sitemap, список страниц Tilda и краулинг публичного сайта;
• Google Search Console и Яндекс Вебмастер: URL с показами, кликами, ошибками и внешними ссылками;
• Яндекс Метрика и другая аналитика: посадочные страницы, цели, источники, устройства и страницы выхода;
• CRM, почта и мессенджеры: какие формы и страницы дают качественные обращения;
• кабинеты рекламы, e-mail-рассылки, соцсети, карточки компаний и партнёрские материалы;
• файлы, документы и страницы «спасибо», если на них ведут ссылки или на них настроены цели.

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

Не меняйте всё одновременно

Если домен сохраняется, а меняется платформа, сохраняйте URL везде, где это разумно. Это снижает число переменных: поисковые роботы и пользователи видят знакомый адрес, а команде не нужно обслуживать сотни новых редиректов. Не заменяйте одновременно домен, структуру, дизайн, CMS, аналитику и смысл страниц, если изменения можно развести по этапам. Google рекомендует по возможности менять крупные элементы последовательно: так легче найти причину проблемы.

Если URL всё же меняется, карта соответствий должна быть готова до релиза. Формат прост: старый URL → финальный новый URL → тип решения → причина → проверка. Каждая важная старая страница ведёт на наиболее близкую по намерению страницу. Массовое перенаправление на главную не сохраняет путь пользователя: Google предупреждает, что нерелевантные массовые редиректы могут считаться soft 404, а Яндекс указывает, что такие редиректы неудобны пользователю и замедляют индексацию.

Контент переносите как ответ на задачу, а не как набор блоков

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

Для каждой приоритетной страницы проведите мини-приёмку контента:

1. Сверьте основной запрос и пользовательскую задачу старой и новой страниц.
2. Проверьте заголовок H1, title, meta description, основной текст, изображения с важным смыслом, таблицы, FAQ, документы и ссылки.
3. Убедитесь, что канонический URL новой страницы указывает на неё саму, если нет особой причины для другого решения.
4. Перепроверьте внутренние ссылки: они должны вести сразу на новый конечный URL, а не проходить через старый адрес.
5. Для удалённого материала без полезной замены отдавайте настоящий 404 или 410, а не красивую страницу ошибки со статусом 200.

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

Формы и заявки: переносите целый маршрут, а не только кнопку

Форма на Tilda — это не один HTML-блок. Она может передавать данные в CRM, почту, Telegram, webhook, Zapier и другие сервисы; Tilda также поддерживает отправку через собственный скрипт. В справке Tilda указано, что при экспорте и отмене подписки нужно добавить собственный скрипт получения заявок: механика приёма данных платформы не становится автономной автоматически. Поэтому новая форма должна иметь собственный, документированный маршрут.

Для каждой формы создайте «паспорт»:

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

Не переносите скрытые поля и обработчики «на глаз». Сделайте реальную тестовую отправку из браузера на мобильном и десктопе, затем убедитесь в трёх точках: браузер получил успешный ответ, заявка появилась в конечной системе, ответственный получил уведомление. Если новая система принимает webhook, зафиксируйте таймауты, повторные попытки и безопасное хранение секретов. Например, Tilda для webhook требует доступный HTTPS-адрес и описывает ограничение ответа в пять секунд с повторными попытками; у новой интеграции условия будут другими, их нужно проверить по документации выбранного сервиса.

Отдельно тестируйте пограничные сценарии: неверный телефон, отказ в согласии, блокировщик скриптов, дубль клика по кнопке, UTM в URL, форма в модальном окне, недоступная CRM и заявка с мобильного браузера. Событие «клик по кнопке» — полезный вспомогательный сигнал, но не замена успешной доставки лида.

Аналитика: сохраните сравнимость, а не просто вставьте счётчик

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

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

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

Для миграции полезнее не менять одновременно и платформу, и логику учёта. Если требуется новая схема аналитики, опишите сопоставление старых и новых событий и оговорите период, когда метрики нельзя сравнивать напрямую. Сохраняйте скриншоты и тестовые идентификаторы отправок: они превращают спор «заявка не дошла» в проверяемую цепочку.

SEO-запуск: URL, серверные ответы и вебмастера

При сохранении домена и URL это прежде всего смена инфраструктуры. Проверьте, что новая версия отвечает кодом 200 OK, доступна роботам, не содержит случайных noindex, а её robots.txt, XML sitemap и canonical согласованы. Контент, предназначенный для поиска, Яндекс рекомендует отдавать в HTML сразу при обращении к странице, а не прятать за обязательным JavaScript. Это особенно важно, если собственная платформа использует клиентский рендеринг.

Если адреса меняются, включайте серверные постоянные редиректы, предпочтительно HTTP 301 или 308. Google рекомендует такие редиректы для постоянного перемещения URL и советует вести их сразу на конечную страницу, не строя цепочки. У старого и нового URL не должно быть маршрута вида A → B → C, когда можно настроить A → C.

Сценарий с переездом на другой домен требует отдельной подготовки. В Search Console подтвердите права на старый и новый сайты и используйте инструмент Change of Address для миграции домена. В Яндекс Вебмастере добавьте и подтвердите оба сайта, настройте соответствующие редиректы и используйте «Переезд сайта», когда меняется основной адрес. Яндекс прямо отмечает, что при смене адреса не гарантируются сохранение числа страниц в выдаче, позиций или трафика; обработка может занимать недели и зависит от переобхода.

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

Приёмка перед переключением DNS

Стенд полезен для проверки функциональности, но до переключения он обычно закрыт от индексации. Составьте два списка: что обязано быть проверено на стенде и что возможно проверить только на боевом домене. У приемки должен быть владелец, а у каждого пункта — доказательство: URL, скриншот, номер тестовой заявки, HTTP-ответ или запись в CRM.

Чек-лист миграции с Tilda

• Есть полный реестр URL, файлов, форм, интеграций, рекламных ссылок и владельцев доступов.
• Для каждой ценной старой страницы утверждён новый URL, сохранение URL или осознанное удаление.
• Карта редиректов проверена на выборке приоритетных страниц и на всех массовых правилах.
• Нет редиректов на нерелевантную главную, цепочек, циклов и редиректов на 404.
• Новый сайт возвращает 200 на существующих страницах, а удалённые без замены — 404 или 410.
• robots.txt, XML sitemap, canonical, noindex и доступность ресурсов проверены на продакшене.
• На всех приоритетных страницах есть один корректный H1, понятный title и нужный контент.
• Все внутренние ссылки, меню, хлебные крошки, CTA, PDF и изображения ведут на конечные адреса.
• Каждая форма протестирована с реальным тестовым контактом до CRM или другого конечного получателя.
• Проверены UTM, события, цели, страница успеха, защита от спама и уведомления об ошибке.
• Счётчики и пиксели не задублированы, доступы к аналитике и вебмастерам сохранены.
• Старый сайт или домен остаётся доступен для корректных редиректов, а бэкап и план отката готовы.
• После запуска отправлены актуальные sitemap и назначен график мониторинга.

Что мониторить после запуска

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

• HTTP-коды старых и новых URL, ошибки обхода и неожиданные исключения из индекса;
• данные URL Inspection / проверок страниц в Google Search Console и Яндекс Вебмастере;
• число проиндексированных новых URL, обработку sitemap и появление неправильных canonical;
• органические переходы на приоритетные посадочные, а не только общую сумму сессий;
• отправки форм, доставку в CRM, долю дублей и качество обращений;
• кампании с UTM, расходы, страницы входа и цели;
• серверные ошибки, скорость и доступность критичных маршрутов.

Не делайте вывод о результате за один день. Google описывает миграцию как процесс по URL: робот должен посетить старые и новые адреса, а скорость зависит от масштаба и сервера. Вместо поиска «средней позиции сайта» ищите конкретные исключения: пропал ли важный URL, стал ли он 404, нет ли редиректа на несоответствующую страницу, доходят ли лиды.

Типичные ошибки при переходе с Tilda

Экспорт приняли за полноценную миграцию

Архив может быть полезен для сохранения материалов, но не переносит автоматически сервисы Tilda и не создаёт поддерживаемую архитектуру. До старта уточните статус форм, CRM, Members, каталога, лент, шрифтов, SSL и сторонних скриптов.

Новую форму проверили только визуально

Красивое поле и сообщение «спасибо» не доказывают, что лид пришёл к менеджеру. Тестируйте конечного получателя, включая отказоустойчивость интеграции и данные атрибуции.

Все старые URL отправили на главную

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

На продакшен попал запрет индексации со стенда

noindex, закрывающий robots.txt, тестовый canonical и пароль на сайте — нормальны в разработке, но критичны после запуска. Проверяйте именно боевой домен.

Рекламу и аналитику оставили «на потом»

В первые часы после переключения такие потери могут стоить больше, чем неточность в отступах. Сначала проверьте посадочные из активных кампаний, UTM и конечные события заявок.

Сразу отключили Tilda и доступы

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

FAQ

Можно ли просто экспортировать сайт из Tilda и больше не платить за платформу?

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

Сохранятся ли SEO-позиции после переноса?

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

Нужен ли 301, если меняется только платформа, а URL остаются прежними?

Нет: если конкретная страница остаётся по тому же каноническому URL, она должна сразу отвечать 200 OK. 301 нужен старому адресу, который действительно переехал на другой постоянный адрес. Не создавайте редирект ради самого редиректа.

Можно ли перенести формы Tilda без изменения логики?

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

Когда отключать старый сайт на Tilda?

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

Нужно ли подавать «Переезд сайта» в Яндекс Вебмастере, если домен не меняется?

Инструмент предназначен для изменения адреса сайта. При сохранении основного домена и URL основная работа — в доступности новых страниц, корректных кодах ответов, sitemap, canonical и мониторинге. Если меняются домен, зона, протокол или вариант с www, следуйте инструкции Яндекса для соответствующего типа переезда.

Перенос должен дать управляемость, а не просто новый визуал

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

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

Источники и дата проверки

Все ссылки проверены 17 августа 2026 года.

1. Tilda Help Center — Code Export — доступность экспорта, его ограничения и условия использования.
2. Tilda Help Center — Integrated Data Capture Forms — подключение получателей форм и условия работы после экспорта.
3. Tilda Help Center — Webhook: Receiving Form Submissions to Custom Scripts — доставка заявок webhook и требования к обработчику.
4. Tilda Help Center — How to Create URL Redirects — ограничения настройки редиректов между доменами на Tilda.
5. Google Search Central — Site Moves and Migrations — подготовка переноса, URL-карта, редиректы, sitemap и мониторинг.
6. Google Search Central — Redirects and Google Search — постоянные и временные редиректы, 301/308 и цепочки.
7. Яндекс Вебмастер — Что такое переезд сайта и как его совершить — проверка сайтов, редиректы и инструмент переезда.
8. Яндекс Вебмастер — Смена структуры и дизайна сайта — требования к контенту, URL и индексации при смене CMS или структуры.