Back in 2021 a client came to me with a brief I'd heard roughly forty times before: "We want the WordPress backend our editors know, but the site needs to be fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.
Then their marketing manager wanted to add a pop-up form. Then a membership plugin. Then live chat with conditional logic tied to post categories. And slowly, quietly, the whole setup started to groan.
That project taught me more about the real limits of headless WordPress than any tutorial ever did. So let me give you the honest picture.
What "Headless WordPress on Vercel" Actually Means
Worth being precise here, because people use the term loosely.
You're running WordPress (usually on a separate server, a managed host like Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.
Vercel doesn't host WordPress itself. Full stop. WordPress needs PHP, a database (MySQL), and server-side execution. Vercel runs Node.js serverless functions and static files. You cannot drop a WordPress install onto Vercel the way you'd drop it onto a cPanel server.
So when someone says "host WordPress on Vercel," what they actually mean is: host the frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.
When This Setup Genuinely Shines
I want to be fair here. I've shipped headless WordPress + Vercel projects that I'm genuinely proud of, and there are specific conditions where the architecture earns its complexity.
High-traffic editorial or media sites
Seahawk had a project for a sports media publisher in 2022. Tens of thousands of page views per day, content team of twelve, editors who flatly refused to leave WordPress. We built a Next.js frontend on Vercel with Incremental Static Regeneration (ISR) set to 60-second revalidation windows. On a big match day, the origin WordPress server barely flinched. Vercel's edge network absorbed the traffic spike without a single conversation about scaling.
For sites where content changes in batches (articles go live, not edited every two minutes), ISR is a brilliant fit. You get static-file performance at the edge with reasonably fresh content.
Sites that need extreme frontend flexibility
If your designer wants custom scroll animations, complex component transitions, or a React-based interactive tool embedded mid-page, a traditional WordPress theme is fighting you the whole way. A decoupled frontend hands that control back to the developer entirely. The design constraints of WordPress themes just disappear.
Developer teams already deep in the Node/React ecosystem
If your team ships React apps all day and treats PHP like a foreign language, forcing them into WordPress theme development is genuinely painful. Headless lets them stay in their world while giving content editors a tool they already know. That's a real productivity win on the right team.
The Tooling Stack I Actually Use
If I'm going headless WordPress + Vercel today, here's what the stack looks like:
- WordPress host: Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
- GraphQL layer: WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
- Frontend framework: Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
- Deployment: Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
- On-demand revalidation: WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
- Preview content: The
@wpengine/headlesspackage or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.
That last point about previews took me longer to get right than I'm comfortable admitting. Editors expect to hit "Preview" in WordPress and see exactly what goes live. With a decoupled setup, wiring that up properly takes a solid day's work.
Where It Breaks Down (And It Does Break)
Alright. Here's where I have to be honest with you, because this is the part most "headless is the future" posts skip.
Plugins. So many plugins.
WordPress's power comes from its plugin ecosystem. WooCommerce, Gravity Forms, membership plugins, booking systems, advanced SEO tools like Yoast (yes, Yoast still works, but the frontend rendering of its meta tags requires extra wiring), slider plugins, anything that touches the frontend. In a traditional setup, the plugin renders PHP directly into the page. In a headless setup, it does nothing visible unless you've explicitly built a frontend component to replicate its output.
I had a client in late 2023 who came to me mid-project (not a Seahawk project, someone else's mess I inherited). They'd gone headless with good intentions and then tried to add WooCommerce. What followed was a four-month detour building a custom cart and checkout flow in React, calling WooCommerce's REST API, handling Stripe webhooks manually, and generally reinventing wheels that WooCommerce had already built. The time cost was roughly three times what just using a traditional WordPress + WooCommerce setup would have been.
Headless WooCommerce is doable. WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.
The preview experience never fully matches
I've shipped six or seven headless WordPress projects now and I have never once had a client who was entirely satisfied with the preview workflow. There's always a gap between hitting "Preview" in WordPress and seeing what actually renders. Sometimes it's a draft mode cookie issue. Sometimes it's ISR cache timing. Editors who came from a traditional WordPress setup find it disorienting, and the complaints come quietly but persistently.
Two systems to maintain
This sounds obvious but it genuinely sneaks up on teams. You're now running two separate infrastructure concerns: the WordPress server (with its own updates, security patches, plugin conflicts, database backups) and the Vercel frontend (with its own build pipeline, environment variables, serverless function limits). When something breaks at 2am, you have twice as many places to look.
At Seahawk we've had projects where a WordPress plugin auto-updated and quietly changed a REST API response shape, which broke a frontend component. No error thrown on the WordPress side. Just a silent content gap on the live site. That kind of failure is genuinely harder to catch than a traditional WordPress error.
Real-time content is awkward
If your site has content that changes frequently (think live scores, stock prices, user-generated comments, anything that needs sub-minute freshness), ISR's revalidation model is a poor fit. You end up either serving stale data or hitting your WordPress backend on every request, which defeats a significant part of the performance argument.
The Costs: What Nobody Puts in the Proposal
Let me be concrete about money and time, because I've seen agencies underbid these projects badly.
- Initial build overhead: Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
- Vercel pricing: The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
- WordPress hosting: You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
- Ongoing maintenance: Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.
When I'd Actually Recommend It
After everything I've just said, here are the specific scenarios where I'd tell a client headless WordPress on Vercel is worth the trade-offs:
- The site is content-heavy and read-heavy: mostly articles or landing pages, not transactional flows
- The content team already knows WordPress and won't entertain switching CMS
- Performance at scale is a genuine business requirement, not just a nice-to-have
- The development team is comfortable with React and modern JavaScript tooling
- No complex plugin dependencies are in the brief, or you've explicitly scoped around them
- A long-term technical owner is in place who understands both sides of the stack
And here are the scenarios where I'd push back:
- The client wants WooCommerce or any plugin-dependent frontend feature
- The team is small and can't absorb the maintenance overhead of two systems
- Editors need a fast, familiar preview workflow and there's no budget to build it properly
- The site has user accounts, dynamic personalisation, or real-time data requirements
- The client just wants it "because it sounds modern"
That last one. I hear it more than I should.
Alternatives Worth Considering First
Before defaulting to this stack, I'd at least put these options on the table:
- Traditional WordPress on a good managed host: Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
- Faust.js by WP Engine: Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
- A purpose-built headless CMS: If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.
---
FAQ
Can I literally deploy WordPress to Vercel?
No. WordPress requires PHP and a MySQL database. Vercel's infrastructure is built around Node.js serverless functions and static file serving. You can deploy your Next.js (or other JavaScript) frontend to Vercel, and have that frontend fetch content from a WordPress instance hosted elsewhere, but WordPress itself runs on a separate server.
Does headless WordPress hurt my SEO?
Not inherently, but it can if you set it up carelessly. With Next.js you get server-side rendering and static generation, both of which produce fully rendered HTML that search engines can index without issue. The risk areas are meta tag handling (Yoast's output needs to be explicitly consumed and rendered by your frontend) and sitemap generation (you'll want to build a dynamic sitemap route in Next.js that pulls from WordPress). Get those right and SEO is fine.
Is Vercel's free plan enough for a headless WordPress frontend?
For a personal project or prototype, possibly. For a commercial site, no. The Hobby plan prohibits commercial use in Vercel's terms, and you'll hit serverless function invocation limits on any site with real traffic. Budget for the Pro plan from day one.
How do I handle WordPress preview mode in Next.js?
Next.js has a built-in Draft Mode (previously Preview Mode in the Pages Router). The pattern is: create a /api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.
What about forms and contact pages?
Forms are one of the cleaner plugin-to-headless migrations. A Gravity Forms submission can post directly to the Gravity Forms REST API. Alternatively, skip WordPress forms entirely and use something like Netlify Forms (though you're on Vercel) or a direct Formspree integration on the frontend. Honestly, for forms, I usually just reach for Formspree and call it done in an afternoon.
---
Headless WordPress on Vercel is a real architecture with real use cases. It's not a silver bullet and it's not a gimmick. The teams that get the most out of it are the ones who went in clear-eyed about what they were trading away, budgeted for the extra build time, and had a specific performance or flexibility problem they were solving. If that sounds like your project, it's worth it. If it doesn't, save yourself the complexity.