Every year someone asks me whether they should go headless: WordPress for the content, React or Next.js for the front end. My honest answer is usually “not yet”. Here’s how I think about it.
What you give up
When you go headless you’re no longer running one system. You’re running two, and maintaining the connection between them. A lot of what WordPress gives you for free stops working or needs rebuilding:
- Previews, and the editor matching what visitors see.
- Most plugins that output anything on the front end: forms, SEO meta, embeds.
- Block styles. Your front end has to render every block your editors can insert.
- Simple hosting. Now there’s a Node server or build pipeline as well.
When I would do it
- The same content goes to several places: a website, a mobile app, a kiosk, a partner’s site.
- The front end is really an application, and the content is only one part of it.
- The team already knows React well and has someone to own the front end long term.
When I wouldn’t
- “It will be faster.” A light block theme with good caching is already fast. This site is a normal WordPress theme and the page weighs less than most JavaScript bundles.
- “It’s more modern.” View transitions, prerendering and scroll animations are all in the browser now, without a framework.
- The site is mainly content, edited by people who aren’t developers.
If you do go headless
Start with the REST API before adding GraphQL. Register only the fields you need with register_rest_field, and cache responses on the front end. Keep a normal theme running too. Previews and 404s will thank you.
register_rest_field( 'post', 'reading_time', [
'get_callback' => fn( $post ) => max( 1, round( str_word_count( wp_strip_all_tags( $post['content']['raw'] ?? '' ) ) / 220 ) ),
'schema' => [ 'type' => 'integer', 'context' => [ 'view' ] ],
] );Headless is a good tool for a specific problem. Make sure you have that problem first.
