Astro vs Webflow: we build both – so we have no reason to sell you either.

No – they solve different bottlenecks. Webflow is a platform bundling visual editing, CMS, hosting and CDN. Astro is an open-source framework with no CMS and no hosting of its own. The question gets useful when you ask it differently: where does it hurt? If it hurts when your marketing team wants to build and change pages, Webflow wins. If it hurts in the content model, in per-site running cost, or in control over what is delivered, Astro wins.

Check that one very carefully, because it is the reason most migrations fail. Free visual layout building does not come along; after the move you maintain fields rather than layouts. There are three replacements: content stays as Markdown in the repository, a headless CMS provides an editing interface, or changes run through a chat agent. Settle this before the migration, or you will migrate the website and lose the maintenance.

No, that is a cliché. A cleanly built Webflow site with sensible images and restrained interactions performs well. The real difference is control rather than raw speed: on a platform the platform decides the markup and ships its runtime, while in Astro you decide about every byte of JavaScript per component. It usually becomes noticeable only after years of accumulated embeds and third-party scripts.

Partly. An export gives you markup, styles and assets – a good reference for the visual result, but no content model, no components and no CMS structure. There is no official migration guide from Webflow into Astro, unlike Next.js, Gatsby or WordPress. In practice that means: the design stays, the technology is rebuilt, and the content is remodelled and carried over.

On Webflow, running the site is a predictable subscription per site that includes hosting, SSL, CDN, backups and the Editor. With Astro the framework itself costs nothing; prerendered pages run on ordinary hosting or a CDN, while on-demand rendered routes need an adapter and a runtime. In exchange you carry updates and operations yourself or put them into a maintenance agreement. For a single site the two often land close together; across a portfolio of many sites they do not.

Not if the migration is planned as an SEO project. That means a complete inventory of every URL, a redirect plan for each old address including pagination, carrying over titles, metadata and structured data, a check in staging, and monitoring after go-live. The usual cause of a drop is missing redirects and changed page structures, not the framework.

Whatever fits your team, not our pipeline. As a rule of thumb: if your marketing team builds pages and design is the engine, we recommend Webflow and deliver it as a Webflow agency. If your archive is growing, if content belongs in version control, or if platform limits and per-site cost are biting, we recommend Astro. In the cases in between we tell you which question to settle internally first – usually the question of who will maintain the content.

Because the two solve different bottlenecks, and we would rather not translate every enquiry into the same technology. Webflow is our route for design-driven sites where a team builds pages itself – we have a client site live in production on it. Astro is our route when content belongs in version control, when the archive grows, or when delivery has to be controlled precisely. In practice that means a recommendation against moving costs us nothing – which is exactly what makes it worth something.

The posts are exported as data and moved into a new content model – in Astro typically content collections with a Zod schema, which are explicitly built for large sets and ship caching for them. We build in parallel: your Webflow site stays online until the new version is signed off on staging. There is one window all the same: the content freeze of two to five days before the switch, so new posts do not end up only in the old system. The switch itself runs through DNS or hosting configuration, with the redirect map going live at the same moment – a matter of minutes. We do not guarantee zero downtime; we keep the old state ready as a fallback.

A fair objection, and it cuts both ways. Webflow has a large market of designers and builders; Astro has a smaller pool of declared specialists. The gap is milder than it sounds: an Astro site is HTML, CSS, TypeScript and optionally React, Svelte or Vue, so anyone working with those is productive within days. The harder question is not how many Astro profiles exist, but whether anyone in your company wants to work with a repository at all.

With Astro the code is yours, the repository sits on your account, and hosting and domain are on your contracts. The framework is open source under the MIT licence – there is no licence we could withdraw. With Webflow it is the mirror image: the account is yours, the platform stays Webflow. In both cases we hand over documented access, a description of the structure and the build or publish route, so your team or another agency can continue without asking us.

What we built, we fix – implementation defects are warranty work, not an extra invoice. Before go-live we put in writing what counts as a defect, what counts as a change request, and how fast we respond. Operations are separate: updates, monitoring and small changes go into a maintenance agreement – or you take them on yourself. What is not in our hands are outages at your suppliers, such as hosting, the CDN or embedded third parties.

Usually yes, but not by themselves. Embedded third-party pieces – booking, reviews, chat – are script embeds and can be carried over; during the rebuild we deliberately decide whether they load immediately, on idle or only on scroll. The forms are what creates work: Webflow receives submissions itself, Astro does not. For that we add a form service or a custom API route. We inventory every embed beforehand and tell you what stays, what is replaced and what is dropped without replacement.

Yes, and it is often the calmer route. Two patterns are common: one bounded area – the blog, say, or a product section – is built in Astro first and served under the same domain through the redirect or proxy layer, while the rest stays in Webflow. Or you start with the few templates carrying the most traffic. The only thing that matters is that the URL structure stays unambiguous across both systems and no address is claimed twice.

Answered fairly: yes, and partly. Webflow is a closed system. You can export markup, styles and assets, but you cannot take the running system with you; the Editor, the CMS and the hosting stay there. That is the price of the package, and for many companies it is a good trade. With Astro the code is yours and the framework is MIT-licensed – in exchange you are tied to your own decisions: the CMS you picked, the hosting adapter, and having someone keep it current.

The mechanism is unspectacular, which is exactly why it holds: an agent writes into the same schema-validated content model your editors use, and triggers a commit and a deploy. Anything that does not fit the schema fails in the build rather than on the live site. Scope is defined per project – which fields, which collections, which approval stage. Structural changes remain development work. That chat agents are day-to-day work here is evidenced by our running WhatsApp AI agent.

The assessment itself costs nothing: you describe your case, we look at the site, and you get a written answer with reasoning – including the version that says "stay on Webflow". Prices for the build are deliberately not on this page, because a number without your page list would be a guess. What drives the frame – number of templates, content volume, CMS, languages, embeds – is on Astro development cost.

Yes. Astro is free and open-source software under the MIT licence; there is no licence fee for the framework itself. Cost arises elsewhere: development, hosting, any connected CMS, and ongoing operations.

Not necessarily. By default an Astro site is fully prerendered and delivered as static HTML, which runs on any web space or CDN. Only routes rendered on demand need a runtime and an adapter, such as @astrojs/node, @astrojs/vercel or @astrojs/cloudflare.

Yes, that is the standard case. Posts sit as Markdown or MDX files in a content collection with a Zod schema, are queried through getCollection() and built into static pages. Alternatively a headless CMS delivers the posts over an API.

Astro delivers fully rendered HTML by default and leaves titles, metadata, structured data and the sitemap entirely to you. Webflow also serves server-rendered HTML. In the end neither of them ranks – content, structure and links do.

Astro is an open-source project developed in the open in the withastro repository on GitHub. The licence is MIT and the copyright notice in the repository reads Fred K. Schott. Documentation and release notes are public at docs.astro.build and astro.build.