A while ago, to improve WordPress cache hit rates and reduce server load from origin fetches, I gradually unified the main page cache lifetimes for W3 Total Cache, EdgeOne, and Cloudflare to 96 hours, or 4 days.

I previously documented this caching strategy in “From CPU Alerts to Dual-Domain Pre-caching: W3 Total Cache, EdgeOne, and Cloudflare 96-Hour Cache Optimization in Practice”:

However, after running with the 4-day long cache, a practical issue emerged:

A new article has been published, but the homepage in the CDN might still show old content.

Regular articles usually do not change frequently after publication, so a 4-day cache is not a problem.

But the homepage and Sitemaps are different.

Every time a new article is published:

• The homepage article list changes;
• The Sitemap index might change;
• Sub-sitemaps like post-sitemap.xml might also update.

Therefore, this time, instead of reducing the cache time for the entire website, I only set a shorter CDN edge cache for these high-churn pages.

The final adjustment is:

This keeps long-term caching for most pages while reducing the maximum stale cache time for the homepage and Sitemaps after a new article is published from 4 days to about 2 hours.

1. Why Not Automatically Purge the CDN After Publishing an Article?

In theory, a more precise approach would be:

After an article is published, WordPress automatically calls the EdgeOne and Cloudflare APIs to purge the corresponding homepage and Sitemap caches.

The entire workflow could be implemented as:

WordPress publishes article → clears local cache → determines Chinese or English → calls CDN API → precisely purges homepage and Sitemap.

This approach would allow new articles to appear on CDN-served pages almost immediately.

But it also means continuing to maintain:

• WordPress publish hooks;
• EdgeOne API;
• Cloudflare API;
• API tokens;
• Chinese and English domain logic;
• Purge failure handling;
• Retry mechanisms.

What I really need to solve right now, however, is not:

Ensuring a new article appears on the homepage within seconds of publication.

But rather:

Preventing the homepage from serving stale content for extended periods due to the 4-day CDN cache.

If an update delay of about 2 hours is acceptable, setting a shorter TTL specifically for the homepage and Sitemaps is much simpler.

Therefore, this time I did not re-enable the Cloudflare plugin that had already been disabled in the WordPress backend, nor did I add automatic purge code.

2. Why Standardize on 2 Hours?

Initially, I considered setting the homepage and Sitemaps to 1 hour.

However, to keep the configurations consistent across both EdgeOne and Cloudflare, I ultimately standardized on:

2 hours

This makes the caching strategy easier to understand when reviewing it later:

• High-churn entry pages: 2 hours;
• Regular HTML: 4 days.

There is no need to remember two different sets of times.

More importantly, shortening the TTL for only a few high-churn URLs this time will not noticeably impact the overall website cache hit rate.

3. Yoast Sitemaps Are Not Just sitemap_index.xml

The website currently uses Yoast SEO.

Opening the Chinese site:

https://www.shuijingwanwq.com/sitemap_index.xml

You can see that the current Sitemap Index contains multiple sub-sitemaps.

These include items like:

/post-sitemap.xml

/post-sitemap2.xml

/page-sitemap.xml

/category-sitemap.xml

/post_tag-sitemap.xml

/post_tag-sitemap10.xml

/series-sitemap.xml

/series_group-sitemap.xml

So setting a 2-hour TTL only for:

/sitemap_index.xml

is not enough.

When an article is actually published, the most direct changes often occur in:

/post-sitemap.xml

Therefore, this update needs to cover both the Sitemap Index and all public sub-sitemaps.

4. w3tc-preload-sitemap.xml Is Excluded from This Rule

The website also has a special file:

/w3tc-preload-sitemap.xml

This is a combined sitemap generated separately for W3 Total Cache Cache Preload.

However, its purpose differs from the Yoast Sitemaps publicly accessed by search engines.

In the current implementation, W3TC Preload reads the origin sitemap through its own process, so the CDN content update issue we need to solve this time does not involve this file.

Therefore:

/w3tc-preload-sitemap.xml is excluded from the “public Sitemap 2-hour cache” scope.

This also means it must be explicitly excluded in the EdgeOne rules.

5. EdgeOne: One Rule to Handle Both Homepage and Sitemaps

Chinese site:

www.shuijingwanwq.com

Currently served via EdgeOne CDN.

To minimize the number of rules, I did not create separate rules for:

“Homepage cache 2 hours”

and:

“Sitemap cache 2 hours”

Instead, I created a single rule:

Homepage and Sitemap cache 2 hours

The outermost layer first restricts the Host:

www.shuijingwanwq.com

Below that, two sibling IF2 conditions are created.

The first handles the homepage:

URL Path = /

The second handles the public Sitemaps.

The homepage branch is very simple:

URL path 等于 /

Actions:

• Node Cache TTL;
• Custom time;
• 2 hours;
• Force cache disabled.

The Sitemap branch uses a regular expression:

^/(sitemap_index|[^/]+-sitemap[0-9]*)\.xml$

^/(sitemap_index|[^/]+-sitemap[0-9]*)\.xml$

And adds:

URL Path 不等于 /w3tc-preload-sitemap.xml

This regex covers:

• /sitemap_index.xml
• /post-sitemap.xml
• /post-sitemap2.xml
• /page-sitemap.xml
• /category-sitemap.xml
• /post_tag-sitemap.xml
• /post_tag-sitemap10.xml
• /series-sitemap.xml
• /series_group-sitemap.xml

While ensuring that w3tc-preload-sitemap.xml does not end up in the 2-hour cache.

After saving, the rule summary is as follows.

6. The EdgeOne Rule Must Be Placed After the Existing 4-Day HTML Rule

The existing:

HTML page cache (SEO safe)

is still retained.

It handles the long-term caching of regular HTML.

The newly added:

Homepage and Sitemap cache 2 hours

is placed further down the rule list.

Therefore, regular articles will not all be reduced to a 2-hour cache due to this adjustment.

The actual result is:

Regular HTML → continues at 4 days
Homepage → 2 hours
Public Sitemaps → 2 hours

This is the actual effect intended by this adjustment.

7. Cloudflare Already Has Multiple Cache Rules

English site:

en.shuijingwanwq.com

Currently served via Cloudflare.

Before making changes, I reviewed the existing Cache Rules.

Among them, the key ones are:

• HTML page cache (SEO safe)
• WordPress personalized cookie bypass cache

Therefore, this time I also did not split it into multiple rules, but only added:

Homepage and Sitemap cache 2 hours

This minimizes the number of rules and makes future maintenance easier.

8. Cloudflare Uses Host + URI Path Matching

The final expression used on the Cloudflare side is:

(http.host eq "en.shuijingwanwq.com" and (
  http.request.uri.path eq "/"
  or http.request.uri.path eq "/sitemap_index.xml"
  or http.request.uri.path wildcard "/*-sitemap*.xml"
))

(http.host eq "en.shuijingwanwq.com" and (
  http.request.uri.path eq "/"
  or http.request.uri.path eq "/sitemap_index.xml"
  or http.request.uri.path wildcard "/*-sitemap*.xml"
))

This handles the following respectively:

Homepage:

/

Sitemap Index:

/sitemap_index.xml

Other sub-sitemaps:

/*-sitemap*.xml

Because this rule itself already restricts to:

en.shuijingwanwq.com

And w3tc-preload-sitemap.xml is located on the Chinese www domain, the Cloudflare side does not need to explicitly exclude it.

The Edge TTL is set to:

Ignore cache control header, use this TTL

Time:

2 hours

The browser TTL was not modified in this step.

The focus of this adjustment is solely on:

Cloudflare edge node cache lifetime.

9. Cloudflare Rule Order Is Equally Important

After adding the new rule, the final relevant order becomes:

6. HTML page cache (SEO safe)
7. Homepage and Sitemap cache 2 hours
8. WordPress personalized cookie bypass cache

This position is very important.

When a regular visitor accesses the homepage:

The general HTML rule matches first, and then rule 7 adjusts the Edge TTL to 2 hours.

However, if the request contains login or other personalized cookies, it will ultimately still hit rule 8:

WordPress personalized cookie bypass cache

Therefore, adding a homepage cache rule will not cause logged-in users’ personalized pages to be cached.

10. After Publishing the New Rule, Perform a URL Purge First

Merely changing the TTL does not guarantee that existing stale cache in the nodes will expire immediately.

For example, the homepage had already been cached according to the 4-day policy, and that stale cache might still persist after the new rule is published.

Therefore, after configuring both EdgeOne and Cloudflare, I performed a custom URL purge on each.

Primarily targeting:

• Homepage;
• /sitemap_index.xml;
• /post-sitemap.xml.

I did not perform a full site purge.

The purpose of this purge was simply to:

Invalidate the existing 4-day stale cache so the new 2-hour rule can take over immediately.

During normal operation, manual purging after every article publication is not required.

11. First Test Revealed That Proxies Can Interfere with CDN Evaluation

When I first tested EdgeOne, I consecutively accessed:

• Homepage;
• sitemap_index.xml;
• post-sitemap.xml;
• A regular article page.

The results showed:

• Request timeouts;
• Multiple MISSes;
• Even regular articles showed MISS.

The curl output at the time also included:

HTTP/1.1 200 Connection established

It was later confirmed that local requests were going through a proxy.

To prevent proxy exit nodes and CDN node changes from interfering with the test, I uniformly added:

--noproxy '*'

--noproxy '*'

For example:

curl -4 --noproxy '*' -sS \
    --connect-timeout 10 \
    --max-time 60 \
    -o /dev/null \
    -D - \
    "https://www.shuijingwanwq.com/"

curl -4 --noproxy '*' -sS \
    --connect-timeout 10 \
    --max-time 60 \
    -o /dev/null \
    -D - \
    "https://www.shuijingwanwq.com/"

After bypassing the proxy, the EdgeOne homepage quickly returned:

First request:

MISS

Subsequently:

HIT

And:

Age: 5

Continuing to increase thereafter.

This indicates that the homepage has successfully entered the EdgeOne node cache.

12. EdgeOne Sitemap and Regular Article Verification

Next, I tested separately:

/sitemap_index.xml

/post-sitemap.xml

And a regular article page.

Results:

sitemap_index.xml

First request:

MISS

Second request:

MISS

Third request:

HIT

post-sitemap.xml

First request:

MISS

Subsequently:

HIT

HIT

This shows that the Sitemaps can properly enter the EdgeOne cache, and it also proves that our configured matching scope covers /post-sitemap.xml.

The regular article page, on the other hand, consistently returned:

HIT

And the Age:

221 → 226 → 231

This indicates that the new rule did not break the original long-term cache for regular articles.

13. Cloudflare First Verification Also Succeeded

After purging the Cloudflare cache, I accessed the English homepage:

First request:

CF-Cache-Status: MISS

Subsequently:

HIT

Age: 3

Again:

HIT

Age: 6

This indicates that the homepage has re-entered the Cloudflare edge cache.

/post-sitemap.xml also showed:

MISS → HIT → HIT

Therefore:

/*-sitemap*.xml

It indeed matches the current Yoast sub-sitemaps.

While testing a regular English article, an interesting set of data appeared:

LAX node:

HIT

Age: 28182

The next request went to LAS:

MISS

Then back to LAX:

HIT

Age: 28190

This also reminded me:

CDN cache does not share a single unified Age across the entire network; it is distributed across different edge nodes.

So seeing a single MISS does not immediately mean the cache rule has failed; you also need to consider which CDN node the request actually landed on.

14. MISS → HIT Does Not Prove the TTL Is Actually 2 Hours

After completing the above verification, another question remained:

We only proved that the cache can be established normally, but how do we know the TTL has actually changed from 4 days to 2 hours?

For example:

MISS → HIT → HIT

Regardless of whether the TTL is:

• 2 hours;
• 4 hours;
• 4 days;

The same result can appear when the cache is first established.

Therefore, I did not end the test immediately, but waited for over two hours before checking again.

15. After Over Two Hours, EdgeOne Homepage MISSes Again

The EdgeOne homepage initially re-established its cache around 18:45.

At 21:12, I tested again.

First request:

EO-Cache-Status: MISS

Subsequently:

HIT

Age: 12

Again:

HIT

Age: 26

This indicates that the previously existing homepage cache was no longer being used directly after more than two hours.

After the new request re-established the cache, the Age started increasing from a very small value again.

A single MISS alone cannot absolutely rule out other factors like node changes or cache eviction.

However, considering:

• EdgeOne being explicitly configured for 2 hours;
• Confirming the homepage could HIT after configuration;
• The wait time exceeding 2 hours;
• The subsequent access resulting in a MISS;
• Immediately followed by a HIT;
• The Age restarting from a dozen seconds;

The actual behavior perfectly aligns with a 2-hour node cache TTL.

16. Cloudflare’s 2-Hour Expiration Evidence Is More Direct

The Cloudflare English homepage re-established its cache around 19:02.

At 21:13, I tested again.

First request returned:

CF-Cache-Status: EXPIRED

Node:

LAX

Second request:

CF-Cache-Status: HIT

Age: 4

Still:

LAX

Third request:

HIT

Age: 7

Still:

LAX

In other words, on the same Cloudflare node, I fully observed:

Cache exists → TTL expires → EXPIRED → re-fetch → HIT → Age restarts

Therefore, on the Cloudflare side, it can be clearly confirmed that:

The 2-hour Edge TTL has actually taken effect.

17. Why Does Cloudflare Still Return max-age=14400?

There is another potentially misleading aspect of Cloudflare’s response.

Even though the Edge TTL has been set to 2 hours, the response still shows:

cache-control: max-age=14400

14,400 seconds equals:

4 hours

But after more than two hours, Cloudflare showed:

CF-Cache-Status: EXPIRED

This is not contradictory.

Because what was modified this time is:

Cloudflare Edge TTL

And the following in the response:

Cache-Control: max-age=14400

is the cache control information visible to the client.

That is to say, currently both can coexist:

Cloudflare Edge: 2 hours
Client Cache-Control: 4 hours

Moreover, the actual EXPIRED results have already proven that the Cloudflare edge nodes are no longer caching the homepage for 4 hours or even 4 days.

Whether the browser TTL also needs to be adjusted from 4 hours to 2 hours is a separate issue.

I did not expand the scope of adjustments this time.

18. Final Cache Structure

After this adjustment, the main strategy can be summarized as follows:

w3tc-preload-sitemap.xml is not included in this public Sitemap CDN TTL adjustment.

The Cloudflare WordPress plugin remains disabled.

No WordPress hooks or CDN API automatic purges were added either.

19. Trade-offs After This Optimization

Increasing the cache time to 4 days previously was not wrong in itself.

It solved the problem of:

Regular pages repeatedly fetching from the origin, overly short cache lifetimes, and low cache hit rates.

And this time, a different problem was solved:

The homepage and Sitemaps are high-churn pages and should not use the exact same cache lifetime as regular articles.

Therefore, the final result is not a binary choice between “2 hours” and “4 days”, but rather a distinction based on page nature:

It is differentiated by page nature:

Stable pages use a 4-day long cache, while high-churn entry pages use a 2-hour short cache.

This way, after publishing a new article, even without any active purge, the stale homepage and Sitemaps at the CDN edge layer will only need to wait a maximum of about 2 hours.

At the same time, a large number of regular articles can continue to benefit from the 4-day cache.

Compared to implementing automatic post-publish purging for both EdgeOne and Cloudflare, this solution is much simpler and has lower ongoing maintenance costs.

Based on the test results after waiting for over two hours:

• EdgeOne showed MISS → HIT, with the Age restarting;
• Cloudflare explicitly showed EXPIRED → HIT, with the Age restarting from 4 seconds.

Therefore, I plan to keep this configuration for now.

If future requirements change to:

The homepage must show new content immediately after an article is published.

Then I will introduce precise CDN API purging.

But for the current website, a 2-hour cache for the homepage and Sitemaps, and a 4-day cache for regular pages is already a more appropriate compromise for the current traffic scale and maintenance costs.