Компании уходят с Webflow на Astro, когда конструктор упирается в потолок: лимиты CMS-коллекций, урезанный кастомный код и хостинг, который нельзя вынести за пределы платформы. Astro решает это через сборку сайта в статический HTML на этапе билда и модель “нулевого JavaScript по умолчанию” - код проекта становится собственностью команды, а не арендой у Webflow. Ниже - конкретные цифры ограничений и пошаговый процесс переезда без потери контента и позиций в поиске.
В проектах веб-разработки Exceltic.dev регулярно видим одну и ту же точку перелома: маркетинговый сайт на Webflow работал нормально, пока в CMS было 500-1000 записей и десяток кастомных скриптов. После 2000+ элементов в коллекции и очередного блока кастомного кода в Embed-элементе начинают падать скорость сборки в дизайнере и отклик страниц.
По данным официальной документации Webflow, обновлённой в мае 2026 года, тарифный план Premium ограничивает проект 40 CMS-коллекциями и 20 000 элементами, а лимит символов в блоке Custom Code зафиксирован на уровне 50 000 знаков независимо от тарифа. Для сайта с блогом, кейсами, вакансиями и мультиязычными версиями этого объёма хватает на 1-2 года активного роста контента, не больше.
Дальше в статье - что именно теряется при наивном переезде, как устроен аудит перед миграцией, почему архитектура Astro закрывает именно эти ограничения, и с какими цифрами Core Web Vitals обычно выходят проекты после переезда.
Проблема не абстрактная. Маркетинг-команда не может добавить нужный tracking-скрипт, потому что упёрлась в лимит символов Custom Code. Разработчик не может подключить свою CI/CD-цепочку, потому что хостинг жёстко привязан к инфраструктуре Webflow. А руководитель не может посчитать реальную стоимость владения сайтом, потому что цена растёт с каждым новым тарифным порогом по числу коллекций и элементов.
Почему компании уходят с Webflow
Решение уйти с конструктора почти никогда не связано с дизайном - Webflow остаётся сильным инструментом для быстрой сборки визуала. Уходят из-за трёх повторяющихся ограничений: потолок CMS, урезанный кастомный код и привязка к хостингу.
Vendor lock-in: ситуация, при которой перенос проекта на другую платформу технически возможен, но требует полной пересборки логики и данных из-за проприетарного формата хранения. Webflow хранит контент, интеракции и логику в закрытом формате, который не экспортируется в рабочем виде - экспортируется только статическая разметка без данных CMS.
Каждое взаимодействие, добавленное в Дизайнере Webflow - анимация при скролле, hover-эффект, переход между страницами - попадает в общий файл webflow.js, который загружается на каждой странице сайта целиком, даже если конкретная страница не использует ни одной анимации. При росте числа интеракций растёт вес этого файла и время выполнения на стороне клиента, независимо от того, видит ли пользователь эти эффекты.
Добавляется стоимость поддержки: тарифная сетка Webflow привязана к росту проекта - количеству CMS-элементов, коллекций, посещаемости хостинга. Рост контента и трафика напрямую конвертируется в рост ежемесячного счёта, при этом сам код проекта команде не принадлежит. Похожая динамика знакома владельцам сайтов на WordPress: они тоже упираются в потолок производительности после определённого объёма контента и плагинов, просто по другой технической причине.
Что теряется при наивной миграции
Прямой перенос “как есть” без плана почти всегда разрушает часть сигналов, которые формировались годами: URL-структуру, редиректы, метаданные и часть контента, привязанного к специфичным для Webflow сущностям.
CMS-коллекции Webflow не экспортируются вместе с данными - выгружается только шаблон HTML без содержимого. Каждую запись коллекции - статью блога, кейс, вакансию - нужно вытащить отдельно через Webflow CMS API или Designer API, иначе после переезда динамические страницы становятся пустыми.
Формы на Webflow работают через встроенный обработчик, который не переносится на внешний хостинг: без миграции на сторонний сервис приёма форм или собственный backend все формы на сайте перестают отправлять данные в день переезда.
URL-структура коллекций и slug-паттерны Webflow не всегда совпадают с тем, что логично для нового стека - без карты редиректов 301 часть накопленной SEO-ценности страниц теряется в течение нескольких недель после переезда, пока Google не переиндексирует новые адреса.
Анимации и интеракции, зависящие от собственного JS-движка Webflow, не работают вне платформы - webflow.js остаётся привязан к инфраструктуре Webflow, и после экспорта эти эффекты просто перестают срабатывать.
Аудит перед переездом - чек-лист
Перед тем как проектировать новую архитектуру, нужно инвентаризировать всё, что сейчас держит сайт на Webflow - иначе часть контента и логики потеряется незаметно.
- CMS-коллекции и связи между ними - сколько коллекций, сколько элементов в каждой, есть ли multi-reference поля, которые придётся переносить как связи в новой модели данных
- Кастомный код - весь код в Page Settings, Site Settings и Embed-элементах: что делает каждый скрипт, откуда тянет данные, какие сторонние сервисы вызывает
- Формы и их получатели - куда сейчас уходят данные из форм: почтовый сервис, внешняя система приёма заявок, сценарий автоматизации
- Интеграции и трекинг - GA4, пиксели рекламных кабинетов, чат-виджеты, A/B-тесты
- Карта URL и редиректов - полный список текущих адресов, включая пагинацию коллекций, теги, фильтры
- SEO-метаданные - title, description, Open Graph, структурированные данные по каждому шаблону страницы
Архитектура нового стека на Astro
Целевая архитектура для контентного или маркетингового сайта, уходящего с Webflow, - Astro поверх headless CMS с рендерингом на этапе сборки (build-time), а не в браузере пользователя.
Островная архитектура (islands architecture): подход, при котором страница по умолчанию рендерится в статический HTML без JavaScript, а интерактивные элементы - форма, слайдер, калькулятор - подгружаются отдельными “островками” только там, где они реально нужны.
Astro решает три ограничения Webflow напрямую:
- Хостинг перестаёт быть точкой блокировки - собранный статический сайт разворачивается на любой инфраструктуре: Vercel, Netlify, Cloudflare Pages, собственный сервер
- Кастомный код больше не ограничен лимитом символов в Embed-элементе - любая логика пишется как обычный код в репозитории, версионируется через git и проходит через CI
- Контент хранится в headless CMS - выбор конкретной платформы зависит от команды и бюджета - без потолка по числу коллекций и элементов, привязанного к тарифу
Из-за рендеринга на этапе сборки браузер получает готовый HTML без ожидания выполнения фреймворка - это прямая причина, почему у Astro-сайтов стабильно низкий LCP по сравнению с сайтами, которые полагаются на клиентский рендеринг или собственный JS-runtime платформы.
Пошаговый процесс миграции с Webflow на Astro
1. Экспорт контента через Webflow CMS API
Каждая коллекция выгружается через Webflow CMS API в формате JSON - это единственный способ получить данные, а не только шаблон. Экспорт нормализуется под схему новой headless CMS, включая multi-reference и rich-text поля.
Пример запроса к Webflow CMS API
curl -X GET "https://api.webflow.com/v2/collections/{collection_id}/items" \
-H "Authorization: Bearer {token}" \
-H "accept-version: 2.0.0"
2. Вёрстка компонентов на Astro
Каждый визуальный блок Webflow (hero-секция, отзывы, карточки кейсов) переносится в отдельный .astro-компонент. Анимации, которые в Webflow держались на webflow.js, переписываются на CSS и IntersectionObserver либо на лёгкую библиотеку вроде Motion One - без общего runtime-файла на каждой странице.
3. Карта редиректов 301
Каждый действующий URL сопоставляется с новым адресом. Редиректы настраиваются на уровне хостинга или CDN до переключения DNS, чтобы избежать простоя в индексации.
4. Перенос форм и интеграций
Формы переключаются на serverless-функцию или сторонний сервис приёма заявок, трекинг-скрипты и пиксели переносятся в код проекта напрямую, без ограничения по количеству символов.
5. Тестирование и запуск
Перед переключением DNS проверяются: работоспособность форм, корректность редиректов, соответствие метаданных по каждому шаблону, скорость по PageSpeed Insights на staging-домене. Домен переключается только после того, как staging проходит все проверки.
Core Web Vitals до и после
Сайты на Webflow с активным набором интеракций и подключёнными сторонними скриптами обычно показывают LCP в диапазоне 3-5 секунд и INP выше 200 мс на мобильных устройствах - из-за общего файла webflow.js, который выполняется на каждой странице независимо от того, нужен ли он ей.
В типовом проекте миграции контентного сайта с Webflow на Astro LCP снижается до 1.2-1.8 секунды, а INP укладывается в порог “хорошо” - менее 200 мс, по методологии Core Web Vitals - почти на всех страницах, кроме тех, что содержат тяжёлые интерактивные виджеты. CLS в большинстве случаев не требует отдельной работы: Astro по умолчанию резервирует место под изображения через встроенный компонент <Image />.
Прирост объясняется архитектурой, а не мелкими оптимизациями: браузер получает готовый HTML без ожидания выполнения JS-runtime, а интерактивность подгружается только там, где она реально нужна странице.
Типичные ошибки при переезде
- Перенос без карты редиректов - обвал позиций в поиске в течение 2-4 недель после переезда, пока Google не переиндексирует новые URL как замену старых
- Ручной перенос контента копипастом - теряются связи между CMS-элементами (multi-reference поля), которые в Webflow работали “из коробки”
- Забытые сторонние скрипты - трекинг-пиксели и чат-виджеты, зашитые в Custom Code, не переносятся автоматически и выпадают из нового сайта
- Отказ от аудита форм - заявки перестают доходить в день переезда, потому что старый обработчик форм Webflow работал только в его собственной инфраструктуре
- Игнорирование staging-тестирования - переключение DNS до проверки редиректов и метаданных на тестовом домене
Для кого актуально
Переезд с Webflow на Astro закрывает боль в первую очередь у компаний с растущим маркетинговым или контентным сайтом: 15+ сотрудников, активный блог или база кейсов, команда, которая упёрлась в лимиты тарифного плана или хочет получить код в собственность вместо аренды инфраструктуры. Если вы планируете переезд сайта с любого конструктора на современный стек, аудит перед переездом - универсальный первый шаг независимо от исходной платформы. Для одностраничного лендинга без активного роста контента миграция может быть избыточной - разница в Core Web Vitals не окупит стоимость переезда, если сайт и так простой.
Часто задаваемые вопросы
Сколько занимает миграция с Webflow на Astro?
Для сайта с блогом и кейсами (50-200 страниц, включая CMS-элементы) типовой срок - от 3 до 6 недель, включая аудит, вёрстку компонентов, перенос контента и тестирование редиректов. Срок растёт пропорционально числу уникальных шаблонов страниц и кастомных интеракций, которые нужно переписать с нуля.
Теряются ли позиции в поиске при переезде на Astro?
Позиции не теряются, если карта редиректов 301 покрывает все действующие URL, а метаданные переносятся без изменений на старте. Временная просадка на 1-2 недели возможна из-за переиндексации, но это не связано с самим стеком - то же происходит при любой смене домена или структуры URL.
Можно ли оставить часть сайта на Webflow, а часть перенести на Astro?
Технически можно через поддомен или отдельный путь, но это редко оправдано: два разных стека увеличивают сложность поддержки, а часть проблем - лимит CMS, ограничения кастомного кода - сохранится там, где сайт остаётся на Webflow.
Нужна ли headless CMS для миграции с Webflow, или можно хранить контент в файлах?
Для сайта с несколькими десятками страниц достаточно markdown-файлов в репозитории. Для сайта с активно растущим блогом, кейсами или вакансиями, где контент редактируют нетехнические сотрудники, нужна headless CMS с админкой - иначе каждое обновление контента потребует участия разработчика.
Что делать с формами после ухода с Webflow?
Формы переключаются на serverless-функцию (например, на Vercel или Netlify Functions) или сторонний сервис приёма заявок. Всю логику валидации и получателей нужно перенести до переключения DNS, чтобы не потерять ни одной заявки в день запуска.
Если ваш сайт на Webflow упёрся в лимит CMS-коллекций или в стоимость тарифа, которая растёт быстрее, чем оправдано объёмом контента - опишите архитектуру текущего сайта команде Exceltic.dev. Проведём аудит и оценим объём работ по переезду на Astro.