Divi CSS Not Updating: Clear the Right Cache in the Right Order

Right in the builder, wrong on the live page

Stale Divi styles have a recognizable pattern, and Elegant Themes' own help center says the cause of a page that looks right in the Visual Builder and wrong outside it is usually cache-related. Before touching anything, note which of these you see. Each one points to a different layer.

• The builder shows the change; the published page does not.
• You see the change when logged in, but a private window or a customer's phone shows the old look.
• A page shows another page's styling, or the Theme Builder header looks different on some pages.
• Theme Options custom CSS changes nothing at all, even after several saves.
• After a Divi update, spacing, colors or row widths shifted across the site.

If the change does not even survive a reload inside the builder, you have a saving problem rather than a caching one. Elegant Themes' changes-not-saving guide lists security plugins, host firewalls, caching, Static CSS File Generation and minify plugins. The general mechanism across themes is in WordPress theme CSS not loading.

Where a Divi style travels after you click Save

Divi does not print most of your design straight into the page. It compiles builder settings, Theme Options and Customizer styles into stylesheet files, and its performance features split them further. With Dynamic CSS on (part of the Performance tab), each page gets a stylesheet built from the modules it uses, and Critical CSS sends above-the-fold styles first and defers the rest. Every one of those files can be cached again by a plugin, a host and a CDN.

The order matters. Clear Divi first so fresh files exist, then the caches in front of it from the inside out. Purge the CDN before Divi regenerates and the CDN simply fetches the old file again.

Who is serving the old style: five suspects

1. A page cache still names yesterday's stylesheet (Divi 4 and 5)

Cached HTML points at a particular CSS file. If the page cache was not purged after Divi wrote a new one, visitors keep receiving the old reference. Check: compare the page logged in and in a private window. If only the private window is stale, it is a cache in front of WordPress. On Divi 5, the vendor's menu troubleshooting guide suggests adding ?nocache=1 to the address as a quick bypass test.

2. Divi's own file failed to regenerate (Divi 4 and 5)

Elegant Themes says that if clicking Clear fixes the problem, invalid custom CSS probably made the file generation fail. Check: paste your Theme Options custom CSS, module CSS and Code module styles into a CSS validator. Missing braces are the usual culprit. If clearing does nothing, the folder may not be writable: Divi's Support Center system report includes a Writable et-cache Directory check, added in Divi 4.22.1. The vendor also notes some hosts block generation or need the cached file deleted by hand in the file manager.

3. An optimizer made its own copy (Divi 4 and 5)

Minify and combine features write new CSS files from Divi's files and cache them separately from pages. Check: in the page source, look for stylesheet addresses inside a cache plugin's folder with hashed names. Switch combining off, clear everything, and test. If that fixes it, let Divi handle CSS and keep the plugin to page caching.

4. The style is being set somewhere stronger (Divi 4 and 5)

Not every stale-looking style is stale. A module's own Advanced, Custom CSS field, a preset, a Theme Builder template or a rule in the child theme can beat the setting you changed. Check: inspect the element and read which rule wins. On Divi 5, option group presets and design variables add two more places a value can come from.

5. The child theme stylesheet kept its old version (Divi 4 and 5)

A child theme loads its style.css through functions.php, usually with a version number. If that number never changes, browsers and CDNs are entitled to keep their copy. Check: open the child stylesheet's address from the page source and look at the ver= value. Bump it whenever you edit the file.

The clearing sequence that sticks

1. 1

   Confirm the save

   Reload the page in the Visual Builder. If the change is gone there too, fix saving first, starting with security plugins and firewalls.

2. 2

   Clear Divi's CSS

   Divi 4: Divi, Theme Options, Builder, Advanced, then Clear beside Static CSS File Generation. Divi 5: Divi, Theme Options, then Clear CSS Cache at the top right.

3. 3

   Purge the caching plugin

   Use purge-all, and clear its separate CSS and JavaScript optimization cache if it has one.

4. 4

   Purge host cache and CDN

   Server cache first, then the CDN, so the CDN refetches fresh files.

5. 5

   Test logged out

   Use a private window and a phone on mobile data, which skips your office network's caches.

6. 6

   Validate custom CSS

   If styles still lag, check every custom CSS location for syntax errors: Theme Options, page settings, module settings, Code modules and the child theme.

7. 7

   Test in Safe Mode

   Divi, Support Center, Safe Mode disables plugins for your login only. If styles update there, a plugin is interfering.

8. 8

   Only then switch static files off

   Turning Static CSS File Generation off is a diagnostic step the vendor suggests, not a permanent setting. Its own description says the option should stay enabled for best loading times.

What Divi 5 changed about its CSS cache

Divi 5 rebuilt the file system behind these styles, and its changelog shows how much of the work concerned caching plugins. During the public beta, Elegant Themes changed Divi to mark old CSS files as stale instead of deleting them, so pages cached by a performance plugin can still find their stylesheet. The same release added automatic cache clearing for more plugins, including FlyingPress, NitroPack, Super Page Cache, SpeedyCache, WP Compress, Swift Performance and the Cloudflare plugin.

• 5.2.1 fixed WP-Optimize's page cache not always clearing after Divi's static CSS was cleared, which left logged-out visitors with broken styles.
• 5.3.1 fixed archive pages showing unstyled post content because Divi's archive CSS cache was not invalidated when a post changed.
• 5.7.0 fixed Theme Builder pages that could generate incomplete critical or deferred CSS after partial cache invalidation.
• 5.8.0 and 5.12.0 stopped a page save from purging all of LiteSpeed Cache, and the whole third-party page cache on Cloudways and similar hosts.

The lesson: on Divi 5, update before you debug. A stale-style fault you are chasing may already be fixed in a later release. Elegant Themes' guide to display issues after a Divi 5 update starts with the same cache sequence above, then custom CSS and unclosed tags in a module's HTML Before and HTML After fields. If an update did more than change colors, read Divi layout broken after an update.

Making the next change show up the first time

• Run one page cache. A plugin cache stacked on a host cache doubles the places old HTML can hide.
• Turn on purge-on-save in the caching plugin, and confirm it fires after a Divi save.
• Give CSS work to one tool. Divi's Dynamic CSS and Critical CSS should not have a rival minifier.
• Keep custom CSS in as few places as possible, and validate it before you paste it.
• Version the child theme stylesheet every time it changes.

The Divi speed guide explains which Performance tab options to keep and why. Stale styles also make menus misbehave and fonts vanish, so if those are on your list, see the Divi mobile menu fix and Divi fonts not loading. The wider set of Divi faults, including the Divi builder that will not load, lives in the Divi repair hub. Our hosting and maintenance plans set these cache rules once and check them after every update.

Six caches for one color change is a design choice

Every layer in that table exists for a reason. Divi compiles CSS to keep pages light, the caching plugin exists because WordPress builds pages on every request, and the CDN exists because the server is far from most visitors. Each fixes a real problem. Together they turn a button color into a purge ritual someone has to remember, and the site's appearance depends on the least reliable step.

A Next.js build compiles styles at build time into files whose names change when their contents change, so a deploy cannot leave an old stylesheet in front of visitors. Content editors work in Athena CMS with a real preview of the published page. That route costs more up front and layout changes need a developer. Weigh it in Divi vs Next.js and the Divi to Next.js migration guide. If you would rather keep Divi and have someone else chase the cache, our theme troubleshooting team does exactly that. More fixes live in the troubleshooting section.