Prefer WordPress. Also like not letting a plugin ecosystem decide my Core Web Vitals fate every Tuesday.
That tension is why you split things. WordPress (or a lean CMS) owns content. Next.js owns the front door. Editors keep the workflows they know. Engineers keep performance, routing, and experiments under control.
Not every site needs this. Brochure sites with three pages and a contact form can stay classic WP and be happy. When marketing wants landing velocity, design systems, and app-like pages next to a blog, headless starts earning its keep.
What “split” actually means day to day
Editors write in WordPress. They use the block editor, drafts, previews, scheduled posts, the stuff they already understand.
The public site is a Next.js app that pulls content through the REST API or GraphQL, renders pages the way we want, and deploys on infrastructure we control.
WordPress becomes a content API with a nice admin UI. It stops being the entire runtime for every visitor request if we don’t want that.
Why bother
Performance and control. I can cache aggressively, ship a design system, and avoid “one more plugin” tax on every page view.
Composable marketing. Landing pages can be React. Blog can be WP-sourced. Tools and calculators can live in the app without fighting PHP templates for shared layout.
Safer experiments. Feature flags, A/B tests, and personalization hooks are less painful when the front end is a real app, not a theme held together with hope.
Clearer boundaries. Content folks stay in WP. Engineers stay in git. Fewer emergency “who changed the theme functions file” moments.
What people get wrong
Headless is not free. You pay in complexity.
Preview becomes a project. You need a sane preview URL story or editors will revolt. Forms, redirects, SEO metadata, sitemaps, and RSS all need deliberate wiring. The “it just worked in WP” list is longer than slide decks admit.
If your team cannot own that glue, stay coupled. A well-tuned classic WordPress site beats a half-finished headless science fair.
default architecture instincts
- WP for posts, pages, custom post types the editors need
- Next.js App Router for the site shell, landing templates, and anything interactive
- On-demand revalidation when content publishes, not “rebuild the world hourly” unless you like waiting
- Explicit mapping for slugs, canonical URLs, and redirects so SEO does not become a surprise fire drill
- Shared design tokens so the blog does not look like a cousin from another brand
Also keep a kill switch mindset. If WP is down, what does the site do? Cache helps. Blindly proxying every request to PHP at runtime recreates the coupling you just paid to remove.
AI fits on both sides, carefully
On the content side, AI helps drafts, metadata, FAQ clusters, and internal linking suggestions inside the editorial workflow.
On the engineering side, agents help scaffold page templates, wire typed fetchers, and keep the mapping layer from turning into spaghetti.
Neither side should invent URLs or publish without a human gate. Headless multiplies blast radius if you let an agent push straight to production because the draft “looked fine.”
When you still say no
- Tiny site, tiny team, no eng capacity
- Editors need pixel-perfect preview tomorrow and you cannot fund it
- The main pain is content quality, not front-end architecture
Architecture does not fix weak offers. It can make a strong content engine feel fast and coherent.
Bottom line
Split content from the front door when the CMS strengths and the experience strengths stop living in the same house peacefully.
WordPress remains excellent at editorial ops. Next.js remains excellent at shipping the site I actually want users to feel. Together they work if you respect the glue.
If you treat headless as a fashion choice, you will hate it. If you treat it as an operator decision about who owns what, it can be one of the cleaner separations in a messy stack.
