My Post Vanished From the WordPress Home Page — Two Cache Plugins Were Fighting

In September I published a post on DigitalRadar and it never showed up on the home page. Not on the category archive either. The post existed — opening its URL directly loaded it normally. But the home page kept listing the old set, as if nothing had been published.

One detail gave the problem away: visiting digitalradar.com.br/?lang=pt showed the post. Visiting the clean URL, digitalradar.com.br, did not. Same content, same server, two different answers depending on whether a query string was present.

What that symptom means

When the same page responds differently with and without a query string, the problem is almost never WordPress itself. It is a caching layer sitting in front of it — and the query string is making that layer step aside.

This is standard behaviour for file-based page caching: it stores a static copy of every “clean” URL and serves that file directly, without ever waking PHP. A URL carrying ?something is usually not treated as the same page, so it slips past the saved file and reaches the real WordPress.

In other words: what I saw with ?lang=pt was the real site. What I saw on the clean URL was an old photograph of it.

The diagnosis

The site runs on LiteSpeed hosting. I had the LiteSpeed Cache plugin active — and, inherited from an older setup, WP Fastest Cache as well.

I opened the file manager and went to wp-content/cache/. There was the evidence:

wp-content/cache/all/index.html          ← generated on June 4
wp-content/cache/all/category/news/index.html
wp-content/cache/wpfc-minified/

WP Fastest Cache was saving a static copy of every URL at wp-content/cache/all/<url>/index.html and serving that file to any visit without a query string. The home page I was looking at had been generated months earlier.

And here is the core issue: when I published a post, the plugin receiving the notification and clearing its own cache was LiteSpeed. WP Fastest Cache was never told, and kept serving the stale file. Two page-cache plugins on one site do not talk to each other — each assumes it is the only one.

The fix, in the order that matters

The order is not a detail here: delete the cache folder before removing the plugin and it rebuilds everything in seconds.

1. Plugins → deactivate and delete WP Fastest Cache. Deactivating is not enough; uninstalling is what removes the rules it wrote.
2. Delete the leftover folders: wp-content/cache/all and wp-content/cache/wpfc-minified. A removed plugin usually leaves its files behind.
3. Clean up .htaccess. WP Fastest Cache writes its own rewrite block. Keep a copy of the file before editing — I saved mine as .htaccess.wpfc-backup — and remove only its block, leaving the LSCACHE and WordPress blocks intact.
4. LiteSpeed Cache → Purge All. Only now, with a single cache plugin, does a purge cover the whole site.

How to confirm it worked

Publish a test post and open the home page by its clean URL in a private window. If the post is there on the first load, you are done. The private window matters because your browser cache can mask the result.

You can also check the response headers. On LiteSpeed servers the response carries x-litespeed-cache with hit or miss. If you see headers from another caching system alongside it, two are still in play.

curl -sI https://yoursite.com/ | grep -i cache

The rule that stuck

Never run two page-cache plugins on the same site. Object cache, browser cache and a CDN coexist happily with one page-cache plugin — but two plugins generating static HTML will, sooner or later, serve different versions of your site.

If your host already runs LiteSpeed, use LiteSpeed Cache and nothing else. It covers page cache, browser cache, minification, lazy loading and WebP conversion. Any additional page-cache plugin becomes a competitor, not a reinforcement.

Frequently asked questions

Why did the post appear with a query string but not on the clean URL?

Because file-based caching only stores copies of URLs without query strings. With the query string, the request slipped past the static file and reached WordPress, which returned the up-to-date home page.

Is deactivating the plugin enough, or must I delete it?

You must delete it. Deactivating stops new files from being generated, but the files already saved and the rules in .htaccess remain and keep being used.

Can I delete the whole wp-content/cache folder?

Yes — it rebuilds itself. The catch is doing it after removing the plugin, otherwise it recreates the files immediately.

How do I know whether I have more than one cache plugin?

Scan your active plugins for “cache”, “speed”, “optimize” or “rocket”, and check whether wp-content/cache/ holds subfolders from different systems. Folders like all/ and wpfc-minified/ belong to WP Fastest Cache.

At DigitalRadar, we document the problems we solve on our own site. Stay on the radar.