A slow first visit to a WordPress archive's second page does not necessarily mean WP Rocket preload is broken. WP Rocket's preload documentation excludes pagination URLs by default, while those pages can still be cached when visited. Separate eligibility for preloading from eligibility for page caching.
Confirm which address you are measuring
Copy the actual next-page link from the public archive. Record whether it uses a path such as /category/news/page/2/ or a query string. Do not invent a second-page URL from the homepage address. A redirect, missing archive, or search URL can behave differently from the intended pagination route.
Open it signed out, with the same consent and personalization state for each test. Administrator sessions often take a different cache path. A warm editor preview cannot demonstrate the experience of a new visitor, and a logged-in slow request does not prove that public caching failed.
Understand the documented exclusions
WP Rocket documents pagination exclusions using the site's pagination base, not only the literal word page. Query-string URLs and several cookie-specific or user-cache variants also do not follow the ordinary preload path. Check the actual configuration and documentation for the installed version before changing filters.
This means an empty preload record for page 2 may be expected. Repeatedly clearing the site cache to force that URL into the queue can make more visitors receive cold responses without correcting the exclusion. Preserve the state you are trying to diagnose.
Compare first and repeat requests to the same public pagination URL before diagnosing a preload failure. Synthetic explanatory visual.
Compare first and repeat requests
On an authorized staging environment, choose one public pagination URL and record a cold request followed by a repeat request. Keep the full URL, cookies, device variant, and access state consistent. Record total time and cache evidence from the hosting stack, not just a single header name assumed to be universal.
| Observation |
Next investigation |
| First request slow, repeat faster with cache evidence |
Cold-generation cost and intended preload policy |
| Both requests slow and not cached |
Cache eligibility, exclusions, cookies, response status |
| Both cached but rendering remains slow |
Frontend assets and browser work |
| Only campaign URL slow |
Query parameters and cache variation |
Timing alone is not enough to identify a cache hit. A database or object cache may warm between requests even when page caching is absent. Match the evidence to the host's actual cache implementation, including any CDN or server cache in front of WordPress.
Fix the expensive cold path when necessary
If the first request is unacceptably slow, inspect the archive query, expensive widgets, and external calls on that page. Use an authorized profiling setup and a bounded fixture. Do not add a tight loop that repeatedly requests every archive page on production while measuring it.
Consider how often deeper pagination receives traffic and how frequently it changes. A large archive with many low-traffic pages may create substantial preload work for little benefit. Any customized warming policy needs an agreed URL scope, request rate, and monitoring window, not a blanket crawl of every possible parameter combination.
If even a normal eligible public page remains pending, use the preload worker and queue guide. That guide addresses stalled work. It should not be used to declare an intentionally excluded pagination URL a worker failure.
Verify after the change without masking the result
Repeat the same first-visit and subsequent-visit comparison after the targeted correction. Keep the original measurement conditions in the record. A different page, account, or query parameter can produce an apparent improvement that does not answer the original complaint.
Check that the archive still returns the correct posts and page links. Performance work should not replace a slow result with an incorrectly shared personalized response. Include the public browser rendering result because a fast HTML response can still load slow images or scripts.
For a persistent delay, HandL WP can trace the archive's slow layer. Bring the exact pagination URL, signed-out conditions, cache evidence, and two request timings. Those details are more useful than another screenshot of a preload progress bar.
Reference and review date
Primary technical reference. Sources checked October 30, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.