Compare
Shapio vs WordPress
WordPress can run headless, and most people reach for it because it's everywhere. Here is what that costs you, and what a CMS built headless from the start does differently.
Side by side
| Area | Shapio | WordPress |
|---|---|---|
| What it is | Shapio A headless CMS built as one: a proper editor, a content model you change live, drafts, revisions, scheduling, localization, roles and an audit log, and a typed REST and GraphQL API for any front end. | WordPress A website platform from 2003 that can be run headless with its REST API, the WPGraphQL plugin and a separate front end; the admin, themes and the plugin system come along whether you use them or not. |
| Separation of concerns | Shapio The CMS is only the content and its API. Your site is a separate project on whatever stack you like, and the admin never renders your pages. | WordPress Admin, theme and front end share one PHP process and one database; running headless means switching off the half you aren't using. |
| Stack | Shapio TypeScript end to end, one Node service, no PHP; the same language as the front ends it feeds. | WordPress PHP and MySQL; your front end is another language and another deploy. |
| Platform-agnostic | Shapio Any host that runs Node or a container: a VPS, Docker, a PaaS; the site can be static on Cloudflare Pages, Vercel or Netlify with a deploy hook on publish. | WordPress Needs a PHP host; headless front ends live elsewhere, and the two must be kept in step by you. |
| Changing a content type | Shapio In the admin, in production, live: a new schema version, no restart. | WordPress Custom post types and fields come from code or plugins such as ACF; fields are stored as post meta with no schema of their own. |
| Schema in git | Shapio Yes. JSON files with stable IDs; | WordPress Only what lives in code. ACF can sync field groups to JSON files; the rest is in the database. |
| Content model | Shapio Typed fields, components, relations and dynamic zones, validated by the server; renaming a label never touches data. | WordPress Posts, pages and post meta, with no schema of their own. Types, validation and the API shape come from whichever plugin added the field, and they change when the plugin does. |
| Delivery API | Shapio REST and GraphQL generated from the model, with typed clients; drafts and private media never leak. | WordPress The REST API in core returns rendered HTML and plugin-shaped data; GraphQL means another plugin. There is no generated client in core and no contract: rename a field in ACF and find out in production. |
| Publishing | Shapio Drafts, revisions, scheduling, and change sets that ship schema and content together as a numbered snapshot a build can pin. | WordPress Drafts, revisions and scheduling per post. The model has no versions at all, so there is no way to ship a field and the content that uses it together, or to roll both back. |
| Localization | Shapio Per field, publish per locale with fallbacks, built in. | WordPress A plugin (WPML or Polylang) that duplicates posts per language. |
| Multi-site | Shapio Several sites on one instance, each with its own model, shared types where you want them. | WordPress Multisite: one codebase, a table set per site, one plugin set for all. |
| Roles and permissions | Shapio Custom roles per content type, field and action; end-user accounts with Google and GitHub sign-in; an audit log. | WordPress Five fixed roles for people. The Abilities API (introduced in 6.9, core in 7.0) gives API consumers capability-based, machine-readable access. Finer editorial control is still a plugin. |
| Security and upkeep | Shapio One server, no plugin surface; an upgrade is an npm or Docker version. | WordPress Core, theme and plugin updates on a schedule. Patchstack counted 11,334 new WordPress vulnerabilities in 2025: 91% in plugins, 9% in themes, six in core. Every capability you add is another plugin to update and another place to be exploited. |
| Hosting | Shapio Node with PostgreSQL, MySQL or SQLite; npm or Docker. | WordPress PHP and MySQL, on any host in the world. |
| Performance | Shapio One Node service answering from the database with a handful of statements per request; builds can be static and pinned to a snapshot. | WordPress PHP renders each request through the theme and every active plugin; headless setups add caching layers to get around it. |
| Visual editing and preview | Shapio Draft preview and click-to-edit, per site, from a snapshot you can pin. | WordPress The block editor previews the theme; headless preview takes a framework integration (Faust.js, a plugin) or custom work. |
| AI | Shapio Assist with your own provider key, off by default; an MCP server for agents. | WordPress Plugins, including Jetpack AI. |
| Ecosystem | Shapio Young and small, on purpose: the things WordPress sells as plugins are in the box. | WordPress The largest in the business: themes, plugins, agencies, hosts, and people who already know it. |
| Pricing | Shapio Apache-2.0, every feature, self-hosted. No paid tier yet; a hosted cloud is planned. | WordPress GPL core; most capability sits in paid plugins and managed hosting. |
Measured
Not measured. WordPress runs on PHP and our harness measures Node CMSs on the same box; a cross-stack number would say more about the hosting than the CMS.
Why switch
And when not to.
WordPress is the default because it is everywhere, not because it is good at this. Going headless with it means assembling a CMS out of plugins, each with its own data shape, update cycle and attack surface, and then fighting the parts of WordPress you no longer use. Shapio is a headless CMS built as one: the content model is data you change live, content and schema ship together, localization, roles, revisions and previews are in the box, and the API is typed from the model. If you need a WordPress theme and a plugin for everything, stay. If you want a CMS for a site you're building yourself, this is the one.