When headless WordPress is the right answer (and when it is not)

We build both traditional WordPress sites and headless ones. This is not a sales position for either. It is the checklist we actually use.

Headless earns its keep when…

• You need a genuinely different front end — an app, a kiosk, or a heavily interactive experience.
• You serve several channels from one product source and want the catalogue logic in one place.
• Your hosting needs edge rendering and caching that a classic theme cannot give you.
• Different teams own the front end and the content, and you want that boundary.

Skip headless when…

• The site is a brochure. WordPress plus a good theme is faster and cheaper to own.
• Nobody on the team will maintain a JavaScript application. Front-end rot is expensive.
• Content editors need to preview changes before publishing. That preview loop is harder headless.
• The performance problem can be solved with caching, a query audit and image discipline.

What we do keep in WordPress

Products, orders, tax, shipping, coupons, users, permissions. WooCommerce is very good at commerce, and headless front ends should consume it through the REST API rather than reimplement it.

The honest cost

You are adding a second system to maintain: a build step, a deployment pipeline, and a preview environment. Budget for that, and the trade is usually excellent. Budget for nothing, and it will bite.