The cache purge that said it worked

I added a tracking tag to a site. The tag appeared in freshly generated pages and on no real URL. So I purged the cache.

wp litespeed-purge all
Success: Purged All!

The pages kept coming back with x-litespeed-cache: hit and the old HTML.

Where the cache really was

The page cache on that host lived in server-level storage outside the WordPress folder, in a directory called lscache. It held 19,189 pages. The wp-content/litespeed folder that I’d assumed was the cache only held about 3 MB of optimized assets.

The WP-CLI purge signal never reached the server’s storage. The command had no way of knowing that, so it reported success.

Purging from wp-admin worked, because that request goes through the web server. On the command line, this did the job:

find ~/lscache -mindepth 2 -type f -delete

It’s safe because it’s only a cache and rebuilds itself on the next request. -mindepth 2 leaves the top-level control file alone.

Check the page, not the message

With a seven-day cache lifetime, a theme or plugin change on that site could look broken for a week. Any fix would seem to have done nothing, and you’d go hunting for a bug that wasn’t there.

So after any purge, I fetch the page twice:

curl -s -D- https://example.com/ -o page.html | grep -i x-litespeed-cache

The first fetch should be a miss and the second a hit, with your new markup in the file. Desktop and mobile are cached separately, so check both.

A success message tells you that a command finished. It says nothing about whether the thing you wanted actually happened.