Elementor Changes Not Showing Even After Clearing Cache — The Real Cause

There's one bug that burned almost three hours of my time the first time it hit: I edited a page in Elementor — moved a section, changed some text, fixed padding — clicked Update, opened the live page in an incognito tab, and… nothing changed. The page kept serving the old version.

Everyone's first reaction is the same: purge the cache. I purged WP Rocket. Purged Cloudflare. Hard-refreshed. Bumped the theme version so the ?ver= query changed. Still nothing. I was rebuilding a marketing site from Figma in Elementor for a client at the time, so the pressure was real.

It turns out that in 9 out of 10 cases, the problem isn't the cache we usually purge. It's somewhere rarely mentioned: Elementor's own internal cache.

Elementor stores rendered HTML separately from its data

This is the part that throws most people off. When you save a page, Elementor does not re-render from data on every page view. It stores the rendered output and CSS in several places at once:

• _elementor_element_cache — post meta holding rendered HTML
• _elementor_css — post meta holding CSS metadata
• _elementor_page_assets — the list of enqueued assets
• A physical file: wp-content/uploads/elementor/css/post-{ID}.css

When you change the layout data (whether through the editor, through update_post_meta('_elementor_data', …), or through a migration script), the data changes but those four caches don't. The page keeps serving the old HTML and CSS. And critically: simply visiting the page does not trigger a regeneration. These layers are not cleared when you purge WP Rocket or Cloudflare, because they aren't a page cache — they're Elementor's own cache.

So the real cache stack you're up against is layered:

browser → Cloudflare/CDN → page-cache plugin (WP Rocket, etc.) → Elementor's internal cache

Most people clear the first three layers and miss the fourth — which is exactly the one causing it.

The fix: invalidate Elementor's cache properly

Delete all four artifacts, then force Elementor to regenerate its CSS. Visiting the page isn't enough — you have to call the CSS generator explicitly:

$pid = 123; // ID of the broken page
 
// 1. Delete Elementor's HTML & CSS cache for this post
delete_post_meta( $pid, '_elementor_element_cache' );
delete_post_meta( $pid, '_elementor_css' );
delete_post_meta( $pid, '_elementor_page_assets' );
 
// 2. Delete the physical CSS file
$css_file = WP_CONTENT_DIR . "/uploads/elementor/css/post-{$pid}.css";
if ( file_exists( $css_file ) ) {
    @unlink( $css_file );
}
 
// 3. Force Elementor to rebuild the CSS (the step people skip)
\Elementor\Core\Files\CSS\Post::create( $pid )->update();

Step three is the key. Without ->update(), you've only deleted the old cache without producing a new one — and the page can render with no styling at all until something triggers a rebuild.

Via WP-CLI (for every page at once)

If your change touched many pages (for example after editing a global setting or running a migration), clear all of Elementor's CSS cache in one go:

wp elementor flush-css

If you need to be more aggressive, do a full regeneration:

wp eval '\Elementor\Plugin::$instance->files_manager->clear_cache();'

clear_cache() deletes every generated CSS file and all _elementor_css post meta — Elementor rebuilds them on demand. This is what I run every time a deploy touches Elementor data directly.

Follow-on symptom: suddenly unstyled header/footer & a giant logo

There's a downstream version of this bug that briefly made me panic. After Elementor's CSS cache is deleted but not yet regenerated, the site can render with no styling at all: the header and footer go bare, the logo blows up out of control, and double scrollbars appear.

The cause: on many installs, the CSS file for the active kit (e.g. post-9.css, where 9 is your Elementor kit ID) plays the role that global.css used to — global color variables, typography, container widths. When that file is gone and not yet rebuilt, the entire styling foundation of the site disappears.

The fix is the same: regenerate the kit's CSS explicitly.

# Find the active kit ID first
wp option get elementor_active_kit
 
# Regenerate (replace 9 with your kit ID)
wp eval '\Elementor\Core\Files\CSS\Post::create( 9 )->update();'

After that, post-9.css reappears and the site's styling recovers.

Checklist for "my Elementor edits won't show"

Next time you hit this, skip the guesswork and work top-down — from the innermost layer:

1. Confirm the data actually saved — check _elementor_data in the database. If it's old, the problem is in storage, not cache.
2. Clear Elementor's internal cache — the four artifacts above, then Post::create($id)->update(). This is the most common cause.
3. Then purge the page-cache plugin (in WP Rocket, "Clear Used CSS" too, not just "Clear Cache").
4. Then purge the CDN/Cloudflare.
5. Finally test in incognito or with DevTools "Disable cache" — browsers love to keep 301s and stale assets.

The key: start at the innermost layer (Elementor), not the outermost (browser). Almost every time it's "I purged everything but it still won't change," the answer is in Elementor's own cache, which an ordinary purge never touches.