Headless WordPress without the regret

Going headless is usually sold as a performance decision. In practice it is an editorial one. The front end gets faster almost by accident; what you actually spend your months on is keeping the authoring experience intact while everything underneath it moves.

Four decisions did most of the work on the last four builds. Everything else was detail.

1. Preview is a feature, not a nice-to-have

If an editor cannot see their draft on the real front end, they will not trust the system, and they will route around it. Build signed, expiring preview URLs that render production code paths on day one — not in phase two.

2. One cache tag per content object

Time-based revalidation is a guess. Tag every fetch with the object it came from, then let the CMS invalidate on save. Editors expect their change to be live before they finish reading the confirmation toast.

3. Keep the admin boring

Every custom admin screen is a thing you now maintain forever. Native blocks and a small set of well-named fields beat a bespoke editorial UI in every case I have measured.

The best sign a headless build is going well: the editors stop asking whether it is headless.

4. Decide who owns the URL

Routing split across two systems is where most of the pain lives. Pick one owner — I put it in the front end, with redirects exported from the CMS at build time — and write it down where the next developer will find it.

None of this is exotic. It is just the set of things I now refuse to leave until phase two.