When people hear "PHP + JSON for publishing" they often think it sounds old-fashioned or overly simple. That reaction is understandable. PHP has been around since the nineties, and JSON is just a data format. Neither is a sophisticated framework.
But sophistication is not what you want in a publishing stack. Reliability, transparency, and portability are what you want. PHP and JSON, used well, deliver all three — and they do something more important in the current environment: they make your content legible to machines.
The machine-readability problem
A typical CMS stores content in a relational database. The database schema is complex, the content is mixed with metadata in non-obvious ways, and accessing it requires a query interface that external tools do not have. AI coding assistants, build scripts, validation tools, and content automation all have to work around this opacity.
JSON content records solve this directly. A JSON file is a self-describing document. Every field is named. The structure is visible without a schema document. An AI assistant can read a content record, understand what every field means, generate a new one that matches the pattern, and validate it against the existing structure — all without any special database access or API integration.
What PHP adds
PHP is the rendering layer. It reads the JSON, resolves the template, and outputs HTML. Because there is no framework abstraction between the content and the output, the path from data to page is short and explicit. A developer — or an AI assistant — can trace exactly what happens to a content record from file to rendered HTML in a single pass through bootstrap.php and a template file.
This transparency matters for AI-assisted development. When an AI tool can read the full rendering path without needing to understand a plugin system, a hook architecture, or an event bus, it can make reliable changes. It can add a new field to a content schema, update the template to render it, and validate the output without unexpected side effects.
The deployment advantage
PHP files and JSON files are static assets until the server interprets them. There is no build step, no compilation, no asset pipeline. A deployment is an rsync. A rollback is restoring the previous files. The entire site state is the contents of the repo at a given commit.
That simplicity extends to automation. A GitHub Actions workflow that validates JSON, lints PHP, generates a sitemap, and deploys via rsync is twenty lines. The equivalent workflow for a CMS-based site involves database migrations, cache clearing, and a dozen other steps that can fail in non-obvious ways.
The right fit
PHP + JSON is not the right stack for a site where non-technical editors need a visual interface, or where the content model is truly relational and complex. For those cases, a CMS with a database backend is the appropriate choice.
For a solo operator running a content-driven authority site — where content is produced by one person or by AI-assisted workflows, where the priority is long-term control over short-term editorial convenience — it is one of the most capable stacks available. The same characteristics that make it simple to understand make it easy to automate.