Worth it
Content shared by a website, a mobile app and other channels; a React or Next.js team building interactive pages; a site whose frontend must stay up even if the admin is under maintenance.
Headless WordPress hosting runs WordPress as a content backend, serving JSON through the REST API or WPGraphQL, while a separate frontend such as Next.js renders the pages. The WordPress half fits ordinary hosting; a server-rendered frontend needs a Node runtime, on a WebJi® VPS from ₹499 a month before 18% GST.
For developers and agencies in India planning a decoupled WordPress build who need to know where each half runs and when headless is overkill.
Last editorial update: 14 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
Headless WordPress hosting runs two systems: WordPress as the content backend, serving JSON through the REST API or WPGraphQL, and a separate frontend — usually Next.js — that renders the pages visitors see. Editors keep the familiar admin; the public site is the frontend app.
| Half | What it does | What it needs |
|---|---|---|
| WordPress backend | Stores content; editors write and publish | Ordinary PHP and MySQL hosting — headless changes nothing here |
| Content API | Returns posts, pages and media as JSON | Built-in REST API at /wp-json, or the WPGraphQL plugin |
| Frontend (server-rendered) | Next.js in SSR or ISR mode builds pages on request or on a schedule | A Node runtime: a VPS running the app under PM2 with Nginx in front |
| Frontend (static export) | Pages generated once at build time | Plain files that any hosting plan can serve |
Teams that only need the WordPress editor and theme can stop at standard WordPress hosting; headless adds a second system to build, host and maintain.
Go headless when the same content feeds several channels or the frontend needs custom app behaviour; stay with standard WordPress for a brochure site or blog with one channel.
Content shared by a website, a mobile app and other channels; a React or Next.js team building interactive pages; a site whose frontend must stay up even if the admin is under maintenance.
A brochure site or blog with no second channel. You take on two systems, lose live theme previews unless you build them, and pay for a Node runtime.
Static or cached frontends can be fast, but slow API responses or heavy rebuilds erase the gain. Measure TTFB before and after.
Use the built-in REST API for simple decoupled sites; use WPGraphQL when a page needs many related pieces — menus, custom fields, linked posts — in one request.
| Attribute | WP REST API | WPGraphQL |
|---|---|---|
| Installation | Built into every WordPress install | A plugin that adds a /graphql endpoint |
| Example request | /wp-json/wp/v2/posts | One query naming exactly the fields needed |
| Round trips | Often several calls per page | Usually one |
| Custom fields and menus | Need extra endpoints or registration | Exposed through the schema, with extensions for ACF |
| Best for | Routes that map cleanly to one content type | Content-heavy pages with nested data |
The WordPress backend fits a shared WordPress plan; a server-rendered Next.js frontend needs a VPS, which WebJi® publishes from ₹499 a month before 18% GST. Small and mid-size builds can run both halves on one VPS.
| Layout | Backend | Frontend | Starting price |
|---|---|---|---|
| Static export | Shared WordPress plan | Static files on the same or another plan | Webji Launch ₹299/month |
| One server | WordPress behind Nginx and the Next.js app under PM2 on one VPS | VPS from ₹499/month | |
| Split | Shared or VPS WordPress | Separate VPS for Node | Both plans, quoted together |
Webji Launch price as published on 4 November 2026 and VPS start price as published on 29 October 2026; checkout shows the current figure before you pay.
Larger builds usually split the halves once rebuild traffic grows. The Next.js hosting page covers the Node side, and deploying Next.js on a VPS walks through PM2 and Nginx.
When an editor publishes, WordPress calls a secret endpoint on the frontend, which expires the cached content so the next visitor gets the new version — no manual deploy. Without a webhook, timed ISR revalidation works at the cost of a short stale window.
In current Next.js (App Router), tag the WordPress fetch, then expire that tag from a Route Handler. The Next.js documentation says a webhook caller should pass { expire: 0 }, and the old one-argument revalidateTag(tag) form is deprecated.
// fetch in a Server Component
fetch('https://cms.example.in/wp-json/wp/v2/posts', { next: { tags: ['posts'] } })
// app/api/revalidate/route.js
import { revalidateTag } from 'next/cache'
export async function POST(request) {
if (request.headers.get('x-revalidate-secret') !== process.env.REVALIDATE_SECRET) {
return Response.json({ revalidated: false }, { status: 401 })
}
const { tag } = await request.json()
revalidateTag(tag, { expire: 0 })
return Response.json({ revalidated: true })
}
On the WordPress side, a small must-use plugin fires the call when a post is published or unpublished:
add_action('transition_post_status', function ($new, $old, $post) {
if ($new === 'publish' || $old === 'publish') {
wp_remote_post('https://www.example.in/api/revalidate', [
'headers' => ['Content-Type' => 'application/json',
'x-revalidate-secret' => WJ_REVALIDATE_SECRET],
'body' => wp_json_encode(['tag' => 'posts']),
'timeout' => 5,
]);
}
}, 10, 3);
Define WJ_REVALIDATE_SECRET in wp-config.php and the same value as REVALIDATE_SECRET in the frontend's environment. Code checked against the Next.js revalidateTag reference, 14 November 2026.
Treat the backend as a private content service: keep the admin off the public domain where you can, authenticate anything beyond public reads, and cache API responses.
Moving an existing WordPress site to a headless setup? The website migration service moves the backend without changing its URLs, and support@webji.services answers 24/7 in Hindi and English with an average first reply under 60 minutes.
No. WordPress stays a PHP and MySQL application. Node is needed only by a frontend such as Next.js running in server mode; a static-exported frontend ships plain files and needs no Node runtime at all.
Only if you build it. The frontend needs a preview route that fetches the draft with authentication, such as an application password, and the WordPress preview link must point to that route. Without it, editors see drafts only inside the WordPress admin.
Backend plugins — custom fields, SEO metadata, forms storage — keep working and can expose data through the API. Plugins that change the theme's front-end output, such as page builders and sliders, have no effect, because WordPress no longer renders the public pages.
They still store titles, descriptions and canonical URLs, but the frontend must fetch and print them in each page's head. Sitemaps and robots.txt must also be served from the frontend domain, not the CMS hostname.
Yes. The content and the REST API are already there, so a frontend can be added later without moving posts. Many teams launch on managed WordPress hosting and add a Next.js frontend once a second channel justifies it.
Next.js and WordPress API details checked 14 November 2026 · Reviewed by the WebJi® team, Jaipur.
Join 12,000+ businesses across India and overseas. Free migration* (subject to terms & approval), INR pricing and 24/7 email support in Hindi & English — average first reply under 60 minutes.