Skip to content
WordPress

Elementor to Bricks: What Transfers and What You Rebuild

9 min read
Contents

Key Takeaways

  • Elementor stores page layouts in the _elementor_data post meta field as a JSON tree, so deactivating Elementor leaves pages with only plain post content, often nothing at all.
  • Bricks replaces the theme layer entirely, so headers, footers, theme parts, global colours, typography, widget styling and popups all rebuild by hand.
  • Audit Before You Touch Anything removes roughly a fifth to a third of pages on older sites, and rebuilding pages by Google Search Console traffic keeps the URL, H1 and copy identical.
  • WDesignKit offers 91 Bricks widgets, but its 3,675 templates, 243 kits and 2,401 full pages are for Elementor and Gutenberg; the 1-Click Widget Convertor only converts self-built widgets on a PRO plan and does not migrate page layouts.

 

Searches for “elementor to bricks” sit at just 10 a month in the US. The trend line is the interesting part: DataForSEO recorded the term up 100 percent month on month, quarter on quarter and year on year when it last refreshed the figure on 29 August 2026. Small numbers, consistent direction.

Most answers to that question skip the part that costs you a weekend, so here it is up front. There is no converter that turns an Elementor site into a Bricks site. Not a plugin, not a script, not a hidden setting. What follows is what genuinely carries across, what you rebuild by hand, and how to sequence the work so your live site never goes down while you do it.

Why People Move From Elementor to Bricks

Elementor is not in trouble. The WordPress.org plugin API lists it at 10,000,000 active installs, version 4.2.4, last updated 31 August 2026, rated 90 out of 100 across 7,297 ratings. It is one of the most widely deployed plugins in WordPress history and it is actively maintained.

People still leave, and usually for one of three reasons. The first is output weight: Bricks generates leaner markup, and on sites where Core Web Vitals are a commercial problem that difference matters. The second is the licence model. Bricks is a theme rather than a plugin, sold directly rather than through WordPress.org, at 79 dollars a year for one site, 149 dollars a year for three, 249 dollars a year for unlimited sites, or 599 dollars once for the Ultimate Lifetime tier. For an agency running dozens of client sites, that lifetime option is the whole argument. The third is preference about how a builder should feel to work in, which is not something anyone should try to talk you out of.

Note the structural difference before you plan anything: Elementor is a plugin that sits on top of your theme, while Bricks replaces the theme entirely. You are not swapping one widget set for another. You are changing the layer that renders your whole site.

Why There Is No Elementor to Bricks Converter

The reason is in how Elementor stores your work. An Elementor page does not live in the WordPress post content the way a block editor page does. It lives in a post meta field called _elementor_data, as a JSON tree of Elementor’s own element types, each carrying settings that only Elementor’s rendering engine understands.

Bricks stores its layouts in its own meta structure, with its own element names and its own settings schema. A converter would need to map every Elementor element and every one of its style controls onto a Bricks equivalent, including elements from any third party addon packs you have installed. Where no equivalent exists, it would have to guess. That is why the tools which claim to do this handle simple text, headings and images acceptably and fall apart on anything with a custom layout, a dynamic query or conditional logic.

Deactivating Elementor does not release that data either. Because the layout was never in post content, the page does not fall back to a tidy version of itself. It falls back to whatever plain content the post actually holds, which on a page built entirely in Elementor is often nothing at all.

What Transfers and What You Rebuild

Worth being precise about this, because “you have to rebuild” is both true and misleading. A lot of your site is not Elementor’s to hold in the first place.

AssetTransfers?Why
Posts, pages, custom post typesYesWordPress core data, untouched by either builder
Media libraryYesStored in uploads and the attachments table
Menus, users, comments, categoriesYesCore WordPress tables
SEO metadataYesOwned by Rank Math or your SEO plugin, not the builder
Plain post contentYesOnly where the page was not fully built in Elementor
Page layouts and sectionsNoLocked in Elementor’s own meta structure
Headers, footers, theme partsNoBricks replaces the theme layer entirely
Global colours and typographyNoElementor kit settings do not map to Bricks
Widget styling and custom CSSNoSelectors are generated per builder
Popups and dynamic templatesNoBuilder specific systems with no shared format

Read that table as good news. Your content and your SEO history survive the move intact. What you are rebuilding is presentation, and presentation is the part you were probably going to revisit anyway.

How to Migrate From Elementor to Bricks, Step by Step

1. Audit Before You Touch Anything

List every page built in Elementor and mark each one keep, merge or retire. On most sites that have been running a few years, a real audit removes somewhere between a fifth and a third of the pages. Every page you retire is a page you do not rebuild, so this step pays for itself more than any other.

2. Work on a Staging Copy

Activating Bricks changes the active theme, which affects the entire front end at once. This is not a change to make on production. Clone the site, migrate there, review it properly, then push the finished result live.

3. Rebuild Global Styles First

Open Bricks and set your colour palette, typography scale, container widths and breakpoints before you build a single page. Skipping this is the most common mistake in a builder migration. You end up styling each page individually, and every later change becomes twenty edits instead of one.

4. Rebuild Templates Before Pages

Header, footer, single post and archive templates come next. These render on every URL, so getting them right early means each page you rebuild afterwards already sits inside a finished frame.

5. Rebuild Pages by Traffic, Not by Menu Order

Pull your top landing pages from Google Search Console and work down that list. Keep the URL, the H1 and the substance of the copy identical as you go. Rankings follow content and links, so a rebuild that preserves both is a rebuild search engines barely notice.

6. Remove Elementor Last

Leave Elementor installed and inactive until every page is verified in Bricks. When you are certain, delete the plugin, then clear the orphaned _elementor_data and _elementor_css meta rows it leaves behind. Take a database backup before you run any cleanup query.

Rebuilding Elementor Widgets in Bricks

Bricks ships a capable set of native elements, but if your Elementor build leaned on an addon pack you will find gaps: advanced sliders, tabbed interfaces, animated counters, pricing tables and the rest of the components that addon libraries exist to provide.

WDesignKit currently carries 91 Bricks widgets in its library, out of 239 widgets across all supported builders. Being straight about the shape of that library matters more than the headline number: the 3,675 ready made templates, 243 kits and 2,401 full pages are built for Elementor and Gutenberg, split 2,040 and 1,635. There are no Bricks page templates. For Bricks you get widgets to rebuild with, not finished layouts to import.

One feature is worth understanding accurately, because its name invites the wrong assumption. The 1-Click Widget Convertor converts widgets between builders, including Bricks, but only widgets you built yourself in the WDesignKit Widget Builder, and only on a PRO plan. As the feature announcement puts it, you cannot import external widgets or third party code. It does not convert page layouts, and it will not migrate an Elementor site. It solves the narrower problem of maintaining one custom component across several builders.

Protecting Your SEO Through the Move

A builder migration is a rendering change, not a content change, which is why most rankings survive it. The failures come from avoidable mistakes: changing URLs without redirects, dropping copy during the rebuild, losing internal links that lived inside Elementor widgets, or shipping a Bricks build that is slower than the Elementor one because the images were never optimised.

Record your top twenty pages and their positions before you start. Check them again two weeks after launch. Small movement in either direction is ordinary; a consistent drop across many pages means something structural broke, and the earlier you catch it the cheaper it is to fix.

Frequently Asked Questions

Why is there no Elementor to Bricks converter?

Elementor and Bricks store layouts in different places and different formats, so a one-click converter would have to translate two separate systems. Elementor keeps page data in the _elementor_data post meta field as a JSON tree, while Bricks uses its own meta structure and element schema. That is why simple text and images may survive in partial tools, but custom layouts, dynamic queries, and conditional logic usually break.

What actually transfers when moving from Elementor to Bricks?

Core WordPress data transfers cleanly, which is the part people often underestimate. Posts, pages, custom post types, media library files, menus, users, comments, categories, SEO metadata, and plain post content all stay intact because they are not locked inside Elementor. WDesignKit Learning Center frames the move as a rebuild of presentation, not content or SEO history.

What do I have to rebuild when switching from Elementor to Bricks?

Page layouts and sections, headers, footers, theme parts, global colours and typography, widget styling, custom CSS, popups, and dynamic templates all need rebuilding. The reason is structural: Elementor is a plugin layered on top of your theme, while Bricks replaces the theme entirely. That means you are changing the rendering layer for the whole site, not just swapping widgets.

What is the safest way to migrate an Elementor site to Bricks without breaking the live site?

A staging copy is the safe path because activating Bricks changes the active theme across the entire front end at once. The practical sequence is audit first, clone the site, rebuild global styles before pages, then templates before pages. That order reduces duplicate work and keeps production untouched until the rebuilt version has been checked properly.

How do I protect SEO during an Elementor to Bricks migration?

SEO usually survives because this is a rendering change, not a content change. The main risks are changing URLs without redirects, dropping copy during rebuilds, losing internal links inside Elementor widgets, or shipping a slower Bricks build because images were never optimised. WDesignKit Learning Center recommends recording your top twenty pages and positions before launch and checking them again two weeks later.

Last reviewed: September 4, 2026

Suggested Reading

Author

Sagar Patel, Founder and CEO of POSIMYTH Innovations
Sagar Patel
CEO · POSIMYTH Innovations · 10+ Years Experience

Sagar is the Founder & CEO of POSIMYTH Innovations, with 10+ years building WordPress products trusted by 100,000+ websites globally. He has led the development of The Plus Addons for Elementor, Nexter, WDesignKit, and UiChemy, all built hands-on from concept to launch. His work focuses on making website building faster, more flexible, and accessible for creators and businesses worldwide.