We have been building with Gutenberg since its early days, long before the block editor developed into the broader system it is today. Over that time, we have watched WordPress move steadily from blocks as a way to compose page content toward blocks as part of the architecture of the entire website.
We recently completed two more rebuilds that reinforced why we continue to take this approach. One was for a professional services company with a large amount of editorial and thought-leadership content. The other was for a product company where products, specifications, categories, downloads, related information and other structured content needed to work together across a much larger publishing system.
The businesses were different, but the architectural question was almost identical: how do you give an organization flexibility today without creating a WordPress implementation that becomes difficult to change tomorrow?
For many projects, our answer is to stay as close as practical to WordPress Core and build around native blocks, structured content, reusable patterns and a controlled design system.
That does not mean every website should use the same architecture. Page builders have legitimate uses. Traditional custom themes can still be very effective. Fully decoupled or headless WordPress can be the right solution for more complex digital platforms.
But if WordPress is going to remain the primary CMS and publishing platform, native blocks increasingly provide the most direct path between what WordPress is today and where the platform is going next.
Gutenberg is no longer just a content editor
When Gutenberg first appeared, much of the conversation was about editing. Could blocks replace the Classic Editor? Would authors like the new interface? How should developers create custom blocks?
Those questions made sense at the time. They no longer describe the full system.
WordPress now defines block themes as themes that use blocks throughout the site, including navigation, headers, content areas and footers. Templates and template parts can be block-based. Global design decisions can be managed through theme.json. Patterns can define reusable compositions. Dynamic information can be connected to blocks through the Block Bindings API. Interactive components can increasingly use WordPress’s native Interactivity API.
In other words, blocks have become part of the platform architecture rather than simply the editing experience. WordPress describes block themes as themes built with blocks across all parts of the site, while its developer documentation describes theme.json as the canonical mechanism for defining Block Editor settings and styles.
That is one of the main reasons we treat Gutenberg differently today than we did during its first releases.
We are not simply asking whether an editor can build a page with blocks. We are asking how much of the website can share one consistent system for content, components, templates, styling and interaction.
What makes a Gutenberg build more future-ready?
Future-ready does not mean that a website will never need redevelopment. There is no architecture that can make that promise.
The practical goal is to reduce unnecessary dependencies and make future changes less destructive.
A native block implementation can separate several layers that traditionally became intertwined in a WordPress theme: content, layout, design tokens, component behavior and application logic. When those concerns are deliberately structured, a redesign does not necessarily require rebuilding the content model, and a content change does not have to change the design system.
That separation gives teams more options later.
A component can evolve without rewriting every page where it appears. Global typography can change without manually updating individual modules. Structured product information can be rendered differently without changing the underlying product record. A pattern can change while the content inside it remains useful.
Future flexibility comes from those boundaries, not from the visual block interface itself.
Why theme.json matters more than it appears to
One of the most important changes in modern WordPress development is also one of the least visible to someone publishing a page.
theme.json provides a native configuration layer for design settings and styles. WordPress uses it to define things such as typography, color, spacing, layout behavior and which controls are exposed to editors. These settings can be established globally and, where needed, configured for individual block types.
For us, this solves an important problem.
Editors need flexibility, but they generally should not be responsible for maintaining the design system.
A marketing team may need to create a new service page, change the order of sections, introduce a callout, select another approved pattern or update imagery. They should be able to do those things without calling a developer.
They probably should not be choosing arbitrary font sizes, introducing slightly different container widths or deciding that one page needs 43 pixels of spacing where the rest of the website uses a defined scale.
Those decisions belong to the system.
A well-built Gutenberg implementation therefore does not give editors unlimited design freedom. It gives them structured flexibility.
WordPress’s own documentation makes this distinction possible at a technical level. theme.json can expose, restrict and define settings globally or at the block level, allowing developers to curate the editing environment rather than simply opening every available control.
That is particularly valuable for enterprise web design, where consistency tends to become harder—not easier—as more people publish content.
The professional services use case: flexible composition
The professional services rebuild was primarily an editorial problem. A professional services organization may have service pages, industries, insights, people, case studies, locations and other content types, but those elements do not always appear in exactly the same sequence.
One service may need supporting case studies and subject matter experts. Another may rely heavily on editorial content. An industry page may need statistics, related capabilities and a different call to action.
Historically, there were two common ways to handle this. Developers could create a growing collection of rigid templates, or a visual builder could give editors a large amount of control over page composition.
Native blocks give us another option. We can define the design systems of the UI/UX as a component system and allow editors to compose approved components according to the needs of the content.
The flexibility exists at the composition level, while typography, responsive behavior, spacing, accessibility and component logic stay controlled. This is much closer to how we already think about a design system. The website is not a collection of independently designed pages. It is a collection of reusable rules and components that can produce many different pages.
The product use case: structured content first
The product-company rebuild had almost the opposite challenge. Here, too much layout freedom would have been a problem.
Products have relationships. They may belong to categories or families and contain specifications, documentation, certifications, imagery, downloads and related products. The content needs to be predictable enough that it can be searched, filtered, reused and maintained.
The important architectural principle is therefore to avoid turning product data into page layout whenever possible.
A specification should remain a specification. A product category should remain structured taxonomy. A downloadable technical document should remain an identifiable data relationship rather than simply becoming a button manually added to a page.
Blocks become the presentation layer for that information. The Block Bindings API is especially relevant to this direction. WordPress describes Block Bindings as a way of connecting dynamic data to block attributes so that the data is reflected in the final markup produced on the front end.
That sounds technical, but the benefit is straightforward: content can remain data while the block decides how that data is presented.
That separation becomes increasingly important as a website grows.
Are Gutenberg blocks better than Elementor or WPBakery?
The more useful question is not whether Gutenberg is universally “better.” It is whether adding another page-building platform provides enough value to justify another architectural dependency.
Elementor, WPBakery and similar tools solved a real WordPress problem. They gave teams sophisticated visual composition capabilities before WordPress Core offered a comparable block-based model, and there are still projects where that convenience is valuable.
The tradeoff is that a page builder introduces another system.
The site now depends on WordPress, the theme, the builder’s layout and component model, and often an ecosystem of builder-specific extensions. Custom modules may depend on APIs unique to that builder. Content and presentation can become more closely coupled to the builder’s markup and data structures.
None of that automatically makes a site poorly built or slow. Performance depends heavily on implementation, and it would be misleading to claim that every native Gutenberg site outperforms every page-builder site.
The architectural difference is simpler. With a native-block approach, our component model is closer to the component model WordPress itself maintains. That means there is one less major abstraction between the CMS and the website. Over a long lifecycle, that matters.
What happens when WordPress itself changes?
This is where staying close to Core becomes especially important. WordPress has continued to expand the block architecture beyond page composition. Block themes extended blocks into templates and site structure. theme.json consolidated design settings. Block Bindings created a native connection between blocks and dynamic data.
The Interactivity API is another important step.
Introduced into WordPress Core in version 6.5, the Interactivity API gives developers a standardized way to add front-end interactions to blocks. WordPress already uses it in Core blocks including Navigation, Search and Query. It supports shared state, actions and communication between interactive blocks.
This matters because modern websites increasingly need behaviors that sit somewhere between traditional server-rendered pages and full JavaScript applications.
Search interfaces, filters, navigation states, carts, accordions, dynamic results and other interactions no longer automatically require every development team to create an unrelated JavaScript architecture.
WordPress is establishing its own standards for those behaviors. That is another reason we prefer not to introduce additional frameworks unless the project actually needs them.
Is headless WordPress more future-proof?
Headless WordPress can be extremely flexible, but it solves a different problem. In a traditional WordPress architecture, the CMS manages the content and renders the website. In a headless or decoupled setup, WordPress typically manages the content while another application controls the front end.
That front end might be built in Next.js, React or another application framework and consume WordPress content through REST, GraphQL or another API layer.
There are very good reasons to do this.
An organization may need the same content distributed to several applications. The website may contain application-level functionality that is better handled outside a traditional theme. A product platform may need a front-end release cycle independent of the CMS. An engineering organization may already have a mature JavaScript application infrastructure.
In those situations, headless WordPress can be a strong architecture. But headless does not mean complexity disappears.
It usually means the organization is maintaining at least two application layers: the CMS and the front-end application. Preview behavior, routing, caching, authentication, deployment, search, plugin compatibility, forms and other capabilities that are closely connected in traditional WordPress may need separate solutions.
The flexibility is real, but so is the operational cost. That is why we do not see headless as the automatic “advanced” version of WordPress. It is an architectural choice that should have a reason.
Does a native block build make headless harder later?
Not necessarily. In many cases, good block architecture can preserve options rather than remove them. The key is how the content is modeled.
If important business information is stored as structured content, taxonomy, metadata and relationships rather than being buried entirely inside presentation markup, that information can be exposed through APIs later.
A future application does not necessarily need to reproduce the WordPress front end. It can consume the underlying content differently.
This is one reason the product-company example is particularly useful. We want product data to have meaning independent of the page on which it happens to appear.
Today, WordPress can manage and render that experience. Tomorrow, the same organization may need some of that data inside a dealer portal, customer application, configurator, or another interface. It may also need to move into an enterprise-grade WordPress environment such as WordPress VIP as traffic, governance, security, or operational requirements grow. A well-structured native build keeps those options open without forcing the organization to rethink the entire content and component model.
Native does not mean using only Core blocks
This is another misconception around Gutenberg.
Building natively does not mean restricting a sophisticated website to the blocks that ship with WordPress.
We build custom blocks when the project needs them.
The important distinction is that those components participate in the WordPress block architecture rather than creating a completely separate editing architecture.
A custom block can have its own attributes, rendering logic, data sources, styles and behavior. It can be dynamic. It can communicate with other blocks. It can use structured WordPress data. It can inherit the site’s design tokens and respond to global settings.
The objective is not to avoid custom development.
It is to make custom development part of the platform rather than something sitting beside it.
Why does this matter?
Most architectural decisions are easy to live with during launch. Their value becomes clearer later.
The organization introduces another service. A product line grows from 40 items to 400. Brand typography changes. Accessibility requirements evolve. A marketing team wants new landing-page combinations. Another system needs product data. WordPress introduces a new capability. A plugin is replaced. A redesign begins.
That is when coupling becomes expensive.
If content, layout, styling and proprietary page-builder structures are tightly connected, a change in one layer can force changes throughout the site.
If those layers have clearer boundaries, more of the system can evolve independently.
This is why we think the strongest WordPress architecture is not the one that gives someone the most visual controls on launch day.
It is the one that creates the fewest unnecessary restrictions on what the organization may need to do next.
Gutenberg is becoming an application architecture for WordPress
After working with Gutenberg since its early development, that is probably the biggest change we have seen.
The conversation used to be about blocks replacing the editor.
Today we are using blocks as components, theme.json as part of the design-system layer, patterns as reusable compositions, Block Bindings as connections to structured data and the Interactivity API for richer front-end behavior.
Those pieces are increasingly connected.
For the professional services rebuild, that architecture created controlled editorial freedom without requiring a new template every time the content changed.
For the product-company rebuild, it gave us a way to keep structured product information separate from the components used to display it.
Neither site is “future-proof” because of Gutenberg alone.
They are better prepared for change because the architecture reduces unnecessary dependencies, keeps important content structured and builds on capabilities that are part of WordPress itself.
That is the real advantage of building close to Core.
For a platform that will continue to evolve, the most flexible foundation is usually the one that does not fight the direction of the platform.