5 Common Reasons Why WP Rocket Page Caching Misses — and How to Troubleshoot

WP Multisite WP MultiTenant
, , ,
1

Background

WP Rocket is one of the most popular caching plugins for WordPress. However, users frequently report: “I installed WP Rocket, but my pages are still slow.” In most cases, the issue isn’t with WP Rocket itself—it’s due to misconfigurations or interference from third-party plugins that prevent cache hits.

Below are the five most common causes encountered in real-world operations.

1. WooCommerce geolocation_ajax Forces 307 Redirects

Symptom: High TTFB (Time to First Byte) on product pages, while the homepage loads normally.

WooCommerce’s geolocation_ajax mode triggers a 307 redirect on every request and appends a ?v= parameter to the URL—causing users to never hit the cache directly.

Diagnosis:

curl -sS -D - -o /dev/null "https://your-domain.com/product/slug" 2>&1 | grep -iE "HTTP/|location"

If you see an HTTP 307 status and the ?v= parameter, this is the culprit.

Fix: For digital storefronts, switch directly to base_address:

wp option update woocommerce_default_customer_address base_address

2. Login-State Cookies Bypass Caching

Symptom: Admins or logged-in users never receive cached versions of frontend pages.

By default, WP Rocket excludes pages served to logged-in users from caching. If your site has many registered users (e.g., membership sites), this means the majority of traffic bypasses the cache entirely.

Diagnosis:

# Access with cookie
curl -sS -D - -o /dev/null -b "wordpress_logged_in_xxx=value" "https://your-domain.com/" 2>&1 | grep -i "x-wp-rocket"

# Access without cookie
curl -sS -D - -o /dev/null "https://your-domain.com/" 2>&1 | grep -i "x-wp-rocket"

Fix: If frontend content is identical for all users, enable “Cache for logged-in users” in WP Rocket’s settings.

3. Query Strings Cause Cache Fragmentation

Symptom: Multiple distinct cache files are generated for the same page due to varying URL parameters.

Tracking parameters—such as UTM tags (?utm_source=...), Facebook’s fbclid, or Google’s gclid—cause WP Rocket to generate separate cache entries for each unique URL.

Diagnosis:

# Count total HTML cache files
find /wp-content/cache/wp-rocket/ -name "*.html" | wc -l

# Check for numerous parameterized cache files
ls /wp-content/cache/wp-rocket/your-domain.com/

Fix: In WP Rocket’s Advanced Settings, add common tracking parameters to the “Query strings to ignore when caching” list:

fbclid
gclid
utm_source
utm_medium
utm_campaign
utm_content
utm_term

4. Other Plugins Define the DONOTCACHEPAGE Constant

Symptom: Certain pages are consistently excluded from caching, with no obvious explanation.

Some plugins define the DONOTCACHEPAGE constant under specific conditions to instruct caching plugins to skip those pages. Common offenders include security plugins, A/B testing tools, and certain form plugins.

Diagnosis:

grep -rn "DONOTCACHEPAGE" /path/to/wp-content/plugins/

Fix: Identify which plugin sets this constant and evaluate whether disabling caching is truly necessary. Often, it’s an overly conservative default behavior.

5. Missing Server-Side Rewrite Rules

Symptom: WP Rocket generates static HTML cache files, yet Nginx/Apache still routes requests through PHP instead of serving the cached files directly.

WP Rocket generates static HTML files—but web servers require explicit rewrite rules to serve them directly and bypass PHP processing.

Diagnosis:

curl -sS -D - -o /dev/null "https://your-domain.com/" 2>&1 | grep -iE "x-wp-rocket|x-powered-by|server"

If the response includes X-Powered-By: PHP but lacks WP Rocket’s cache headers (e.g., X-WP-Rocket: HIT), the static files aren’t being served.

Fix: Ensure your Nginx configuration includes WP Rocket’s official rewrite rules (available in WP Rocket’s documentation), or verify that Apache’s .htaccess contains the corresponding directives.

General Troubleshooting Workflow

# 1. Confirm whether cache is being hit
curl -sS -D - -o /dev/null "https://your-domain.com/" 2>&1 | grep -iE "x-wp-rocket|cache"

# 2. Inspect redirect chain
curl -sS -o /dev/null -w "HTTP: %{http_code} | TTFB: %{time_starttransfer}s\n" -L "https://your-domain.com/"

# 3. Verify cache file existence
ls -la /wp-content/cache/wp-rocket/your-domain.com/

# 4. Clear cache and retest
wp rocket clean --confirm

Run this workflow whenever facing caching issues—it will identify the root cause in most cases.

2

这是一篇关于单站点环境下 WP Rocket 缓存问题的优秀排查指南。在 WordPress Multisite 网络中，缓存问题会更加复杂，因为需要区分网络级和站点级配置。

对于 Multisite 管理员，除了上述原因，还需要注意以下几点：

网络级缓存配置
在 Multisite 中，WP Rocket 可以作为网络激活的插件。Super Admin 需要在网络管理面板中设置全局缓存规则，这些规则会应用到所有子站点。但子站点的管理员可能在自己的站点设置中覆盖部分选项，导致缓存行为不一致。

用户登录态的特殊性
在 Multisite 网络中，wordpress_logged_in_ cookie 的作用域是整个网络。如果启用了"为已登录用户缓存"，需要确保所有子站点的前端内容对网络用户是一致的，否则可能显示错误信息。

缓存文件路径结构
Multisite 的缓存文件结构不同：

# 子域名安装模式
/wp-content/cache/wp-rocket/子域名.主域名/

# 子目录安装模式  
/wp-content/cache/wp-rocket/主域名/子目录/

排查时需要确认正确的路径。

网络插件冲突
某些网络激活的插件可能会在特定条件下为所有子站点设置 DONOTCACHEPAGE。需要检查网络插件目录：

grep -rn "DONOTCACHEPAGE" /path/to/wp-content/plugins/network-activated-plugin/

Rewrite 规则差异
Multisite 的 Nginx/Apache 配置比单站点复杂。子域名模式需要通配符 SSL 和服务器块配置，子目录模式需要额外的 rewrite 规则。确保 WP Rocket 的规则被正确集成到 Multisite 的主配置中。

推荐的 Multisite 缓存策略

  1. 在网络级统一管理缓存排除规则
  2. 对于内容差异大的子站点，谨慎启用"已登录用户缓存"
  3. 定期清理整个网络的缓存碎片
  4. 使用 switch_to_blog() 函数在排查时切换到特定子站点上下文

如果遇到特定于 Multisite 的缓存问题，可以在 /c/multisite 分类下进一步讨论。