Divi to Next.js: Getting Your Pages Out of the Shortcodes

Divi 4 and Divi 5 hide your words in different wrappers

Every Divi site you might move today was built in one of two storage formats, and the extraction work starts by finding out which. Divi 4 writes the whole layout into the post content as nested shortcodes: [et_pb_section] holds [et_pb_row], which holds [et_pb_column], which holds modules such as [et_pb_text]. Design choices ride along as attributes on those tags. Your headline sits in the middle of it, a few hundred characters of settings away from the next sentence.

Divi 5 changed the wrapper. Version 5.0.0 left beta on February 26, 2026, and Elegant Themes says it drops shortcodes and saves content in a block-based WordPress format. The switch is opt-in: a Divi 4 site stays on the old update path until someone clicks Enable Divi 5 Updates and runs the Divi 5 Migrator, which the vendor says converts pages, posts, custom post types, Theme Builder templates, WooCommerce products, Divi Library items, widgets and presets. Modules from third-party vendors that are not Divi 5-ready are not converted. They stay in backward-compatibility mode, still stored as shortcodes.

The practical upshot: a Divi 5 site is cleaner data, but rarely pure data. Plenty of Divi sites carry a module pack from another vendor, and every module from a pack that is not Divi 5-ready is a Divi 4 shortcode living inside a Divi 5 page.

The morning after Divi is switched off

Owners sometimes test their exit by activating a different theme. On a Divi 4 site the result is immediate and ugly. Divi registers its shortcodes; without Divi, WordPress no longer knows what [et_pb_section] means, so it prints the tag as text. The words survive. The layout, spacing, images placed by modules and every button turn into a paragraph of brackets. We cover the repair side of this at Divi shortcodes showing after a theme change.

Divi 5 behaves better but is not free of it. Elegant Themes' own help pages say that if a plugin providing modules in backward-compatibility mode is deactivated, those modules display as shortcodes. And the design itself still depends on Divi: block-format content is easier to read, yet no other theme knows how to draw it. The data is portable. The look is not.

Theme Builder, Library and presets: the Divi that is not on any page

Exporting posts and pages catches perhaps the most visible half of a Divi site. The rest lives in places that a standard WordPress export treats as afterthoughts, and each needs its own decision.

Extracting text and media without the Divi residue

The goal is content an editor would recognize, with none of Divi's scaffolding attached. We do not screen-scrape the rendered pages for this, because rendered HTML carries Divi's class names and wrappers into the new site. We read the stored data, module by module, and decide what each kind of module becomes.

• Text modules become rich text: headings, paragraphs, lists and links kept; inline styles, font tags and empty spacer paragraphs dropped.
• Image modules become an image reference with its alt text and link. The file itself goes through the image migration, where originals are pulled from the media library rather than Divi's resized copies.
• Blurbs, buttons and call-to-action modules become structured fields (title, text, icon, link) so the new design can render them consistently.
• Toggles and accordions usually hold FAQs. They become question and answer pairs, which also makes FAQ schema straightforward to generate.
• Sliders and galleries are reviewed by hand. Slide text often repeats elsewhere, and a homepage slider is a frequent cause of a slow first paint.
• Contact form modules are rebuilt, not copied. The fields are listed, the email routing is confirmed, and the new form is tested before launch.

Third-party modules get the same treatment once we know what their shortcodes contain. Some hold real copy; some are a countdown timer for a sale that ended long ago. The inventory decides, not the parser. Owners who want to see where their pages stand today can run Divi through our Divi speed guide first, which explains the Performance tab settings that the new build makes unnecessary.

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

Eight steps from Divi site to Next.js launch

A common question is whether to run the Divi 5 Migrator first, since Divi 5 data is cleaner. If you are leaving, usually not. Upgrading a site you are about to retire adds a migration on top of a migration, and we can read Divi 4 shortcodes directly. The exception is a site already half-converted, where we read both formats.

1. 1

   Snapshot and freeze

   Take a full copy of the database, uploads, theme and plugins. Agree a content freeze date, or a log of edits made after it, so nothing written during the build is lost.

2. 2

   Inventory the Divi layer

   List every page, post, project, Theme Builder template and its assignment, Library item, preset and third-party module in use. Note which plugins do real work and which only decorate.

3. 3

   Crawl the live URLs

   Record every indexed address, its title, description, canonical and status code. This list becomes the redirect map and the test plan.

4. 4

   Parse and clean the content

   Unwrap Divi 4 shortcodes or read Divi 5 block data, map each module type to clean fields, and load the result into the new CMS. Spot-check long pages by hand against the live site.

5. 5

   Rebuild templates as components

   Theme Builder headers, footers and body layouts become Next.js layouts. Presets become design tokens. The mobile menu is built once and tested on real phones, which retires problems like a Divi mobile menu that will not open.

6. 6

   Build and compare on a preview address

   Every page type is checked side by side with the Divi original: content, links, forms, images and metadata. Differences are either fixed or written down as intended.

7. 7

   Redirect and launch

   Changed addresses get permanent redirects in the Next.js config. DNS moves, the sitemap is submitted, and the old site stays archived, not deleted.

8. 8

   Watch the first weeks

   Search Console coverage, 404 logs, form submissions and Core Web Vitals field data are reviewed until the numbers settle.

Keeping the rankings Divi earned

Search engines rank addresses and content, not themes. Divi does not own your permalinks; WordPress does. So the default plan is to keep every URL exactly as it is, including project pages, category archives and any odd slugs a past editor invented. Where the new structure genuinely improves on the old one, each changed address gets a single permanent redirect to its new home, never a chain. Our guides on URL structure and redirect planning go through the details.

Titles and descriptions usually live in an SEO plugin, not in Divi, and they are exported separately and checked against the crawl. Schema that a plugin generated generically is rewritten per page type. Heading structure gets a second look too: Divi designs often use H1 and H2 tags for visual size, and a clean rebuild is the moment to put one real H1 on each page. The full checklist is in migrating without losing SEO.

Divi owns the look of your pages. It never owned the addresses, and that is what keeps the rankings safe.

What makes one Divi exit take longer than another

Two Divi sites with the same page count can be very different jobs. These are the drivers we price against after a free site audit, and the reason quotes are fixed only once the inventory is done.

• Third-party module packs. Each one is a new shortcode vocabulary to read and a decision about what its content becomes.
• Number of Theme Builder templates. A handful of templates is quick to map. Dozens, with overlapping assignments, take real untangling.
• Divi version state. A clean Divi 4 site or a fully converted Divi 5 site is simpler than one stuck halfway.
• WooCommerce. Products, orders and customers are their own project; see WooCommerce to Next.js.
• Forms and integrations. Every form, CRM connection and tracking script is listed, rebuilt and tested.
• Design changes. A faithful rebuild is faster than a redesign, though many owners take the chance to fix what annoyed them.

For how quotes are structured and how long each phase takes, read what a WordPress to Next.js move costs and the migration timeline. Payment plans exist through website financing.

From the Visual Builder to plain fields and a preview

Divi owners are used to editing on the canvas, and some will miss it. After the move, the site runs on Athena CMS: pages, projects and posts are plain fields with a real preview, and every version is kept, so a bad edit is one click from undone. What changes is that layouts are built in code. Owners edit words, photos, offers and projects; a new kind of page is developer work, which is also why it does not break when something updates.

Behind the editor sit AI agents that replace jobs Divi sites hand to plugins. Argus watches for broken links, failing forms and slow pages. Aegis checks daily for intrusions and backdoors. Picasso makes sure every image is described and sized. Iris handles search titles and social cards. How the handover works is described at switching from WordPress to Athena.

Not every Divi site should leave. A designer-run brochure site on the lifetime license may be better served by a careful Divi 5 upgrade from our Divi developers. If you are still deciding, the Divi vs Next.js comparison sets out both sides, the WordPress to Next.js hub covers the wider move, and our Next.js development team does the build when the answer is go.