ACF vs Gutenberg: Which Should You Use for a Custom WordPress Website?

If your marketing team needs a developer every time they want to add a section to a page, your WordPress website has an editing problem.

But the opposite can be just as frustrating.

Give editors complete freedom to build anything they want, and you can eventually end up with inconsistent layouts, broken design patterns, pages that look different from one another, and content that becomes increasingly difficult to maintain.

This is why the question “ACF vs Gutenberg” is more important than it initially appears.

It is not really a question about which technology is better.

It is a question about how much control your content editors should have, what kind of data your website needs to manage, and where the boundaries of your design system should exist.

ACF and Gutenberg solve different parts of that problem.

And for most new custom WordPress websites we build today, our answer is not to choose one and eliminate the other.

We generally prefer a Gutenberg-first editing experience, using custom Gutenberg blocks, block patterns, theme.json, and WordPress’s native block architecture for page composition, while using ACF and structured fields where the content actually needs to behave like structured data.

That distinction matters.

Because the goal isn’t to give your team maximum freedom.

The goal is to give them maximum useful freedom without allowing them to accidentally break the system.

Why the WordPress Editing Experience Matters

A custom website is usually built with two very different groups of people in mind.

The development team thinks about:

• Architecture
• Reusability
• Maintainability
• Performance
• Security
• Data structures
• APIs
• Long-term extensibility

The marketing or content team thinks about:

• “Can I change this headline?”
• “Can I add another section?”
• “Can I replace this image?”
• “Can I create a new landing page?”
• “Why do I need a developer to do this?”

Both groups are asking reasonable questions.

The problem occurs when the website architecture satisfies one group at the expense of the other.

A site can be technically excellent but provide a terrible editorial experience.

It can also provide an extremely flexible editing experience while becoming difficult for developers to maintain.

That’s why the editing system should be considered part of the website architecture, not merely an administrative interface.

What Are ACF and Gutenberg Actually Solving?

Before comparing them, it helps to separate the two concepts.

Gutenberg is WordPress’s block-based editing system

The WordPress Block Editor allows content to be composed from individual blocks such as headings, paragraphs, images, buttons, columns, groups, and custom blocks.

Developers can extend that system by creating their own blocks. (WordPress Developer Resources)

So Gutenberg is fundamentally concerned with content composition and editing.

ACF is a structured-data and customization framework

Advanced Custom Fields allows developers to create custom fields and field groups that can be attached to posts, pages, Custom Post Types, users, taxonomies, and other WordPress objects.

Those fields can then be used by the site’s templates and application logic. (ACF)

So ACF is fundamentally concerned with capturing and managing structured data.

That’s the first important distinction.

Gutenberg is not simply an alternative to ACF.

And ACF is not simply an alternative to Gutenberg.

They overlap in some areas, particularly with ACF Blocks, but their architectural purposes are different.

Gutenberg vs ACF: The Real Difference

A simplified comparison looks like this:

	Gutenberg	ACF
Primary purpose	Content composition	Structured data
Editing model	Blocks	Fields / field groups
Best for	Page layouts and editorial content	Specific data attributes
Developer control	High when properly curated	Very high
Editor flexibility	High	Controlled
Custom blocks	Native	ACF Blocks available
Structured fields	Possible, but not always ideal	Excellent
Design-system integration	Excellent	Depends on implementation
Requires custom development	Often, for sophisticated sites	Often
Reusable layouts	Block patterns	Field groups/templates
Ideal role	Page/content composition	Structured content and business data

The mistake is treating the table as a competition.

A well-architected website can use both.

The more important question is:

Which type of content belongs in which system?

The Problem With the “Blank Gutenberg Canvas”

When someone says they don’t want Gutenberg because they don’t want clients to “break the design,” they’re often responding to a legitimate problem.

But Gutenberg itself isn’t necessarily the problem.

An unrestricted editor can be.

There is a significant difference between:

“Here’s Gutenberg. Build whatever you want.”

and:

“Here’s a carefully designed block system built specifically for your organization.”

The second approach is where Gutenberg becomes much more interesting for custom WordPress development.

WordPress provides developers with APIs for creating custom blocks, controlling their available settings, creating patterns, locking portions of layouts, and curating the editing experience. (WordPress Developer Resources)

That means a custom WordPress website doesn’t have to give editors every possible WordPress control.

You can decide what they need.

Custom Gutenberg Blocks: Freedom Inside Boundaries

Imagine a company’s website has a standard “Feature Section.”

The design requires:

• A heading
• Supporting text
• An image
• Three feature items
• A specific spacing system
• A predefined responsive layout
• Brand-approved colors

One approach is to give the editor generic Group, Columns, Image, Heading, Paragraph, and Button blocks and ask them to construct the section.

Technically, that works.

But now the editor can also:

• Change spacing arbitrarily
• Choose colors outside the brand palette
• Change column proportions
• Add unnecessary nested containers
• Recreate the same section differently on every page

A better approach may be a custom Feature Section block.

The editor might see:

Feature Section

• Heading
• Description
• Image
• Feature 1
• Feature 2
• Feature 3

The development team controls:

• HTML structure
• Responsive behavior
• CSS
• available design options
• spacing
• typography
• accessibility
• component relationships

The marketing team controls:

• What the section says
• Which image it uses
• Which features are displayed

That’s a much healthier division of responsibility.

The editor has freedom over content.

The development team retains control over architecture and design rules.

theme.json: The Design System Behind Gutenberg

This is where modern WordPress development gets considerably more interesting.

theme.json allows a theme to define settings and styles for the Block Editor, including things such as color palettes, typography, spacing, layout, and per-block configuration. WordPress specifically documents theme.json as a mechanism for curating the editor experience and limiting which customization options are exposed to users. (WordPress Developer Resources)

For example, a custom website might define:

• Approved brand colors
• Approved font sizes
• Content widths
• Wide-layout widths
• Spacing scales
• Button styles
• Border settings
• Typography options

Instead of allowing an editor to choose any arbitrary value, the development team can expose the values that make sense for that particular brand.

That changes the philosophy from:

“Don’t let the client touch anything.”

to:

“Give the client the right controls.”

That’s a fundamentally better editorial experience.

And importantly, theme.json isn’t limited exclusively to block themes. Classic themes can also take advantage of it for editor configuration and styling. (WordPress Developer Resources)

As of the current WordPress documentation, theme.json version 3 is the latest specification and works with WordPress 6.6 and later. (WordPress Developer Resources)

Block Patterns: Don’t Make Editors Build Everything From Scratch

Even a well-designed block system can become tedious if editors have to construct every page manually.

That’s where block patterns become useful.

A block pattern is essentially a predefined arrangement of blocks that can be inserted into content and then customized by the editor. WordPress also supports locking portions of patterns to preserve important aspects of a design. (WordPress Developer Resources)

Consider a typical corporate website.

You might create patterns for:

• Hero sections
• Call-to-action sections
• Testimonials
• Service grids
• Team sections
• Logo walls
• FAQ sections
• Contact sections
• Content-with-image sections

The editor doesn’t start from an empty canvas.

They start from something that already follows the company’s design system.

They can then modify the content without rebuilding the architecture.

This is one of the biggest differences between a custom Gutenberg implementation and simply installing WordPress and handing someone the Block Editor.

So Where Does ACF Fit?

Very much into the picture.

There are many situations where structured fields are simply a better representation of the data.

Imagine a real estate website.

A property isn’t merely a page of arbitrary content.

It has structured attributes:

• Property type
• Price
• Bedrooms
• Bathrooms
• Square footage
• Location
• Availability
• Gallery
• Construction year

Those values may need to be:

• Filtered
• Sorted
• Queried
• Displayed in specific locations
• Exposed through an API
• Used in templates
• Used by search functionality

That’s structured data.

A field-based approach makes considerably more sense than asking an editor to manually construct those attributes using arbitrary blocks.

This is where ACF remains extremely useful.

ACF field groups are specifically designed to attach structured fields to WordPress content and other WordPress objects. (ACF)

Structured Data vs Editorial Content

A useful rule is:

If the editor is writing or composing something, Gutenberg is often a good fit.

If the application needs to understand the value as a specific piece of data, a structured field is often a better fit.

Consider a restaurant website.

Editorial content

A restaurant’s “About Us” section could be composed using:

• Heading
• Paragraph
• Image
• Gallery
• Quote

Gutenberg makes sense.

Structured data

The restaurant could also have:

• Address
• Phone number
• Opening hours
• Latitude
• Longitude
• Delivery radius
• Reservation URL

Those values are not really page composition.

They are data.

You may want to query them, validate them, expose them through an API, or use them in multiple parts of the application.

That’s where structured fields or other data structures become more appropriate.

Custom Post Types Change the Conversation

ACF and Gutenberg also shouldn’t be evaluated independently from the underlying WordPress data model.

Suppose you’re building a website for a law firm.

Instead of creating dozens of ordinary pages, you might create a Lawyer Custom Post Type.

Each lawyer could have:

• Name
• Photo
• Position
• Practice areas
• Biography
• Email
• Phone
• LinkedIn URL

WordPress Custom Post Types allow developers to create dedicated content types with their own administrative interfaces and querying behavior. WordPress recommends registering content-focused Custom Post Types in a plugin rather than a theme so that the content remains portable if the theme changes. (WordPress Developer Resources)

Now you have a much more meaningful architecture:

Custom Post Type

→ Lawyer

Structured fields

→ Position
→ Practice areas
→ Contact information

Gutenberg

→ Biography and editorial content

Custom blocks/patterns

→ How the lawyer is presented on pages

The systems aren’t competing.

They’re working together.

Under the Hood: What Actually Gets Stored?

This distinction matters to developers because the editor UI isn’t the architecture.

Gutenberg content is represented as block markup within WordPress content. Blocks have attributes and can be rendered statically or dynamically, depending on their implementation. The Block Editor provides APIs for registration, metadata, rendering, variations, supports, and other behavior. (WordPress Developer Resources)

A simplified block might conceptually look like:

<!-- wp:paragraph -->
<p>This is some content.</p>
<!-- /wp:paragraph -->

A custom block can have its own attributes and rendering behavior.

A dynamic block can render its final output on the server rather than storing the final HTML as the canonical representation.

ACF takes a different route.

Its fields store additional data associated with WordPress objects. ACF then provides developer APIs for retrieving and rendering those values. (ACF)

ACF also has its own block implementation.

ACF Blocks are not an alternative block editor.

They are custom block types integrated into WordPress’s block system, with ACF providing a PHP-oriented development model and field integration. Current ACF documentation recommends registering ACF Blocks using block.json, and ACF Blocks can use features such as InnerBlocks, block context, variations, and styles. (ACF)

That distinction is important because the old mental model of:

“ACF = old-school fields, Gutenberg = modern blocks”

is too simplistic.

Modern ACF and modern Gutenberg can coexist inside the same architecture.

What About ACF Blocks?

This is where the comparison becomes particularly nuanced.

ACF Blocks allow developers to create custom blocks while using ACF’s field-based development model.

For a PHP-heavy WordPress team, this can be attractive because ACF provides a familiar field and template workflow while still participating in the block editor. ACF describes its Blocks framework as a PHP-based way to develop custom block types without requiring the same JavaScript/React development workflow associated with native block development. (ACF)

That can make sense for certain projects.

But we don’t recommend choosing ACF Blocks simply because they require less JavaScript.

The better question is:

What architecture produces the best long-term result for this project?

There are cases where a native WordPress block is the right abstraction.

There are cases where an ACF Block is appropriate.

There are cases where neither is necessary because an existing core block plus a pattern is sufficient.

And there are cases where a structured field should exist outside the block entirely.

The technology should follow the content model.

ACF vs Gutenberg for Maintainability

This is one of the most important considerations for a business owner.

Your website isn’t finished when it launches.

It may be maintained for five, seven, or ten years.

During that time:

• Employees change
• Marketing teams change
• Developers change
• Branding changes
• WordPress changes
• Business requirements change
• New integrations are added

The architecture needs to survive those changes.

An editor experience that requires a developer for every minor content change creates operational dependency.

But an editor experience that lets users arbitrarily modify the structure of every page can create another form of technical debt.

That’s why we prefer controlled flexibility.

A well-designed custom Gutenberg implementation can allow the marketing team to create and modify content while keeping the site’s underlying design system constrained.

Likewise, ACF can keep structured data explicit and predictable instead of forcing editors to represent application data as free-form content.

The goal is not to minimize developer involvement at all costs.

The goal is to make developer involvement necessary only when the underlying system actually needs to change.

What About Performance?

This is an area where we recommend avoiding simplistic claims.

It would be inaccurate to say:

“Gutenberg is faster than ACF.”

Or:

“ACF makes WordPress slow.”

Neither technology automatically determines the performance of a website.

Performance depends on the complete system:

• Theme architecture
• Plugins
• Queries
• Database usage
• Rendering strategy
• JavaScript
• CSS
• Images
• Third-party services
• Caching
• Hosting
• CDN configuration
• WooCommerce workload
• Content volume

A poorly architected Gutenberg site can perform badly.

A carefully designed ACF-based site can perform extremely well.

The same is true in reverse.

Performance should therefore be treated as an architectural concern rather than a reason to automatically choose one editor technology over another.

The Biggest Architectural Mistake: Treating Everything as Content

One of the patterns we look for when evaluating a WordPress website is whether the content model actually reflects the business.

Imagine an eCommerce company has:

Products

Brands

Locations

Team Members

Case Studies

Services

Blog Posts

If everything is implemented as pages with arbitrary fields and manually constructed layouts, the site may become difficult to query and maintain.

A better architecture recognizes that different information has different behavior.

A Case Study might have structured fields for:

• Industry
• Services provided
• Technologies
• Project type

while still using Gutenberg for the actual narrative.

A Location might have:

• Address
• Phone
• Coordinates
• Hours

while using Gutenberg for descriptive content.

A Service might have:

• Service category
• Related services
• CTA configuration

while Gutenberg handles the editorial presentation.

The result is a WordPress installation that behaves more like a properly modeled application than a collection of pages.

That’s exactly where WordPress becomes much more powerful than the typical “website builder” perception suggests.

When ACF Makes More Sense

ACF remains an excellent choice when you need structured information.

Consider ACF when:

You have clearly defined fields

For example:

Price, SKU, address, phone number, date, status, coordinates.

Those are data points rather than arbitrary page content.

The data needs to be queried

If your application needs to ask:

“Show all locations within this region.”

or:

“Find all properties under $500,000.”

structured data becomes important.

The content model has predictable attributes

If every team member has the same set of attributes, a field group is often more appropriate than letting editors build the structure manually.

The application depends on the data

If information feeds:

• APIs
• Search
• Filters
• Mobile applications
• Integrations
• Automated processes

structured data becomes even more important.

The editing interface needs to be extremely constrained

There are situations where the best editorial experience is essentially a form.

If a user should only enter:

• Name
• Price
• Date
• Image
• Status

there is little reason to provide a full content canvas.

When Gutenberg Makes More Sense

Gutenberg becomes particularly compelling when the content is editorial and compositional.

Consider it when:

Marketing teams create pages frequently

They can compose pages from approved blocks and patterns without requiring a developer.

Content structure varies

A blog article might contain:

• Text
• Images
• Quotes
• Videos
• Tables
• CTAs
• Lists
• Embedded content

A rigid field group can become cumbersome for this type of content.

You want reusable design components

Custom blocks and patterns can provide reusable building blocks while maintaining a consistent visual language.

You want the editing experience to evolve with WordPress

The Block Editor is a core WordPress platform rather than a separate page-builder ecosystem. Its APIs continue to expand around blocks, patterns, templates, styles, and editor customization. (WordPress Developer Resources)

You want controlled visual editing

A carefully configured Gutenberg implementation can provide something between a rigid form and an unrestricted page builder.

That middle ground is often exactly what businesses need.

What We Recommend

For new custom WordPress websites, Boostmonitor generally recommends a Gutenberg-first architecture.

But that does not mean:

“Use Gutenberg for everything.”

It means:

Use Gutenberg for what Gutenberg is good at, and use structured data for what should behave like structured data.

Our typical architecture might look something like this:

WordPress core

The foundation for:

• Content
• Users
• Permissions
• Revisions
• Media
• REST API
• Taxonomies
• Posts

Custom Post Types

For meaningful business entities such as:

• Projects
• Properties
• Locations
• Team members
• Services
• Case studies
• Events

Gutenberg

For:

• Page composition
• Editorial content
• Landing pages
• Blog content
• Marketing sections
• Content-driven layouts

Custom Gutenberg blocks

For components that have:

• A defined purpose
• A specific visual structure
• Controlled settings
• Reusable business value

Block patterns

For frequently used combinations of blocks and predefined layouts.

theme.json

For:

• Typography
• Colors
• Spacing
• Layout constraints
• Editor controls
• Design-system rules

ACF / structured fields

For:

• Business-specific metadata
• Structured attributes
• Application data
• Fields that need predictable querying or validation
• Data associated with Custom Post Types

This isn’t an either/or architecture.

It is a content architecture.

A Real-World Example

Suppose we were building a website for a professional services company.

We might create a Services Custom Post Type.

Each service could contain structured information such as:

• Service category
• Short description
• Featured image
• Related services
• Contact CTA configuration

The main service description, however, could use Gutenberg.

We might then build custom blocks such as:

Service Hero

Benefits Grid

Process

Testimonial

Related Services

CTA

We could create patterns that combine these blocks into common layouts.

And theme.json could define the design system governing:

• Typography
• Colors
• Spacing
• Content widths
• Buttons
• Layout controls

The marketing team could then create a new service page without asking a developer to construct it.

But they also wouldn’t be handed an unrestricted canvas with every possible WordPress control.

They would have a purpose-built editorial system.

That’s the difference.

Maximum Editorial Freedom Does Not Mean Maximum Technical Freedom

This is perhaps the most important principle behind our approach.

A client doesn’t necessarily need the ability to change everything.

They need the ability to change everything they should be responsible for changing.

If a marketing manager changes a headline, that’s content.

If they change an image, that’s content.

If they rearrange a series of approved sections, that’s editorial control.

If they change the site’s underlying spacing system, typography hierarchy, HTML structure, responsive behavior, or data model, that’s usually a development concern.

A good WordPress architecture creates a boundary between those responsibilities.

The editor gets freedom inside the system.

The developer owns the system itself.

That is how you create a website that is both flexible and maintainable.

ACF Isn’t Obsolete. Gutenberg Isn’t the Answer to Everything.

There is a tendency in WordPress discussions to turn technology choices into migrations from “old” to “new.”

That’s rarely useful.

ACF is not obsolete.

Gutenberg is not universally superior.

Native blocks are not automatically better than ACF Blocks.

ACF Blocks are not automatically better than native blocks.

And custom fields aren’t automatically better than blocks.

The correct architectural decision comes from asking:

What does this information represent?

If it’s a structured business attribute, model it as structured data.

If it’s editorial content, let editors compose it.

If it’s a reusable interface component, consider a custom block.

If it’s a common page composition, consider a block pattern.

If it’s part of the design system, control it through the theme and theme.json.

If it’s a business entity, consider a Custom Post Type.

The technology becomes much easier to choose once the underlying problem is correctly defined.

How Boostmonitor Approaches Custom WordPress Websites

At Boostmonitor, we don’t approach a custom WordPress project as:

“Which plugins should we install?”

We start by asking:

“What does the business actually need WordPress to do?”

That distinction affects everything that follows.

We look at:

• Who will manage the website
• What content they will manage
• Which information is structured
• Which information is editorial
• Which workflows need automation
• Which components should be reusable
• Which design decisions should be controlled
• Which data needs to be exposed through APIs
• Which functionality belongs in custom plugins
• How the system needs to evolve over time

From there, the editing experience becomes part of the architecture.

For a modern content-driven website, that often means a Gutenberg-first experience built around custom blocks, patterns, and a controlled design system, complemented by structured fields where they provide a better data model.

That’s how we push WordPress further.

Not by forcing every project into the newest WordPress feature.

Not by adding another plugin because it is popular.

And not by locking clients out of their own websites.

We build the system around the business.

The Bottom Line

So, ACF vs Gutenberg?

For most new custom WordPress websites, we would choose Gutenberg as the primary editorial experience, not because ACF is outdated, but because modern Gutenberg provides a strong foundation for controlled, reusable, block-based content editing.

Then we’d use ACF or other structured data mechanisms where the business actually needs fields.

The important distinction is this:

Gutenberg should manage composition.

Structured fields should manage structured data.

Custom Post Types should model meaningful business entities.

Custom blocks should encode reusable interface components.

Block patterns should simplify common page compositions.

theme.json should help enforce the design system.

When those pieces are designed together, WordPress stops being just a CMS with an editor.

It becomes a flexible application platform with an editorial experience designed around the people who actually use it.

And that’s the real goal.

Don’t give your team more control than they need. Give them better control over what matters.

Frequently Asked Questions

Is Gutenberg better than ACF?

Neither is universally better.

Gutenberg is generally better suited to composing editorial content and page layouts, while ACF is particularly useful for structured data and custom fields.

For many custom websites, using both produces a better architecture than choosing one exclusively.

Is ACF still relevant?

Absolutely.

ACF remains highly relevant for structured content, Custom Post Types, business-specific fields, and situations where editors need a controlled form-based interface.

ACF also provides ACF Blocks, which integrate custom fields with WordPress’s block system. (ACF)

Can Gutenberg replace ACF?

Not completely.

Gutenberg can handle a tremendous amount of editorial functionality, but that doesn’t mean every piece of business data should be represented as block content.

If an application needs predictable, structured values such as price, location, status, coordinates, or other attributes, structured fields may still be the better model.

Should I use ACF or custom Gutenberg blocks?

That depends on what you’re building.

If the component is primarily a reusable visual/editorial component, a custom Gutenberg block may be appropriate.

If the component needs structured fields and a PHP-oriented development workflow, an ACF Block may make sense.

If the information is actually metadata belonging to a business entity, it may be better represented as fields on a Custom Post Type rather than as a block at all.

Is Gutenberg suitable for custom WordPress websites?

Yes. In fact, Gutenberg can be an excellent foundation for custom WordPress websites when the editor is deliberately curated.

Custom blocks, patterns, theme.json, block locking, templates, and other Block Editor APIs allow developers to build controlled editing experiences rather than simply handing users an unrestricted canvas. (WordPress Developer Resources)

Can clients edit Gutenberg websites without a developer?

Yes—and that should be one of the objectives of a well-designed implementation.

The key is not to give clients unlimited control.

A properly architected Gutenberg website gives them the controls they need to manage content while protecting the underlying design system and technical architecture.

That’s the difference between editorial freedom and technical freedom.

A good custom WordPress website should provide the first without requiring the second.