Moving from a page-builder theme to a block theme (the honest playbook)

01Why people move off page-builder themes

The pull toward block themes is real, and it's not just hype. Three things are pushing people off page builders at once: performance, lock-in, and a native editor that finally grew up.

Performance is the loudest reason. Page builders load their own CSS and JavaScript on every page, plus the wrappers and nested divs they generate to make drag-and-drop work. That weight shows up directly in Core Web Vitals — slower loads, more layout shift, worse mobile scores.

Lock-in is the quieter reason, and the one that bites later. Once your pages are built in a proprietary builder, that builder owns your layouts. Deactivate it and the page falls apart. You're paying a subscription partly to keep your own content readable.

And the native block editor has matured. Block themes now do full-site editing — headers, footers, archive templates, single-post templates — all in the same interface, with no extra plugin. The capability gap that justified a builder in 2019 has mostly closed.

• Speed — no builder runtime means less CSS/JS and cleaner markup, which helps Core Web Vitals.
• No lock-in — block content is stored in WordPress core's format, not a vendor's database tables or shortcodes.
• One interface — full-site editing covers templates and content without bolting on a builder.
• Lower cost and surface area — one fewer paid plugin, one fewer thing to keep updated and secure.

02The hard truth: builder content does not cleanly convert

Here's the part most "switch to blocks" articles skip. There is no reliable one-click converter from a page builder to native blocks. Anyone selling you a frictionless migration is selling you a surprise.

Elementor, Divi, and WPBakery each store layouts in their own way. Elementor and Divi keep a structured layout payload in post meta. WPBakery wraps everything in its own shortcodes inside the post body. None of those formats map one-to-one onto native blocks.

So when you deactivate the builder, the pages don't gracefully fall back to clean blocks. Elementor and Divi pages render as a stack of unstyled raw content. WPBakery pages show their shortcodes as literal text — readers see things like [vc_row] sitting in the middle of your copy.

Plan for rebuilding the layouts, not converting them. The text and images inside those layouts are recoverable, but the structure — columns, sections, styled buttons, tabs, sliders — has to be rebuilt in blocks. That's the honest scope, and pretending otherwise is how migrations blow up mid-stream.

Conversion plugins do exist, and a few are genuinely useful for simple layouts. But on anything design-heavy they produce a messy approximation you'll spend longer cleaning than rebuilding. Treat them as a starting sketch, never a finished result.

03What carries over vs. what you rebuild

The good news cushions the bad: your actual content is safe. It's only the builder-controlled presentation that you have to recreate. Sorting one from the other up front is what keeps this manageable.

What carries over untouched

• Post and page text — the words live in the database and survive the switch.
• Media library — images, video, and files are stored independently of any theme or builder.
• URLs and permalinks — your address structure is a WordPress setting, not a builder feature.
• SEO data — titles, meta descriptions, and schema belong to your SEO plugin, not the theme.
• Comments, users, and categories — all database-level and unaffected.

What you rebuild from scratch

• The homepage — almost always the most builder-heavy page on the site.
• Landing and sales pages — multi-column sections, hero blocks, pricing tables, calls to action.
• Builder-bundled elements — sliders, tabs, accordions, and styled buttons made of the builder's widgets.
• Templates — header, footer, and any archive or single-post layout the builder or old theme controlled.
• Global styles — colors, fonts, and spacing defined in the builder's design settings.

A simple blog post written in the builder usually rebuilds in minutes — it's mostly text the editor can absorb. A bespoke homepage with six animated sections is an afternoon. Estimate the project by counting the second kind, not the first.

04The staged approach that keeps you sane

Do not flip the switch on your live site and start rebuilding while visitors watch broken pages. The whole migration belongs on staging, sequenced so nothing public breaks until the new version is genuinely done.

Start by cloning the site to a staging copy. Most decent hosts give you one-click staging; if yours doesn't, a plugin like WP Staging makes a local clone. This is the sandbox where everything risky happens.

The order of operations

• Back up first — full files and database, downloaded off the server and tested once by restoring to staging.
• Clone to staging and do every following step there, never on production.
• Install and activate the block theme on staging while the old builder content is still present for reference.
• Rebuild templates first — header, footer, single-post, and archive — so every page has a consistent frame.
• Rebuild key pages next — homepage and top landing pages, the ones that earn money or rank.
• Migrate posts post-by-post, starting with your highest-traffic URLs, checking each one as you go.
• Push to live only when staging is fully walked through and nothing renders as raw shortcodes or unstyled content.

Working post-by-post feels slow, and it is. But it's the only way to catch a page where a builder element silently dropped out, before that page is the one a customer lands on. Batch it across sessions if the site is large — there's no prize for doing it all in one sitting.

05Choosing a block theme

The block theme you pick sets the ceiling for how much rebuilding feels like fighting the tool. A few have earned their reputations for full-site editing that doesn't make you miss the builder.

• Kadence — strong full-site-editing support, a generous free tier, and lots of starter patterns; a common landing spot for people leaving Elementor.
• GeneratePress — lightweight and performance-first, with a loyal following among people who care most about speed and clean markup.
• Blocksy — modern, design-flexible, and well-suited to people who want visual control without a separate builder.
• Twenty Twenty-Five — WordPress's own default block theme; no cost, no vendor, and the truest expression of where core is heading.

If you want the smallest learning curve and a big library of pre-built patterns to rebuild against, Kadence or Blocksy tend to feel friendliest. If raw speed and minimalism matter most, GeneratePress and the default theme are hard to beat.

One practical tip: pick the theme before you start rebuilding, and build a couple of test pages in it first. Each theme's pattern library and global-style system is a little different, and you want to learn its quirks on a throwaway page, not on your homepage.

06Cleaning up leftover shortcodes and builder cruft

Even after you rebuild the visible pages, the old builder can leave debris in the database — orphaned shortcodes, leftover meta, and enqueued assets that no longer do anything. Clearing it is what makes the speed win real.

WPBakery is the worst offender here because its shortcodes live inside post content. If you deactivate it before rebuilding a page, that page will show literal [vc_row] and [vc_column] tags as plain text. Rebuild the page in blocks first, then those shortcodes are gone with the old content.

Elementor and Divi store layout data in post meta rather than the body, so you don't get visible shortcode text — but the meta lingers after you stop using them. It's dead weight, not a display bug, and it's safe to leave until you're certain every page is rebuilt.

A safe cleanup sequence

• Rebuild every page first — never delete builder data while any live page still depends on it.
• Search your content for stray shortcode tags (like [vc_ or [et_pb_) and clean any that slipped through.
• Deactivate the builder plugin and walk the whole site again on staging before deleting it.
• Remove the plugin only after a full pass confirms nothing breaks — and only on staging, with a backup in hand.
• Leave database cleanup for last, and use a reputable optimization plugin rather than hand-editing tables.

07Keeping SEO and URLs intact through the rebuild

Rebuilding layouts is where rankings get accidentally thrown away — not because blocks rank worse than builders, but because people change URLs and tank speed while they're "in there anyway."

The rule is restraint. A theme and builder change does not require a single URL to change. Keep your permalink structure identical, keep existing slugs, and don't consolidate or rename pages as part of the same job. Google indexes addresses; leave the addresses alone.

If a rebuild genuinely does retire a URL — you merge two landing pages, say — set a 301 redirect from the old URL to its closest equivalent the same day you publish. A 301 passes the old page's ranking value forward; skipping it hands you 404s and lost links.

• Don't touch permalink settings or rename slugs during the migration.
• Confirm SEO plugin data survived — titles, descriptions, and schema should be intact, since they're plugin-owned.
• Benchmark speed before and after — run PageSpeed Insights on key pages so you can prove the block theme is faster, not assume it.
• 301 any retired URL to its closest match on the day it goes live, then watch Search Console for 404s.

08Is it actually worth it?

Not every site should make this move, and pretending otherwise wastes people's weekends. The right answer depends on what kind of site you have and where it is in its life.

When it's worth it

• Content-led sites — blogs and editorial sites where most pages are mostly text rebuild quickly and gain real speed.
• Sites paying for lock-in — if a builder subscription mainly exists to keep your pages readable, escaping it is a durable win.
• Sites failing Core Web Vitals — when builder bloat is measurably hurting your scores, blocks are a direct fix.
• Smaller sites — fewer builder-made pages means a smaller rebuild and a faster payoff.

When it's often not worth it (yet)

• Large, design-heavy sites — hundreds of intricately built pages turn a switch into a multi-week project.
• Mid-cycle redesigns — if a planned redesign is coming, fold the move into that instead of doing it twice.
• Sites that depend on builder-only features — some advanced builder widgets have no clean block equivalent yet.
• No staging, no backup, no time — without a safe sandbox, the risk outweighs the benefit; fix that first or wait.

A reasonable middle path: migrate the highest-value, lowest-complexity pages first, prove the speed gain, and leave the gnarly builder pages for a future redesign. You don't have to convert the whole site in one heroic push to start banking the benefit.

09Frequently asked questions

Will I lose my blog posts when I switch from Elementor to a block theme?

No — the post text lives in the database, not in Elementor. What you lose is the builder-made layout around that text. Posts written mostly as text rebuild in minutes; posts built as elaborate Elementor layouts need their structure recreated in blocks.

Is there a tool that converts Elementor or Divi to native blocks?

There are conversion plugins, but none are reliable on complex layouts. They can sketch a starting point for simple pages, but on design-heavy pages they produce a mess that takes longer to clean than to rebuild. Treat conversion as manual rebuilding, not a button.

Why do I see [vc_row] text on my pages after disabling WPBakery?

WPBakery stores its layouts as shortcodes inside the post body. With the plugin off, nothing interprets those shortcodes, so they render as literal text. The fix is to rebuild the page in blocks — once the new content replaces the old, the shortcodes are gone.

Will switching to a block theme hurt my rankings?

Not by itself. Rankings drop when URLs change or speed regresses — not because content moved from a builder to blocks. Keep your permalinks and slugs identical, 301 anything you do retire, and a block theme usually helps rankings by improving speed.

How long does the migration take?

It scales with the number of builder-made pages, not the size of your content. A small content site can be a focused weekend; a large, design-heavy site is a multi-week project. Count your complex builder pages — that number, not your post count, sets the timeline.

This is general, experience-based guidance from running a theme shop, not financial or professional advice for your specific site. When the cost of a mistake is high, build on staging, keep a tested backup, and get a second pair of hands.