Headless WordPress decouples the editor from the front end and pays for it forever — a second deploy target, a hydration tax on every page, a REST or GraphQL boundary in the middle. Atlas keeps WordPress whole and renders deterministic JSON manifests, server-side, where the content already lives. The difference is structural — and it shows up everywhere.
On the left · the incumbent
A Next.js front end on Vercel. WordPress on a separate origin as a content API. Two deploy pipelines, two hosting bills, a REST or GraphQL boundary in the middle, and hydration on every page load.
On the right · what Atlas does
One Gutenberg block. Deterministic JSON manifests, rendered server-side. Static chrome ships zero JS; islands hydrate only where marked.
Authors edit content in WordPress. Developers build the front end in a separate Next.js repo, fetching posts and ACF fields over GraphQL or REST. The two halves drift — what an editor sees in the WordPress admin is no longer what renders.
Two repos, two mental modelsAuthor edits one block inside Gutenberg. The block reads a structured manifest. The same layout, applied twice, is the same bytes twice — because it is the same JSON twice.
Structured, legible, repeatableThe Next.js front end fetches JSON, renders React on the server, then ships the framework runtime to the browser to re-hydrate the same tree. Every page pays the hydration tax — even the ones that have no interactivity.
Hydration on every loadMarkup is rendered server-side from the manifest, by WordPress itself. Static chrome ships as plain HTML with no hydration cost. JavaScript only loads for islands the manifest explicitly marks.
Deterministic, hydration-lightLayout lives in front-end code. Content lives in WordPress. The contract between them is a hand-rolled GraphQL schema or a wall of REST endpoints. Moving a page anywhere else means reconstructing both halves of the split.
Locked to the boundaryManifests are plain JSON, version-controlled in git. Diff them in pull requests. Move them between sites. Read them in any editor. Layout is no longer trapped in the database — or in a separate front end.
Git-native, diff-ableThe source of truth is split: copy in WordPress, layout in the Next.js repo, the contract between them a fragile schema. To know what a page renders, you read two codebases and infer the join.
Split across two stacksThe manifest is the source of truth. It lives in your repository alongside the rest of the codebase. The Gutenberg editor is a view onto it, not the only place it exists.
JSON in the repoVercel goes down, the front end goes down. WordPress goes down, the front end shows stale or empty content. Two deploy targets, two on-call surfaces, two ways for the site to break independently.
Two failure surfacesDeactivate Atlas and the block degrades to plain HTML. No theme rewrite required. The page does not vanish; it simply loses the dynamic shell around its content.
Graceful, reversibleTwo hosting bills. A Node front end whose framework upgrades cascade through every component. A REST or GraphQL contract that needs versioning every time the schema shifts. Two years in, the architecture costs more than the content it serves.
Compounding overheadManifests compose, diff, and refactor like the rest of your codebase. A change to the schema is a pull request. Site-wide edits are a find-and-replace across JSON, reviewable before they ship.
Refactorable like codeOne block. Manifests in git. Server-rendered HTML. The page builder was the wrong layer all along.
Install Atlas