# The Post Changed and the Homepage Did Not: Auto-Purge Only Clears the Pages You Ticked

> The post URL is fresh and the homepage, category and feed still show the old version. Auto-purge clears a list you configure, and listing pages are usually left off it.

- Published: 2026-10-01
- Updated: 2026-10-04
- Author: xSpeed Cache Team
- Tags: Caching, Performance, WordPress, fix:auto-purge
- Canonical: https://xspeedcache.com/blog/homepage-not-updating-after-publish/

---

Updated October 2026

LiteSpeed Cache ships a Default Front Page TTL of 604,800 seconds, a full week, held separately from the TTL on the post you just edited, per its own cache documentation read on 1 October 2026. WP-Optimize did not clear the author archive when a post was saved until version 4.2.4 on 30 July 2025, per its changelog. Both point at one thing. A purge is not an action on your site. It is an action on a list of URLs, and that list is shorter than you think. The question is not whether the purge ran. It did. The question is what was on the list.

![Three URLs after one publish: the post is fresh, the homepage and the category archive still serve the old copy](https://xspeedcache.com/images/blog/homepage-not-updating-three-fetches.webp)

## Quick Summary: Which Page Is Stale Tells You Which Problem You Have

| If this is what you see | Do this | Why |
|---|---|---|
| Post fresh, homepage or archive stale | Widen the auto-purge list, then warm it | The purge covered the post, nothing derived |
| Post URL also stale | Find the layer holding it | A different failure: [a purge that clears nothing](https://xspeedcache.com/blog/cache-purge-does-nothing/) |
| Fresh, then stale minutes later | Check what re-warmed it | Something re-cached a copy predating the edit |
| Only the feed is stale | Check the [feed TTL](https://xspeedcache.com/docs/feeds-and-api/) | Feeds are a separate store with their own lifetime |

## The Listing Sweep: Three Fetches That Name the Problem

Establish which failure you have before changing a setting.

1. Fetch the post URL and confirm the edit is in the HTML.
2. Fetch the homepage and the category archive the post belongs to.
3. Compare. Fresh at step 1 and stale at step 2 means the purge scope is wrong.

Run each fetch logged out. A logged-in session usually bypasses the page cache, so every page looks right while visitors see something else. If the post URL is stale too, answer the layer question first.

**Two limits.** A CDN in front means you are testing the nearest edge until you repeat the fetch against the origin, or [connect the CDN to the plugin](https://xspeedcache.com/docs/cloudflare/) so one purge reaches both. And a theme building its list from a widget cached under another key shows an old title on a page whose own entry is fresh.

## The Derived Set: Every URL One Post Appears On

LiteSpeed's documentation puts it plainly: "When a post is published or updated, other pages may change as well, including category listings, tag listings, the blog's front page, and various archives." Each is a separate URL with its own entry.

| URL type | Lists the post | Often outside the default purge |
|:---|:---:|:---:|
| The post itself | ✅ | ❌ |
| Front page and blog index | ✅ | ✅ |
| Category and tag archives | ✅ | ✅ |
| Author and date archives | ✅ | ✅ |
| Pagination past page 1 | ✅ | ✅ |
| RSS and comment feeds | ✅ | varies |

![One post fans out to six cached URL types, one cleared by default](https://xspeedcache.com/images/blog/homepage-not-updating-derived-set.webp)

Cache Enabler added "post type, taxonomies, author, and date archives to the new associated cache" in 1.5.0, per its changelog read 1 October 2026.

## Five Reasons a Listing Page Keeps the Old Copy

| Cause | Evidence |
|---|---|
| The archive type is not ticked in the settings | LiteSpeed: "You can specify which types of pages are automatically purged whenever a post is updated or created" |
| The plugin never associated archives with the post | Cache Enabler 1.5.0 added author and date archives to its associated cache |
| An archive was purged but the author archive was missed | WP-Optimize 4.2.4, 30 July 2025: "also purge the author archive cache upon post save" |
| A stale copy is served on purpose while the page rebuilds | LiteSpeed's Serve Stale returns the purged copy until PHP finishes |
| A rule cleared the front page, then stopped doing so | WP Super Cache 3.1.2, 19 August 2026, ignores a post ID of 0, which "could delete the front page cache unexpectedly" |

Only the first two are configuration. The rest are the plugin's code changing underneath you, so your version matters as much as the tickbox.

## Widening the Purge Without Clearing the Whole Site

The temptation is purge-everything. Resist it on any site with traffic: every cleared page is a PHP rebuild, so a publish emptying ten thousand entries buys one correct homepage at the price of an afternoon of slow responses. LiteSpeed's guidance is to "select only the necessary options", because "your theme and how it displays posts determine which pages you should select."

Work from the list your theme renders:

- Tick the front page and blog index. Nearly every theme lists posts on one.
- Tick the taxonomies your permalinks use. No author archive, leave it off.
- Tick date archives only where the theme links them.
- Leave the all-pages override off unless a post widget is site-wide.

We ship the narrow behaviour by default in xSpeed Cache, our own plugin from WPDeveloper. Version 1.3.6, 28 September 2026, records the correction we had to make: "Publishing a post on an nginx host no longer purges the server's entire cache, only the pages the post touches," per our changelog on the [WordPress.org plugin page](https://wordpress.org/plugins/xspeed/). Over-purging and under-purging are one bug with two signs.

Run the free xSpeed Scan on your own site: [xspeedcache.com/scan/](https://xspeedcache.com/scan/)

## Warm the Listings Before a Visitor Finds Them

A purged archive is uncached, and the next visitor waits for PHP. A preloader fixes that by requesting the pages itself, and hides a second version of this symptom: warming that runs before your edit lands writes the old page back.

Our 1.3.5 release of 22 September 2026 names a failure of ours here: cache warming "no longer identifies itself in a way that common firewall rule sets block, so newly published posts are warmed again on sites running 7G/8G-style protection." If listings stay cold after a publish, check the warmer reaches them. WP Rocket tracks the same work in a `wp_wpr_rocket_cache` table whose rows move from pending to completed or failed, per its preload documentation, so a stuck queue is visible rather than guessed. A preloader that never finishes has [its own fix](https://xspeedcache.com/blog/cache-preloader-never-finishes/).

## Checking This Across Twenty-Five Client Sites

One site is a browser tab. Twenty-five is a spreadsheet nobody keeps. What scales is picking the two URLs that matter on each site, the front page and the busiest category, and checking those after a publish rather than auditing settings. [xSpeed Hub](https://xspeedcache.com/xspeed-hub/) does it across a fleet from one place. On a store the pair that costs money when stale is the shop and its product-category archives, so [WooCommerce stores](https://xspeedcache.com/use-cases/woocommerce/) come first.

## Frequently Asked Questions

### I updated my post and the homepage is still showing the old title. Is my cache broken?

No. A correct post URL proves the cache cleared something. Widen the auto-purge list to cover the front page, then confirm with the sweep above.

### My category page updated but the tag page did not. Why only one?

Each archive type is its own checkbox in most plugins, and most ship with a subset ticked. Match them to what your theme links.

### How long until a stale archive fixes itself?

At its TTL. LiteSpeed's default front page lifetime is 604,800 seconds, so a week is possible on an untouched setting.

### Why did my homepage go stale again ten minutes after I fixed it?

Something re-cached it. A preloader, crawler or uptime monitor requests the page and stores a copy, and one predating your edit wins until the next purge.

### Should I just enable purge all on every publish?

Only on a quiet site. On a busy one it turns each publish into a site-wide rebuild, a cost [checking whether caching works](https://xspeedcache.com/blog/check-wordpress-caching-working/) will show.

## Conclusion: Purge the Set, Not the Page

A publish changes one post and several pages. Clearing the first and not the rest is the default on more plugins than it should be, and the three-fetch sweep tells you which half you have. Tick the archive types your theme renders, warm them, then check the front page after the next publish.

**What to do this week:** run the sweep on your busiest category, tick the archives your theme links, confirm the warmer reaches them, then watch one publish end to end. If you would rather the narrow purge came as the default, xSpeed Cache is free, and paid tiers start at $29 a year with a 14-day money-back guarantee: [Free vs Pro](https://xspeedcache.com/free-vs-pro/) and [pricing](https://xspeedcache.com/pricing/) set out what moves between them. When a stale page outlives a purge, the [full sweep for clearing every store](https://xspeedcache.com/blog/how-to-clear-wordpress-cache/) and our [common problems reference](https://xspeedcache.com/docs/common-problems-and-troubleshooting/) carry the rest.