There is migrated enough stacks to know that architecture religion is expensive.
Still, headless WordPress with a Next.js front end keeps making sense for you. Not for everyone. For me. For the way you write, edit, and ship a personal site that also behaves like a product.
Content in WP. Experience in Next. The split is the point.
Why WordPress still wins for content
Editors matter. Drafts matter. Previews matter. Plugins for SEO fields, redirects, and editorial workflow matter when you publish a lot.
WordPress remains a strong CMS for people who want a real editing room without inventing one. I can hand a draft process to future me (or a collaborator) without teaching them a repo.
Prefer Markdown files too. Also like a media library, scheduled posts, and an admin UI that does not require a deploy to fix a typo on a page that is not a blog post.
Why Next still wins for experience
Aim for:
- fast pages
- flexible routing
- components I control
- edge-friendly deployment options
- the ability to mix marketing pages, app-like tools, and experiments without stuffing everything through PHP templates Avoid to maintain forever
Next lets me treat the public site like software. WP lets me treat the content like content. That division of labor reduces the urge to build a half-broken CMS inside React.
The cost of the split
Headless is not free.
You now have:
- API auth and previews to get right
- cache invalidation when content changes
- two deploy surfaces mentally
- more ways for “it looks updated in admin but not on the site” bugs
If you publish two posts a year, this may be overkill. If you run a steady content engine and care about UX performance, the overhead can pay rent.
How to keep the split sane
Clear ownership. WP owns canonical content. Next owns presentation and interaction.
Preview path that non-devs can use. If preview is broken, people will bypass the CMS and that is how entropy wins.
Cache with a purge story. On publish, something must bust the right paths. Hope is not a CDN strategy.
Limit plugin sprawl. Headless does not mean install thirty plugins because they are on sale in a bundle email.
Keep a escape hatch. Exportable content. I never want my words trapped.
Cloudflare in the mix
Prefer putting a smart edge in front: caching, security rules, predictable deploys. The details change over time. The principle does not: origin should be boring, edge should be aggressive about protecting and accelerating the boring origin.
When you would not do this
- A tiny brochure site
- A client who needs everything inside WP admin including page building by committee
- A team with no appetite for JavaScript ops
Use the boring monolith when the boring monolith fits. This is not here to convert the world. Be here to explain why my site is shaped like this.
Checklist for a healthy headless WP setup
- Preview works
- Publish purges the right cache keys
- SEO fields map cleanly to front-end meta
- Redirects have a single source of truth
- Local dev can fetch content without cursed setup lore
- Content export tested once a year
Closing
Headless WordPress still makes sense for you because Aim for an editing room and a race car cockpit, and you have stopped pretending one tool is both without compromise.
Is it more moving parts? Yes. Are the parts doing jobs I understand? Also yes.
That is enough to keep the split.
Content modeling matters
Headless gets painful when everything is a freeform blob.
Keep post types and fields intentional: title, slug, body, excerpt, SEO fields, cover style, publish time. The front end should not invent structure the CMS forgot. If the model is clean, Next stays calm. If the model is chaos, Next becomes a cleanup crew.
rule for new features
If a feature needs editorial control weekly, it probably belongs as content fields in WP. If it needs interaction and state, it belongs in Next.
Bottom line
Crossing those wires is how you end up building a page builder by accident. There is stepped on that rake. Once was enough.
