There Are Two Kinds of WordPress Hybrid. Most People Only Describe One.
A custom theme with React islands and a React app over the WordPress API are different bets with different ceilings. Two live sites, sorted honestly.
This post is part of Beyond the Hybrid, my guide to the web architecture ladder, from legacy CMS to sites that own their own database.
When people say “WordPress hybrid” they usually mean one thing: a React front end reading from WordPress through its API. That is a real pattern and I run it on this site. But it is only one of two hybrids, and the other one is the one most businesses should try first.
Hybrid one: the theme-level hybrid
A theme-level hybrid keeps WordPress fully in charge of routing and rendering. What changes is everything the visitor touches. I design the front end as a standalone, vibe-coded site first, then convert it into a hand-built WordPress theme, then add interactive pieces as small islands where they earn their place.
Marketing Podcast Network works this way. It was redesigned as an independent front end, then converted into a WordPress theme. More than 10,000 sitemap URLs are still served by WordPress underneath it.
The appeal is that nothing operational changes. Editors use the same wp-admin. SEO plugins keep working. The URLs that took years to rank do not move. You get a site that looks and performs like it was built this year, without migrating anything.
Hybrid two: the decoupled hybrid
A decoupled hybrid splits the system in two. WordPress becomes the back office: editors, products, orders. A separate React application, compiled with Vite, becomes the storefront, reading content over the REST or GraphQL API.
This site runs this way, and it carries one safeguard I consider non-negotiable: the server renders a full-text version of every route before React loads. Without it, the front end is invisible to AI crawlers that do not run JavaScript. I learned to treat that fallback as load-bearing; I wrote about why in AI crawlers don’t run JavaScript.
The decoupled hybrid buys you an app-grade front end: real client-side routing, state, a cart that behaves like software. It costs you a second system. Two deploys, two sets of dependencies, and a contract between them that somebody has to keep.
Side by side
| Site | Rung | Data | Rendering | Raw words | Mobile Lighthouse (perf / SEO / a11y) |
|---|---|---|---|---|---|
| Marketing Podcast Network | Theme-level hybrid | WordPress | Server (PHP) | 1,821 | 97 / 100 / 88 |
| ChrisSlater.ai | Decoupled hybrid | WordPress + WooCommerce | PHP fallback, then React | 1,259 | 95 / 100 / 95 |
Raw words: visible text in the HTML before JavaScript runs, which is what most AI crawlers read. Lighthouse: mobile lab runs under simulated slow 4G and a 4x CPU slowdown, median of five, measured October 2026.
Which one to choose
I use a simple test. If the improvement you need is how the site looks and how fast it loads, choose the theme-level hybrid. If the improvement is how the site behaves, with interactive tools, stateful flows and app-like navigation, choose the decoupled hybrid.
And if what you need is for the site to hold things WordPress was never designed to hold, such as accounts, listings, bookings or records with rules, neither hybrid is the answer. That is the rung above both of them, and it is the subject of Beyond the Hybrid.
Where to go from here
If you are trying to work out which rung your site belongs on, start with the full ladder, or see rebuild options and price ranges. If you would rather just ask, tell me what your site has to do and I will tell you what I would build.