For most content-led client sites, classic WordPress — block editor plus a server-rendered theme — wins on editability, operational simplicity, and controlled cost; choose headless WordPress when you need an independent frontend, app-like interaction depth, or separate deploy pipelines, and you accept running two systems in production. That is our default recommendation for agency work, and it is the same lens we use when scoping white-label web development builds. The long version lives in our guide to scaling creative frontend work for agencies.
What each option actually is
Classic WordPress means the familiar stack: content and admin in WordPress, theme templates rendering pages, plugins extending behavior. Editors work in the same interface that publishes the site. Performance work, caching, and QA happen in one system your team already knows. Headless WordPress means WordPress is the content backend only; a separate frontend application consumes content through WordPress’s REST API or another content gateway, then renders the experience. You gain frontend freedom and an independent deploy pipeline — and you take on a second codebase, second hosting story, and second release process.
Neither architecture is morally superior. They optimize for different constraints: editorial autonomy and operational simplicity on one side, frontend control and shipping independence on the other. The mistake is choosing by trend instead of by client, content model, and team capacity.
Side-by-side comparison
| Dimension | Classic WordPress | Headless WordPress |
|---|---|---|
| Editability | Strong: editors preview and publish in the familiar admin; what they see maps closely to front-end modules | Weaker by default: editing still lives in WordPress, but preview and “will this break the layout?” questions often need custom work |
| Performance ceiling | Very good with disciplined themes, caching, and lean assets; one rendering path to optimize | Can be excellent: static rendering, CDN-first frontends, and modern frameworks help — at the cost of more moving parts to keep fast |
| Cost to build & run | Usually lower: one stack, one deploy, one QA surface | Higher: two codebases, environment parity, and dual maintenance enter the estimate and the retainer |
| Motion capability | Full capability with GSAP and careful asset budgets inside the page; constrained by how the theme is structured | Strong for app-like routing and orchestrated transitions when the frontend is purpose-built for them |
| Operational complexity | Lower: one admin, one update path, one incident surface | Higher: frontend and CMS release trains can drift; integrations and preview flows need explicit ownership |
When classic is the right call
Pick classic when editors need to own day-to-day publishing without a developer in the loop, when the site is a marketing or content property rather than a product UI, when budgets are finite and retainer simplicity matters, and when your delivery model depends on proven WordPress patterns. Most agency retainers are healthier with one system to patch, back up, and explain. Motion still has a place: production-grade interaction work fits classic builds when it is scoped, budgeted, and tested — the same standards we apply inside our Figma to WordPress delivery.
Classic also aligns with shorter timelines. Fewer systems mean fewer handoffs, which matters when the plan is already tight; see realistic Figma to WordPress timelines and cost drivers for how scope moves the calendar. If your design leans on rich interaction from day one, pressure-test direction early with a motion sprint before committing template structure.
When headless earns its complexity
Choose headless when the frontend must behave like an application: client-side routing with orchestrated page transitions, highly custom data fetching, or a design system that should not be constrained by PHP templates. Choose it when engineering wants an independent deploy pipeline separate from editorial publishing, when you are serving multiple frontends from one content source, or when performance strategy requires static generation at the edge. Each of those benefits is real — and each comes with preview workflows, environment management, and a second team’s worth of ownership.
Headless is the wrong default when the client’s team barely uses the admin beyond posts and pages, when plugin ecosystem coverage matters, or when no one on the account owns the frontend stack long-term. Complexity you cannot staff becomes complexity you cannot maintain.
Our expert opinion
Default to classic unless a concrete requirement forces headless. Write that requirement down — “we need X and classic cannot do X” — and if the sentence needs adjectives instead of mechanisms, keep classic. Then invest the saved operational budget into what clients actually feel: editorial safety, fast pages, polished motion, and rigorous QA. Architecture fashion fades; a site the client’s team can run without calling you does not. When the frontend load grows past internal capacity, agencies plug us in behind their brand via white-label development rather than rewriting the stack to chase flexibility nobody asked for.
Further reading: when prototyping beats immediate implementation in prototype first vs build first, and how we verify the result in our cross-browser QA process. Selected builds are in the Switch Sound & Music and Mujer Raíz portfolio pages.
Key takeaways
- Default to classic WordPress for content-led client sites; move to headless only for a written, specific requirement that classic cannot meet.
- Headless trades editorial and operational simplicity for frontend control — budget two systems to build, QA, and maintain before you commit.
Frequently asked questions
Is headless WordPress faster than classic?
It can be, and classic can also be very fast. Speed comes from asset discipline, rendering strategy, hosting, and QA budgets — not from the word “headless.” Measure against Core Web Vitals targets on the stack you will actually ship.
Does headless break the WordPress editor experience?
Editing still happens in WordPress, but preview fidelity and guardrails depend on custom integration work. If non-technical editors must publish complex layouts confidently, factor that integration into scope from day one.
Can we run GSAP motion on classic WordPress?
Yes. Production motion work — timelines, scroll-triggered sequences, reduced-motion fallbacks — fits classic builds when performance and accessibility budgets are part of the plan, not an afterthought bolted on during QA week.
Which option costs less over three years?
Classic usually does, because ongoing cost is dominated by maintenance surface: updates, incidents, and release coordination across systems. Headless can still win on total value when multi-surface delivery or app-like UX is core to the product — value, not sticker price, decides.
How do we decide with a client in the room?
Ask who edits, what must the frontend do that classic cannot, and who owns each system after launch. If those answers are thin, default to classic. Pair the conversation with our agency frontend scaling guide so the choice reflects delivery capacity, not hype.