The previous seven parts covered what the REST API makes possible. Once the tooling is in hand, one question follows naturally: should the front end be split off entirely? This part is an honest answer to it.
What headless actually gives you
Without overstating it, three things. First, several consumers share one body of data — a site, an app and an in-store kiosk reading the same content. Second, a front-end team gets its own stack and its own release cadence. Third, you choose the rendering layer independently of WordPress.
Notice what is missing. “Speed” is not on that list. Headless builds are often faster, but that is because somebody built a good new front end, not because of the separation itself. Spend the same effort on cache layers and asset discipline and you usually reach the same place for far less.
The most underestimated cost: preview
WordPress preview is the theme rendering that post. With no theme there is nothing to render. Restoring preview in a headless setup means building a dedicated route in the front end, fetching the draft through an authenticated request, and keeping that route out of public indexing. It is a small project of its own.
Postpone it and editors start working by publishing and then checking the live page, which is precisely how publishing accidents happen.
Editing experience and plugins
The value of the block editor is that the editing screen resembles the result. Split the front end off and that resemblance goes; the editor becomes, in practice, a form. The markup blocks produce also has to be re-interpreted or rebuilt on the other side.
The more concrete issue is plugins. Anything that worked by printing on the front end simply stops — SEO meta tags and structured data, forms, redirects, related posts, consent banners. Each has to be rebuilt in the front end, or you have to confirm the plugin exposes its data over REST. SEO in particular becomes wholly the front end’s responsibility.
Operational cost is a real cost
After separating, you have two deployables, two sets of logs, two caches and two CI pipelines. During an incident you must first decide which side is at fault, and version compatibility between the two becomes something you manage. This is not a cost you can optimise away; it is a standing cost the architecture creates.
There is a middle path. Keep the theme and use REST only for the pieces that need to be interactive: search, filters, application forms, a dashboard widget. That covers a great deal, and it keeps preview, SEO and the plugin ecosystem intact. Everything in this series applies directly to it.
Next part
This is the last article across the six developer series. Extending WordPress through hooks is covered in using hooks and filters properly, and the measurement work deferred here is in profiling WordPress performance. The order in which we make these calls on a real site is written out on our process page, and handing upgrades, optimisation and a security review over as one job is our optimization program.