Обсудить задачу

Из Tilda на Headless CMS: почему визуальный редактор тормозит рост

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

Почему компании уходят с Tilda

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

PageSpeed на мобильных устройствах - первый симптом. Типичный коммерческий сайт на Tilda без специальной оптимизации показывает 45-60 баллов на мобильных. Это не катастрофа, но и не конкурентный результат: Google учитывает Core Web Vitals как сигнал ранжирования, а мобильный трафик давно превысил десктопный.

Вторая проблема - ограниченный контроль над SEO. Tilda позволяет прописать title и description для каждой страницы, но возможности на этом заканчиваются. Нельзя управлять заголовками HTTP, тонко настраивать canonical, добавить кастомный structured data без Zero Block. Для контентных сайтов с десятками страниц это означает ручную работу при каждом изменении.

Vendor lock-in - самый неочевидный риск. Контент существует внутри блоков Tilda. Нет экспорта в стандартный HTML или Markdown. Если нужно переехать, вы переносите контент вручную - страницу за страницей. Один проект с 40 страницами и Zero Block-блоками - это 2-3 недели только на перенос контента.

Zero Block и кастомный код решают конкретные задачи, но создают технический долг. CSS-анимации, встроенный JavaScript и кастомные формы держатся на клею из обходных путей. При обновлении шаблона Tilda часть кастомизаций ломается. Команда, которая не умеет работать с кодом, теряет контроль над собственным сайтом.

Наконец, нет server-side rendering и динамических маршрутов. Персонализация, A/B-тестирование на уровне URL, кастомные страницы для сегментов аудитории - всё это требует либо дорогих обходных путей, либо другого инструмента.

Что теряется при наивной миграции

Наивная миграция - это «скопировал контент, поднял новый сайт, закрыл Tilda». Такой подход гарантированно роняет органический трафик на 2-4 месяца и иногда не восстанавливается.

URL-структура - критический момент. Tilda генерирует URL по своей логике. Если новый сайт отдаёт те же страницы по другим адресам без 301-редиректов, Google видит их как новые страницы без истории. Весь ссылочный вес, накопленный годами, обнуляется.

Zero Block с кастомным кодом не переносится автоматически. Каждый такой блок - это ручная работа разработчика: разобрать, что делает код, воспроизвести в новом стеке. Блоки с анимациями на GSAP, кастомные калькуляторы, интерактивные элементы - всё это требует отдельного аудита.

Формы и интеграции в Tilda часто настроены через встроенный конструктор форм или виджеты. При переезде обработчики форм нужно перенастраивать заново: Webhooks, интеграции с CRM, уведомления по email - ничего не переходит само.

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

SEO-сигналы: потеря редиректов - это только начало. Если на старом сайте были страницы с накопленными внешними ссылками, а на новом они недоступны или изменили URL без редиректа, эти ссылки перестают работать. Упомянутые в аудите миграции evilunion.com данные показывают: правильно настроенный Astro-сайт не теряет SEO-позиций при переезде, если редиректы выставлены заранее.

Аудит сайта на Tilda перед переездом

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

Инвентаризация страниц и URL: выгрузите полный список всех страниц из панели Tilda. Для каждой зафиксируйте текущий URL, заголовок, SEO-метаданные. Если сайт индексируется, экспортируйте данные из Google Search Console - это покажет какие страницы реально получают трафик и имеют позиции.

Zero Block аудит: пройдитесь по каждому Zero Block и задокументируйте что он делает: анимация, кастомная форма, интерактивный элемент, интеграция. Оцените сложность воспроизведения в новом стеке. Некоторые Zero Block’и тривиальны (CSS-класс), другие - это полноценные мини-приложения на JavaScript.

Обработчики форм: найдите все формы на сайте. Для каждой - куда идут данные (email, CRM, webhook), какие поля обязательны, есть ли валидация. Включая формы в попапах и формы, скрытые за условиями.

Сторонние скрипты: откройте исходный код каждой страницы и выпишите все внешние скрипты: аналитика (GA4, Яндекс.Метрика), пиксели (Meta, Google Ads), чаты (Intercom, JivoSite), формы (Typeform, Jotform). Это ваш чеклист для воспроизведения на новом сайте.

SEO-данные: для каждой страницы из Search Console с позициями выше 20 зафиксируйте: title, description, H1, основные ключевые слова. Это минимальный набор который нужно воспроизвести точно.

Медиа-активы: выгрузите все изображения и видео с сайта. В Tilda файлы хранятся на CDN платформы - после закрытия аккаунта они становятся недоступны.

Выбор нового стека

Для большинства маркетинговых сайтов B2B-компаний оптимальный стек в 2026 году - Astro + Sanity. Вот почему это сочетание работает лучше альтернатив.

Astro - статический генератор сайтов, который собирает HTML на этапе сборки. Результат: страница отдаётся как готовый HTML-файл без выполнения серверного кода при каждом запросе. PageSpeed 94-100 на мобильных - это стандартный результат для хорошо собранного Astro-сайта, а не исключение. LCP в среднем на 46% быстрее чем у аналогичного WordPress-сайта. Важно: Astro отправляет по умолчанию ноль JavaScript - интерактивность добавляется только там, где она нужна.

Sanity - headless CMS с визуальным редактором. Для команды контента это означает: редактор со WYSIWYG-интерфейсом, который не требует знания Markdown или кода. Для разработчиков - структурированный API с типизацией, portableText для богатого контента, webhooks при публикации. Контент в Sanity принадлежит вам и экспортируется в любой момент.

Комбинация решает ключевое противоречие Tilda: редакторы хотят визуальный интерфейс, разработчики хотят контролируемый стек. Sanity Studio разворачивается как часть проекта и настраивается под конкретную структуру контента.

Когда выбирать Next.js вместо Astro: если сайт предполагает динамические маршруты, серверную персонализацию, API-роуты или e-commerce с большим каталогом - Next.js с его App Router и server components даёт больше гибкости. Для чисто контентного маркетингового сайта Astro проще, быстрее и дешевле в обслуживании.

Хостинг: статические сайты на Astro деплоятся на Vercel, Netlify или Cloudflare Pages. Стоимость для маркетингового сайта - $0-20 в месяц против $30-100+ за managed WordPress. Деплой по push в git занимает 30-90 секунд.

Пошаговый процесс миграции

Миграция с Tilda на Headless CMS занимает 4-8 недель в зависимости от объёма сайта и количества кастомных элементов. Ниже - структура работы для типичного маркетингового сайта на 20-50 страниц.

Шаг 1 - Инвентаризация

Выполните аудит по чеклисту из предыдущего раздела. Результат: таблица всех страниц с URL, SEO-метаданными, списком кастомных элементов и форм. На этом шаге часто обнаруживается что 30-40% страниц не получают трафика и не нужны на новом сайте - это упрощает миграцию.

Одновременно настройте мониторинг текущего сайта: Google Search Console (если не настроена), PageSpeed Insights базовый замер, скриншоты ключевых страниц. Это «до» для сравнения после запуска.

Шаг 2 - Экспорт контента

Tilda не имеет нативного экспорта контента в структурированном формате. Контент переносится вручную или через скрипты, которые парсят HTML экспорт страниц.

Для каждой страницы: скопируйте текст, изображения скачайте локально, зафиксируйте структуру заголовков (H1-H3). Если на сайте много однотипных страниц (например, карточки услуг), структурируйте их в таблицу - это ускорит создание контента в Sanity.

В Sanity создайте схему для каждого типа контента: страница услуги, кейс, статья блога, лендинг. Схема определяет поля и их типы. Один раз настроенная схема работает как шаблон для всего контента.

Шаг 3 - Сборка нового сайта

Разработка компонентов в Astro идёт параллельно с наполнением CMS. Стандартный подход: сначала компоненты для главной и ключевых страниц услуг, затем блоговая инфраструктура, затем вспомогательные страницы.

Центральный момент - настройка интеграции Astro и Sanity: запросы через Sanity Content Lake API, типизация через @sanity/client, preview-режим для редакторов. При правильной настройке редактор видит изменения контента в реальном времени до публикации.

Каждый Zero Block из инвентаризации воспроизводится как React или Astro-компонент. Кастомные формы подключаются к тому же обработчику (webhook, CRM), что и раньше - меняется только фронтенд.

Шаг 4 - Настройка редиректов

Это самый критичный шаг для сохранения SEO. Для каждой страницы старого сайта нужен 301-редирект на соответствующую страницу нового.

В Astro редиректы настраиваются в astro.config.mjs:

Пример конфигурации редиректов в Astro
// astro.config.mjs
export default defineConfig({
  redirects: {
    '/old-page-url/': '/new-page-url/',
    '/services/': '/uslugi/',
    // ...
  }
})

Для Vercel и Netlify редиректы прописываются в vercel.json или netlify.toml. Перед запуском проверьте каждый редирект в списке инвентаризации - пропущенный редирект для страницы с позициями это прямой урон SEO.

Шаг 5 - Запуск и мониторинг

Запуск проходит в два этапа: сначала новый сайт поднимается на staging-домене и тестируется командой. Чеклист перед переключением DNS: все редиректы работают, формы отправляют данные, скрипты аналитики срабатывают, мета-теги корректны на каждой странице.

После переключения DNS: в первые 48 часов мониторинг статусов в Search Console, проверка crawl errors, подтверждение что старые URL корректно редиректят. В течение первых 2 недель Google заново обходит сайт и перераспределяет PageRank через редиректы. Позиции могут незначительно колебаться - это нормально при правильно настроенных редиректах.

Core Web Vitals до и после

Реальные числа - главный аргумент в разговоре о переезде. На основе типовых проектов миграции маркетинговых сайтов с Tilda на Astro:

PageSpeed (мобильные): 45-60 до миграции -> 92-98 после. Разница в 35-50 баллов - это переход из «красной» зоны в «зелёную» в Google Search Console.

LCP (Largest Contentful Paint): 3.5-5 секунд на Tilda -> 1.0-1.8 секунды на Astro. Порог «хорошо» по стандарту Google - менее 2.5 секунды. Большинство Tilda-сайтов не проходят этот порог на мобильных без специальной оптимизации.

CLS (Cumulative Layout Shift): Tilda-сайты с анимированными блоками часто показывают CLS 0.15-0.25. На Astro при правильной вёрстке - стабильно менее 0.05.

INP (Interaction to Next Paint): заменил FID с марта 2024. На статических сайтах Astro без тяжёлого JavaScript INP стабильно держится ниже 100 мс. Это принципиально: Astro отправляет ноль лишнего JS, интерактивность подключается точечно.

По данным сравнительного исследования wppoland.com (2026), Astro 6 достигает PageSpeed 98-100 со временем загрузки менее 500 мс. В реальных проектах числа чуть скромнее из-за изображений и сторонних скриптов - но 92-96 на мобильных это устойчивый результат.

Практический кейс: в типовом проекте миграции маркетингового сайта (15-25 страниц, 3-4 формы, GA4 + Meta Pixel) переезд с Tilda на Astro + Sanity занимает 5-6 недель. После запуска через 4-6 недель позиции восстанавливаются до исходного уровня или превышают его за счёт улучшенных CWV.

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

Запуск без редиректов - самая дорогая ошибка. Встречается в 30-40% самостоятельных миграций. Симптом: через 2-3 недели после запуска трафик падает на 30-60%. Причина: Google обрабатывает смену URL как удаление старых страниц.

Перенос структуры Tilda 1:1. В Tilda контент организован по блокам, а не по смыслу. Прямой перенос блочной структуры в компоненты нового сайта воспроизводит все слабые места старого сайта. Миграция - это возможность переосмыслить структуру страниц.

Игнорирование мобильной версии. Tilda автоматически адаптирует блоки для мобильных. В кастомной разработке адаптивность нужно проектировать осознанно. Особенно критично для форм и CTA-блоков.

Неправильная настройка Sanity Studio. Редакторы получают доступ к CMS без обучения и начинают использовать portableText нестандартно - вставляют HTML-код в текстовые поля, нарушают структуру заголовков. Инвестируйте 2-4 часа в настройку и объяснение схемы редакторам до запуска.

Потеря форм. Zero Block с кастомной формой часто содержит валидацию и логику которая нигде не задокументирована. При воспроизведении упускают обязательные поля или условия показа. Тестируйте каждую форму на staging до запуска.

Деплой без тестирования на реальных устройствах. PageSpeed Insights показывает симуляцию. Проверяйте сайт на реальном Android-смартфоне среднего класса - именно так его видит ваша аудитория.

Для кого актуально

Переезд с Tilda на Headless CMS оправдан для компании, у которой выполняется хотя бы одно из условий:

  • Органический трафик есть и важен, но PageSpeed на мобильных ниже 70 баллов
  • Сайт ведут 2+ человека и нужен управляемый рабочий процесс для контента
  • Планируется блог, база знаний или любой другой раздел с регулярными публикациями
  • Нужны интеграции с CRM, аналитикой или рекламными системами на уровне событий
  • Есть технический долг в виде Zero Block’ов, которые периодически ломаются
  • Компания рассматривает международный рост и нужна мультиязычность

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

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

Часто задаваемые вопросы

Сколько времени занимает переезд с Tilda на Headless CMS?

Для маркетингового сайта на 15-30 страниц - 4-6 недель. Для сайта с 50+ страницами, кастомными Zero Block’ами и несколькими типами контента - 8-12 недель. Основные факторы: количество страниц, сложность кастомных блоков, наличие блога, количество форм и интеграций. Инвентаризация перед стартом позволяет оценить объём точнее и избежать сюрпризов в процессе.

Потеряю ли я SEO-позиции при переезде?

При правильно настроенных 301-редиректах и сохранении SEO-метаданных позиции восстанавливаются в течение 4-6 недель. Более того, улучшение PageSpeed с 50 до 95+ баллов на мобильных - это позитивный сигнал для Google, который в долгосрочной перспективе улучшает ранжирование. Риск есть только при наивной миграции без редиректов или при смене URL-структуры без маппинга.

Смогут ли редакторы без технических знаний работать в Sanity?

Да. Sanity Studio - это WYSIWYG-редактор с визуальным интерфейсом. Редактор создаёт и редактирует контент так же как в Google Docs, только с более строгой структурой (заголовки, текст, изображения, встраиваемые блоки). Первичная настройка структуры - задача разработчика, дальнейшая работа с контентом не требует технических навыков. Обучение для нового редактора - 1-2 часа.

Почему не WordPress вместо Headless CMS + Astro?

WordPress закрывает задачу переезда с Tilda, но не решает проблему производительности. Средний WordPress-сайт показывает PageSpeed 55-75 на мобильных - лучше неоптимизированной Tilda, но далеко от 90+. WordPress требует постоянного обслуживания: обновления плагинов, безопасность, кэширование. Astro + Sanity проще в обслуживании (статика не взламывается), быстрее по умолчанию и масштабируется без роста стоимости хостинга. Если команда уже знает WordPress и нет проблем с PageSpeed - оставаться на нём разумно. Если цель - производительность и независимость от экосистемы плагинов, современный стек выигрывает.


Если ваш сайт на Tilda упирается в ограничения платформы и вы рассматриваете переезд - опишите задачу команде Exceltic.dev. Проведём аудит и оценим объём работы по миграции: какие страницы переезжают, что требует переработки, какой стек подойдёт под вашу команду. Разберём архитектуру и дадим честную оценку сроков и рисков.

Ещё статьи

Все →