Page builders like Elementor, Divi, and WPBakery made WordPress approachable for a generation of site owners who didn't want to touch code. But the trade-off is real: bloated markup, slower pages, recurring license fees, and content that's effectively held hostage by the plugin that created it. The good news is that since the block editor matured and Full Site Editing landed, you no longer need a page builder to design a polished, fast WordPress site. You can do nearly everything natively — and the result is lighter, more portable, and easier to maintain.

This is a practical guide to building a complete WordPress site using only the tools WordPress ships with: the block editor (Gutenberg), block themes, the Site Editor, and theme.json.

Why skip the page builder in the first place?

The case against page builders isn't aesthetic snobbery — it's concrete.

Lock-in. This is the big one. Build a page in Elementor, then deactivate the plugin, and your beautifully designed layout collapses into a wall of raw shortcodes or empty <div> soup. Your content is married to the builder. Migrating away later means rebuilding pages by hand.
Page weight and render blocking. Page builders load their own CSS and JavaScript frameworks on every page. It's common for a builder to add 1–2 MB of assets and several render-blocking files before your actual content even appears. That directly hurts your Largest Contentful Paint, and Google wants LCP under 2.5 seconds.
Nested div soup. Builders wrap your content in deeply nested wrapper elements to make their drag-and-drop grid work. More DOM nodes mean slower rendering and messier accessibility.
Cost. Most serious page-builder setups are annual subscriptions — Elementor Pro and Divi both run in the range of a yearly renewal you'll pay forever. The native tools are free.

None of this means page builders are evil. They're a reasonable choice for some workflows. But if performance, portability, and long-term maintainability matter to you, the native stack is now genuinely competitive.

What replaces each page-builder job

The mental shift is realizing that everything a page builder does maps to a native equivalent. Here's the translation:

Layout and structure

Page builders give you sections, rows, and columns. The block editor gives you the same primitives:

Group block — your generic section wrapper. Set background colors, padding, and constrained vs. full width here.
Columns block — multi-column layouts that stack responsively on mobile by default.
Cover block — a hero section with a background image or video, overlay, and centered content.
Row and Stack variations — flexbox-based horizontal or vertical arrangements for things like button groups or icon rows.

These produce clean, semantic HTML with no proprietary shortcodes. Deactivate any plugin you like; the layout survives.

Global design (colors, fonts, spacing)

This is where a page builder's "global settings" panel lived. In a block theme, the equivalent is theme.json plus Global Styles (Appearance → Editor → Styles). theme.json is a single configuration file that defines your design tokens — your color palette, font families and sizes, a spacing scale, and layout widths. Set your brand blue once, and it appears as a swatch everywhere in the editor. Change it in one place and it updates site-wide. This is the closest native analog to a design system, and it's far cleaner than hunting through a builder's per-element overrides.

Headers, footers, and templates

Page builders sell "theme builder" add-ons to let you design your header and footer. In a block theme that capability is built in via the Site Editor. You edit the header and footer as template parts, and you design the actual page templates — single post, archive, 404, search results — visually, with blocks. No add-on, no extra license.

Reusable sections

The builder feature here is "global widgets" or "saved templates." Natively, you use patterns. A pattern is a pre-arranged group of blocks you can drop in anywhere. Synced patterns (formerly "reusable blocks") go further: edit one instance and every copy across the site updates — perfect for a call-to-action block or a promo banner you reuse on twenty pages.

Dynamic content and lists

Need a grid of recent posts, a filtered product list, or a custom loop? That's the Query Loop block. It pulls posts (or any custom post type) by category, tag, author, or date and renders them with a template you design once. It's the native answer to a builder's "posts widget," and it respects your theme's styling automatically.

The honest middle ground: block plugins aren't page builders

Here's a nuance that trips people up. There's a category of plugins — GenerateBlocks, Kadence Blocks, Stackable, and Spectra — that add more blocks to the native editor. These are not page builders, and that distinction matters.

A page builder replaces the WordPress editor with its own interface and saves content in its own format. A block-library plugin extends the native block editor with extra blocks (advanced containers, query loops, accordions, tabbed content) while still saving standard block markup. Deactivate GenerateBlocks and you'll lose the styling on its specific blocks, but your content stays as recognizable WordPress blocks — not shortcode rubble. GenerateBlocks in particular is famous for being extremely lightweight, generating minimal CSS only for the blocks you actually use.

So if you want a little more layout power than core provides without reintroducing builder bloat and lock-in, a block-library plugin is the sweet spot. You're staying on the native rails.

A real workflow, start to finish

Forget generic "audit then deploy" advice. Here's how a page-builder-free build actually goes:

Pick a block theme. Confirm the theme supports Full Site Editing — it must have a templates folder and a theme.json. The default Twenty Twenty-Five is a solid, fast starting point. Ollie, Frost, and Ona are excellent free block themes, and GeneratePress or Kadence pair well with their respective block plugins.
Define your design tokens in theme.json. Set your color palette, fonts, font-size scale, and spacing scale first. Doing this up front means every block you add afterward inherits consistent styling instead of you styling each one by hand.
Build your templates in the Site Editor. Lay out your header and footer template parts, then your single-post and archive templates. Get the skeleton right before touching individual pages.
Assemble pages with patterns. Build your homepage and landing pages from Group, Columns, and Cover blocks, saving any section you'll reuse as a pattern. Use synced patterns for anything that must stay identical site-wide.
Add a block-library plugin only if you hit a wall. Start with core. Reach for Kadence or GenerateBlocks only when you need a specific block core doesn't offer.

What you actually give up

Going native isn't free of trade-offs, and pretending otherwise would be dishonest:

Pixel-perfect dragging. The block editor uses a constrained layout model, not absolute positioning. You can't drag an element to arbitrary coordinates the way you can in Elementor.
Some advanced features. Elementor Pro's motion effects, popup builder, and sophisticated form builder don't have one-to-one native equivalents. You'll add dedicated plugins for popups or forms instead.
A learning curve. The Site Editor's distinction between templates, template parts, and patterns confuses newcomers. It takes a few hours to build the mental model.
Client familiarity. If you hand sites to clients who already know Elementor, expect some retraining.

For most sites the math favors going native: dramatically lighter pages, better Core Web Vitals, zero recurring license fees, and content that stays yours no matter what plugin you do or don't run. The page builder was a bridge. With block themes and the Site Editor, you may not need the bridge anymore.

Building a WordPress Site Without a Page Builder