The page builder exit guide: moving WordPress to native blocks
A complete guide to leaving Elementor, Divi, WPBakery, Beaver and Oxygen for native Gutenberg and ACF blocks — what breaks, the exit steps, and how to keep…
verifiedReviewed by Tommy Smith,Content Director
To leave a page builder: build your ACF blocks first, then migrate from the rendered front-end (not the builder's raw data), map each section to a block, and import as drafts. Set 301 redirects, then deactivate the builder. Never just disable it — most builders leave blank pages or raw shortcodes.
Who this is for
- Agencies: Retainer clients stuck on Elementor, Divi, WPBakery, or Oxygen.
- Freelancers: Performance and maintenance pain from bloated builder CSS.
- Developers: Teams standardising on native ACF blocks for all new builds.
Steps at a glance
- Inventory builder usage — pages, headers, popups, CPT templates.
- Build the replacement ACF block library and editor training plan.
- Migrate content section by section; never deactivate the builder early.
- Remove builder plugins after redirects, QA, and client training.
Page builders win the first hour of a project and cost you for years after. Elementor, Divi, WPBakery and the rest get a site live fast, but they lock your content into a proprietary format, ship a heavy runtime to every visitor, and tie your renewal fees to someone else's roadmap. This is the complete guide to leaving them for native Gutenberg blocks backed by ACF — what to expect, what breaks, and how to do it without losing content or rankings.
Why agencies leave page builders
- arrow_rightPerformance — native blocks output clean HTML and far less inline CSS/JS, which shows up directly in Core Web Vitals.
- arrow_rightOwnership — ACF blocks are your code and your markup, with no third-party runtime shipped to visitors.
- arrow_rightEditor consistency — your team works in one editor (Gutenberg) instead of a builder bolted on top of it.
- arrow_rightCost — no per-site builder licences multiplied across a portfolio of client sites.
- arrow_rightLongevity — no dependency on a plugin that can be sold, abandoned, or break on a WordPress update.
First, know what you're dealing with
Every builder stores layout differently, and most of them break if you simply deactivate the plugin. Knowing the storage format tells you why a naive switch-off leaves blank pages or raw shortcodes.
| Builder | How it stores layout | What breaks if you deactivate |
|---|---|---|
| Elementor | _elementor_data postmeta (JSON) | Pages render blank; content trapped in meta |
| Divi | Shortcodes in post content | Raw et_pb shortcodes show or vanish |
| WPBakery | Shortcodes in post content | vc_row shortcodes left as visible text |
| Beaver Builder | Serialized postmeta | Modules disappear; raw fallback |
| Oxygen | postmeta + ct_ shortcodes | Whole page structure is lost |
The exit approach, step by step
- 1Build your target ACF block library first, so the content has somewhere clean to land.
- 2Crawl the live, rendered pages — after the builder has done its work.
- 3Map each section to its matching ACF block; anything ambiguous falls back to an editable text block so nothing is lost.
- 4Import as drafts and review the mapping before anything goes live.
- 5Set 301 redirects for any URL that changes.
- 6Only then deactivate and delete the builder, and retest your key templates.
Builder-specific guides
The mechanics differ slightly per builder — we've covered the big ones in depth, so jump to yours:
- arrow_rightElementor to Gutenberg & ACF
- arrow_rightDivi to Gutenberg & ACF
- arrow_rightWPBakery to Gutenberg & ACF
- arrow_rightBeaver Builder to Gutenberg & ACF
- arrow_rightOxygen Builder to Gutenberg & ACF
- arrow_rightBricks Builder to ACF blocks
- arrow_rightAvada / Fusion Builder to ACF blocks
The Page Builder Exit Playbook
How Elementor, Divi, WPBakery, Beaver and Oxygen store layout, what breaks if you just deactivate them, and the step-by-step approach to a clean exit.
- check_circleWhat each builder leaves behind
- check_circleThe section-by-section exit approach
- check_circleA pre-exit safety checklist
- check_circlePost-migration cleanup steps
Don't break your SEO on the way out
A builder migration changes your markup and often your URLs, so treat SEO as a first-class part of the job.
- arrow_rightSet 301 redirects for every changed URL — see how to build a redirect map after a redesign.
- arrow_rightCarry titles, meta descriptions and canonicals into Yoast or Rank Math rather than regenerating them.
- arrow_rightRewrite internal links to the new paths instead of relying on redirect chains.
- arrow_rightRebuild any structured data the builder was outputting.
- arrow_rightThe full list lives in rebuild a WordPress site without losing SEO.
When it's OK to keep a builder
Not every site needs to leave. If a client edits happily, performance is acceptable, and the site is short-lived, the cost of migrating can outweigh the benefit. The case for leaving is strongest for portfolios of client sites, performance-sensitive sites, and long-lived flagship sites you'll maintain for years.
A page builder is a great way to launch and a poor way to live. Leave when the maintenance and licence cost outgrows the convenience.
How AIRA helps
AIRA reads the rendered page, so it doesn't care which builder produced it — it classifies sections into your ACF blocks the same way every time, sideloads media, rewrites internal links, and generates the redirect map. Walk through it in how to use AIRA.
Client communication during a builder exit
Clients fear losing the editor they learned. Set expectations early: Gutenberg plus ACF blocks replaces the builder canvas, not the ability to edit. Schedule a handover demo on staging before cutover. The page builder migration hub links every builder-specific guide for proposals and SOW appendices.
Timeline expectations
A ten-page Elementor site with an existing ACF library: two to four dev-days content migration plus one QA-day. Fifty-page Divi portfolio: one to two weeks. Builder exit is rarely the whole rebuild — theme build, forms, CPTs and redirects run in parallel. See how long a rebuild takes for full project framing.
Download the exit playbook
Use the gated playbook below for a printable builder-by-builder checklist — what each stack leaves behind, pre-exit safety steps, and post-migration cleanup. Pair it with the migration checklist for launch-day verification.
Portfolio standardisation: why agencies exit builders en masse
Single-client builder exits happen for performance or cost. Portfolio-wide exits happen when agency leadership calculates cumulative licence fees, inconsistent editor experiences, and migration tooling that only works with ACF field keys — not Elementor widgets. Standardising on one ACF block library means every rebuild reuses the same spec sheet, the same QA checklist, and the same handover documentation. The second builder exit pays back faster than the first because the block library exists.
- arrow_rightCalculate annual builder licence cost × active client sites — compare to ACF Pro and one-time block library investment.
- arrow_rightMeasure median Lighthouse score across builder clients vs block-based clients — sales teams use this in new business pitches.
- arrow_rightDocument editor training hours per builder vs Gutenberg — ops teams feel this cost every onboarding.
- arrow_rightTrack support tickets tagged 'builder conflict' or 'plugin update broke layout' — exit ROI includes reduced support load.
Editor training and change management
Clients fear losing the builder they learned during the initial project. Successful exits include a staging walkthrough before cutover: insert a hero block, edit a repeater row, swap an image, publish a draft. Show them Gutenberg sidebar fields map to the same content they edited in Elementor panels — different UI, same outcomes. Record a five-minute Loom for the handover doc; clients re-watch when staff turnover.
Performance gains agencies can quote with numbers
Page builders enqueue global CSS and JS on every page — often 200–600 KB before content-specific assets. ACF block themes typically output semantic HTML with scoped stylesheets. Before-and-after Lighthouse runs on homepage and one interior page give concrete CWV improvements for proposals. Performance is not the only exit reason, but it closes deals when the client's current mobile score is red.
| Metric | Typical builder site | Typical ACF block rebuild |
|---|---|---|
| Mobile LCP | 3.5–6s | 1.8–2.8s (varies by hosting) |
| Unused CSS/JS | High — builder bundles global | Lower — per-block templates |
| DOM depth | Deep wrapper divs | Shallower semantic markup |
| Editor JS load | Builder + Gutenberg | Gutenberg + ACF only |
Builders not in the main table — still the same exit pattern
SeedProd, Brizy, SiteOrigin, Zion, and GeneratePress Premium content blocks all follow the same rule: migrate from rendered HTML, not proprietary storage. Thrive, Flatsome, Salient, and Bricks have dedicated guides in this blog — the exit sequence is identical even when storage format differs. See Thrive migration, Flatsome migration, Salient migration, and Bricks migration.
Legal and licensing considerations on exit
Builder licences are often per-site annual subscriptions. Confirm contract terms before removing builder plugins — some agencies include licence renewal in maintenance retainers. After exit, remove builder plugins from the install to prevent accidental reactivation and security surface from unused code. Client owns ACF block templates in their theme or blocks plugin — document that ownership in handover for long-term maintainability.
Builder-specific exit guides
This is the overview — jump to your builder: Elementor, Divi, WPBakery, Oxygen, Bricks, Avada. Non-WordPress platforms: page builder migration hub. CPT-heavy agency sites: custom post type migration.
Frequently asked questions
Can I migrate off a page builder without losing SEO?expand_more
Yes, if you carry over titles, meta descriptions and canonicals, set 301 redirects for changed URLs, and rebuild structured data. The markup changes, but your rankings are tied to content and URLs, which you can preserve.
Do I have to rebuild every page by hand?expand_more
No. The slow part — re-mapping each section into native blocks — is exactly what a tool like AIRA automates by crawling the rendered pages and classifying sections into your ACF blocks, with a review step before import.
Which page builder is hardest to leave?expand_more
Builders that store layout as proprietary postmeta (Elementor, Beaver, Oxygen) are the most opaque, because the content isn't in the post body. Migrating from the rendered front-end sidesteps that entirely.
Should I exit the page builder before or after the new theme is ready?expand_more
After — always. The new ACF block theme and library must be complete on staging with content imported as drafts before you deactivate the builder on production. Exiting in the wrong order causes downtime and empty pages.
Can I leave the builder installed but inactive as backup?expand_more
Bad practice — inactive builders still update (security patches), confuse editors who see them in the plugin list, and tempt clients to reactivate for 'one quick edit'. Export PDFs of old pages if the client needs reference; remove the builder after sign-off.
How do I price a builder exit for a client on a maintenance retainer?expand_more
Separate the exit as a project phase with fixed scope — block library, migration credits, QA, training — not buried in monthly hours. Retainer hours cover ongoing edits after exit; migration is a one-time capital project with defined deliverables.
Do builder exits always improve Core Web Vitals?expand_more
Usually, when the new theme is well-built and hosting is adequate. Poor hosting, unoptimised images, or twenty plugins still hurt scores after exit. Set honest expectations — builder removal removes a major JS/CSS source, not every performance problem.
What if the client refuses to leave the builder?expand_more
Document the trade-offs in writing — licence cost, performance ceiling, migration cost later. Some clients stay on builders happily; the exit case is strongest for long-lived flagship sites, performance-sensitive verticals, and agency portfolios standardising on blocks.
Ryan Hale
Head of Front End Development
Ryan Hale is Head of Front End Development at AIRA, where he leads the team building the engine that migrates WordPress sites into native ACF blocks. He has spent more than a decade building and rebuilding WordPress sites for agencies, with deep, hands-on expertise in Advanced Custom Fields, Gutenberg block development, and large-scale content migrations that protect search rankings. He writes about ACF, moving off page builders like Elementor and Divi, and the practical craft of shipping fast, maintainable WordPress rebuilds.
Reviewed to our editorial guidelines.
