WordPress on Netlify: What Headless Actually Means, the Three Ways to Do It, and What Breaks

You cannot run WordPress on Netlify, because Netlify serves static files and functions and WordPress is a PHP application with a MySQL database. What people mean by WordPress on Netlify is headless: WordPress keeps running on a host somewhere as the editor and the API, and a static site built from that API is what Netlify serves. That gives you a fast front end and keeps the editing experience. It also means you are now running two systems instead of one, and the parts of WordPress that assume they own the front end, forms, previews, comments, most plugins, either break or need rebuilding.

The search results are a vendor page saying WordPress sites work with Netlify, a forum thread saying they do not, and a plugin company explaining headless. All three are right about different things. This post is the version that starts from what actually runs where, then covers the three ways to do it, the list of what breaks, and the cases where the extra system pays for itself.

Table of contents

• What runs where
• The three ways to do it
• What breaks, in the order you will notice
• When it is worth it
• The WordPress half still needs a host
• A minimal working setup
• How this fits the rest of the stack
• FAQ

What runs where

A normal WordPress site is one system. PHP renders every page on request, reads from MySQL, and serves the result. Themes control the front end, plugins hook into everything, and the admin lives at /wp-admin on the same host.

A headless WordPress site is two systems. WordPress still runs, on a host that runs PHP and MySQL, but its theme is irrelevant because nobody visits it. It exists to give editors the admin interface and to expose content through the REST API or WPGraphQL. The second system is a front end, built by a static generator or a framework, that fetches the content at build time and produces the pages visitors see. That front end is what lives on Netlify.

So the sentence WordPress on Netlify is really WordPress on a PHP host, plus a front end on Netlify, plus a webhook between them so that publishing a post triggers a rebuild. The hosting bill did not go away; it doubled and moved.

The three ways to do it

1. Static site generator plus the WordPress API. Eleventy, Astro, Hugo or Gatsby fetch posts from /wp-json/wp/v2/ at build time and generate HTML. Netlify builds on a webhook from WordPress. This is the simplest headless shape: the front end is fully static, there is no runtime, and the WordPress host only needs to be up during builds and editing.

2. A framework front end with WPGraphQL. Next.js or Nuxt query WordPress through the WPGraphQL plugin, which gives you a typed schema and one request per page instead of several. Pages can be static, server-rendered or a mix. More capable, more moving parts, and the server-rendered pages need a runtime, which on Netlify means functions.

3. A static export plugin. A plugin such as Simply Static or WP2Static crawls the WordPress site and writes out HTML, which is then pushed to Netlify. The theme stays in charge of the front end, so nothing needs rebuilding in a new language. It is the least work and the least flexible, and dynamic features simply do not export.

If the goal is speed and security for a content site, and the team is not a JavaScript team, option 3 is underrated. If the front end is going to be a product in its own right, option 2. Option 1 sits in between and is where most headless blogs end up.

What breaks, in the order you will notice

Everything that assumed WordPress owned the front end is now either broken or a rebuild. The list is longer than the tutorials admit.

• Forms. Contact form plugins render on the PHP side and submit to it. On a static front end, the form either posts to the WordPress host across domains, with CORS and nonce problems, or gets replaced with a static-host form feature or a separate service.
• Previews. An editor clicks Preview and sees the WordPress theme, not the real site, because the real site is built elsewhere. Live preview of an unpublished post on the headless front end is a project in itself.
• Comments. Native comments render server-side. They are gone unless the front end fetches and posts them through the API.
• Plugins that output HTML. SEO plugins, galleries, tables, sliders, related posts: anything that hooks into the theme output does nothing on the headless front end. Some expose their data through the API; many do not.
• Search. WordPress search is a PHP query. The static front end needs its own index.
• Menus and widgets. Available through the API with the right plugin, but the front end has to render them.
• Redirects and 404s. Handled by WordPress before; handled by the static host’s configuration now, and the two can disagree.

The honest estimate for a mid-sized content site with a contact form, search and an SEO plugin is that headless costs a few developer weeks to reach parity with the site you had. That is fine if the payoff is real. It is a bad surprise when the goal was just a faster site.

When it is worth it

Headless earns its cost in specific cases.

• The front end is a product. An app with a marketing site and a blog that share components, where editors need a CMS and developers need a framework.
• Extreme traffic or extreme security requirements. A static front end cannot be exploited through a theme vulnerability and serves any spike from a CDN. The WordPress host can sit behind a login and never face the public.
• Multiple front ends from one source. A website, a mobile app and a newsletter all reading the same content.
• A team that already works in a JavaScript framework and would rather not write PHP themes.

It is not worth it for a brochure site or a blog whose only problem is speed. A well-hosted WordPress with caching is fast enough, and it keeps forms, previews and plugins working with no rebuild.

The WordPress half still needs a host

This is the part the headless tutorials skip. Wherever WordPress runs, it needs PHP, MySQL, updates, backups and a way to edit files and the database when a plugin misbehaves. Netlify does not provide that; you bring it.

The requirements are lighter than for a public WordPress site. Nobody hits the front end, so the host only carries editors and build-time API requests. That fits a small managed WordPress plan. On RunxBuild, managed WordPress starts at $3 a month on the Starter plan and has a file manager and a database browser in the dashboard, so fixing a broken plugin or editing wp-config does not need SFTP; see managed WordPress on RunxBuild for what the dashboard covers. The static front end can then live on any static host, including a RunxBuild static site built from the repository on the same webhook.

The one thing to configure carefully on the WordPress host is access: the REST API needs to be reachable by the build, and the admin should not need to be reachable by anyone else.

A minimal working setup

For option 1 with Eleventy, the wiring is three pieces.

// _data/posts.js
module.exports = async function () {
  const res = await fetch(process.env.WP_API_URL + '/wp-json/wp/v2/posts?per_page=100&_embed');
  return res.json();
};

A template that iterates over posts and renders title.rendered and content.rendered. A build hook URL on the static host, added to WordPress through a webhook plugin so that publishing calls it. And the WP_API_URL environment variable set on the static site’s build, pointing at the WordPress host. From there, every publish is a rebuild and every rebuild is a deploy.

How this fits the rest of the stack

Headless WordPress is a real architecture with real benefits and a real cost: two systems, two hosts, and a rebuild of everything that assumed one. Decide with that in view. If you go ahead, price both halves together, the managed WordPress plan that serves the editors and the static site that serves the readers, in the RunxBuild hosting calculator, and connect both in the dashboard so that the webhook between them is the only glue.

Useful related references:

• Headless Architecture: When Splitting the Frontend Is Worth It
• WordPress Self-Hosting: LAMP, Docker, or Managed RunxBuild
• Next.js CMS: Choosing Between Git, Headless, and Something You Already Have
• Managed WordPress on RunxBuild

FAQ

Can you host WordPress on Netlify?

Not WordPress itself. Netlify serves static files and functions and cannot run PHP or MySQL. You can host a static front end on Netlify that is built from a WordPress site running elsewhere, which is what headless WordPress means.

What is headless WordPress?

WordPress used only as an editor and an API, with the visitor-facing site built separately by a static generator or a JavaScript framework. The theme is unused; content reaches the front end through the REST API or WPGraphQL.

Is headless WordPress faster?

The front end is, because it is static and served from a CDN. Whether the difference matters depends on how well the normal site was hosted and cached. A cached WordPress site on decent hosting is often fast enough that headless is not the cheapest way to the same result.

What stops working with headless WordPress?

Anything that rendered on the PHP side: contact forms, previews, comments, search, and most plugins that output HTML. Each needs rebuilding on the front end or replacing with a separate service.

Where does WordPress run in a headless setup?

On a host with PHP and MySQL, same as always, but with lighter requirements because only editors and builds hit it. A small managed WordPress plan is enough; the static front end handles the traffic.