If you saved a change in Elementor and the live page still looks old, something is serving a stored copy. Clear Elementor’s own files first (Elementor → Tools → Clear Files & Data), then your caching plugin or host cache, then Cloudflare, and check in a private window last. Going in that order stops one layer from quietly re-caching the old version from another.
This is one of the most common “is my site broken?” moments in WordPress. You hit Update, the editor shows your new heading, new colours, new button, and then the live page shows exactly what was there before. Refresh. Still old. Refresh again on your phone. Still old.
Your change almost certainly saved. The problem is that a modern WordPress site keeps several copies of every page so it can load faster, and at least one of those copies hasn’t been told that anything changed. We run into this constantly while building and maintaining client sites, especially on hosts that add their own server cache on top of a caching plugin. The fix is rarely difficult once you know where the copies are kept.
First, find out which layer is serving the old page
Before clearing everything, spend thirty seconds working out where the stale copy lives. It tells you what to fix, and whether it will happen again.
- Open the page in a private or incognito window. If the new version appears there, the problem is only your browser’s cache. Jump to the last step below.
- Add a random query string to the URL, for example
https://yoursite.com/page/?nocache=4821. Most page caches treat this as a different URL. If the new version appears now but not on the normal URL, a page cache (plugin, host or Cloudflare) is holding the old copy. - If even the query-string version is old, the stale content is coming from Elementor itself: its generated CSS files or its Element Cache. Start with the first fix below.
The query-string trick is also how we check API work. When a site’s host caches REST API responses, adding ?_t= plus a timestamp to each request forces a fresh answer every time.
- Your browserStored copies of CSS, JavaScript and images on your own device
- CDN (e.g. Cloudflare)Edge copies of files served close to the visitor
- Server or page cacheLiteSpeed, NGINX or a caching plugin storing finished HTML
- Elementor Element CachePre-rendered widget HTML, kept for 1 day by default
- Elementor CSS filesGenerated post-XX.css files in /uploads/elementor/css/
Clear from the bottom up: Elementor first, browser last.
Fix 1: Clear Elementor’s files and data
Elementor doesn’t just save your design. It turns it into CSS files (stored in /wp-content/uploads/elementor/css/) and, on current versions, also stores pre-rendered HTML for elements. If those generated files are out of date, every other cache will faithfully keep serving the wrong thing.
- In your WordPress dashboard, go to Elementor → Tools.
- On the General tab, find Elementor Cache and click Clear Files & Data.
- Wait for the spinner to finish. Elementor rebuilds the files the next time anyone visits a page, so the first load afterwards may be a little slower.
This button used to be called “Regenerate CSS & Data” in older versions, so older tutorials may use that name. It does the same job.
Fix 2: Check Elementor’s Element Cache setting
Newer versions of Elementor include a feature called Element Cache. It stores a ready-made copy of each widget’s HTML so pages don’t have to be rebuilt on every visit. By default, that copy is kept for 1 day.
That’s normally fine, because saving a page in the editor clears its cache. But if the content changes some other way, the old copy can survive until it expires. We’ve seen this with:
- widgets that pull in dynamic content, such as a shortcode or a “latest posts” list;
- pages updated by a script, an import tool or the REST API instead of the editor;
- migrations and search-and-replace jobs that edit the database directly.
You can find the setting under Elementor → Settings → Performance → Element Cache. The options run from Disable to 1 Year. For a site that changes often, a shorter time such as 1 hour or 6 hours is a sensible middle ground. You can also turn caching off for a single widget: select it in the editor, open the Advanced tab and set Cache Settings to Inactive.
If you edit _elementor_data directly (with a plugin, script or the REST API), Elementor does not know the page changed. Always clear Elementor’s files afterwards, or your edit will not appear until the cache expires.
Fix 3: Purge your caching plugin or host cache
Next comes the full-page cache. This stores the finished HTML of each page and is usually the biggest speed win on a WordPress site. It is also the most common reason a change stays invisible.
Where to purge depends on what your site uses:
| Cache | Where to purge it | Good to know |
|---|---|---|
| LiteSpeed Cache | LiteSpeed Cache → Toolbox → Purge → Purge All | Common on cPanel hosts running LiteSpeed web server. |
| WP Rocket | Admin bar → WP Rocket → Clear and preload cache | Preloading rebuilds pages so visitors don’t hit a cold cache. |
| W3 Total Cache | Admin bar → Performance → Purge All Caches | Also clears its minified CSS and JS. |
| WP Super Cache | Settings → WP Super Cache → Delete Cache | Simple file cache; clears quickly. |
| Host server cache | Your hosting panel (for example SiteGround, Cloudways Breeze or a “Varnish” / “NGINX cache” button) | Some hosts add this silently. If nothing else works, ask your host whether it exists. |
The last row is the one that catches people out. Some hosts run a server-level cache that sits in front of WordPress and doesn’t show up in your plugin list. On one site we worked on, pages and even REST API responses kept coming back stale for hours, and no plugin setting changed anything. The query-string test from the start of this guide was what proved the host’s cache was responsible.
Fix 4: Purge Cloudflare (or another CDN)
If your domain runs through Cloudflare with the orange cloud (proxy) switched on, Cloudflare may be caching your files at its edge servers around the world.
- Log in to Cloudflare and select your domain.
- Go to Caching → Configuration.
- Under Purge Cache, choose Custom Purge to clear specific URLs, or Purge Everything if you changed site-wide styles.
Cloudflare recommends purging only the URLs you changed where possible, because purging everything makes the next few visits slower while its cache refills. For a one-off Elementor style change, clearing a handful of URLs is usually enough.
By default Cloudflare only caches static files such as CSS, JavaScript and images, not your HTML pages. So if only your styling looks old, Cloudflare is a likely suspect. If your text is old, look at your page cache first.
Fix 5: Clear your browser cache last
Finally, make sure you aren’t looking at a copy stored on your own device.
- Windows and Linux: press Ctrl + F5 or Ctrl + Shift + R for a hard reload.
- Mac: press Cmd + Shift + R.
- Phone: open the page in a private tab, which ignores the stored copy.
Why the order matters
It’s tempting to clear everything at once, but order makes a difference. If you purge Cloudflare first and someone visits before you clear your page cache, Cloudflare can grab the old page again from your server and cache it for another few hours. Clearing from the inside out (Elementor, then server, then CDN, then browser) means each layer refills from a copy that is already up to date.
When clearing caches doesn’t fix it
If you’ve cleared every layer and the page is still wrong, the issue probably isn’t caching. Check these before anything else:
Quick checks
- Did you edit the right page? Duplicated pages and drafts often share a title.
- Is a theme builder template (header, footer or single post) overriding your page?
- Is the change inside a global widget or template that saved separately?
- Does the page have a responsive setting hiding the element on desktop or mobile?
Deeper causes
- A security plugin or firewall blocking Elementor’s save request.
- A PHP memory limit too low for the page, so the save silently fails.
- File permissions preventing Elementor from writing CSS to
/uploads/. - Staging and live sites pointing at different databases.
A useful test: open the page in Elementor again. If your change is missing in the editor too, the save failed and caching isn’t the issue. Look at your browser’s console (F12) while saving for a red error, and check that your PHP memory limit is at least 256 MB.
Your change is almost always saved. Clear Elementor’s files first, then your page cache, then Cloudflare, then your browser. If a site keeps doing this, lower Elementor’s Element Cache time and ask your host whether they run their own server cache.
Frequently asked questions
Does clearing Elementor’s cache delete my designs?
No. Clear Files & Data only removes generated CSS files and cached HTML. Your pages, templates and settings are stored separately and are not touched.
Why do my changes show when I’m logged in but not for visitors?
Most caching plugins skip the cache for logged-in users, so you see the live version while visitors get the cached one. Test in a private window, where you’re logged out.
Should I turn off Element Cache completely?
Usually not. It makes pages faster for visitors. Lowering the duration is a better trade-off than disabling it, unless you have widgets that must always show live data.
How often should I clear my cache?
You shouldn’t need to on a schedule. Good caching plugins clear the affected pages automatically when you update them. Manual clearing is for site-wide changes such as new global colours, fonts or header designs.
Sources: Elementor Help: My changes do not appear online; Cloudflare Docs: Purge cache; LiteSpeed Cache documentation: Toolbox. Menu names checked against Elementor’s source code in September 2026.
More in How-To & Fixes
WordPress Contact Form Emails Not Arriving? Fix It With SMTP
Form submissions vanishing or landing in spam? Why WordPress emails fail, and how to fix delivery with SMTP for your host's mailbox, Gmail or Outlook.