kitloom vs headless WordPress: keeping the data without keeping WordPress

Teams that want out of a WordPress theme often reach for headless WordPress first. It is a sensible move: nothing has to be migrated, editors keep the admin they know, and the front end can be anything. kitloom also keeps the WordPress data where it is, but it makes the opposite cut. Headless WordPress keeps WordPress and replaces the front. kitloom keeps the database and replaces WordPress.

So the question is not which one keeps your content. Both do. The question is which part of WordPress you want to leave behind.

What each one is

Headless WordPress means WordPress stays as the content back end, with wp-admin, the block editor and its plugins, while a separate application draws the site. That application reads content over an API:

• The WordPress REST API, part of WordPress itself. Its handbook describes it as an interface "for applications to interact with your WordPress site", sending and receiving JSON, and it is also the foundation of the block editor. Public content is available without signing in; private content, custom post types and meta are available with authentication or when they are set to be shown.
• WPGraphQL, a free, open-source plugin that adds a GraphQL schema and API to WordPress. It has a first-party extension that exposes Advanced Custom Fields to the schema.

kitloom is a Laravel CMS whose storage is the WordPress database: wp_posts, wp_postmeta, wp_terms, wp_options, wp_users and the plugins' tables. It handles a request the way WordPress does, so the same URLs answer, and it has its own admin in Filament 5 or Laravel Nova 5. WordPress's PHP no longer runs. kitloom can be headless too: every page also answers as JSON, and kitloom/api serves the basics of WordPress's wp/v2 REST API.

Side by side

	Headless WordPress	kitloom
Where content lives	The WordPress database	The same WordPress database
Moving an existing WordPress site	Nothing moves; you build a new front end	Point a kitloom application at the database; migrate adds kitloom's tables beside WordPress's
URLs after the move	Whatever the new front end's router produces; matching WordPress's permalinks is its job	WordPress's permalink settings, rewrite rules and canonical redirects are read, so the same URLs answer
Users' passwords	Unchanged; WordPress still signs users in	Kept; WordPress's hashes (phpass and bcrypt) are read
Plugin data	Plugins keep running; the front end sees what they expose over REST or GraphQL	Read by kitloom modules in each plugin's format, for the plugins listed on WordPress Compatibility
Admin	wp-admin with the block editor	Filament 5 or Laravel Nova 5, with a visual editor
Front end	Any framework, as a separate application	Blade, Vue or React themes in the same application, or any front end on page JSON
WordPress code still running	Yes: core, plugins and their updates	None
Applications to run	Two: WordPress and the front end	One Laravel application
AI agents (MCP)	WordPress's MCP Adapter plugin (pre-1.0) exposes the abilities the site's plugins register, and nothing until they opt in	Built in (kitloom/ai): Claude, Cursor or your own agent connects to /mcp and works on content, media, settings and every installed module, with the rights of the key's user; locked settings, nothing deleted for good, every change in the activity log
Price model	WordPress and WPGraphQL are free; you host and maintain both applications	$149 for one site or $299 for unlimited sites, once, with 12 months of updates and a 14-day refund

When headless WordPress is the better choice

• Editors must keep wp-admin and Gutenberg. If the people who write the site depend on the block editor and its patterns, headless WordPress keeps that exactly. kitloom has no block editor; blocks already in content are drawn as WordPress draws them, and new content is written in a visual editor.
• The site depends on plugins kitloom does not cover. In headless WordPress every plugin keeps working on the back end. In kitloom a plugin without a module leaves its data in the database and its shortcodes on the page as text.
• You want a way back at any time. Nothing about headless WordPress is one way. kitloom writes new arrays as JSON, which WordPress does not read, so going back means restoring a backup.
• The front end is built on WPGraphQL. kitloom has no GraphQL. A Next.js or Nuxt front that reads WordPress's REST API works with kitloom too (see below), but one written against WPGraphQL's schema would have to move to REST or to kitloom's page JSON first.
• There is no budget for a license. WordPress and WPGraphQL are free.

When kitloom is

kitloom fits when the problem is WordPress itself, not only its themes:

• An AI agent runs the site, under your control. kitloom ships an MCP server. Claude, Cursor or your own agent connects to /mcp and does the work: posts and pages, media, menus, SEO and redirects, form messages, the shop's products, orders and sales, bookings, courses, translations. It acts as the user whose key it holds, through the same code as the admin. An author's key writes drafts, a read-only key only reads, and the settings that decide who gets in or what code runs on every page are locked. Nothing is deleted for good, every change is in the activity log, and revoking the key stops it at once. See Run your site from Claude or Cursor.
• You want WordPress off the server. No core and plugin updates to track, no functions.php, no hooks. The code is Laravel: Eloquent models, events, queues, Composer packages and tests. See What Is WordPress Here, What Is Laravel.
• One application instead of two. Headless WordPress means running, securing and deploying WordPress and a separate front end. kitloom is one Laravel app with the admin, the site and the API in it.
• URLs should keep working without writing a router. kitloom reads the permalink settings, category and tag bases, the static front page and the canonical redirect, as WordPress did. A headless front has to reproduce all of that itself.
• You still want a JavaScript front. kitloom's Vue and React themes run on Inertia in the same application. Or ask any address with Accept: application/json and get the page as data: its kind, its template and its parts. See Headless & APIs.
• Your Next.js or Nuxt front can stay. kitloom serves WordPress's REST API at the same address, /wp-json/wp/v2/, with the same routes, parameters and X-WP-Total headers for the core fields, so a decoupled front written against WordPress can point at kitloom instead. Fields that plugins add to the REST answers are not there, and meta is empty, so check what your front reads. See The WordPress REST API.
• The plugin data is covered. ACF and Secure Custom Fields, Contact Form 7 and Flamingo, WooCommerce with HPOS orders, Rank Math, LearnPress, Houzez and Listeo, Slide Anything, Nextend Social Login. Polylang and WPML sites are converted once. Yoast SEO's meta is not read today; support is in progress.

The move itself

A headless project has no migration step, which is its appeal. kitloom keeps that risk low a different way: it can draw the site from the live database with a MySQL user that may only SELECT, while WordPress goes on as it is. A script then compares the two sites address by address: status codes, redirects, titles, canonical tags, content, the lists on archives, leftover shortcodes. You switch when the report says what you want it to say. The steps are in Migrate from WordPress, and the reasoning in Moving a WordPress site to Laravel without moving the content.

Try both

For headless WordPress, start with the REST API Handbook or WPGraphQL, on a copy of your site.

For kitloom, open a sandbox in one click, no sign-up: Filament demo or Nova demo. Then look at your own site through kitloom with a read-only database user, as Migrate from WordPress describes. Prices and the refund are on Pricing.