The ACF versus Gutenberg debate gets treated as a matter of taste, and it shouldn’t be, because the two store content in fundamentally different ways with consequences that surface for years.
I build custom WordPress sites for a living, and I still reach for ACF flexible content over Gutenberg blocks on nearly every custom corporate build. Not out of habit: I’ve defended this decision in writing to agencies and enterprise clients who expected Gutenberg, walked them through the tradeoffs, and watched the reasoning hold up through legal reviews, accessibility audits and multi-year maintenance. This post is that argument, expanded.
What Each One Actually Is
Gutenberg is WordPress’s native block editor: content is assembled from blocks, edited visually, and the resulting block markup is saved into each page’s content. Custom blocks are built in React and JSX with their own build tooling.
ACF flexible content is a different model: editors assemble pages from a menu of predefined sections, fill in labeled fields for each one, and drag to reorder. The data is stored as structured fields, and a PHP template renders each section’s markup. Editors own the content and the order, the template owns every line of HTML.
That storage difference, markup in the page versus markup in the template, drives almost everything below.
Where Gutenberg Genuinely Wins
Being fair to it first, because Gutenberg has real strengths:
- It’s native. No plugin dependency, no license, and it will be maintained as long as WordPress exists.
- True WYSIWYG. Editors see something close to the real page while editing, which non-technical teams genuinely love, and which is often the reason clients ask for it by name.
- Best for editorial content. For blog posts and article-style pages, where content is mostly headings, paragraphs, images and embeds, Gutenberg is excellent and it’s what I use for exactly that.
- A large ecosystem. Thousands of prebuilt blocks and patterns exist, which matters if you’re assembling a site rather than designing one.
For a custom-designed marketing or corporate site, though, the weaknesses start stacking up fast.
The Modularity Problem: Blocks Are Not Modules
Here’s the core of the argument, and it’s the point that decided a recent enterprise build I did through an agency partner.
Gutenberg blocks look modular in the editor, but the markup a block generates is saved into each individual page. Build 10 pages with a hero block, then discover a design flaw or an accessibility failure in that hero, and you have 10 pages to open, edit and republish. Build 200 pages and you have 200. On a site with legal or compliance review, where every published change may need sign-off, that multiplication is not an inconvenience, it’s the single biggest risk in the platform choice.
ACF modules live in one template file. The same design fix is one edit, deployed once, and every page that uses the section is updated instantly. Nothing needs to be reopened, re-edited or re-reviewed page by page.
This is the same argument I make about template-based schema markup and most other things in CMS architecture: anything duplicated into pages will drift, and anything centralized in a template stays correct. A block-based page builder bakes duplication into its storage model.
Editors Lose Nothing That Matters
The standard objection is that clients want the WYSIWYG experience, and the honest answer is that a well-built flexible content setup gives editors everything they actually asked for:
- Add sections to a page from a menu
- Drag sections to reorder them
- Edit clearly labeled fields for text, images, links and options
- Adjust per-section layout settings where the design allows variation
No code, no HTML, no design decisions to get wrong. What editors give up is the ability to visually fiddle with spacing and alignment, and on a professionally designed site that’s a feature, not a loss. The design system survives contact with the content team.
Four More Reasons ACF Wins Custom Builds
Accessibility stays fixed
Accessible markup is precise: landmark structure, heading order, ARIA attributes, focus handling. With structured modules that markup is locked in the template where editors can’t break it. With Gutenberg, editors can rearrange and nest blocks in ways that silently destroy heading hierarchy and structure, and an accessibility audit’s fixes have to be applied everywhere the block was used, then defended against every future edit. For clients with WCAG obligations this alone justifies the choice, and it’s a major part of my accessibility consulting work.
Development is simpler and less fragile
Custom Gutenberg blocks are React and JSX development with per-block build tooling, block.json configuration, and deprecation handling every time a block’s markup changes. On enterprise hosting with code review, all of that gets reviewed too. An ACF module is a PHP template and a field definition: significantly less technical time, much less error prone, same visual result for the editor.
Structured data feeds everything else
ACF stores real fields, and structured fields can power anything: search facets, filtered directories, location lookups, JSON APIs, Schema.org markup generated from the same data that renders the page. Gutenberg stores content as HTML markup, and HTML can’t cleanly feed any of those systems. The moment a project includes an API, an integration or serious structured data, field-based storage stops being a preference and becomes a requirement.
The two don’t blend
A tempting compromise is to build some templates with ACF modules and the rest with Gutenberg. In practice the two don’t intermingle: a template is one or the other, and splitting a site between them means building and maintaining every shared design component twice, in two different systems, forever. Pick one model for the custom-designed portion of a site and stay consistent.
Where I Land
My rule after years of building both ways:
- Editorial content, blogs, articles: Gutenberg. It’s genuinely the best writing experience WordPress has ever had.
- Custom-designed pages, corporate sites, anything with compliance, accessibility or integration requirements: ACF flexible content. The modularity is real, the markup stays correct everywhere at once, and the structured data pays dividends across the whole stack.
Handled correctly, with well-designed modules and clearly labeled fields, ACF flexible content gives editors the control they want and gives the site an architecture that can absorb change. That combination is what a CMS is supposed to deliver, and it’s the foundation of how I approach every custom WordPress build.