Webflow vs Astro with a headless CMS: who can change what?

Moving a marketing site from Webflow to Astro with a headless CMS changes who controls the code and how the publishing workflow is built. It does not have to mean that every new page needs a developer.

The useful comparison is between two actual setups, not the best version of one platform and the worst version of the other.

What makes a move worth considering

Recurring engineering work, difficult content requirements and a need for clearer code review or testing can all justify a migration review. A framework preference alone does not explain the benefit to the team that publishes the site.

Name the problem in operational terms. Is content duplicated? Are integrations hard to change safely? Does engineering already own most updates? Are routine page launches blocked by the current setup?

Then ask whether a repair, a different plan or a separate application could address the problem without moving the whole site.

What marketing can actually do

With Astro and Sanity, marketers can edit content and, when a page-building model is implemented, compose pages from approved sections. A new section design or schema change still needs development. Sanity documents visual editing and an Astro integration; those capabilities need to be configured around the site's components.

Use a task comparison during scoping:

This is a scoping worksheet, not a universal feature score. Demonstrate the important tasks before committing to the migration.

What engineering gains and inherits

A repository can give developers a direct place to review components, dependencies, routes and tests. It also gives them responsibility for maintaining that code and the services around it.

Shared code with a product is possible only when the components and runtime boundaries are compatible. Reading from an external system still requires integration work. A headless stack also has service limits, including those documented by Sanity.

Do not describe the new setup as unlimited or maintenance-free. Its advantage should be clearer control over work your team actually needs to do.

Request-time features are a separate decision

A conventional Designer-built Webflow page and a code application are different execution environments. But Webflow Cloud supports code-based applications, so “Webflow cannot run server-side logic” is too broad a description of the current platform.

For a portal, account-specific page or live-data feature, choose the rendering and hosting approach around that requirement. It may be part of the Astro migration, or it may belong in a separate application.

A hybrid setup can be useful

Keeping the marketing site in Webflow while moving a specialized area into code can preserve a working publishing workflow. It can also create duplicate styling, multiple deployments and new integration boundaries.

Choose the split because it makes ownership clearer, not because a hybrid is automatically cheaper or safer.

Compare the same five tasks in both systems

A fair evaluation uses the same content, the same people and the same required result. Ask the team to demonstrate a headline edit, a new campaign page, a shared content update, a new section design and an urgent correction.

Do not compare a fully configured Webflow site with an empty CMS, or a polished custom CMS demo with an unmaintained Webflow build. Both comparisons can make the preferred choice appear inevitable. The useful question is what the proposed implementation will let this team do once the project is finished.

For each task, note the steps, permissions, preview experience, approval process and time waiting for another person. A workflow that takes fewer clicks but requires an unavailable developer may be less useful than one the marketing team can complete independently.

Define the contract between content and components

In a headless setup, a content block and its rendered component form a contract. The block defines what editors can provide; the component defines how those values appear and behave. A clear contract gives editors useful control without exposing implementation details they should not have to manage.

A hypothetical customer-story feature might allow an editor to choose a story, select an approved visual variant and write a short introduction. It would not need fields for arbitrary CSS selectors or animation timing. If a new campaign requires an entirely different pattern, that becomes a deliberate design and development task.

The table describes a possible operating model, not an automatic entitlement provided by every CMS installation. Include the intended boundary in the migration scope.

Follow a campaign page from draft to correction

In a representative headless workflow, an editor creates a page from approved sections, selects existing content and checks a preview. The page goes through the team's review process, then publishing makes it eligible for the production delivery path.

What happens next depends on rendering and caching. A static deployment may need a build to finish. A request-rendered page may obtain the current content through a configured data path. Either approach needs an understandable status and a way to investigate when the live result differs from the editor's expectation.

Now test a correction. Can the editor identify the current version, change the wrong value and confirm that the public route has updated? Can the team recover an earlier version if needed? The recovery experience belongs in the evaluation because publishing mistakes happen in every system.

Do the equivalent exercise in Webflow using the permissions and workflow the team actually has. Record what is convenient, what requires a specialist and what would change after migration.

Account for previews, permissions and environments

A preview is a product feature for editors. It should explain which content is being shown and keep unpublished material within the intended access boundary. A screenshot of a finished page is not a substitute for an editor using the actual preview process.

Permissions should follow responsibilities. Someone who edits article copy may not need access to production credentials or schema changes. Someone maintaining the application may need deployment access without being responsible for approving marketing claims.

Separate environments also need a policy. If development uses a copy of production content, decide how it is refreshed and how accidental writes are avoided. If previews use draft content from the main dataset, make that behavior explicit. The goal is a setup that the team understands well enough to operate without relying on one person's memory.

Put maintenance into the comparison

A headless implementation introduces interfaces between systems: CMS to frontend, publishing to deployment, forms to their destination and analytics to its reporting service. Those interfaces can be well documented and testable, but they still need owners.

Ask what happens when a build fails, a webhook is delayed or a content type changes. Ask who updates dependencies and who verifies that the editor experience still works afterward. The answer can be a small support arrangement or an internal responsibility; it should not be an unassigned expectation.

Webflow has its own operational work around integrations, custom code and publishing. Compare the real responsibilities in both setups rather than describing one as managed and the other as entirely manual.

Choose with a short acceptance exercise

Before signing off on the architecture, ask the people who will use it to complete the representative tasks. Record the result and the unresolved gaps. If routine work becomes clearer and the team can own the added responsibilities, the move has a practical case.

If the proposed setup makes everyday publishing harder without solving a recurring problem, improve the model or reconsider the scope. A partial move may preserve a useful workflow while solving a specialized requirement elsewhere.

Use Sanity versus Webflow CMS for the content-model comparison and modeling content in Sanity for the design of the editorial controls themselves.

Decide using recent work

Take real requests from the last few months and walk through them in the proposed setup. Include ordinary publishing and an unusual change that required engineering.

Compare the work required, the people involved and the ongoing costs. Do not assume that Webflow removes all maintenance or that Astro automatically improves performance.

The better setup is the one your team can use and maintain while meeting the site's requirements.

Discuss your current setup before deciding which platform should own each part.

Sources

• Sanity: Visual editing with Astro. Checked September 18, 2026.
• Sanity: Technical limits. Checked September 18, 2026.
• Webflow Cloud: Introduction. Checked September 18, 2026.