Elementor to Next.js: Getting Your Content Out of the Builder and Into Real Fields

The page you edit is not the page WordPress stores as content

In a plain WordPress page, the content field holds the page. Elementor works differently. Its source code saves the layout as JSON in a post meta key named _elementor_data, marks the page as builder-made with _elementor_edit_mode, and keeps page-level settings in _elementor_page_settings. Every time you save, Elementor also writes a plain-text copy of the page into the ordinary content field, with dynamic content stripped out, so search and excerpts have something to read.

That plain copy is why a standard export looks almost right and is quietly wrong. You get the words in order, but not which words were a button, which image sat beside which paragraph, or which block was a testimonial. The standard REST routes are no better, because the WordPress handbook lists metadata among the things the API shares only with authenticated requests. A clean migration reads the JSON itself, from a database export or a small script on the old site.

Inside _elementor_data: containers all the way down

Elementor's developer documentation describes the format plainly. Each element has an id, an elType that says what it is, a settings object with everything you set in the panel, and an elements array holding its children. Older pages nest sections, columns and inner sections; newer ones nest containers. Widgets sit at the bottom of the tree, each with a widgetType such as heading, text-editor, image or button.

Extraction is a walk down that tree. A script visits every element in reading order, ignores the purely visual settings (padding, borders, motion effects), and collects what a reader would notice: heading text and level, paragraphs, images with their alt text, links and button labels, list items, and the items inside tabs and accordions. What comes out is a clean sequence of content blocks, which is then mapped to the fields of the matching page type in Athena CMS.

The tricky part is intent. A heading widget set in huge type might be the page's real H1 or a decorative number. Three image boxes in a row might be services, team members or logos. A script can find them; a person decides what they mean. On a site with a few saved templates that decision is made once per template. On a site where every page was built by hand, it is made page by page, which is the main reason Elementor sites take longer and cost more than block-editor sites, as the cost guide explains.

Widget by widget: what carries over and what gets rebuilt

Add-on packs deserve a warning. Every widget pack stores its settings in its own shape, so a site with two or three packs needs a reader for each. The upside is that migration is often the moment those packs disappear for good: the one carousel that justified a whole plugin becomes one component. The page builder vs Next.js comparison explains why that matters for speed.

Theme Builder parts become page types

Elementor Pro's Theme Builder is where an Elementor site keeps its skeleton: the header, the footer, the single-post template, the archive template, sometimes a separate template for each custom post type. Each one carries display conditions that decide where it appears. When two headers fight over the same pages, those conditions are usually why.

In Next.js, these map almost one to one onto things the framework already has. The header and footer become a shared layout. Single and archive templates become route templates for each page type. Dynamic tags, the Elementor feature that pulls a post title or a custom field into a widget, become plain references to fields in the content model. The display conditions turn into routing rules written in code, which is a relief: they stop being a hidden setting and become something anyone can read.

• Header and footer templates become one layout, edited in Athena through menu and contact fields.
• Single templates for posts, services or projects become one page type each, with fields matched to their dynamic tags.
• Archive and loop templates become listing pages with real pagination and filters.
• The 404 template becomes the site's not-found page, finally consistent with the rest of the design.

If your site runs on Hello Elementor, almost everything visible came from the Theme Builder, so this step is most of the job. The theme-specific walkthroughs are Hello Elementor to Next.js and, for sites on the theme Elementor is moving into maintenance mode, Hello Biz to Next.js.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Popups and forms: move the behavior, not the markup

Popups are stored as templates of their own type, each with display conditions, triggers (on page load, on scroll, on exit intent) and advanced rules about how often to show. Migrating them is mostly a business question. List every popup, check which ones still run a live offer, and rebuild only those, as components that load when triggered rather than on every page. Popups that announce a sale from two summers ago can retire quietly.

Forms carry more weight, because leads depend on them. For each Elementor form we record the fields, the validation, every action after submit (email, webhook, CRM or email-marketing connection) and the confirmation message. The Next.js version is rebuilt with server-side validation and spam protection that does not punish real customers, a topic covered in why WordPress forms get spammed. If past entries matter to you, export them from WordPress before launch; they do not move with the form.

Migrate what the popup did for the business, not what it did to the page.

Global colors and fonts, turned into design tokens

Elementor keeps site-wide styles in a kit: a special template whose ID is stored in the elementor_active_kit option. Its settings hold the global colors (four system colors named Primary, Secondary, Text and Accent, plus any custom colors you added), the global typography in the same system-plus-custom pattern, button and form styles, and the breakpoints.

That is a gift for a migration, when it was used properly. Global colors become color tokens, global fonts become typography tokens, and the breakpoints inform the responsive layout. Fonts are then self-hosted through next/font, so text no longer waits on a third-party server. The catch is that many Elementor sites set colors widget by widget instead of using the globals, which leaves a dozen near-identical blues scattered through the JSON. Part of extraction is collecting every color actually used, merging the near-duplicates and agreeing on a short palette.

The Elementor exit, in order

1. 1

   Inventory

   Every page, post, template, popup and form, with the Elementor and Pro plan in use, every add-on pack, and every URL Google knows. Start at the free site audit.

2. 2

   Export the data

   A database export or a script that reads _elementor_data for every page and every elementor_library template, plus the active kit's settings.

3. 3

   Classify the layouts

   Group pages by the template or pattern they follow, decide what each widget means, and define the page types and fields in Athena.

4. 4

   Extract and map

   Walk each page's JSON, pull the content in reading order, and load it into the matching fields, with images moved and alt text kept.

5. 5

   Rebuild the skeleton

   Header, footer, page templates, popups that earn their place, and every form, built in Next.js from the design tokens.

6. 6

   Redirect and compare

   Every old URL kept or redirected, each new page checked against the Elementor original on a preview address, then launch.

Search protection runs through every step rather than at the end; the full method is in migrating without losing SEO, and the time each step takes is discussed in the migration timeline.

When staying on Elementor is the better move

Elementor is good at what it was built for. If your marketing team rearranges landing pages every week, the site is small, and speed is acceptable, a cleanup by an Elementor developer costs far less than a migration. Converting old sections to containers and removing unused add-on packs often buys a lot. If the site is broken right now, the Elementor repair guide is the faster first stop.

The move makes sense when every new feature needs another add-on, when the license and update cycle eats real hours, or when leads depend on speed that Elementor's markup keeps taking back. The comparisons at Hello Elementor vs Next.js and Divi vs Elementor vs Next.js lay out the trade. Elementor is also common on top of other themes, so the Astra and OceanWP migration pages cover the same ground from their side. After the move, your team edits in Athena, and switching from WordPress shows what changes for them.