Skip to content
System nominalUTC --:--:--Articles 107

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
Technical cover graphic for Evaluating a page builder in an afternoon, on a staging site
Generated schematic — WP series, REV 2.6.

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.

TestEnds the evaluationCosts money, can be planned
1. Reusable headerThe header must be changed on every pageThe header is global, but the builder needs training
2. Custom post typeThe editor needs two screens and duplicates the dataThe archive is a theme template outside the builder
3. ExportThe prose is not in the exportThe layout is lost and the text survives
4. JavaScript offThe text is absent and the site exists to be readThe page is blank, but the site's job is a form
5. Price changeThe editor cannot do it without touching layoutThe editor needs a guide and one obvious place
6. ExitLeaving requires retyping the contentLeaving 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

Related in WordPress Internals