WordPress Needs an Official Second Door for the Frontend

WordPress already lets people publish a site with a theme. It should also make it straightforward to keep WordPress for writing and publishing while building the frontend with other tools.

People often call this “headless WordPress.” I’m using “decoupled frontend” because WordPress can keep serving theme-based sites while also supporting a separate frontend. Astro is one way to build that second experience.

People are already working on this. WP Engine’s Headless WordPress Toolkit brings together plugins, packages, documentation, and examples. It includes preview tools and webhooks, and demonstrates frontends built with Astro and Next.js. Faust and HeadstartWP offer other ways to build headless sites. See the toolkit project index.

For many content-focused sites, a static export such as Simply Static may be the simpler choice: WordPress renders the site, and the plugin publishes a static copy. That’s different from building a separate application frontend in Astro. This proposal is about giving teams a choice when static publishing is not enough.

That work matters. It also makes the opportunity clearer: the next step shouldn’t be another framework that locks developers into one stack. WordPress Core should establish stable, shared contracts that any toolkit and frontend can use.

Themes and blocks should remain the default for most sites. This is a second door: an official, supported way to use WordPress as the content system and choose a separate frontend.

Give every site a contract

WordPress already describes REST routes with schemas, and clients can inspect those schemas through the API. Core could build on that foundation by publishing an OpenAPI description for the routes and data a site actually exposes—including opted-in post types and metadata, block types, and public Abilities. REST API discovery, custom post types, registered metadata.

An official command—something like npx @wordpress/client https://mysite.com—could generate TypeScript types from that description, using tools such as openapi-typescript. The command is a proposal; it doesn’t exist today.

That would give developers and agents a reliable starting point for a specific site. Where schemas are complete, type checks could catch mismatched fields and block attributes before they reach the editor. That’s better than guessing and finding out later that the API rejected the data.

Let frontends work with blocks

WordPress post responses already include rendered content, and edit-context responses can include raw content. Core also has block-related REST routes, including a renderer for individual dynamic blocks. What’s missing is a standard page-level response that gives a separate frontend the structured block tree and the information needed to render it. Post responses, block renderer.

Core could add an endpoint that takes a URL and returns the page’s head data—title, canonical URL, JSON-LD—along with each block’s attributes, inner blocks, and rendered output. It could also return an asset manifest: the styles and scripts required by the blocks on that page.

That last piece needs careful design. A plugin block can depend on assets and behavior that aren’t obvious from its markup. A manifest would give a frontend a defined way to request those assets. The frontend could render supported blocks as native components and use server-rendered output for blocks it doesn’t recognize.

Make the hard parts shared work

For a decoupled WordPress frontend, preview, cache invalidation, forms, and maintaining a separate frontend are recurring challenges. Headless WordPress guides cover these tradeoffs, including the work needed to replace frontend features that WordPress plugins normally render.

Core could give developers a shared starting point:

• Frontend URL: Let a site set its frontend URL. WordPress could use it when generating permalinks, sitemap links, and canonicals, and send the Preview button to the frontend with a signed, short-lived token.
• Webhooks: Define standard events for publishing, updating, deleting, menu changes, and style changes. Include affected URLs so a frontend can refresh the pages that changed.
• Forms: Let plugins describe form abilities with input and output schemas, then define a convention for rendering and submitting them in a frontend. WordPress 6.9’s Abilities API already supports schemas and permission checks; using it for interoperable forms would be a new convention, not an existing feature. Abilities API.
• Design tokens: Provide an export of the site’s resolved design settings—colors, typography, and spacing—so a frontend can use the same values as the editor. theme.json and Global Styles already provide structured settings and styles; the proposed export would make them easier to consume outside WordPress. Global Settings and Styles.

Projects like the Headless WordPress Toolkit already solve parts of this at the plugin and toolkit level. Core could make those integrations more portable by standardizing the contracts they depend on.

Give people something they can run

WordPress should ship a reference frontend: a working example of how the contract, blocks, preview, and assets fit together.

Astro would be a good candidate for a content-focused starter. Its default output is pre-rendered at build time, which suits many editorial sites. The starter could include components for core blocks, image handling, SEO, search, comments, previews, and deployment examples. Astro rendering modes.

The starter wouldn’t require anyone to use Astro. It would give developers a real project to learn from and adapt. A local workflow could run WordPress and the frontend together, with TypeScript checks and browser tests to help catch mistakes early.

Be honest about the tradeoffs

A separate frontend adds work. The editor won’t automatically show exactly what the separate site will look like. Plugins that rely on WordPress rendering their frontend output will need a supported integration or a frontend replacement. Teams also need to plan for separate build and monitoring workflows, even if their hosting provider brings some of that together.

Those are reasons to make the path easier to evaluate and build—not reasons to leave every team on its own. A supported starter, clear contracts, and common integrations would let developers see the costs up front and spend more time on the parts of their sites that are unique.

The work doesn’t need to start from zero. Core can build on the REST API, the Abilities API, and the experience gained from projects like the Headless WordPress Toolkit. The opportunity is to make the contracts stable and the path official, so any toolkit or frontend can build on them.

WordPress doesn’t need to become a frontend framework. It needs to be an excellent foundation for whichever frontend a team chooses.

The pieces are already here. Connect them, ship a reference implementation, and let people get on with making things.