You’ve been told Astro is fast. Then someone asks: “How do we update the blog?” That question exposes the part of the Astro pitch that usually gets skipped. Astro is a frontend framework — it has no built-in content editing interface. Before you go live, you need to decide how your team will actually change words on a page. This article answers that completely — including the option nobody leads with: you might not need a headless CMS at all.
What “Headless” Actually Means
A traditional CMS like WordPress couples two things together: the content database and the frontend that renders it. You log in, write a post, save it, and WordPress handles the HTML output. The CMS and the website are the same system.
A headless CMS cuts those apart. The CMS stores and serves content through an API. The frontend — your Astro site — calls that API to get the content and decides how to display it. The CMS is the warehouse; your Astro build is the storefront.
This separation gives you flexibility. You can use the same content in a website, a mobile app, and an email campaign without duplicating it. But that flexibility comes with a cost: you are now maintaining two systems, paying for two platforms, and integrating them yourself.
How Astro Fetches Content
Astro can pull content from a headless CMS in two ways, and the choice matters for your editorial workflow.
Build-time fetching is the default Astro pattern. When you trigger a deploy, Astro calls the CMS API, pulls all the content, and bakes it into static HTML files. The result is fast — no database queries at runtime, no API latency for visitors. The trade-off: when a content editor publishes something in the CMS, the live site does not update immediately. A webhook fires, Vercel or Netlify starts a new build, and 1–3 minutes later the change is visible. For most blog posts and landing pages, that delay is invisible to readers.
Request-time fetching with SSR means Astro calls the CMS API on every page request. Content is always current. This is the right choice for personalized pages, real-time inventory, or anything that changes faster than a build cycle. SSR adds hosting complexity and removes the performance floor of fully static HTML.
For a typical business website — a blog, service pages, case studies — build-time static is the correct default. The 1–3 minute publish lag is not a meaningful problem. Your content editor does not need instant live preview; they need a reliable way to make changes.
Do You Even Need a Headless CMS? Three Scenarios
Before evaluating CMS platforms, ask a harder question: does your editorial workflow actually require one?
Scenario 1: Markdown files in the repository. Astro has first-class support for Markdown and MDX. Content lives as .md files inside your project. Editors push changes via Git — or a developer handles updates on request. This approach costs nothing, has no SaaS dependency, and is technically the simplest architecture available. It is the right fit for sites that change rarely: portfolios, small business brochure sites, documentation. If your content editor is a developer or is comfortable with Git, this covers most of what you need.
Scenario 2: A Git-based CMS. Tools like Decap CMS (formerly Netlify CMS) and Tina CMS sit on top of your Git repository. Editors get a web interface — a form for fields, a rich text editor for body copy — but underneath, their edits are commits to the same Markdown files. There is no separate API, no separate database. Decap is free. Tina’s open-source version is free; the hosted version starts at $29/month. For small teams where the content model is simple, this covers everything. The editorial experience is basic but functional.
Scenario 3: An API-based headless CMS. Sanity, Contentful, and Storyblok are fully independent platforms. Content lives in their cloud, not your repo. They offer structured content models, role-based access, localization, approval workflows, and rich editorial interfaces. This is the right choice when you have a dedicated marketing team updating content daily, complex content relationships across multiple content types, or multi-channel publishing needs. It is also where the costs start to climb.
The honest answer for most SMBs: Scenario 1 or 2 is enough. Scenario 3 is built for editorial teams that will actually use the advanced features.
The Main Headless CMS Options for Astro
Astro maintains official integrations with 20+ CMS platforms. Here are the five most relevant for business websites:
| CMS | Best For | Pricing | Astro Support |
|---|---|---|---|
| Sanity | Complex content models | Free (3 users), $15/user/mo+ | Official, GROQ |
| Contentful | Enterprise editorial | Free tier, $300+/mo Pro | Official, REST/GraphQL |
| Storyblok | Visual editing | Free (1 user), $99/mo+ | Official, visual editor |
| Tina CMS | Git-based, simple UI | Free OSS, $29/mo hosted | Good |
| Decap CMS | Lightweight Git-based | Free | Markdown direct |
Sanity is a developer’s CMS. Content schemas are defined in JavaScript. The editing interface — called Sanity Studio — is a React app you configure and deploy yourself. Sanity’s query language, GROQ, is powerful but has a learning curve. The free plan covers up to 3 users with reasonable API limits. Beyond that, it is $15 per user per month. For a team of 5 editors, that is $75/month in addition to your hosting.
Contentful is the enterprise choice. The interface is polished, the permissions model is robust, and the documentation is thorough. The free tier covers 5 users and 25,000 entries — sufficient for getting started. But if you need a production-ready setup with multiple environments, locales, and team management, you are looking at the Professional plan at $300+ per month. That number surprises most SMB clients when they see it for the first time.
Storyblok is the closest a headless CMS gets to a visual page builder. Editors can see a live preview of the page while editing components. The free plan supports one user; the Starter plan is $99/month and covers up to 5 users. For teams that want something closer to a WordPress page builder experience in a headless setup, Storyblok is the strongest option — but you are still paying for a separate platform on top of your hosting.
Tina CMS works on Git files with a clean editing interface. It supports MDX, has inline editing capabilities, and Astro support is solid. For small teams that want a real editing UI without a SaaS bill, the open-source version is the most practical option in this list.
Decap CMS is minimal and free. A config file, a bit of setup, and editors get a form-based interface over your Markdown files. No hosted version, no subscription. For sites that do not need complex content modeling, Decap removes the need for a paid CMS entirely.
The Editorial Experience Question
The practical test for any CMS is not its API documentation — it is whether your content editor will actually use it without complaining.
Sanity Studio looks like a developer built it, because you built it. The interface adapts to your content schema, but it requires configuration work upfront. Non-technical editors can use it, but the setup cost is on your development team.
Contentful’s interface is clean and professional. It looks like enterprise software because it is. Editors with experience in marketing platforms pick it up quickly. But the cost for a real subscription makes it hard to justify outside of mid-market and enterprise budgets.
Storyblok’s visual editor is the strongest selling point for non-technical marketers. Seeing changes on the page as you type reduces back-and-forth. If a client has been using Squarespace or Wix, Storyblok is the most approachable transition.
None of them compare to WordPress Gutenberg in terms of zero-setup familiarity. WordPress has 15 years of documentation, a tutorial for every possible task, and a Gutenberg editor that most marketers have already used. There is no configuration step. There is no custom content schema to build. The editing interface ships with the platform. For most marketing teams, the question is not “which headless CMS has the best UX” — it is “why is this harder than WordPress?”
That is not a dismissal of headless architecture. It is an honest acknowledgment of where the friction lives.
Static vs Dynamic — The Practical Decision
Choosing between static and SSR Astro is a decision with real downstream consequences for hosting, performance, and cost.
Static sites — built at deploy time, served as flat HTML files — are simpler to host. Vercel, Netlify, and Cloudflare Pages serve static files globally for free or near-free. There are no servers to maintain, no runtime errors from API failures at page load. Performance is essentially guaranteed because there is nothing to compute at request time.
SSR adds a server layer. Pages are rendered on demand. Hosting costs more, infrastructure is more complex, and you are responsible for what happens when the CMS API is slow or unavailable at request time. You get real-time content in exchange.
For 90% of business websites — blogs, service pages, case studies, landing pages — static is the correct architecture. The editorial team publishes content, waits 1–3 minutes, and the change is live. That is not a meaningful bottleneck for any content cadence that makes sense for a small marketing team.
SSR becomes necessary when you need user accounts, personalized content, or data that changes faster than a build cycle can accommodate. E-commerce with live inventory, real-time pricing, A/B test variants tied to user cookies — these are the genuine use cases for SSR. A blog with weekly posts is not.
The choice of CMS and the choice of static vs dynamic are connected. If you pick a Git-based CMS like Decap, you are inherently on a static architecture. If you need real-time content, you are looking at SSR and an API-based CMS. Map the editorial workflow first, then choose the architecture.
What This Costs — The Full Picture
The headless CMS pitch often leads with hosting cost. “Vercel is free for static sites.” That is true. But hosting is the smallest line item in a headless Astro project.
Development time is the largest cost. A headless CMS integration — choosing a platform, modeling the content schema, building the Astro data layer, connecting webhooks, and training the editorial team — adds 20–40 hours of development work compared to building with WordPress. At agency rates, that is $2,000–$6,000 in upfront cost that does not appear in any CMS pricing table.
Monthly SaaS fees vary by platform. A team of 5 on Sanity is $75/month. Storyblok Starter is $99/month. Contentful Professional is $300+/month. Git-based options like Tina (free OSS) and Decap (free) bring this to zero, but they trade CMS features to get there.
Hosting for a static site is near-zero on the major platforms. This is the genuine advantage headless architecture delivers on the infrastructure side.
Compare that to a custom WordPress build: managed WordPress hosting with staging, SSL, CDN, and daily backups runs $30–$80/month all-in. The CMS is included. The editorial interface is included. There is no webhook to configure, no content model to build, and no separate SaaS subscription. For a straightforward business site with regular content updates, the total cost of ownership is lower — not higher — than a headless Astro setup with a commercial CMS.
This is not the answer the tech stack conversation usually arrives at. But it is the accurate one for most SMBs.
Where headless Astro with a commercial CMS makes economic sense: multi-channel publishing where the same content feeds a website, mobile app, and other surfaces. High-traffic sites where serving static HTML from a CDN provides meaningful performance and infrastructure savings over a WordPress setup under load. Organizations with dedicated frontend and content teams that can maintain two separate systems. If WooCommerce commerce is not part of the project, the WordPress argument weakens slightly — but for pure content sites, it holds for most clients.
The Right Architecture Starts With the Right Question
Headless CMS with Astro is a real, production-ready pattern. The ecosystem is mature. Official integrations exist for every major platform. Build pipelines are fast and well-documented. For the right project, it is the correct choice.
But “the right project” is a narrower category than the framework advocacy suggests.
The question that determines the architecture is not “which CMS is most developer-approved” — it is “who edits content, how often, and how much are you willing to pay every month for the tooling to support that?” A solo founder updating a blog quarterly does not need Contentful. A marketing team publishing daily across multiple channels might. A business site with service pages and a 10-post blog is probably better served by a well-built WordPress installation than by a headless setup that requires ongoing CMS subscription costs and more complex deployment infrastructure.
Astro is a legitimate choice for teams that need it. So is WordPress. The honest answer depends on your editorial workflow, your team, and your budget — not on which framework is trending this quarter.