Moving Away from Elementor to FSE + Claude Code: The 2026 WordPress Build Stack

In short: Moving from Elementor to FSE + Claude Code means treating AI as a theme developer, not a page builder. Start from a thin block theme — Twenty Twenty-Five or a lightweight custom one — and let Claude Code generate your theme.json, synced patterns, template parts, and custom blocks. Hand clients a locked, native Gutenberg surface. Ship everything through Git, never SSH edits to production.

This is a build stack, not a migration button. The pieces are known and the tooling is mature; the discipline is what separates a fast, maintainable site from faster mystery meat. Here's how the whole thing fits together, and where a human still has to own the call.

Why are agencies abandoning Elementor for FSE + Claude Code?

Elementor got heavy at the same moment Claude Code got fast, and that timing is the whole story. For years the page builder earned its keep on one promise — ship a client-editable site quickly. Practitioners in the r/WordPress discussion on moving off Elementor report builder sites idling around 400–500MB of RAM against 100–200MB for equivalent Full Site Editing builds. Those figures are anecdotal and self-reported, not benchmarked. But the direction matches what most agency owners feel every time a staging box crawls.

The front end tells the same story with harder edges. Block-theme sites average a time-to-first-byte near 180–280ms versus 320–520ms for page-builder sites on identical hosting, and a block-theme homepage ships roughly 40–80KB of CSS where an Elementor build lands closer to 150–400KB before a single image loads, per this 2026 look at block theme vs page builder performance.

Here's the shift that actually reorders the market: when an assistant generates a custom section in a minute, drag-and-drop stops being a moat. The edge moves to maintainability, performance, and a clean editing surface — the same argument running through the case for where WordPress and AI are heading: fewer plugins, not more.

What does the FSE + Claude Code stack actually replace?

Think of it as a black box. You feed in a design system and a content structure; what comes out is a thin block theme, a set of patterns and templates, and a native Gutenberg editing surface. No page-builder layer sits between the database and the browser — and that missing layer is where most of the weight went.

Line the overhead up and it gets stark. Gutenberg plus a block theme adds roughly 0–30KB of CSS and 0–20KB of JS per page, against Elementor Pro's 150–300KB of CSS and 100–200KB of JS. Independent scoring, meanwhile, puts Gutenberg near 89/100 with a page-speed figure around 3.5s versus about 81/100 and 5s for Elementor, according to one WordPress page builder performance comparison.

The DOM count is the quiet killer. Elementor wraps a div around nearly every widget, producing something like three to five times the baseline node count, documented in a 2026 Gutenberg vs Elementor vs Divi in 2026 teardown. Fewer nodes means less to paint, less to hydrate, less to break.

None of this is a fringe bet anymore. FSE is production-ready for new builds, and its maturity is the through-line of the WordPress 2026 outlook — the block editor stopped being the risky choice a couple of release cycles ago.

How does Claude Code actually build a WordPress block theme?

Treat Claude Code as the theme developer on your team, not a faster page builder. The build reveals itself in layers, and it helps to introduce them in the order the theme itself loads: design tokens first, then reusable structure, then the narrow slice that genuinely needs custom code.

theme.json: the design system as data

Everything starts in theme.json. Colors, typography, spacing steps, layout widths, block defaults — it's your entire design system expressed as one structured file, and it's exactly the kind of dense, spec-driven artifact Claude handles well. Describe your palette and scale, and it drafts a coherent token set you refine rather than type by hand, a workflow walked through in detail in this account of building a block theme with Claude Code.

Synced patterns and template parts

Next comes structure. Synced patterns — the feature formerly called reusable blocks — give you edit-once, propagate-everywhere content, and paired with FSE template parts you get genuine inheritance across the site. Change a call-to-action pattern in one place and every page carrying it updates. That combination is the real payoff for editorial teams, and it is the thing a page builder never gave you cleanly.

Custom and ACF blocks, only where fields matter

Most sections need no custom code at all. Reach for ACF or hand-built custom blocks only where content genuinely needs structured fields — a pricing grid, a team roster, a spec sheet — so an editor fills labelled inputs instead of arranging loose blocks. Everywhere else, native blocks plus a good pattern library do the job without adding a maintenance surface.

Agent-skills and the Git loop

Claude Code doesn't arrive knowing WordPress conventions, so you teach it. The official WordPress agent-skills repo ships portable bundles of instructions, checklists, and scripts — for blocks, themes, plugins, and security — that install to ~/.claude/skills/ and load automatically for the assistant.

That skill-bundle pattern is what makes the broader wave of WordPress AI agents useful instead of generic: hand the model a checklist, not a vague prompt, and its output stops reading like scaffolding. Point it at your brand guidelines and it will draft a starter set of patterns and templates you then refine — the same starter-content advantage behind automating a WordPress build with AI agents. Be honest about the ceiling, though: Claude is an accelerator, strong at theme.json, scaffolding, and boilerplate, and consistently weak at design taste, responsive edge cases, and visual QA. Those stay human.

Which theme should you start from: Twenty Twenty-Five, Kadence, or a thin custom theme?

Start close to core. Twenty Twenty-Five keeps you on WordPress's own block-theme conventions and spares you another abstraction layer to fight when Claude is doing most of the assembly. There is no official Twenty Twenty-Six release yet, so 2025 is the current baseline to build against.

The community lean is either Twenty Twenty-Five as-is or a very thin custom block theme derived from it. A stripped, opinionated theme suits an AI-led build far better than a heavy "does-everything" theme, because every extra feature the theme bakes in is one more thing Claude has to reason around and you have to override. Kadence or GeneratePress are reasonable middle-ground picks when you want a bit more built-in flexibility, but the principle holds: less framework, more of your own theme.json.

How do you keep clients from wrecking the layout?

Do not try to recreate Elementor's blank-canvas freedom. That freedom is exactly what lets a client drag a heading three sections down and break the page. The goal is a constrained, native Gutenberg surface: a system the client edits confidently without ever touching the parts that hold the design together.

You assemble that from four levers — a locked header and footer, synced patterns for the common sections, a limited allowed-block list per post type, and ACF or custom blocks only where structured fields are needed. Mapped together, they answer the question every agency actually has: who is allowed to change what.

Read the table top to bottom and the pattern is clear: the client owns content, the developer owns structure, and the boundary is enforced by the platform rather than by a hopeful note in a handover doc. Combine native and custom where each earns its place — lean native for most sections, structured blocks only where the content demands them. Don't reinvent a field system Gutenberg already ships.

What's the safe deploy workflow — and what should you never let Claude do?

The whole thing lives in a Git repo. You develop locally or on staging, make small commits, review every diff, and only then deploy. Small commits matter more than usual here, because they turn an AI's output into something you can read, reject, and roll back one change at a time instead of accepting a wall of generated code on faith.

Never let Claude Code SSH-edit production directly. It feels quick, and it quietly trades Elementor's bloat for faster mystery meat — undocumented changes, no diff history, nothing to revert to when a template breaks at 5pm on a Friday. The safe loop is boring on purpose, and boring is what keeps a site maintainable two years in.

One caveat on scope: this stack shines for new builds. Migrating a large existing classic-theme site rarely goes cleanly in one shot — those jobs work best as hybrids, a block theme for new templates alongside the classic theme for legacy pages, with Elementor's leftover database traces cleaned up deliberately rather than assumed gone.

Key takeaways

• Treat Claude Code as a theme developer, not a page-builder replacement — it accelerates theme.json, patterns, and boilerplate, but design and QA stay human.
• Start from a thin block theme close to core (Twenty Twenty-Five or a lightweight custom one); skip heavy "does-everything" themes.
• Performance is the real argument: block themes ship a fraction of the CSS/JS and DOM nodes Elementor does, with measurably better scores.
• Give clients a constrained native surface — locked header/footer, synced patterns, a limited allowed-block list, ACF only where fields are needed.
• Ship through Git with small commits and diff review; never let an assistant edit production over SSH.

FAQ

Do I need to know how to code to build with FSE + Claude Code?

You need enough judgment to read a diff and make design and architecture calls, but you don't need to write most of the code by hand. Claude handles the boilerplate — theme.json, patterns, template scaffolding. Treat it as an accelerator you supervise, not autopilot: the value is in the calls you make about what to keep, reject, and refine.

Should I start from Twenty Twenty-Five or a custom block theme?

Start with Twenty Twenty-Five, or a thin custom theme derived from it. Both keep you close to WordPress core and avoid a second abstraction layer to fight. Avoid heavy multipurpose themes when Claude is doing most of the build — every baked-in feature is one more thing to reason around and override. Go fully custom only when you have a specific reason the default structure can't meet.

Can Claude Code migrate an existing Elementor site to FSE?

Not cleanly in one shot. Large classic or Elementor sites work best as hybrids — a block theme for new templates while the legacy pages stay classic — and you migrate section by section. Elementor also leaves database traces behind, so budget time to clean those up rather than assuming a switch flips everything over.

Should I let Claude Code edit my live site over SSH?

No. Use a Git repo, a local or staging environment, small commits, and diff review before every deploy. Direct SSH edits to production feel fast but just swap Elementor's bloat for faster mystery meat — changes with no history and nothing to revert to when something breaks.

Are ACF blocks or native Gutenberg blocks better?

Neither wins outright; combine them. Lean native for most sections, since native blocks plus a solid pattern library cover the common cases with no extra maintenance surface. Reach for ACF or custom blocks only where content genuinely needs structured fields, like pricing tables or team profiles. Don't reinvent a field system Gutenberg already gives you.

If you want the deeper decision framework behind the editing surface — page builder versus ACF versus custom blocks for client sites — read our breakdown of the best WordPress editing setup for clients and pick the guardrails that fit your team.