WordPress Page Builder Flood is a Problem You Can’t Ignore

The WordPress page builder flood is accelerating faster than most of us can test it. Etch, Builderius, Mosaic, Clutch, Unblock, and a growing pile of block editor extensions all want a piece of the same market. WordPress did not need another hundred widgets, but that is not what this wave is selling.

The pitch has changed. These tools are selling cleaner HTML, class systems, design tokens, dynamic data, reusable components, code access, safer deployment, and AI that can work with the page instead of merely writing filler copy for it. The target is no longer just the business owner who cannot code. It is the developer, freelancer, and agency builder who knows enough CSS to be annoyed by the old tools.

That makes the WordPress page builder flood worth watching. But it doesn’t make every new builder ready for client work.

The 2026 WordPress Page Builder Dataset

I checked 15 builders and block systems against official changelogs, WordPress.org records, and public release pages on July 28, 2026. Eight had changed since the earlier article snapshot. That release velocity is useful evidence, but it is not the same thing as production readiness.

BuilderObserved versionChannelActive installsChange vs article
Etch1.6.3stableNot on WordPress.orgchanged since article
Builderius1.3.5-betastable100matches or expands article
Mosaic1.0.5stableNot on WordPress.orgmatches or expands article
Clutch1.446.1betaNot on WordPress.orgmatches or expands article
GenerateBlocks2.3.0stable200,000matches or expands article
Blockera1.12.2stable100matches or expands article
Greenshift13.1.4stable70,000changed since article
Kadence Blocks3.7.8.1stable600,000changed since article
Spectra familyLegacy 2.20.0; Blocks 1.0.2stable1,000,000changed since article
Stackable3.19.10stable100,000matches or expands article
Unblock1.0.0-beta.7betaNot on WordPress.orgchanged since article
Elementor4.2.0stable10,000,000changed since article
Bricks2.3.9 stable; 2.4-beta2stable_and_betaNot on WordPress.orgchanged since article
Divi5.9stableNot on WordPress.orgmatches or expands article
Beaver Builder2.11.0.1stable100,000changed since article

W3Techs separately estimated Elementor on 31.5% of WordPress sites, Beaver Builder on 1.0%, Bricks on 0.3%, and Divi Builder on 0.1%. Those crawl-based shares and WordPress.org active-install counts use different populations, so I do not combine them.

This WordPress Page Builder Flood Is Different

The new wave is different because it starts with the professional workflow, not the beginner’s widget panel. Etch, Builderius, and Mosaic build inside WordPress, while Clutch takes an adjacent Next.js route. They still return to the same ideas: real web primitives, global systems, reusable components, dynamic content, and fewer trips between disconnected screens.

Class-first styling is the turning point. A builder becomes maintainable when it stops treating every element as a unique snowflake and starts treating a website as a system.

That sounds like a small distinction until you inherit a 200-page site. Per-element sliders feel fast on page one. By page 50, they become a search operation: which button has the correct padding, where did that color come from, and why does the tablet breakpoint behave differently on this one template?

Classes, variables, components, and design tokens reverse that relationship. The first page takes more thought. The fiftieth page becomes easier because the decisions already exist. Bricks proved there was a serious WordPress audience for that approach. The newer builders are taking the same demand and pushing it toward code access, data modeling, deployment, and AI.

WordPress page builder flood market map showing established builders, new visual development environments, and Gutenberg-native extensions
The page-builder market is splitting into three lanes, and each one solves a different workflow problem.

15 WordPress Builder Releases and Status Changes

The WordPress builder market is moving on three fronts: new products are filling out core workflows, Gutenberg plugins are splitting into old and new product lines, and established builders are shipping new design-system and AI features.

Product familyCurrent public releaseKey release detail
Etch1.6.2, stableJuly 8: taxonomy editing, loop editing, and asset-manager changes
Builderius1.3.5, betaStatic export and Remote Sync shipped; History and Undo plus visual CSS Grid remain in progress
Mosaic1.0.5, stableJuly 7: ACF support, interactions, style variables, conditions, and editor controls
Clutch1.446.1, betaJanuary 14 beta for a visual Next.js platform, not a WordPress page builder
GenerateBlocks2.3.0, stableSecurity hardening, direct CSS support for Pro tools, and media-toolbar changes
Blockera1.12.2, stable200+ installs; last public release July 2025; Pro still described as in development
Greenshift13.1.2, stableCurrent AI work includes dynamic template generation and updated model support
Kadence Blocks3.7.8, stableJune 29 security and capability hardening; 600,000 active installations
Spectra familyLegacy 2.20.0; Blocks 1.0.0Legacy is maintenance-only; new development moved to the separate Blocks plugin
Stackable3.19.10, stableEndpoint hardening, API-key masking, integration fixes, and saving improvements
Unblock1.0.0-beta.6, betaOne block maps to one HTML element, with visual conditions and expression operators
Elementor4.1.5, stableDesign System panel, transferable classes and variables, and Angie Atomic editing
Bricks2.3.9, stable; 2.4, betaStable maintenance plus beta AI Abilities, MCP, Builder Browser, and design-system transfer
Divi5.9, stable65 fixes and improvements plus variable fonts and the CSS Grid Editor
Beaver Builder2.11, stablePopups, global-color work, Font Library support, accessibility, attributes, and performance changes

Three New WordPress Builders and One Adjacent Platform

Etch, Builderius, and Mosaic are the three new WordPress builders I would watch most closely. Clutch belongs nearby because it can use WordPress as a content source, but it is primarily a visual Next.js development platform. Treating all four as direct page-builder alternatives hides the most important architectural difference.

ProductCore ideaWhere it livesCurrent caution
EtchProfessional visual development that authors Gutenberg blocksInside WordPress, with its own development environmentMy hands-on testing stopped at 1.5.0
BuilderiusHTML, CSS, dynamic data, versioning, deployment, and AIInside WordPress as a builder and templating layerStill beta, with major workflow features unfinished
MosaicTheme builder, visual editor, and class-based design systemInside WordPress as a unified site-building systemAccessibility and key integrations remain roadmap work
ClutchVisual Next.js development with components, agents, and data sourcesOutside the traditional WordPress theme layerAdjacent platform, not primarily a WordPress page builder
Comparison matrix showing Etch, Builderius, Mosaic, Clutch, and Unblock across native output, design systems, dynamic data, deployment, and platform category
Three WordPress builders, one adjacent platform, and one Gutenberg-native beta share tools without belonging to one product category.

Etch Wants WordPress Development to Feel Like One System

Etch launched its production line in January 2026. Its pitch is not “Elementor with fewer wrappers.” Etch wants the development environment, WordPress content architecture, and client editing experience to speak the same language.

  • It exposes HTML and CSS instead of hiding them behind proprietary controls.
  • It lets builders work with selectors, classes, components, custom post types, custom fields, loops, and templates in one environment.
  • It authors the result to Gutenberg blocks so clients can edit content in the native block editor.
  • Its experimental Etch Intelligence layer works with the site’s structure and code.

That architecture is interesting because it separates building from editing without creating two unrelated versions of the page. The professional gets the deeper environment. The client gets blocks and guardrails.

Etch’s July 8 release added taxonomy editing, better loop editing through Etch Intelligence, and asset-manager changes. My hands-on experience ends at version 1.5.0. Etch requires an Index Template, which acts as the fallback when no more specific template matches.

Builderius Treats Versioning as Part of the Builder

Builderius visual editor showing the inserter, page canvas, and navigator panels
Builderius combines its visual canvas with development-oriented inserter and navigator panels.

Builderius is the most development-tool-shaped product in this group. It combines semantic HTML, visual CSS controls, a code editor, variables, components, dynamic data, GraphQL, conditions, and an unusual feature for a WordPress builder: development and production branches.

You can save named releases, switch between development and live states, compare alternative versions, roll back, and move Builderius work between sites. That matters because page building is not only a design task. It is also change management, and WordPress builders have traditionally pushed that responsibility onto staging plugins, hosts, and a developer’s memory.

Builderius remains in beta. Its July releases added static exports to ZIP files, GitHub Pages, and Cloudflare Pages, followed by Remote Sync and taxonomy export. History and Undo plus visual CSS Grid controls remain in progress. Gutenberg integration, collaboration, and the marketplace remain planned.

I wouldn’t standardize a client workflow around Builderius while it remains in beta.

Mosaic Combines the Theme, Builder, and Design System

Mosaic Builder walkthrough covering its site-building workflow.

Mosaic’s argument is simple: WordPress themes, page builders, and supporting plugins each solve part of the workflow, but the pieces do not fit cleanly. Its answer is one class-based system containing the theme builder, visual editor, dynamic data, conditional logic, interactions, and design tokens.

Mosaic 1.0.5 added broader style variables, ACF support, interactions, Gutenberg Styles, improved conditions, semantic lists and accordions, and editor visibility controls. Accessibility work is in progress. WooCommerce is next, while the Gutenberg Block Builder remains in the backlog without a confirmed date.

Clutch Is an Adjacent Next.js Platform

Clutch interface connecting WordPress, n8n, Contentful, and Google Maps to a personalized web experience
Clutch treats WordPress as one external data source in a wider Next.js workflow.

Clutch is not primarily a WordPress page builder. It is a visual Next.js development platform built around components, agents, MCP, and external data sources. WordPress can supply content, but it is only one possible backend.

Clutch remains in beta.

When you use WordPress behind a separate Next.js front end, you may remove some theme and plugin limitations, but headless is not a free performance button. You now own a deployment pipeline, preview behavior, caching, forms, search, redirects, SEO rendering, and every integration that assumed PHP would render the page. A traditional builder problem can quietly become an infrastructure problem.

Treat Clutch as an application architecture choice, not a Beaver Builder alternative.

Gutenberg Has Its Own Page-Builder Flood

The second flood is happening inside Gutenberg. GenerateBlocks, Blockera, Greenshift, Kadence Blocks, Spectra, Stackable, and Unblock all extend the native editor, but they make different bets about how much interface and abstraction WordPress needs.

This route has one structural advantage: the content stays in WordPress’s block model. You are extending the editor rather than replacing it with a parallel application. That does not eliminate plugin dependency, but it usually gives content a better chance of surviving a theme change or a tooling rethink.

GenerateBlocks is still my default for this approach. It gives me a small set of layout primitives, global styles, patterns, queries, and increasingly capable site-building blocks without turning the editor into a widget warehouse. I have used it since its 2020 launch and built hundreds of pages with it.

Blockera works as an advanced mode for the block editor. It adds responsive controls, block states, advanced styling, and inner-block customization to core blocks. Its public plugin footprint is still small: 200+ active installations, an older July 2025 public release, compatibility declared only through WordPress 6.8.5, and a Pro product still described as in development.

Greenshift pushes further into animations, interactions, dynamic content, full-site building, and AI-assisted dynamic templates while conditionally loading assets.

Kadence Blocks and Stackable represent the mature earlier wave. They proved that many users wanted page-builder controls without leaving Gutenberg. My Gutenberg blocks plugin guide covers that field in more detail. The short version is that more blocks do not automatically create more freedom. A focused system beats a 90-block menu you will never fully learn.

Spectra Legacy and Spectra Blocks Are Separate Product Lines

Spectra now consists of two product lines. Spectra Legacy maintains the original plugin for existing websites. Spectra Blocks is the actively developed rebuild launched in July 2026. Existing sites do not automatically carry every global color, typography setting, block default, or custom CSS assumption into sections rebuilt with the new plugin.

Spectrum separating Spectra Legacy from Spectra Blocks and placing GenerateBlocks, Kadence, Stackable, Greenshift, Blockera, and Unblock by control level
Spectra Legacy and Spectra Blocks are separate product lines; placement on the control axis is qualitative, not a benchmark.

Count Systems, Not Blocks

A block collection gives you more things to insert. A page-building system gives you repeatable classes, components, responsive rules, patterns, and guardrails. Count systems, not blocks.

Unblock Gives You HTML-Level Control in Gutenberg

Unblock is technically ambitious and still beta. I have it installed on anantamias.com, but I wouldn’t use it for client production yet.

Unblock’s documentation describes it as beta and relatively raw, while its About page calls the core stable and production-ready. Its core idea is direct: one block maps to one HTML element. A Section can render a <section>. A Group can be a <div>. Blocks can receive any valid tag, class, data attribute, ARIA attribute, custom CSS, JavaScript interaction, condition, or dynamic expression.

Annotated diagram showing how Unblock maps one Gutenberg block to one HTML element with attributes, CSS, dynamic data, and inspectable output
Unblock keeps the Gutenberg block model close to the web platform.

In other words, Unblock does not try to protect you from the web platform. It puts HTML, CSS, and data binding inside Gutenberg. If you know what you are doing, that is liberating. If you do not, you now have enough freedom to create an inaccessible, inconsistent mess without ever opening a code editor.

The AI assistant is what makes the experiment timely. You can describe a result and let the assistant write CSS, attributes, and expressions. That lowers the syntax barrier, but it does not remove the need for judgment. AI can generate an ARIA attribute. It cannot guarantee that your interaction makes sense to a keyboard user or that the resulting component belongs in your design system.

I would use Unblock locally to learn where Gutenberg can go. I wouldn’t hand it to a client team because the current interface still expects a technically confident operator.

Elementor, Bricks, Divi, and Beaver Builder Are Not Standing Still

The old guard still owns the installed base, and it is rebuilding around the same ideas the newcomers promote. Elementor, Bricks, Divi, and Beaver Builder are all shipping current releases. They move at different speeds, but none can fairly be described as dormant.

A GravityKit analysis of the April 2026 HTTP Archive crawl found Elementor on 32.67% of WordPress origins in its sample. The native Block Editor appeared on 20.62%, Divi on 5.72%, Beaver Builder on 1.11%, and Bricks on 0.34%. Those detections overlap, so they are not slices of one neat market-share pie.

Horizontal bar chart showing April 2026 WordPress page builder detection rates for Elementor, the Block Editor, Divi, Beaver Builder, and Bricks
These are overlapping detection rates, not slices of one market-share pie.
  • Elementor now centers its Atomic line on a Design System panel, transferable classes and variables, and Angie editing for layouts, components, forms, classes, and variables.
  • Bricks keeps improving components, Gutenberg integration, WooCommerce, forms, rendering, and design-system transfer. Its current beta also introduces AI Abilities through the WordPress Abilities API and MCP.
  • Divi 5 is now on a weekly release cadence after leaving beta, with recent work covering variable fonts, a visual CSS Grid editor, and dozens of fixes. Divi AI Agent remains in development.
  • Beaver Builder remains the conservative option, but its current release adds popups, global-color improvements, WordPress Font Library support, accessibility work, custom attributes, performance changes, and AI design-system hooks.

Bricks is the most useful signal in the numbers. It recorded 71.2% year-over-year growth in detected origins. Its measured share increased by 0.15 percentage points, from 0.19% to 0.34%. The detections can overlap, so they are not mutually exclusive shares that must total 100%. The absolute Bricks share is still small, but the growth shows that developers will accept a steeper learning curve for cleaner output, classes, components, and control.

Elementor’s response matters even more because of its scale. Variables, classes, components, and an atomic editor are not niche developer vocabulary anymore. They are becoming the baseline language of mainstream WordPress building. Divi 5 tells a similar story from another direction: legacy products need architectural rewrites to compete with tools that start fresh.

Timeline showing Beaver Builder 2.11, Bricks 2.3.9 stable and 2.4 beta, Divi 5.9, and Elementor 4.1.5 releases from July 7 to July 15
Five releases in nine days show active development across established builders; stable and beta releases are labeled separately.

What the New Builders Are Actually Changing

The new builders are changing workflow expectations, not WordPress market share. Their shared enemy is the fragmented process of building a site across a theme panel, builder, custom-fields plugin, code-snippet plugin, staging system, media library, and half a dozen admin screens.

Annotated diagram of a modern WordPress builder showing design tokens, components, dynamic data, output, versioning, and client editing
Modern builders compete on the complete site-production workflow, not only the visual canvas.

They Are Attacking Proprietary Abstraction

Older builders often created a private language for the web. You learned the builder’s section model, its responsive controls, its widget hierarchy, and the places where custom CSS was allowed to leak through. The new tools keep pointing back to HTML elements, CSS properties, selectors, variables, and components.

That does not eliminate lock-in. A Builderius release, Mosaic component, Etch recipe, and Clutch project are still product-specific objects. But skills transfer better when the interface maps to web standards. Learning flexbox in a builder should make you better at flexbox everywhere else.

They Are Turning Styling Into a System

Design tokens, classes, variables, and components appear in nearly every serious product now. This is not feature-list coincidence. Per-element styling fails at scale, and every builder eventually discovers the same math.

Suppose a site has 40 button instances and each one stores five local design decisions. That is up to 200 small values to keep consistent. A shared component turns those 200 decisions into a handful of controlled properties. The point is not that components are fashionable. The point is that they reduce variance.

They Are Making Dynamic Data Normal

Custom post types, fields, loops, conditions, and queries used to separate a basic page builder from a developer tool. Etch, Builderius, Mosaic, Bricks, and Unblock now treat dynamic data as part of the normal visual workflow.

A freelancer can build a five-page brochure site with almost anything. The harder work is a property directory, course catalog, documentation library, membership site, or WooCommerce store where one template needs to render hundreds of structured entries safely.

AI Is Becoming a Builder Interface

AI features are moving beyond one-click layout generation. Elementor lets Angie edit Atomic layouts and design-system values. Etch Intelligence can update existing loops. Greenshift can generate dynamic templates. Bricks is testing AI Abilities through the WordPress Abilities API and MCP. These features still operate inside vendor-specific systems, so they do not solve builder lock-in.

The useful version of this is translation. You describe the layout or behavior, the tool produces standards-based HTML and CSS, and you can inspect the result. The dangerous version hides a growing pile of generated decisions behind a friendly prompt box. AI is a speed tool. It still is not a taste tool, an accessibility expert, or an exit plan.

WordPress core is moving in the same general direction. The official 2026 roadmap includes responsive styling controls, expanded block tools, Phase 3 collaboration workflows, and AI with project-wide guardrails. That gives Gutenberg extensions a stronger base, but it also raises the bar for builders that replace the native experience.

More Choice Creates a New Kind of Lock-In

Cleaner HTML does not automatically mean a low-risk platform. The new lock-in is less likely to look like a page full of dead shortcodes. It can look like a team that only knows one workflow, a component library that cannot travel, a hosting setup tied to one vendor, or a client who cannot edit anything without calling the original developer.

Export Is Not Interoperability

No builder here offers a documented, supported, lossless migration path that preserves layouts, responsive rules, dynamic data, interactions, and design tokens across products. The popular tools do have import and export features, but those features keep you inside the same ecosystem:

That is portability within a product, not interoperability between products. None of these tools translates an Elementor page into Bricks, a Divi layout into Gutenberg, or a Beaver Builder template into Etch. Components, classes, responsive rules, conditions, queries, forms, and dynamic templates remain builder-specific.

Diagram showing that same-product template export does not translate components, classes, breakpoints, or dynamic data into another WordPress page builder
Same-product export is portability within a builder, not interoperability between builders.

The new page builders are no different. Etch writing to Gutenberg may preserve more editable content. Cleaner HTML may reduce the pain of rebuilding. Builderius can move Builderius work between sites. Those are useful improvements, but they do not create a cross-builder migration path.

So choose a builder as if you will use it for the working life of the site. If you leave, expect to pay for a manual migration: rebuilding templates, translating the design system, recreating dynamic behavior, retraining editors, and testing every important page again. The WordPress page builder flood makes trying another tool feel cheap. It does not make leaving one cheap.

Six-part WordPress page builder migration workflow covering inventory, templates, design systems, dynamic data, editor training, and regression testing
The real migration bill is the manual reconstruction around the content.

I would check eight things before using any new WordPress page builder on production:

  1. Content storage: What remains if the builder is deactivated?
  2. HTML output: Are the elements semantic, accessible, and reasonably shallow?
  3. Style ownership: Can you use classes, variables, and a global design system?
  4. Dynamic data: Can templates, loops, conditions, ACF fields, and custom post types work without fragile glue?
  5. Rollback: Can you safely reverse a bad deployment or builder update?
  6. Client editing: Can a non-developer change content without entering the development environment?
  7. Support and hiring: Are documentation, integrations, support, and skilled implementers available?
  8. Migration and exit path: What exactly must be rebuilt if you switch builders or the company disappears?

Products fail. Teams change direction. Founders sell companies. WordPress core changes. A good tool can still be the wrong foundation if leaving it means rebuilding the business under pressure.

Do Not Test a Builder With a Hero Section

Rebuild one production-style page with a query loop, custom fields, responsive states, forms, accessibility requirements, and a client-editing handoff. Pretty cards reveal almost nothing about long-term maintenance.

What I Would Use on a Production Site Today

For a content-heavy site I own, I would still start with the native block editor, GenerateBlocks, and a controlled set of custom or ACF blocks. That stack is not the most exciting option in 2026. It is the one I know I can maintain, measure, and hand over without turning the content into a hostage.

For advanced client sites, I would choose an established builder based on the team’s skills and the site’s maintenance model. Bricks makes sense for a developer-led, class-first workflow. Elementor makes sense when add-ons, templates, and hiring flexibility matter more. Beaver Builder makes sense when stability and client predictability win. Divi 5 deserves fresh evaluation because it is no longer the same technical product Divi 4 was.

I would test Etch, Builderius, Mosaic, and Unblock on local or staging sites, one at a time. I would evaluate Clutch separately as a Next.js platform that can consume WordPress data. In either case, rebuild a page that already exists, inspect the output, model dynamic content, test responsive behavior, hand it to another editor, and then remove the tool to see what survives.

Six-step process for testing a WordPress page builder with a real page, output inspection, dynamic data, responsive behavior, editor handoff, and deactivation audit
Test the complete workflow and exit path before committing to a WordPress page builder.

Frequently Asked Questions

What are the newest WordPress page builders in 2026?

Etch, Builderius, and Mosaic are three notable new WordPress builders in 2026. Clutch is an adjacent visual Next.js platform that can use WordPress as one data source, so it should not be treated as a direct fourth page-builder alternative.

Is Etch ready for production websites?

Etch calls its current line production-ready, but my hands-on experience ends at 1.5.0. Test your custom fields, loops, breakpoints, plugin stack, and client-editing workflow before using it on an important site.

Is Builderius still in beta?

Builderius is still beta. Static export and Remote Sync have shipped, while History and Undo plus visual CSS Grid remain in progress. I wouldn’t standardize it for client work until the beta ends and the unfinished workflow features ship.

Does Mosaic work inside Gutenberg?

Mosaic is a WordPress theme builder and visual development system. Its Gutenberg Block Builder remains in the backlog without a confirmed date, so treat Mosaic as its own integrated environment today, not as a finished Gutenberg extension in the same category as GenerateBlocks or Greenshift.

Is Unblock ready for client sites?

I wouldn’t standardize Unblock for client production yet. Its documentation describes a beta and relatively raw HTML, CSS, JavaScript, and data-binding engine, while its About page calls the core stable and production-ready. Use it locally or on staging until the release status and client-facing workflow are clearer.

Will Gutenberg replace Elementor and other page builders?

Gutenberg will replace some page-builder use cases, especially content-heavy sites and controlled design systems. Elementor, Bricks, Divi, and Beaver Builder will remain relevant where teams need faster visual production, mature add-on networks, complex templating, or familiar client workflows. The likely future is hybrid, not winner-takes-all.

The builder that wins will not be the one with the loudest launch, the largest widget count, or the cleverest AI demo. It will be the one that becomes boring infrastructure: clean enough for developers, constrained enough for clients, and stable enough that nobody has to think about it after the site ships.

Until then, keep your production stack boring and your staging site curious.

Disclaimer: This site is reader-supported. If you buy through some links, I may earn a small commission at no extra cost to you. I only recommend tools I trust and would use myself. Your support helps keep gauravtiwari.org free and focused on real-world advice. Thanks. - Gaurav Tiwari