Evaluating a page builder in an afternoon, on a staging site
Six tests a team can run on a staging site in one afternoon, covering reusable headers, custom post types, content exports and the editor who changes a price.
Priya Raghunathan · @praghunathan
Frontend and accessibility
- Topic
- WP
- Section
- WordPress Internals
- Published
- 19 OCT 2026
- Reading time
- 9 MIN
- Words
- 2156W
The question that arrives before a page builder quote is which one is best. That cannot be answered in an afternoon. The answerable question is narrower: will this builder still fit this site in two years, when the person who chose it has moved on and somebody else is changing a price?
A builder decision fails in patterns a demo does not show. A price is typed into a layout instead of stored once, so changing it means editing several places. A header is rebuilt on every page, so a new phone number takes a morning. An export is full of layout instructions and almost no prose, so leaving is a retyping project. None of that concerns page quality. It concerns the shape of the site built with it.
This is analysis, not a review. Nobody at WPSifero has installed Divi or built a site with it, and the six tests below have not been run on Divi by anyone here. Product facts come from Elegant Themes' own published pages, cited in the sentence that uses them.
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 tests below are described rather than performed on Divi, and every statement about the product is taken from Elegant Themes' own published pages, cited where it is used.
A review reports on a site you will never log into
A review reports one installation. The writer had a content model, a set of plugins and a tolerance for how the builder handles an awkward page. A conclusion that it is easy for clients is a conclusion about those clients and that site; the variables are not published with the verdict and do not transfer.
A demo is the same problem in purer form: clean text, no irregular content, nobody editing at five on a Friday. It shows the tool can produce that page, and says nothing about a price that changes every quarter or an export somebody else has to read.
Divi is the builder this piece can cite, because Elegant Themes publishes documentation and WPSifero is in its affiliate programme. That is a reason for care with claims, not for a verdict. The tests produce observations about a staging site, the only site whose behaviour a reader can check.
What the afternoon needs before the first test
Four things, none of them a demo account.
- A staging copy of a real site, or a clean install loaded with real content: home, a services page with a price, a post, a page with a form, and one entry of a custom post type.
- A second install with the builder absent.
- An editor account for a colleague who does not work on the site.
- A browser with a JavaScript switch and a text editor for the export.
Write down the result that would end the evaluation before starting. A business that changes prices weekly cannot accept a price inside a layout. A staff directory cannot accept a builder that edits the body and hides the fields. That constraint turns six observations into a decision.
Keep a record with four columns: test, time, clicks, what happened. Impressions are cheap and memory is unreliable an hour later. The record makes the test repeatable after an update.
test minutes clicks fatal? what happened
1 reusable header ____ ____ ____ ______________________
2 custom post type ____ ____ ____ ______________________
3 export and read ____ ____ ____ ______________________
4 JavaScript off ____ ____ ____ ______________________
5 price change ____ ____ ____ ______________________
6 exit clicks ____ ____ ____ ______________________
If a test cannot be set up in half an hour, write down why. Setup friction is a result too.
The first three tests are about content that has to survive
The order follows how content fails: reuse, then structured data, then removal. Each test separates an expensive result from a fatal one by whether the task recurs every month or happens once, badly.
Test one: a reusable header, changed in one place
Elegant Themes' documentation states that a global library item is a Module, Row or Section that appears the same on whatever pages it is added to, and that editing it changes every page that uses it. Build a header as a global item, add it to three pages, change one word, reload all three.
Look for three changed pages, one library entry edited on its own, and no page holding the old header. A page that did not change means the header was copied rather than referenced, and every design change repeats per page. The builder may draw well; the site has no shared header.
That is fatal where one person maintains a consistent design, because the work grows with page count and the drift stays invisible until two pages disagree. A five-page site redesigned before it is edited survives it.
Test two: a custom post type, and where the builder stops
WordPress lets a plugin register a post type with its own fields. Put three entries into staging, open one in the builder, and change the body and a field without leaving the interface. Then open the archive and decide which tool draws it.
A builder can stop at the edge of the post body. The body is what it owns; the fields belong to the post type, so a builder that does not know them shows the body and hides the data. The editor gets two screens and no rule about which holds the price.
Look for one screen that changes both, and a listing page with the same design vocabulary. If the archive is a theme template outside the builder, the site has two design systems. A brochure site passes by having nothing to test; a directory fails in a way builder skill does not fix.
Test three: export the content and read what came out
Use the WordPress export tool, open the file, and find one page. Is the prose readable? 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. Either format can put the text in the export; the difference is how much of the file is instruction.
Look for readable paragraphs separated from decoration. Attributes with the text buried inside mean a move keeps the words and loses the design. No words at all mean the content lives outside the post body, and leaving is retyping.
The migration path matters: it shows how old content is treated. Elegant Themes' documentation states that the Divi 5 Migrator converts supported modules, that unsupported modules keep running wrapped in the Divi 4 framework, and that a page containing one loads that framework for the page, which they say can affect performance. That is their sentence, not a measurement here. It suggests a count: how many pages hold an unsupported module, and whether the site can carry them while the rest move.
The last three tests are about everyone who is not the builder
The next three are about the people around it: the reader without script, the editor without a developer, the owner who wants to leave. None is a performance measurement.
Test four: load the page with JavaScript disabled
Turn JavaScript off, reload, and read the screen. Are the body text and the price in the response, or is the page a shell that fills in after script runs? A page that shows nothing is not broken for everyone; its content depends on code executing.
Look for the words, price and links without script. This is not an accessibility audit and says nothing about a screen reader. It says what the site offers to anything that reads HTML without script: a feed, a print view, an archive.
That is fatal only when the site's purpose is to be read as text and the text is missing. For a marketing page whose job is a form, a blank no-script page is a warning, not a rejection.
Test five: hand a price change to somebody non-technical
Create an editor account for a colleague who does not build sites, and ask them to change the price on the services page. Do not point at the field. Watch where they click, count the minutes, note whether they ask which page the price is on, then ask them to change it back.
Look for one obvious place where the number lives, a preview in context, and a publish step they understand. A price is data. If the editor finds it inside a text module, the site is using a layout as a database, and the next change will be done the same way with less patience.
If the editor cannot finish without touching layout, or must change the number in more than one place, the site will accumulate wrong prices. A better builder does not fix that. Ten minutes of guidance with one obvious place is a pass.
Test six: count the clicks it takes to leave
Three exits. Deactivate the builder on staging and load a page: if raw shortcodes such as [et_pb_text ...] appear, the content without its interpreter is unreadable. Export and import into the clean install: count what survives. Then build one page in another tool: count the steps from blank to signed off.
Look for the number of steps and what is lost at each. A builder that stores readable text has a short exit; one that stores layout instructions has a long one, and the length belongs next to the renewal price.
That price is the last input. 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, both covering unlimited websites, and the comparison table on that page sets one year at $89 against ten years at $249. Prices change, so read the page rather than this paragraph. Ten years is a purchase with a migration at the end; two years is a rental whose exit cost has to be paid inside the term.
If leaving requires retyping and nobody budgeted for it, the licence is not a subscription. It is the price of not doing a migration, and the proposal should say so.
The failures that end the evaluation
Not every failure is fatal. The middle column ends the evaluation for a site with recurring content work; the right column costs money that can be planned for.
| Test | Ends the evaluation | Costs money, can be planned |
|---|---|---|
| 1. Reusable header | The header must be changed on every page | The header is global, but the builder needs training |
| 2. Custom post type | The editor needs two screens and duplicates the data | The archive is a theme template outside the builder |
| 3. Export | The prose is not in the export | The layout is lost and the text survives |
| 4. JavaScript off | The text is absent and the site exists to be read | The page is blank, but the site's job is a form |
| 5. Price change | The editor cannot do it without touching layout | The editor needs a guide and one obvious place |
| 6. Exit | Leaving requires retyping the content | Leaving requires rebuilding templates only |
A builder that cannot be left without retyping is wrong for a site whose owner may sell or hire another agency. A builder whose archive sits outside the tool is wrong when the listing pages are the product.
The checklist cannot say whether the vendor will support the product in three years, or whether the output will look dated. Those are judgment calls with no test, and a review has no evidence either.
Test the site, not the product
If test one, three or five fails fatally, stop: the price and the feature list do not matter, because the site cannot do the work it will be asked to do every month. If test two, four or six fails, price the work and put it in the proposal. If all six pass, choose on fit and licence.
A review cannot substitute. It is a conclusion about somebody else's site, and the variables behind it are not in the text. The checklist measures the reader's own staging copy, and repeats when the builder updates or the client hires an editor.
WPSifero has not run these six tests on Divi. That is why this is a checklist and not a verdict: a verdict would describe a site this publication does not have. The tests are the honest alternative to trusting a review, including any review this site might publish.
Run them in order, write down what happened, and let the site answer. A review tells you what somebody else concluded about theirs. The checklist tells you what will happen to yours.
Priya Raghunathan · @praghunathan
Frontend and accessibility
Reviews interfaces for what happens when JavaScript fails, the keyboard is the only input, and the connection is slow. Focused on Core Web Vitals, semantic markup and progressive enhancement.
Continue