Headless WordPress with Silex: a fast static front end, a back office your clients already know

If you build sites for clients, you know the tension. Clients love WordPress because they can log in and edit their own content. But shipping a modern WordPress front end for real clients, one that stays fast, stays secure, and stays maintainable, is genuinely hard work. Plenty of agencies and freelancers have wrestled with page builders and heavy themes, then quietly gone back to a monolithic WordPress they now have to babysit.

Headless WordPress is the way out of that tension, and Silex makes it approachable. The idea is simple: WordPress keeps doing what it does best, as the content back office, and Silex designs the front end visually and publishes it as a plain static site. Your client keeps editing in the WordPress admin they already know; the public site is just fast, standard HTML and CSS, regenerated from WordPress whenever the content changes. This article explains how that works, when it is the right call, and, just as importantly, when it is not.

A note on where this comes from. The workflow below was shown live, end to end, on two Silex Labs streams, each with a working WordPress professional in the room asking the hard questions: Emmanuel Mutel, a freelance web designer and integrator, and Hugo Blanchard of the WordPress agency Digital Korner (and its plugin studio WP Connect), in Nantes. Thanks to both for the honest, hands-on perspective. We have kept their framing and re-verified the durable technical facts (WPGraphQL, the ACF/SCF situation, the Eleventy build) against current sources.

First, credit where it is due: WordPress is a great CMS

Let's be clear up front, because this is not a "leave WordPress" article. WordPress is one of the great free software projects. It powers a huge share of the web, its editing experience is familiar to millions of people, and its plugin ecosystem is enormous. When a non-technical client sits down to write a blog post, add a team member, or swap a hero image, WordPress is a genuinely good place for them to do it.

The thing that ages badly is not WordPress the CMS. It is the traditional coupling of that CMS to the public front end: PHP running on every request, a database exposed to the internet, a theme layered with a page builder, and a maintenance burden that never ends. Headless keeps the good part, the back office, and replaces the fragile part, the runtime front end. You are not fighting WordPress. You are letting it do the one job it is best at.

What "headless WordPress" actually means

In a normal WordPress site, one server does everything: it stores your content, renders the pages in PHP, and serves them to visitors. "Headless" means you unplug the head, the front end, from the body, the CMS. WordPress becomes a pure content back end, reachable through an API, and something else builds the pages your visitors actually see.

With Silex, that "something else" is a visual editor plus a static build:

1. WordPress holds the content. Posts, pages, and custom fields live in WordPress exactly as your client expects.
2. WordPress exposes that content over an API through the WPGraphQL plugin, which adds a GraphQL endpoint to any WordPress site. Silex only reads from it, no writes or mutations, so you can keep the endpoint locked down.
3. Silex designs the front end against that real content, visually, in the browser.
4. The site is published as static files generated by Eleventy at build time. No PHP, no database, on the public server. Just HTML, CSS, and assets.

The published site is not "connected" to WordPress at runtime. The content is pulled in once, at build time, and baked into files. As the team put it on stream: once the build is done, you can switch the WordPress server off entirely and the live site keeps running, because it is only files on a host.

Why decouple the front end at all

Splitting the CMS from the front end buys you four concrete things.

Speed. A static site is about as fast as the web gets. There is no PHP to execute and no database to query when a visitor arrives, so pages are served as plain files, ideally from a CDN. In production, the Silex team reports Lighthouse/PageSpeed scores above 90 on mobile and close to 100 on desktop for these sites. Images are part of that: the Eleventy build can resize them and convert them to modern WebP or AVIF formats automatically, so a client can upload a large JPEG without thinking about it and still get an optimised <source> in the final HTML.

Security and low maintenance. This is the one a WordPress professional on the stream was most blunt about. An un-updated WordPress is a target: skip updates for a few months and you can expect to be hacked. A static site has almost no attack surface, because there is nothing dynamic running on the public server. And in a headless setup you can lock the WordPress admin down hard, restrict it to certain IP addresses, or keep it off the public internet entirely, exposing only a read-only GraphQL route. The content flows out to the build; nothing flows back in.

Sobriety. Nothing executing on the server on each request means less compute, lighter pages, and a smaller footprint. Clean, hand-tuned static HTML tends to score well on tools like Website Carbon, and it gives you a solid, standard foundation to build accessible pages on, rather than the deep stacks of nested <div>s that heavy themes and page builders often generate.

No lock-in. A Silex site is standard HTML and CSS that you can host anywhere: GitLab Pages for free, an FTP host, your own server, any CDN. There is no proprietary runtime underneath and no platform holding the live site hostage. If you ever move away from Silex, you still have standard files and you still have your content in WordPress. Portability is the default, not an export button with asterisks.

How it works, step by step

Here is the actual pipeline the streams demonstrated, from a blank project to a client-editable site.

1. Turn WordPress into a headless source

Install the WPGraphQL plugin on the WordPress site. That is the only required piece: it gives you a single GraphQL URL that Silex understands. Silex only needs read access to that route, no write access, no mutations, so you can keep the rest of WordPress locked down.

2. Model your content with custom fields

Raw WordPress posts come with a lot of markup you do not want to drop straight into a designed page. The clean approach is to define your own fields, so the client fills in a title, an image, a date, a short description, and each of those maps to a specific styled element in your design.

That is what a custom fields framework does, and here we recommend a fully libre one: Pods. Pods is free software (GPL), community-run, gives you every field type at no cost, and has WPGraphQL support built into its core since version 2.9, so your fields show up in the API with a checkbox. It keeps the whole stack free and libre, end to end.

The better-known option is Advanced Custom Fields (ACF), maintained by WP Engine. It is worth knowing the current state of play: in October 2024, during the WP Engine / WordPress.org dispute, the WordPress.org team forked ACF into Secure Custom Fields (SCF), now the version that ships from the WordPress.org directory. Any of these works with a headless-with-Silex workflow, you are just defining field groups and Silex reads them the same way. If you are starting fresh, Pods is the one we would reach for.

3. Design the front end in Silex, against real content

In Silex you build the page visually: containers, layers, CSS classes you create and reuse, responsive breakpoints. Two habits matter here, and both came up as beginner traps on stream: create real classes rather than styling an element's ID, and think about your class structure before you start decorating blocks.

Then you bind content. Select a text element, and in its settings you can assign it a value coming from WordPress, a post title, a custom field, an excerpt. For a list of posts you define a loop: one design that generates one page per post, each with its own URL, exactly like a collection page. Under the hood Silex turns this into a templated loop in the static build, but you create it with clicks, not code.

4. Handle SEO and slugs without a plugin

Because you control the templates, you do not need a WordPress SEO plugin on the front end. Page slugs and permalinks come straight from WordPress data (pagination.items), and the SEO title, description, and social share image are just fields you map in Silex's page settings. The simplest pattern the team recommended: add plain text fields in Pods (or ACF/SCF) for "SEO title" and "SEO description", plus a site-wide fallback for when a client leaves one blank. If your client is attached to Yoast, you can still pull its values, but a couple of custom fields is often one plugin lighter and perfectly enough.

5. Publish, and let the client rebuild on their own

Publishing runs a build (on GitLab CI, using Eleventy) that pulls everything from WordPress and writes the static site. The important part for client autonomy: install a deploy plugin on WordPress, or wire up a GitLab trigger token (a URL you call, optionally via POST), and the client can trigger a fresh build from inside WordPress. They never open Silex. They edit their content, hit a button, and their live site updates.

The real value: you deliver, your client stays autonomous

This is the point of the whole approach, so it is worth stating plainly. Headless WordPress with Silex is not about migrating an existing WordPress site to static, and it is not about replacing WordPress. It is a delivery model for freelancers and agencies:

• You design and build the front end in Silex, ship a fast, clean, portable static site, and hand over a WordPress back office set up with the right fields and modules.
• Your client edits their content in the WordPress admin they already know, adds posts, swaps images, fills in sections, and publishes, without touching the design or the code, and without depending on you for every text change.

As Hugo Blanchard (Digital Korner) summed it up: Silex can be effectively invisible to the client. They do not need to know it exists. They live in WordPress; the fast static site takes care of itself.

Where headless is not the right choice

Headless is a real trade-off, not a free win. Be honest with yourself and your client about when to skip it:

• Small, low-traffic sites where performance and security are already fine. If a simple WordPress site does the job, adding a build pipeline is complexity you do not need.
• Clients who want everything in one tool. Headless means two moving parts, WordPress plus the Silex/build setup. Some clients (and some budgets) are better served by staying monolithic.
• Sites that rely on dynamic, front-end WordPress plugins. Anything that must run PHP on each request for the visitor, live search, on-page dynamic personalisation, certain membership or e-commerce flows, does not translate cleanly to a static front end. If the interactivity is core to the site, headless will fight you.
• Teams with no appetite for a build step. The moment you go beyond a plain static site, you take on GitLab, a pipeline, and a rebuild-on-publish habit. It pays off for professional work; it is overkill for a one-page brochure.

If any of those describe your project, a classic WordPress build is the honest recommendation.

Side by side

Who should reach for this

Reach for headless WordPress with Silex if you are a freelancer or agency delivering sites to clients who want to manage their own content, if performance and security matter for the project, and if you would rather hand over standard files you can host anywhere than tie the live site to a platform. It is a particularly good fit for studios doing recurring professional work, where a fast, low-maintenance front end and an autonomous client are both worth real money.

Stay with a classic WordPress build if the site is small, if the client wants a single tool, or if the front end genuinely depends on dynamic WordPress plugins. Right tool, right job.

See it in action

The whole workflow above was built live on stream, with our two guests. Watch the episodes:

Silex loves WordPress developers, with Emmanuel Mutel.

WordPress special, with Hugo Blanchard (Digital Korner).

A libre-framed close

The honest summary is this: WordPress is an excellent CMS, and it is at its best when it is doing the content job and not being asked to also be a fragile, exposed, high-maintenance front end. Silex is a facilitator, a visual, integrated way to build that static front end and deploy it for free on GitLab Pages or anywhere else, so you get WordPress's editing comfort without WordPress's runtime baggage.

And Silex is free software, libre, not just "open source" in the marketing sense. It is licensed AGPL and stewarded by the non-profit Silex Labs. That matters for a tool you build a client business on: no single company can quietly close it, buy it, or fence off the feature you will need next year. You keep the source, you keep the site, you keep control. "Open source" is the phrase people search for; freedom is the reason it is built this way.

If that fits how you want to work, try the editor, read the docs, and come ask questions in the community. And if a plain WordPress build is the right answer for your project, that is a good outcome too. The point is to choose with your eyes open.