Recaching a website usually means purging old cached files first, then letting visitors or a crawler rebuild fresh copies. Cloudflare handles cache at the network edge, while LiteSpeed Cache handles cache at the web server and WordPress level. Cloudflare can purge everything or purge selected URLs, cache tags, hostnames, and prefixes on supported plans [source: Cloudflare]. LiteSpeed Cache is better for refreshing generated pages, CSS, JS, and object cache inside a LiteSpeed-powered WordPress site.
TLDR: If the issue is an old image, CSS file, or page being served from Cloudflare’s edge, Cloudflare Cache Purge is the right first move. If the issue is stale WordPress content, minified files, product pages, or logged-in behavior, LiteSpeed Cache Purge should run first. For example, a store that changes a homepage sale banner at 9:00 a.m. may purge LiteSpeed first, then Cloudflare, so 95% of visitors stop seeing the old “20% off” banner within minutes instead of waiting for cache expiry. The safest order is usually LiteSpeed purge, then Cloudflare purge, then test in a private browser window.
What “recache” really means
Recaching is not one single button. It is a short process. First, the old cached copy must be removed. Then the fresh version must be created and served. A site may have several cache layers, which is where people lose time.
- Browser cache: stored on the visitor’s device.
- Cloudflare cache: stored at Cloudflare data centers near visitors.
- LiteSpeed Cache: stored on the hosting server, often tied to WordPress.
- Object cache: database query results, often powered by Redis or Memcached.
- Plugin or theme cache: generated CSS, JS, templates, and page fragments.
The annoying part is simple: the site owner may update a page and still see the old version because one layer did not get the message. It drives people crazy when a text edit takes 3 seconds to save but 10 minutes to appear.
Cloudflare Cache Purge: best for edge cache problems
Cloudflare Cache Purge clears cached files from Cloudflare’s global network. This matters when Cloudflare is serving an older file before the request reaches the origin server. The origin might already have the new version, but Cloudflare may still send the previous one.
Cloudflare purge is useful when:
- A replaced image still shows the old design.
- A CSS file changed, but visitors still see broken styling.
- A JavaScript file update is not loading for public visitors.
- A page cached by Cloudflare APO or page rules remains stale.
- A DNS or routing change has made testing confusing.
There are two common choices. Purge Everything clears all cache at Cloudflare. It is simple, but it can reduce performance for a while because Cloudflare must rebuild its cache from the origin. Custom Purge clears only selected URLs or files. This is cleaner for busy sites.
For example, if only /pricing/ changed, purging the whole site is heavy-handed. A custom purge for that URL is better. If a theme update changed many CSS and JS files, a full purge may be faster and less fussy.
LiteSpeed Cache Purge: best for WordPress and server cache
LiteSpeed Cache Purge clears cache generated by LiteSpeed Web Server and the LiteSpeed Cache plugin. On WordPress sites, it can purge single posts, the homepage, categories, feeds, REST API responses, minified assets, object cache, and more.
LiteSpeed purge is useful when:
- A WordPress post or page was edited but still shows old text.
- WooCommerce product prices or stock counts are stale.
- Menus, widgets, or headers have changed.
- CSS or JS optimization created outdated combined files.
- The site uses LiteSpeed crawler to prebuild cached pages.
LiteSpeed is closer to WordPress, so it understands content changes better than Cloudflare. When a post is updated, LiteSpeed can purge related pages such as category archives, tags, and the homepage. Cloudflare usually sees only URLs and files unless extra integration is set up.
The catch is that LiteSpeed settings can get messy. A site may have page cache, object cache, browser cache, CSS minify, JS defer, guest mode, and crawler settings all running at once. One wrong checkbox can make a fresh page feel haunted.
Cloudflare purge vs LiteSpeed purge
| Feature | Cloudflare Cache Purge | LiteSpeed Cache Purge |
|---|---|---|
| Cache location | Cloudflare edge network | Origin server and WordPress layer |
| Best for | Static files, edge cached pages, global delivery | WordPress pages, WooCommerce, generated assets |
| Risk of full purge | More origin traffic from many regions | More server work while cache rebuilds |
| Granular purge | URLs, prefixes, hostnames, tags on supported setups | Posts, pages, categories, CSS, JS, object cache |
Best order for refreshing website content
For most WordPress sites using both tools, the best order is:
- Purge LiteSpeed Cache first. This clears the origin-level cached page.
- Purge CSS and JS optimization files if the design changed.
- Purge object cache if database-driven content is stale.
- Purge Cloudflare cache next. This removes the old version from edge servers.
- Preload or crawl key pages so visitors do not trigger all rebuilds.
- Test as a logged-out visitor in a private browser window.
This order matters because Cloudflare may fetch from the origin after a purge. If LiteSpeed still has the old copy, Cloudflare can cache that old copy again. Then the site owner has to repeat the job. Honestly, that feels like paying twice for the same mistake.
When to purge everything
A full purge is useful after major changes. Examples include a redesign, a theme migration, a domain change, new global CSS, major plugin updates, or a broken cache state that cannot be traced. It is also reasonable before a launch review.
Still, full purge should not be the default for every blog edit. On high-traffic sites, clearing all cache can spike server load. A news site with 50,000 visits per hour may not want every page rebuilt at once. Custom purge is safer when only one article, product, or image changed.
Common mistakes to avoid
- Purging only Cloudflare: The origin may still serve stale LiteSpeed cache.
- Purging only LiteSpeed: Cloudflare may continue serving old edge files.
- Testing while logged in: Admin users may bypass cache and see a different version.
- Ignoring file names: Replacing an image with the same file name can keep old browser cache alive.
- Overusing purge everything: It can slow the site while cache is rebuilt.
Practical recommendation
A small content edit should start with a LiteSpeed purge for the page. A design or asset issue should include CSS and JS purge. If Cloudflare is active, the matching URL or file should be purged there too. A major release should use full purge in both systems, followed by cache warmup.
The cleanest setup uses automatic purging. LiteSpeed can purge related WordPress pages when content changes. Cloudflare can be connected through plugins or API rules so edge cache clears when needed. Manual purging should be the backup, not the daily routine.
FAQ
What is the fastest way to recache a website?
The fastest safe method is to purge the changed page in LiteSpeed, then purge the same URL in Cloudflare. After that, the page should be visited once to rebuild the cached copy.
Should Cloudflare or LiteSpeed be purged first?
LiteSpeed should usually be purged first. Then Cloudflare should be purged. This prevents Cloudflare from pulling an old cached page from the origin.
Is “Purge Everything” bad?
It is not bad, but it can be wasteful. It clears all cached content and may increase server load while the cache rebuilds. It is best saved for large updates or cache problems that are hard to isolate.
Why does the old version still show after purging?
The old version may be stored in browser cache, object cache, another plugin, or a CDN rule. Testing in a private window and adding a query string, such as ?v=2, can help confirm the source.
Does LiteSpeed Cache replace Cloudflare?
No. LiteSpeed Cache works mainly at the server and WordPress level. Cloudflare works at the edge network level. Many sites use both for better speed and fresher content control.