A page builder decides how almost every page on your site is stored, edited and displayed. That is why a fault in Divi, WPBakery, Beaver Builder or a similar tool feels so total: one bad update or an expired licence and suddenly the homepage, the service pages and the landing pages all misbehave together. This page covers the builders other than Elementor (which has its own repair page), the problems we see most with them, what you can safely check, and how we put things right. If you are still working out what kind of fault you have, our WordPress error guide is the place to begin.
Why builder problems behave differently from other WordPress errors
Most plugins add one feature. A builder replaces the way content is written. Each builder saves your layouts in its own format, and only that builder knows how to turn the format back into a finished page. That has two practical consequences.
First, the builder cannot simply be switched off to see whether it is the culprit. With some builders, deactivating them turns every page into a wall of bracketed codes. Second, the builder is often tied to something else: a theme, a licence, an add-on, or a specific version of PHP or WordPress. A problem that looks like “the builder broke” is regularly one of those ties coming loose.
Older builders were designed around shortcodes, the bracketed tags WordPress uses to let plugins insert content. Divi and WPBakery have historically stored layouts this way, which is why codes such as [et_pb_section] or [vc_row] appear in the page text when the builder is not running. Newer approaches store structured data instead. Neither is wrong, but it changes what a fault looks like and how risky a fix is.
Common problems by builder
Divi
- The Visual Builder will not load or loads with missing controls. Usually a plugin clash, a caching or optimisation plugin interfering with the builder’s scripts, or too little server memory.
- Styling missing or out of date on the live site. Divi can generate static CSS files for speed. When those files are stale, or cached again by another plugin or a CDN, visitors see an older look.
- Updates refuse to install. Divi updates through Elegant Themes’ own system rather than the WordPress.org directory, so the theme options need a valid account username and API key. When those are missing or the membership has lapsed, the site quietly stays on an old version.
- Codes on the page after a theme change. Switching away from the Divi theme without keeping the Divi Builder plugin active leaves the shortcodes behind.
Divi’s Support Center, inside the theme’s menu, includes a safe mode that temporarily sets other plugins and customisations aside for your session. It is a useful first test.
WPBakery Page Builder
- Bundled with the theme. Many commercial themes include WPBakery. A bundled copy usually only updates when the theme’s developer ships a new version of it, so an old theme often means an old builder, with the compatibility problems that follow.
- Raw codes showing instead of layouts. If WPBakery is deactivated, removed, or fails to load because of an error, pages display
[vc_row]and[vc_column]tags as plain text. - Front-end or back-end editor blank. Script conflicts and old add-ons written for an earlier WPBakery release are frequent causes.
- Licence confusion. A theme’s bundled copy and a separately bought licence behave differently for updates and support, and owners are often not sure which one they have.
Beaver Builder
- Editor not launching or saving. As with other builders, script clashes, security rules and memory limits are the usual suspects.
- Stale layout styling. Beaver Builder caches the CSS and JavaScript it generates; its settings include a tool to clear that cache, which should be followed by clearing any site or server cache.
- Theme and add-on drift. Beaver Builder is often paired with its own theme and with third-party add-on packs, which need to stay in step with the builder version.
Other builders
We also work on sites built with tools such as Oxygen, Bricks, Thrive Architect and block-based toolkits that extend the WordPress editor. If your trouble is with the standard block editor itself rather than a third-party builder, see our post on block editor problems.
What you can check without making it worse
Take a full backup of files and database first. With a builder this matters more than usual, because the layouts live in the database and a careless test can change many pages at once.
- Do not deactivate the builder on the live site to test it. On shortcode-based builders this immediately exposes raw codes to every visitor. Use the builder’s own safe mode or a staging copy instead.
- Find out where your builder comes from. In the Plugins screen, check whether the builder is a standalone plugin or was installed by the theme (often listed as a “required” or “recommended” plugin). That tells you who supplies its updates.
- Check licences and update keys. Expired or missing keys are a very common reason for an outdated builder.
- Clear the builder’s cache, then every other cache. Builder caches, caching plugins, host caches and CDNs can each hold an old copy.
- Note what changed recently. A theme update, a PHP change by the host, a new plugin, or a builder update. If the trouble started straight after one of these, our post-update repair page explains the rollback options.
- Look at one page in detail. If only one page is wrong, the problem is likely content on that page. If every builder page is wrong, the problem is the builder, its files or something loading alongside it.
How we repair page builder sites
Map the stack first
Before changing anything we write down the builder, its version and where it is updated from, the theme and whether it bundles the builder, every add-on pack, and the PHP version. Builder faults are so often caused by one of these drifting out of step that the map frequently points to the answer by itself.
Diagnose on a clone
We make a backup, clone the site to staging and reproduce the fault there. That lets us switch builders, add-ons and themes on and off freely without a single visitor seeing raw shortcodes or a broken homepage.
Fix at the source
Depending on what we find, the fix may be bringing the builder up to date through the correct channel, updating or removing an add-on that no longer keeps pace, regenerating the builder’s CSS, adjusting an optimisation plugin so it leaves the builder’s scripts alone, or correcting broken content on individual pages. When a page’s layout data has been damaged, we compare it with the backup and restore only that page rather than rolling back the whole site.
Check the whole site, not just the reported page
Builders reuse global elements such as headers, footers, theme templates and saved modules. A fix that solves one page can affect others, so we review the main templates and a spread of pages on desktop and phone before the change goes live. Problems that turn out to be wider styling faults are handled under our layout broken repair work, and pages that load with nothing in the content area are explained in our post on pages that load blank.
When repair is not the best answer
Sometimes the honest conclusion is that a site is held together by an outdated bundled builder inside a theme that no longer receives updates. Repairing it buys time, and we can do that, but each future PHP or WordPress change will raise the same questions. In that situation we lay out the choices plainly: keep repairing, move to a maintained version of the same builder, or rebuild key templates on a different foundation. A full rebuild belongs with our website redesign service; smaller changes to an existing theme are covered by theme customisation.
Builder faults are part of what our WordPress bug fixing service takes on. Tell us which builder you use, what you see (a screenshot is ideal) and what changed recently, and you will hear back with a straight account of the fault, and of what fixing it involves, before any work starts.