Welcome to our refreshed Planted Sky site. We'll share the full story soon.

Read the update
(708) 825-7492 Book a Strategy Call

WordPress Builder Guide

Choosing a WordPress page builder, and using it without ruining the site.

The WordPress builder landscape has more options than anyone needs, and most of them encourage habits that quietly degrade your site over time. Here is how we evaluate the main contenders, the philosophy we apply when we build on WordPress, and where each option actually fits.

Where we sit.

We default to headless for most new projects, but we build on WordPress regularly when it is the better fit. This page is the WordPress-specific take from working developers who have shipped on every builder listed below. We will tell you when one option is genuinely the right call, including the ones we would not pick first ourselves. Read with that calibration.

The bigger problem with page builders.

Gutenberg and the visual builder boom turned content editors into accidental designers. The editor experience is intoxicating. The output, often, is not.

Every editor becomes a designer

When the builder exposes every styling control to every editor, every page becomes a fresh design experiment. Type sizes drift, spacing becomes inconsistent, the brand gets diluted one well-meaning edit at a time.

No two pages share a DOM

If editors can drop, nest, and arrange anything anywhere, the resulting markup varies wildly across the site. CSS specificity fights pile up. Mobile breaks in different places on different pages. QA becomes a treadmill.

Accessibility regresses quietly

Heading order, focus state, contrast, semantic landmarks - all of it depends on consistent structure. Free-form editing erodes that consistency, and accessibility issues show up as audit failures or, worse, as the user experience degrading for people who rely on assistive tech.

Performance bleeds

Each free-form edit tends to add a div, a stylesheet, an inline override. Multiplied across a hundred pages of edits over two years, the site is slower than it should be and nobody can quite point at why.

Our philosophy: the buck stops at sections.

The sweet spot is letting non-developer editors stack pre-built sections - and giving them no controls beyond that.

What editors should do

  • Add a section to a page
  • Remove a section
  • Reorder sections
  • Pick between predefined section variants (e.g. testimonial one-up vs three-up)
  • Edit the content within a section: text, images, links, dates
  • Pick from approved layout / color / heading-level options when the developer exposed them

What editors should not do

  • Add new arbitrary elements inside a section
  • Rearrange columns within a section
  • Change typography, spacing, or color outside approved tokens
  • Nest components recursively
  • Modify the section's underlying HTML structure
  • Toggle CSS classes or apply inline styles

The reasoning

Each freedom we hand to a non-developer editor is a place where the DOM, the accessibility, the performance, or the brand can quietly degrade. Sections are the right unit of editor control because they are vetted as a whole. The structure is right by construction. The brand is right by construction. Mobile is right by construction. The editor's job becomes choosing the right section and filling it with the right content - which is exactly the job they are best suited to do.

The one important exception: heading levels.

Heading order (H1, H2, H3) is determined by where a section sits in the page outline, not by how the section was designed. A hero might use an H1 on a homepage and an H2 on a campaign landing page that has a different top-level heading. The same testimonial section might be an H2 on one page and an H3 nested under another H2 elsewhere.

This is the exception to the "no editor controls inside the section" rule. Editors need a heading-level picker per section instance because semantic structure depends on the page, not the section. A good build exposes that control cleanly without surfacing twenty other typography knobs alongside it.

That requires care from the developer up front. It is one of the small details that separates a build that ages well from one that quietly slips out of compliance.

The main contenders.

Six approaches to building on WordPress, from cleanest output to largest community.

Bricks

Modern, code-clean, developer-oriented

Code output
Excellent. Minimal markup, sensible classes, no inline-style soup.
Performance
Light. Among the fastest WP builders.
Developer curve
Moderate. Rewards developers who think in components.
Editor curve
Steeper than Divi or Elementor for the average editor.
Community size
Small but active and growing. Strong third-party ecosystem.
Abandonment risk
Low-mid. Single-vendor product, but commercially backed and shipping consistently.
Section discipline
Strong. Encourages reusable templates and components.
Where it fits
Our most-recommended builder for marketing sites where the team has technical chops.

Etch

Newer, designer-friendly, in the same philosophical lane as Bricks

Code output
Clean. Built around modern CSS and modular thinking.
Performance
Light. Performance-first by default.
Developer curve
Lower than Bricks. More opinionated, fewer escape hatches.
Editor curve
Friendlier for editors who think visually.
Community size
Very small. Worth watching as it matures.
Abandonment risk
Higher than Bricks. New product, smaller backing.
Section discipline
Strong by design.
Where it fits
Worth piloting for projects where designers and editors collaborate closely on visuals.

Native Blocks (Gutenberg)

WordPress's first-party block editor

Code output
Variable. Core blocks are clean. Third-party block plugins range from clean to chaotic.
Performance
Light when scoped, heavy when stacked with block plugins.
Developer curve
Real. Block development requires React and the WP block APIs.
Editor curve
Mixed. Editors fluent with Gutenberg are productive. New editors find the UI confusing.
Community size
Massive. Backed by core WordPress.
Abandonment risk
Effectively zero. It is the official path forward.
Section discipline
Possible with Block Patterns and Locked Templates - requires intentional setup.
Where it fits
Content-heavy editorial sites where developers do most of the structural work.

ACF Blocks

Advanced Custom Fields running on the native block API

Code output
Excellent. Developer defines the block; editor fills in fields. No surprises in the markup.
Performance
Light. As lean as the developer makes the block.
Developer curve
Familiar to anyone who has used ACF. Lower than building native React blocks from scratch.
Editor curve
Lowest of any WP option. Editors fill out forms - no layout decisions to make.
Community size
Large. ACF is the de-facto custom-fields tool in the WP world.
Abandonment risk
Low. Acquired by WP Engine, actively maintained.
Section discipline
Excellent. Closest WP analog to the headless content workflow.
Where it fits
Content-driven sites where editors should fill in fields, not arrange layouts. Our preferred WP approach when headless is not the call.

Divi

The original visual page builder, now with a long legacy

Code output
Heavy. Output carries the legacy of every feature shipped over the past decade.
Performance
Penalty is real. Improvements every release, but you start from a heavier baseline.
Developer curve
Low for editors, high for developers extending it cleanly.
Editor curve
Low. Marketed at non-technical owners. Drag-and-drop everywhere.
Community size
Enormous. Marketing budget and tutorial ecosystem are unmatched.
Abandonment risk
Effectively zero. Massive user base.
Section discipline
Possible with Library Items and locking, but the default UX encourages free-form editing.
Where it fits
Inherited Divi sites where migration is not in scope, or teams already deep in the ecosystem.

Elementor

Most popular WP page builder by user count

Code output
Heavy. Same legacy concerns as Divi - lots of nested wrappers, lots of inline CSS.
Performance
Penalty is real. Improvements with the Flexbox containers, still heavier than modern builders.
Developer curve
Low for basic use, high for clean custom widgets.
Editor curve
Lowest barrier to entry. The biggest reason for its popularity.
Community size
Enormous. Largest WP page-builder community.
Abandonment risk
Effectively zero. Public company, sustained development.
Section discipline
Possible with Templates and locking, but most installs do not enforce it.
Where it fits
Inherited Elementor sites, or teams whose existing workflow is built around it.

Abandonment risk: the trade for a better builder.

The pattern

Newer builders deliver a better developer experience because they are not carrying a decade of legacy decisions. Cleaner output, lighter performance, modern architecture. The trade is real abandonment risk.

Cwicly was a popular up-and-comer that wound down operations in 2024. Its users had to migrate. The smaller and newer the builder, the higher the risk.

How to weigh it

For projects with a five-year horizon, abandonment risk matters. Look for active development, financial backing or commercial product (not just a passion project), an engaged community, and a clear plan for the next major release.

Bricks, ACF Blocks, and the native Gutenberg ecosystem all clear that bar today. Etch is too new to know - we like the direction but would not bet a multi-year project on it yet.

What we recommend, by project shape.

Marketing site, technical team, performance matters

Bricks, or skip WordPress entirely and go headless. Both deliver clean output and modern performance. Headless wins on Core Web Vitals; Bricks wins if WordPress is a hard requirement.

Content-heavy editorial site, mostly developer-driven

ACF Blocks, or headless. ACF Blocks is the closest WP analog to the headless content workflow - editors fill fields, developers shape the structure. Lowest risk of an editor breaking the site.

Inheriting a Divi or Elementor site

Assess migration cost honestly. Sometimes the right move is to stay on the existing builder and apply section-based discipline through Library Items / Templates / locking. Sometimes the technical debt is bad enough that a rebuild on something cleaner pays off in eighteen months.

Brand-new project, non-technical owner who wants to DIY

WordPress may be the wrong starting point. Wix, Squarespace, or Shopify (for physical products) will be faster to ship and easier to maintain alone. See our platform overview for the broader category comparison.

Team already deep in Elementor or Divi

Continue there, but apply section-based discipline. Build a Library / Template set, lock the right elements, train editors to stack and fill rather than freely arrange. The builder is not the problem; uncontrolled editing is.

Same philosophy, different platform.

Most of what we say about the content editing workflow on a headless build applies to a WordPress build with the right page builder. The content modeling, the section-based editing, the brand guardrails, the heading-level discipline - all of it transfers.

The platform changes. The philosophy does not.

See the full content editing workflow →

Talk through your project.

If you are already on WordPress and unsure which way to go, or weighing a fresh build, we will give you a working developer's read on which approach fits.

Schedule a Call

Thirty minutes. Bring project context, leave with a clear recommendation.

Schedule a Call

Prefer email? Reach us at bobby@plantedsky.com.

Comparing to headless?

The head-to-head guide weighs WordPress against the headless approach we default to for new projects.

Headless vs WordPress