How to inspect what a page builder stored in the database

A quote for moving a site off a page builder is usually assembled from the wrong evidence: a page count from the sitemap and a look at the front end. Both are reasonable. Neither says what the pages are made of.

Disclosure: WPSifero earns a commission on sales made through the Elegant Themes link in this article. The price you pay is the same. Nothing here is a review: nobody at WPSifero has built a site in Divi, the queries below come from standard SQL behaviour rather than from a Divi site inspected for this article, and every statement about the product is taken from Elegant Themes' own published pages, cited where it is used.

The browser receives the rendered result: sections, rows, text, images. The database receives the instructions. On a Divi site those instructions changed between major versions. Elegant Themes' documentation states that Divi 4 stored a page as shortcodes in the post content, for example [et_pb_text ...], and that Divi 5 uses a block-based framework which does not use shortcodes. The same page can look identical in either format, which is why a visual inspection cannot price the work.

This is a procedure for looking, not a review of the product. The queries are ordinary SQL, and the interpretation rules come from Elegant Themes' own published documentation, cited where they are used.

What a database check can and cannot tell you

The check is one column. WordPress stores the body of a post or page in wp_posts.post_content, and a page builder either writes its own markup there or it does not. For Divi, the difference between the two storage formats is visible as a string: shortcode brackets in one, a block comment namespace in the other. The whole inspection is a copy, a few queries and a read of the rows that come back. The examples test posts and pages; custom post types are separate rows in the same table, so a query that filters them out cannot speak for them.

Documentation and database answer different questions. Elegant Themes' pages describe what each format is meant to be. The database describes what an installation contains after several years of edits, a stalled migration and a plugin that was removed. A useful inspection uses the documentation to interpret the string and the string to correct the assumption. Neither source is sufficient alone.

A copy is the right place to start. Run the queries against a staging database or a read-only replica; the statements only read, but a LIKE scan over post_content still walks rows, and production is a poor place to discover the size of the table. Confirm the table prefix in wp-config.php first. The examples use wp_, and an install that changed the prefix usually fails loudly rather than returning nothing, which is the easier failure to notice.

Two characters in the pattern are worth a sentence. In MySQL and MariaDB, square brackets are literal, so [et_pb_ needs no escape. The underscore is a single-character wildcard, so '%[et_pb_%' formally matches any character where the underscore sits. It still matches the literal shortcode, and it will also match a string that differs in that one position. A strict version escapes the underscore: '%[et_pb\_%'. The distinction matters only when a query returns a row that is not a shortcode, which leads to the preview column below.

The shortcode test, and the count that changes the quote

Divi 4's format leaves a fingerprint. A page built with it contains a shortcode whose name begins et_pb_, because that was how the builder handed a module to WordPress to render. The first query lists the rows that carry the fingerprint and shows enough of each one to judge it.

SELECT ID, post_type, post_status, post_title,
       LEFT(post_content, 160) AS preview
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status IN ('publish', 'draft', 'pending', 'private', 'future')
  AND post_content LIKE '%[et_pb_%'
ORDER BY post_modified DESC;

The preview does the work that a count cannot. A row whose preview opens with [et_pb_text is a page stored in the Divi 4 format. A row whose preview is an article about shortcodes is a false positive: the string is in the page because the page discusses it. There is no query that tells the two apart without reading the text.

The second query counts. It is the number that changes a quote, because a site with a handful of builder pages and a site where the builder holds nearly every page are the same format and different projects.

SELECT post_type, COUNT(*) AS rows_with_shortcodes
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status = 'publish'
  AND post_content LIKE '%[et_pb_%'
GROUP BY post_type;

Two filters in that query do real work. post_type IN ('post', 'page') excludes revisions, which also live in wp_posts and would inflate any count of pages. The status filter excludes drafts, while the listing query deliberately includes them: a migration that stopped halfway often leaves drafts in the old format, and those rows are part of the story even though they are not published.

Compare the count with the number of published posts and pages, so the result has a denominator:

SELECT post_type, COUNT(*) AS published_rows
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status = 'publish'
GROUP BY post_type;

A handful of shortcode rows against a large published page count describes a Divi 4 site with a little builder content. A shortcode row count that matches the published page count describes a Divi 4 site where the builder is the site. Both return rows for the shortcode test. Only one of them makes the migration the main project.

The block test, and the control that makes it readable

Elegant Themes' Migrator documentation describes the Divi 5 framework as block-based rather than shortcode-based. That changes the test from a bracket search to a block search, and the namespace to look for is wp:divi/.

SELECT ID, post_type, post_status, post_title,
       LEFT(post_content, 160) AS preview
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status IN ('publish', 'draft', 'pending', 'private', 'future')
  AND post_content LIKE '%wp:divi/%'
ORDER BY post_modified DESC;

A null result is only meaningful if the query could have returned a row. That is what a control is for. Core blocks live in the same column, so a search for wp:paragraph should find content on any site that has used the block editor. Running both counts in one statement makes the difference visible:

SELECT
  SUM(post_content LIKE '%wp:divi/%')     AS divi_block_rows,
  SUM(post_content LIKE '%wp:paragraph%')  AS core_block_rows
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status = 'publish';

If core_block_rows is zero on a site with published pages, the control has not proved anything: the query may be pointed at the wrong table or prefix, the content may not be in post_content, or the site may have no core block content. The shortcode count from the previous section is the better control in that case. Rows there prove the table and prefix are right, so a zero Divi block count is a real zero; no rows there leaves the storage question open rather than answered. If the core count is healthy and the Divi count is zero, the site has no rows in the Divi 5 block format. If both counts are above zero, the site has Divi block content and core block content, and whether shortcodes are also present is the other test.

The block test has the same false-positive problem. A tutorial page that quotes the block markup contains the namespace without being built from it. The preview column exists for this, and a count is a map rather than the territory.

Reading the result: three formats, four answers

The two tests together put the posts and pages in one of four states, and each has a different consequence.

A site returning rows for the shortcode test only is a Divi 4 site. A site returning rows for the block test is already on the Divi 5 framework. A site returning both is mid-migration. That last reading is not speculation: Elegant Themes' documentation on the Migrator states that supported modules are converted, and that modules not yet supported continue to run wrapped in the Divi 4 framework. The same documentation states that a page containing one of those modules loads the Divi 4 framework for that page, which Elegant Themes says can affect performance. The performance caveat is theirs, and this article adds no measurement to it.

Both does not always mean mid-migration. A page that quotes a shortcode in a code sample, or a tutorial page that quotes the block namespace, can produce the same pair of strings. Counting rows that contain both is worth the extra query before the site is described as halfway through anything:

SELECT COUNT(*) AS both_rows
FROM wp_posts
WHERE post_type IN ('post', 'page')
  AND post_status = 'publish'
  AND post_content LIKE '%[et_pb_%'
  AND post_content LIKE '%wp:divi/%';

Storage is not structure. Elegant Themes' documentation defines a global library item as a Module, Row or Section that appears the same on whatever pages it is added to, and editing it changes every page that uses it. A search of post_content searches page records, so it counts pages, not edits. On a site that uses shared items, a migration estimate built only from row counts is describing a different job.

What the storage format decides

The format is not a quality verdict. Shortcode-era Divi 4 content and Divi 5 block content are both legitimate outputs of the product, and a site can run on either. What the format decides is what can be done next.

Three consequences follow from where the words sit. Migration tooling has to understand the format it finds, and a site that contains both requires it to understand both. Search and replace has to work around the encoding: a shortcode carries settings in the same string as the text, and a block carries them in an attribute payload, so a naive replacement of a phone number can hit a setting as easily as a paragraph. And the exit from the builder depends on what renders the page: a shortcode depends on the code that registers it, and a block depends on the block being registered. Neither is a promise of portability, and a block-based format is not the same thing as core blocks.

Those three consequences become questions for any builder's support before committing to it. Where is page content stored? What happens to a page if the builder is deactivated? What does the migration path do with modules that are not supported yet? A vendor that answers in writing has given a better basis for a decision than a demo has.

For Divi, the licence sits alongside the storage question. Elegant Themes' pricing page, as published on 2026-10-19, lists Divi at $89 billed yearly and Divi Lifetime at $249 as a one-time payment; the page's own comparison table sets one year at $89 against ten years at $249. Prices change, so check Elegant Themes' current pricing page for Divi before relying on either figure. If the inspection says the site stays on Divi, the choice between annual and lifetime is the next decision. If it says the site is halfway through a migration, the licence is not the next decision.

The rule is not "pick blocks" or "pick shortcodes". It is to inspect before quoting and quote the format that is actually there. Run the shortcode search, run the block search, count the rows, and read the previews. Shortcodes only means a Divi 4 site and a migration project. Divi blocks only means the shortcode question is settled. Both means the count of both rows is the place to start, because Elegant Themes' documentation says a page with an unsupported module keeps the Divi 4 framework. Neither means no Divi content in the posts and pages tested, which is a useful answer about where not to look.