I keep seeing people use WordPress as a headless CMS with React or Next.js on the front end. So you take a perfectly functional content management system with built-in templating and then throw away half of it to rebuild the front end in JavaScript?
Someone please explain what problem this solves that a well-built WordPress theme doesnt.
Performance, developer experience, and multi-channel delivery. A Next.js front end with ISR serves pages in under 100ms from the edge. A WordPress theme making database queries on every request cannot compete.
Plus if you need to serve the same content to a mobile app, a kiosk, and a website, you build the API once and consume it everywhere. A theme only serves the website.
the performance argument is real but overstated. A WordPress site with proper caching (Redis object cache + page cache + CDN) serves pages in 200-300ms. Not as fast as static but fast enough that most users cannot tell the difference.
Headless makes sense for complex interactive UIs. For a content site? Usually overkill.
@noderunner multi-channel I will grant you. But 90% of the headless WordPress sites I see are just regular websites. No app, no kiosk, no API consumers. They are using headless because it is trendy, not because they need it.
The developer experience point is underrated. Modern front-end tooling with component libraries, TypeScript, and hot module reloading is objectively better than editing PHP template files. Teams ship faster and the code is more maintainable.
Is it necessary? No. Is it better for teams that already know React? Absolutely.
Both sides have valid points. Headless WordPress makes sense when you have a JavaScript team, need multi-channel, or have complex interactive requirements. Traditional WordPress makes sense when you have a PHP team, a simple content site, and editors who need the preview button to work.
Pick based on your team and requirements, not the hype cycle.
The taxonomy design should reflect how users think about the content, not how the organization is structured internally. Card sorting with real users reveals the gaps.
My developer disappeared and now I need to figure this out myself. These explanations are a lifesaver.
This is helpful but overwhelming. Just tell me the simplest path that works for a small organization.
i inherited this exact setup on a client site last year. The previous developer left no documentation. Took two weeks just to understand what all the plugins were doing.
This is really helpful for my class project. The real-world perspective fills in gaps that the textbook leaves out.
The block editor has gotten better about this in recent releases. Check the theme.json settings for layout and spacing before overriding with CSS.
Edge functions handle this use case perfectly. Sub-10ms response times for personalized content without hitting the origin.
I would model this as a reference type rather than embedding the data inline. Makes it reusable across content types.