WordPress

When you should not go headless (yet)

July 28, 20263 min read
Cover image for “When you should not go headless (yet)”

Key takeaways

  1. Headless is a product decision, not a badge—fix foundations before uncoupling.
  2. Page-builder debt and plugin sprawl often need WordPress engineering first.
  3. If nobody will own GraphQL and Node after launch, stay classic for now.
Sometimes the theme is not the problem.

Headless is the right move when the frontend product outgrows the theme—component libraries, multi-channel content, or Core Web Vitals targets a PHP theme cannot hit cleanly.

It is the wrong move when:

  • Your pain is messy plugins and page builders, not the rendering model. Fix the WordPress foundation first.
  • Editors need rich in-context preview that you are not ready to rebuild on Next.js.
  • The site is primarily brochure content with infrequent redesigns and a small team.
  • You do not have anyone who can own a GraphQL schema and a Node deploy after the agency leaves.

Often the highest-ROI engagement is WordPress development that leaves you headless-ready later: clean themes, intentional content models, and no page-builder lock-in.

Industry context

Context for staying (or leaving) classic

Industry context on WordPress adoption and ownership—not CodeFern client guarantees.

Work with CodeFern

Ready to grow the stack?

Tell me what you are shipping—WordPress, a headless cutover, React Native, or a mix—and we will map a clear next step.