Astro and Statamic as a Headless CMS

What Statamic 6.31 Changes for Headless Websites

Businesses choosing a content management system usually need two things from the same website: an easy place to manage content and a fast, reliable experience for the people visiting the site.

Statamic and Astro can divide those responsibilities.

Statamic gives the business a content management system for pages, articles, navigation, images, SEO information, reusable content, and other website data. Astro handles the public-facing website that customers actually visit.

The two systems communicate through an API.

This approach has been possible for some time, but Statamic 6.31, released in September 2026, makes that connection substantially easier to build, reuse, and maintain. Statamic specifically expanded its REST API to support headless websites and integrations more effectively.

For website owners, these changes make Astro + Statamic worth considering alongside other modern CMS options.

How an Astro and Statamic website works

A traditional Statamic website can use Statamic to manage content and generate the pages visitors see.

A headless implementation separates those jobs.

The architecture can work like this:

Statamic

• Stores and organizes website content
• Gives administrators a control panel
• Manages pages, articles, projects, navigation, taxonomies, images, and other content
• Controls user permissions and publishing workflows

Astro

• Builds the public website
• Controls the design and frontend components
• Generates the HTML visitors receive
• Handles interactive features when the website needs them
• Can deploy through a platform such as Vercel

The Statamic API

• Connects the two systems
• Sends content from Statamic to Astro

A visitor browsing the finished website generally has no reason to communicate directly with the Statamic control panel.

For many marketing websites, Astro can generate the public pages ahead of time and distribute those pages through a CDN. Astro uses static generation by default and also allows individual routes to render on demand when a website needs server-side functionality.

That gives a business considerable control over how its public website operates.

Statamic already supported headless websites

Statamic had a REST API and GraphQL support before version 6.31.

Developers could already create an Astro frontend that requested content from Statamic.

The problem involved the amount of project-specific knowledge that the frontend needed.

A developer might need to tell the Astro application:

• The page collection uses the handle pages
• Blog posts live in articles
• Projects live in projects
• The primary navigation uses main
• Images use a particular asset container
• The website has specific language or regional configurations

Every website could organize those resources differently.

Developers could account for those differences, but each project required more configuration. Reusing the same integration across several Statamic websites also required more assumptions about how each CMS had been configured.

Statamic 6.31 addresses that problem directly.

Statamic can now tell Astro how the CMS has been organized

One of the largest additions in Statamic 6.31 involves API discovery.

A connected application can now ask Statamic which resources exist.

The REST API can expose information about:

• Collections
• Taxonomies
• Navigation
• Asset containers
• Website locales
• Individual collection configurations

Statamic also added an API health check that lets an integration confirm that the API responds correctly.

This sounds highly technical, but the practical result matters for businesses maintaining websites for several years.

Developers can create a more reusable connection between Statamic and Astro. The frontend can obtain more information directly from the CMS rather than relying on a growing list of manually configured assumptions.

That can reduce the amount of project-specific integration code developers must maintain.

It can also make future changes easier to manage when a business adds another content collection, language, navigation structure, or content source.

Astro can request pages by their URL slug

Statamic 6.31 also improved the way external frontends request individual entries.

The REST API can now retrieve an entry using its slug.

A URL such as:

/services/commercial-construction

contains a slug that Astro can use to locate the corresponding Statamic content.

Previously, integrations often needed additional logic to find the internal content ID associated with a URL.

Statamic now lets a frontend request an entry using the same URL information the website already has.

For a website owner, this simplifies the connection between the CMS and the pages visitors browse.

It also gives developers a cleaner foundation for websites with hundreds or thousands of pages.

Astro can request less data when it only needs a small amount

A project listing page may only need four pieces of information:

• Project name
• Project URL
• Featured image
• Location

The website does not need the entire project record to display a simple card.

Statamic 6.31 expanded support for selecting specific fields through its REST API. Developers can request a smaller set of information when a page only needs part of an entry.

A project archive, for example, can request the information needed to display its cards. The individual project page can request the complete record when someone opens it.

This gives developers more control over the amount of information exchanged between the CMS and the frontend.

Multilingual websites get a cleaner connection

Statamic also improved API support for Multi-Site websites.

The API now accepts a dedicated site parameter when requesting entries and other content. A frontend can explicitly request the English, French, Spanish, or other configured version of an entry.

That creates a cleaner connection for organizations that operate regional or multilingual websites.

An Astro website can determine which language the visitor requested and retrieve the corresponding Statamic content.

For organizations that expect their website to expand into multiple markets, this capability gives the architecture room to grow without requiring developers to redesign how the frontend communicates with the CMS.

Live Preview makes the combination much more practical for content editors

Marketing departments need to see how changes will appear before publishing them.

Statamic supports Live Preview for external frontends. A developer can configure Statamic so its preview window loads an Astro page. Statamic automatically provides a temporary preview token that allows the frontend to retrieve the work-in-progress version of the content.

The process can work like this:

1. An editor opens a page in Statamic.
2. Statamic opens the Astro website inside its Live Preview window.
3. The editor changes a headline, image, button, or page section.
4. Statamic provides the current preview information to Astro.
5. Astro requests the unpublished content.
6. Astro renders the page using the actual website components.
7. The editor sees the updated page before publishing it.

Statamic also supports sending an update event to an external frontend instead of refreshing the entire preview window after every change. A developer can use that event to refresh the Astro preview when the editor updates content.

This gives businesses an important combination: structured content management inside Statamic and an accurate preview rendered by the actual Astro website.

The public website can remain static while preview pages render on demand

Astro provides another useful architectural option for this setup.

A business can keep normal website pages statically generated:

/about/

/services/

/projects/

/contact/

The internal preview URLs can render on demand:

/preview/about/

/preview/services/

/preview/projects/

Astro allows developers to opt individual routes out of static generation while keeping the rest of the website pre-rendered.

That means Live Preview does not require every visitor request to run through a server-rendered application.

The public website can continue serving pre-generated pages while editors use dynamic rendering for unpublished content.

Website visitors can receive very little unnecessary frontend code

Astro works particularly well for content-heavy business websites because it generates HTML ahead of time and sends JavaScript only where the website needs browser interactivity.

A company website may contain:

• Service pages
• Case studies
• Leadership profiles
• Articles
• Locations
• Resources
• Testimonials
• Contact information

Most of that content does not require a large JavaScript application running in the visitor's browser.

Astro can send straightforward HTML for those pages and add client-side JavaScript to specific interactive components when necessary.

That can support strong website performance when developers also manage images, fonts, analytics, third-party scripts, and other performance factors carefully.

Separating the CMS can reduce the amount of backend infrastructure exposed through the public website

A headless Statamic implementation can also separate the CMS environment from the public website.

A company might operate:

www.company.com

for the Astro website and:

cms.company.com

for Statamic.

The public domain serves the Astro frontend. Authorized administrators access Statamic separately.

This architecture can reduce the number of requests that reach the CMS server during normal public browsing. A static Astro page can come directly from the frontend hosting platform without running PHP or querying Statamic for every visitor.

The Statamic installation still requires security updates, responsible hosting, backups, authentication controls, and routine maintenance. Separating the systems does not eliminate those responsibilities.

It does give developers additional control over how much of the CMS infrastructure participates in everyday website traffic.

This architecture gives businesses more control over the CMS backend

Statamic runs on Laravel and allows organizations to host the CMS in an environment that fits their requirements.

That opens possibilities for websites that need more than content management.

A Statamic installation can support custom business logic, integrations, private data connections, specialized forms, internal workflows, or other Laravel functionality while Astro handles the public presentation layer.

This can work especially well for organizations that expect their website to connect with internal systems later.

The CMS and frontend have separate responsibilities, so developers can extend the backend without tying every feature directly to the public page-rendering system.

It can also create a cleaner path for future frontend changes

The content lives in Statamic while Astro controls presentation.

A well-planned content model may describe a project with fields such as:

• Project name
• Location
• Industry
• Description
• Featured image
• Services
• Completion date
• Related projects

Those fields describe the project itself.

The Astro frontend decides whether that project appears as a card, full case study, search result, featured homepage item, or another presentation.

This separation can help businesses reuse the same content in new layouts or applications later.

Good content architecture remains important. A poorly planned CMS can still tie content too closely to one particular design.

Astro + Statamic gives WordPress website owners another migration option

Many businesses evaluating a WordPress redesign assume the replacement CMS must also generate the entire public website.

A Statamic and Astro architecture gives those businesses another option.

WordPress commonly stores content, runs plugins, processes PHP, connects to a database, and generates the public website within the same application. Caching systems can reduce the work WordPress performs for repeat visitors, and a carefully maintained WordPress website can achieve strong performance.

Astro approaches public delivery differently.

For pages generated during deployment, Astro creates the HTML before the visitor asks for it. The hosting platform can then distribute that finished output through its CDN.

Statamic continues handling content management in its own environment.

For a business that has experienced years of increasingly complicated WordPress maintenance, this architecture can provide a clearer division of responsibilities.

The public website does not need a collection of WordPress plugins to control layouts, page components, caching, frontend optimization, and other presentation requirements. Developers create those features directly within the Astro application.

Statamic gives content administrators the fields and editing controls they need to manage the website.

Structured content can protect the website design

One of Statamic's strongest uses involves giving content editors appropriate control over content while developers maintain control over the design system.

Consider a homepage hero section.

An editor may need control over:

• Headline
• Supporting text
• Image
• Button text
• Button destination
• Approved layout option

The editor does not necessarily need independent controls for margins, font sizes, arbitrary colors, absolute positioning, or dozens of visual settings.

Developers can create defined Astro components and corresponding Statamic fields.

The marketing department manages the information inside those components. The website continues following its established typography, spacing, accessibility, responsive behavior, and brand standards.

This approach also helps businesses maintain consistency as more people contribute content over several years.

Publishing a static Astro website requires a deployment strategy

Businesses should understand one operational consideration before choosing this architecture.

If Astro generates a page during deployment, changing the Statamic content does not automatically change the already-generated HTML sitting on the frontend host.

The publishing workflow needs to trigger another Astro deployment.

A typical process can work like this:

1. An editor publishes a change in Statamic.
2. Statamic triggers a deployment webhook.
3. The frontend hosting platform starts an Astro build.
4. Astro retrieves the latest approved content.
5. Astro generates the affected website output.
6. The hosting platform deploys the new version.

For most business websites, this process can happen automatically.

Websites that require certain information to change immediately can also render selected Astro routes on demand instead of generating those routes ahead of time.

Developers should decide which model fits the site's actual publishing requirements.

Astro + Statamic does create two application environments

Website owners should also account for the infrastructure involved.

A headless implementation commonly includes:

Statamic hosting

This runs the CMS, control panel, API, assets, and any Laravel functionality.

Astro hosting

This serves the public website and handles any on-demand Astro routes.

The company therefore operates a CMS environment and a frontend environment.

That requires appropriate deployment procedures, backups, monitoring, environment configuration, and documentation.

A small brochure website with a handful of pages may gain little from that additional architecture. Statamic can render websites directly, and that remains a strong option for many projects.

Astro becomes more compelling when the business values frontend performance, component-based development, independent frontend deployment, highly customized presentation, or a frontend that may eventually use more than one data source.

Statamic 6.31 makes this architecture easier to standardize

The largest improvement from Statamic 6.31 may become apparent over the life of several projects.

Developers can now build a more reusable Statamic integration for Astro.

Instead of teaching every Astro website the exact names of every Statamic resource, an integration can ask the CMS for more of that information.

Statamic can identify the collections, navigation structures, taxonomies, asset containers, and sites that the API exposes. The frontend can then work with that information using a more consistent integration.

For an agency maintaining several websites, this can reduce one-off development and make future maintenance more predictable.

For a website owner, consistency behind the scenes can translate into easier upgrades, fewer custom dependencies, and a clearer development process.

Statamic remains responsible for content management

The technology only works well when the CMS gives people a practical editing experience.

Statamic offers developers considerable control over how they configure the control panel.

We can create content structures around the information a business actually manages.

A construction company might have dedicated project fields.

A healthcare organization might manage locations, providers, services, and patient resources.

A nonprofit might manage programs, events, impact stories, and reports.

A professional services company might manage employees, service areas, insights, and case studies.

The CMS can present those fields with labels and controls that correspond to the organization's content.

Astro then determines how the website presents that information.

That creates a useful division between content management and frontend design.

Statamic 6.31 makes Astro + Statamic a stronger option for business websites

Statamic's September 2026 API improvements make Astro + Statamic considerably easier to consider as a repeatable headless website architecture.

The release adds better resource discovery, slug-based entry requests, more precise field selection, cleaner Multi-Site requests, and other API improvements. Statamic's existing external Live Preview capabilities also give content editors a practical way to preview their work through an Astro frontend.

A business can gain:

• A dedicated content management environment
• A fast Astro frontend
• Structured content controls
• Live previews of unpublished changes
• Static delivery for appropriate pages
• On-demand rendering where the website needs it
• Greater control over frontend development
• Laravel capabilities behind the CMS
• A cleaner separation between website content and website presentation

This architecture still requires thoughtful implementation. Publishing workflows, preview routes, deployments, security, hosting, backups, and content modeling all need proper planning.

For businesses planning a major website rebuild, especially organizations evaluating a move away from a complicated WordPress installation, Astro + Statamic now deserves serious consideration.

At Afteractive, we evaluate the CMS and frontend architecture around how a business will actually use its website. Statamic with Astro gives us another strong option when an organization needs structured content management, a highly customized frontend, and more control over how its website operates and grows.