A few times a year a client asks us: "Our marketing team loves WordPress, but the site feels slow and dated. Should we go headless with React?" The honest answer is sometimes yes, more often "not yet", and occasionally "fix the theme first". This post is how we decide, so you can judge a proposal from us or from anyone else.
What "headless WordPress" actually means
WordPress keeps doing what it is good at: the admin screen, users, media library, custom post types, and the editing workflow your team already knows. The public website, though, is a separate React or Next.js application that reads content from WordPress over the REST API or WPGraphQL.
That gives you two codebases, two deployments and two places where things can break. It is a real trade, not a free upgrade.
When we recommend it
The front end is a product, not a brochure. If the site has a property search, a pricing calculator, a member dashboard or a booking flow, a React front end is the natural home for that logic. Bolting it into theme PHP and jQuery gets painful fast.
Content goes to more than one place. A tour operator we could imagine working with wants the same itineraries on the website, in an Android app and in an iOS app. One WordPress back end feeding all three through an API saves a lot of copy-pasting.
The design needs full control. Some brand work does not fit into any theme or page builder without fighting it. In that case a custom React front end is cheaper over two years than patching a theme every quarter.
Performance is a business requirement. If most of your visitors arrive on mid-range phones over mobile data, which is common in Nepal and South Asia generally, a mostly static, pre-rendered front end helps. But see the next section before assuming it is the only fix.
When we tell clients to wait
The site is mostly pages and a blog. A well-built classic theme, decent hosting, image compression and caching will usually get a content site to a good speed. Most "WordPress is slow" complaints we see come from 40 active plugins, uncompressed hero images and shared hosting, not from PHP rendering itself.
The team relies on plugins that render on the front end. Page builders, form plugins, WooCommerce checkout, membership plugins and SEO plugins all assume they control the HTML. In a headless setup you either rebuild each of those pieces in React or lose them. We have seen headless projects stall at the "oh, the contact form was a plugin" stage.
Editors need live preview. In classic WordPress an editor clicks Preview and sees the real page. Headless requires someone to build a preview route, and it is easy to get wrong. If your editors publish ten times a day, budget for this properly.
There is nobody to run the second system. A Next.js front end needs a host, environment variables, a build pipeline and someone who will notice when it fails at 2 a.m.
The checklist we go through first
Before proposing a rebuild, we spend a day on the existing site and write down:
- Which plugins affect what visitors see, and which only affect the admin.
- What the slowest ten pages are and why (database queries, images, third-party scripts).
- How content is structured. Fields buried in page-builder shortcodes are hard to expose cleanly through an API; fields in custom post types or ACF are easy.
- Who edits, how often, and whether they need preview and scheduled publishing.
- Whether anything else, such as a mobile app, a kiosk or a partner system, will want this content.
Often the result is a smaller job: remove plugins, move to a proper host, convert the heaviest templates, add object caching. The client keeps their budget for features.
If we go headless, how we build it
- Model content first. Custom post types and fields get designed before any React is written. Clean content is what makes the API pleasant.
- Pick one API style. REST is fine for most projects and needs no extra plugin. We reach for WPGraphQL when the front end needs deeply nested data in one request.
- Pre-render what rarely changes, fetch what does. Landing pages and articles can be generated ahead of time and refreshed when an editor publishes, using a webhook from WordPress to the front end. Search, prices and stock stay dynamic.
- Build preview on day one. A draft URL that renders unpublished content with a signed token. It is not glamorous and it is the thing editors will ask about first.
- Keep forms and checkout boring. For WooCommerce we usually leave checkout on WordPress and make the catalogue headless, or the other way round only if there is a strong reason.
- Protect the back end. Put the WordPress admin behind a separate subdomain, limit who can reach the API write endpoints, and keep plugins updated. Headless does not make WordPress immune to the usual problems.
Where AI fits, if it fits
Once content lives behind a clean API, it is much easier to add useful things: a site search that understands questions, or an assistant that answers from your published pages and cites them. That needs structured content and a proper index, which is another reason to model content carefully. We would not add it just to say we did; we add it when support staff keep answering the same questions by email.
What to ask a vendor
- What exactly will we lose from our current plugin list, and how will it be replaced?
- How will editors preview unpublished changes?
- Who hosts the front end, and what does it cost per month?
- What happens to our SEO: redirects, sitemaps, structured data, canonical URLs?
- If we part ways, can another developer pick this up?
If the answers are vague, the project will be too.
Our take
Headless WordPress is a good tool when the front end has real application logic, or when content must reach several channels. For a typical business site, tidy WordPress with sensible hosting is cheaper and easier to live with. We would rather tell you that after a day of review than sell a rebuild that your team will struggle to maintain.
If you are weighing this for your own site, get in touch with Rayaxis and send us the URL. We will tell you plainly which route we would take.