Why Many Agencies Still Prefer ACF Over Gutenberg

ACF and Gutenberg are not really competing for the same job. Gutenberg is excellent when the editor needs to compose long-form content out of a fixed block vocabulary, when the site is plugin-distributed, or when block-based theming (FSE) is genuinely the right architecture. ACF Flexible Content still wins when an agency needs to ship many sites quickly off a shared component library with custom design per client. The honest answer for most agency work in 2026 is "it depends on the client deliverable", not "ACF won" or "Gutenberg won".

Jump to:

• The framing problem in this debate
• When Gutenberg is the right answer
• Where ACF still wins for agency delivery
• The hidden cost of maintaining a custom block ecosystem
• The reusable Flexible Content pattern, in detail
• How I decide for a fresh project
• What ACF Blocks change about the calculus
• What I would build today on a fresh agency project

The framing problem in this debate

The ACF vs Gutenberg argument keeps getting framed as "which is the future of WordPress content editing." That framing is wrong because it treats both tools as solving the same problem. They do not. Gutenberg solves "compose flexible content out of a shared block vocabulary, then store it in post_content as HTML comments wrapping HTML." ACF Flexible Content solves "let the editor pick from a curated list of layouts that the developer fully controls the markup of, then store the data as structured meta keys."

If the editor's job is mostly typing rich text and dropping in some images, Gutenberg is the more natural editing surface. If the editor's job is "assemble a landing page from heroes, CTAs, stat rows, testimonials, pricing tables, and content-feed blocks that the agency built specifically for this brand", ACF Flexible Content is the more natural editing surface. Both can do both jobs. Neither does both well.

When Gutenberg is the right answer

I reach for Gutenberg first when one of these is true:

• The site is a blog or publication where the content shape is dominated by paragraphs, headings, images, and the occasional embed.
• The site is a plugin or theme being distributed to many third-party WordPress sites, where the editor experience has to feel native to WP core.
• The site uses FSE (full-site editing) and the design system is built on core blocks plus a small handful of custom blocks.
• The client team is already comfortable with the block editor and would experience ACF Flexible Content as a regression.
• The deliverable includes the post_content being portable to other WordPress installs without losing layout.

The last bullet is the underrated one. ACF Flexible Content data lives in wp_postmeta and is meaningless without the field group registration and the templates that render it. Gutenberg's content travels as HTML inside post_content and renders (imperfectly but workably) on any WordPress install. For sites where content portability matters, that is a real Gutenberg win.

Where ACF still wins for agency delivery

The ACF win is most pronounced under a specific shape of agency work: you have a small team, you ship a lot of custom-design marketing sites, and you want a repeatable backend that the front-end developer styles per project.

Concretely:

• Custom design per client, repeated structure across clients. Same hero, CTA, testimonials, pricing layouts; wildly different visual treatments per brand. ACF Flexible Content stays the same; the front-end implementation is custom every time. The editor experience does not regress per project.
• Editorial control of which layouts exist. Gutenberg gives the editor every core block plus every block in every active plugin. ACF Flexible Content gives the editor only the layouts the developer registered. For an agency, that constraint is the feature.
• Predictable output HTML. The template that renders each ACF layout is a normal PHP partial. There is no <!-- wp:block --> comment to parse, no block attribute serialization to worry about, no surprise inline styles from the editor.
• Easier handoff to junior front-end devs. "Style this .hero partial" is a more legible task than "create a custom block, register its attributes, write the edit and save functions, register the InspectorControls."
• Stable abstractions across WordPress versions. ACF Flexible Content's API has changed remarkably little since the early 5.x releases. The Gutenberg API has had multiple breaking changes between WP versions; agencies that built custom blocks in the WP 5.x era have done real rework to keep them current.

This is the operational case, not a polemical one. It explains why many agencies have not migrated and is not an argument that they never will.

The hidden cost of maintaining a custom block ecosystem

The Gutenberg cost that agencies underestimate is not the time to build the initial custom blocks. It is the maintenance over the next four years.

A custom block is a small React component with a save function that produces serialized HTML, an edit function for the editor UI, registered attributes, and possibly InspectorControls. Each of those surfaces has changed in non-trivial ways over Gutenberg's lifetime: the block API version bumps (v1 to v2 to v3), the package boundaries (@wordpress/blocks, @wordpress/block-editor, etc.) have reorganized, the recommended patterns for dynamic blocks have shifted toward render.php and block.json, and the FSE migration introduced a separate axis of theme-template change.

If you built five custom blocks for a client in 2021 and a different five for another client in 2022, by 2025 you have ten block codebases, each with its own slightly-different React patterns, each requiring its own dependency updates, each needing its own QA pass when the next WP major bumps the block API. Multiply that across an agency's client portfolio and the maintenance burden compounds.

ACF Flexible Content templates are PHP partials. They do not break across WordPress versions. They do not require a build step. They do not require a separate React runtime for the editor. The editor surface (the field group config) is data, not code. The maintenance burden is roughly zero, for years on end.

This is the asymmetry that drives the agency preference. It is not about preferring one editing paradigm over the other; it is about the long-tail maintenance bill.

The reusable Flexible Content pattern, in detail

When I talk about a "reusable component system" built on ACF Flexible Content, what I mean concretely is this: in mu-plugins/, a single acf_add_local_field_group() call registers the canonical Flexible Content field, with the same set of layouts (hero, CTA, stat_row, testimonials, pricing, content_grid, feature_list, faq, cta_banner) attached to a "page builder" field on every page-type post. Each layout has its own sub-fields. Each layout has a matching partial under template-parts/flexible-content/{layout-name}.php. The page template loops the Flexible Content and includes the matching partial for each layout.

The same registration ships with every client project. The partials get rewritten per client to match the design. The data shape stays identical, so I can copy a populated page from one project to another (via wp post and wp meta commands) and get a reasonable layout immediately, even though the visual treatment will look different.

What this means for the agency operationally:

• A two-week build for a new client is two weeks of template work and design, not two weeks of "reinvent the page builder."
• A junior front-end developer onboards by being shown nine PHP partials. There is no React layer in the way.
• The "what layouts exist" decision is centralized in one field-group registration. No surprises six months later.

This is what an agency stack built around ACF for a decade looks like. I covered the broader operational case in Using Claude CLI to Manage WordPress Sites and Using AI with WP-CLI for Faster WordPress Operations, but the foundation under all of it is this Flexible Content pattern.

How I decide for a fresh project

The decision matrix I actually use:

The hybrid pattern (Gutenberg for the body, ACF for structured fields and the page builder) is the most common shape on my current projects. The two are not mutually exclusive. The editor uses Gutenberg for the body content where Gutenberg shines, and the page builder field uses ACF Flexible Content for the layout assembly where ACF shines.

What ACF Blocks change about the calculus

The middle path is ACF Blocks, which lets you register custom Gutenberg blocks using ACF's field groups for the editor UI and PHP render templates for the output. You get the editor experience inside Gutenberg, you skip the React layer, and you keep the maintenance profile closer to ACF Flexible Content than to native custom blocks.

This is the right answer for projects that want to live inside the Gutenberg editing surface (because the client team prefers it, or because the rest of the site is FSE) but cannot justify the React-block maintenance burden. I have shipped ACF Blocks on three projects in the last two years and would reach for the pattern again on most "we want Gutenberg but with our own components" briefs.

The honest caveat is that ACF Blocks render in the editor as a server-side preview rather than as a native block, which can feel a beat slower than a native block in the editor experience. For most editor workflows that is fine; for editor-experience-obsessed clients it is a real consideration.

What I would build today on a fresh agency project

If a new client came in tomorrow wanting a marketing site with the usual mix of pages, the stack would be:

• ACF Flexible Content for the page builder field on every page-type post.
• ACF Blocks for the handful of components that the editor needs to drop into long-form Gutenberg body content (testimonial pulls, callouts, related-post cards).
• Gutenberg core blocks for the blog body content where it belongs.
• A single shared mu-plugins/acf-fields/ directory that defines the Flexible Content layouts and the ACF Blocks registration, copied from project to project and tweaked per client.

That stack ships fast on the first project, maintains itself for years, and avoids the trap of "we will rebuild the page builder for every client." It does not pretend that Gutenberg is bad; it picks Gutenberg for the jobs it does best and picks ACF for the jobs it does best. That is the operational answer the framing of the debate keeps missing.