A decision table we actually use with clients, and the three cases where headless costs more than it returns.
The honest version of this decision has nothing to do with technology preference. It comes down to how many people edit the site, how often, and whether anyone on the team can keep a Node process alive at three in the morning.
When headless earns its keep
Headless pays for itself when the front end has to serve more than one surface — a website, a mobile app and a partner API from one content model. It also pays when traffic is spiky enough that rendering at the edge is cheaper than scaling PHP, or when the design demands interaction that a template engine fights you on.
When it does not
Three cases where we have talked clients out of it. A marketing site with two editors and forty pages: the extra build step buys nothing and costs a deployment pipeline. A team with no JavaScript engineer: you have moved the maintenance burden somewhere nobody can reach it. And a site whose main problem is unoptimised images — which headless does not fix, it just relocates.
Classic WordPress with a disciplined block library gets you 90% of the performance for a fraction of the operational weight. Start there, and let a real constraint push you off it.