How to Set Up a Warmup Cache Request on WordPress (Step-by-Step Guide)

A cold cache is the single biggest reason a freshly deployed WordPress page feels slow. You clear the cache, a visitor lands on the homepage, and the server has to rebuild the page from scratch. This guide shows you exactly how to set up a warmup cache request so that never happens again.

What Is a Warmup Cache Request

A warmup cache request is an automated HTTP call that visits a page before a real user does. The server generates the page, stores a static copy, and the next visitor gets the cached version instead of a freshly rendered one. This process is also called cache preloading or cache priming.

The mechanics are simple. A crawler, cron job, or plugin sends a GET request to each URL you want cached. The response triggers your caching layer, whether that is a WordPress plugin, Varnish, or Nginx FastCGI cache, to save the output. By the time a human visitor arrives, the page is already sitting in cache.

Without this step, every cache clear resets the clock. The first visitor to each URL pays a tax in load time while the server regenerates HTML, runs database queries, and executes PHP. A warmup cache request removes that tax by shifting the cost from a real visitor to an automated one.

Why a Cold Cache Slows Down Your WordPress Site

A cold cache adds hundreds of milliseconds to Time to First Byte on the first request after every purge. On a typical WordPress install without a page cache, TTFB can run 300ms to 1 second or more depending on plugin count, theme complexity, and server specs. With a warm cache, that number often drops to 50ms to 150ms because the server skips PHP execution entirely.

This matters most right after three events: a full cache purge, a plugin or theme update, and a fresh deployment. Each event wipes stored pages. If you run a WooCommerce store with 10,000 product pages, the first shopper to hit each product after a purge triggers a full page rebuild. Multiply that by concurrent traffic and you get CPU spikes, not just slow pages.

Cache hit ratio is the metric that tells you how well warmup is working. A site with no warmup strategy often sits at 70% to 85% hit ratio right after a purge, climbing back up only as organic traffic slowly repopulates the cache. A properly configured warmup cache request can push that ratio above 95% within minutes of a purge, because the crawler repopulates the cache before real traffic arrives.

Warmup Cache Request Methods Compared

There is no single correct way to warm a WordPress cache. The right method depends on your hosting stack, your technical comfort level, and site size.

Method	Best For	Setup Difficulty	Server Load Control	Cost
WP Rocket (Preload)	Most WordPress sites, non-developers	Low	Moderate, built-in throttling	Paid
LiteSpeed Cache Crawler	Sites on LiteSpeed servers	Medium	High, granular settings	Free
Free warmup plugins (Warmer, Warm Up Cache)	Budget sites, simple needs	Low	Low to moderate	Free
Manual cron + WP-CLI or wget	Developers, agencies, custom stacks	High	Full control	Free
CDN-level warmup (Cloudflare, NitroPack)	High-traffic or multi-region sites	Medium	High, offloaded to CDN	Paid

WP Rocket and LiteSpeed Cache cover most use cases. If your host runs LiteSpeed, use the built-in crawler since it runs at the server level and does not compete with PHP workers the way plugin-based crawlers do. If you are on Nginx or Apache with a generic host, WP Rocket or a free plugin is the more practical starting point.

Before You Start: Requirements for Cache Warmup

A warmup cache request only works if a few conditions are met first.

Your site and sitemap need to be publicly accessible. Preloading fails silently on sites behind maintenance mode, password protection, or a login wall, since the crawler gets blocked before it reaches the page.

You need an active page caching layer already installed. Cache warmup fills a cache. It does not create one. Install a caching plugin such as WP Rocket, LiteSpeed Cache, or W3 Total Cache first, confirm pages are cacheable, then move to warmup.

You need a valid XML sitemap. Most warmup tools pull their URL list from a sitemap generated by Yoast SEO, Rank Math, All in One SEO, or the WordPress default sitemap at /wp-sitemap.xml. Confirm this URL loads and lists your actual pages before configuring anything else.

Check your hosting provider’s stance on outbound self-requests and cron jobs. Some shared hosts throttle or disable server-level crawlers to protect shared resources. If your crawler shows zero progress, contact support before assuming a config error on your end.

How to Set Up a Warmup Cache Request With WP Rocket

WP Rocket is the most common starting point because preload is built in and requires almost no manual tuning.

Step 1: Install and Activate

Purchase and download WP Rocket, then upload it through Plugins, Add New, Upload Plugin in your WordPress dashboard. Activate it. WP Rocket begins working immediately with default settings, including basic page caching.

Step 2: Enable Preload Cache

Go to Settings, WP Rocket, Preload tab. Confirm the Preload Cache option is toggled on. It ships enabled by default, but always verify after installation. This single toggle is what turns your page cache into a true warmup cache request system rather than a passive cache that only fills as visitors arrive.

Step 3: Confirm Sitemap Detection

WP Rocket auto-detects sitemaps from Yoast SEO, Rank Math, SEOPress, All in One SEO, and the WordPress default sitemap. Check the Preload tab to confirm a sitemap was found. If you use a custom or non-standard sitemap URL, add it manually in the same tab.

Step 4: Trigger and Verify the First Preload

Click Clear and Preload Cache from the WP Rocket dashboard or the admin toolbar. This clears existing cache files and immediately starts the crawl. To confirm it worked, connect via SFTP and check /wp-content/cache/wp-rocket/yourdomain/ for generated HTML files, or query the wp_wpr_rocket_cache database table for populated rows.

On a site with a few hundred pages, expect the first full preload to finish in a few minutes. On a site with tens of thousands of URLs, it can take hours, and WP Rocket recommends limiting preload to your most visited pages using its Smart Preload Helper on very large catalogs.

How to Set Up a Warmup Cache Request With LiteSpeed Cache

If your host runs LiteSpeed Web Server, this free plugin includes a server-level crawler that outperforms PHP-based alternatives because it runs outside the WordPress request cycle.

Step 1: Add Your Sitemap

Install and activate LiteSpeed Cache. Navigate to LiteSpeed Cache, Crawler, Sitemap Settings tab. Enter your sitemap URL. This is typically yoursite.com/wp-sitemap.xml, or yoursite.com/sitemap_index.xml if you run Rank Math. Save changes.

Step 2: Turn On the Crawler

Go to the General Settings tab within Crawler. Toggle the Crawler switch to On. Save changes again. Without this step, the sitemap is stored but no warmup cache request ever fires.

Step 3: Refresh the Crawler Map

Click the Map tab, then click Refresh Crawler Map. This pulls the current URL list from your sitemap into LiteSpeed’s internal queue, which is the list the crawler works through on each run.

Step 4: Run the First Crawl

Go to the Summary tab and click Manually Run. LiteSpeed starts crawling immediately instead of waiting for the next scheduled run. Watch the Map tab for status colors: gray means waiting to be crawled, green means already cached, blue means it just got cached, and red means blocklisted due to a failed response.

For ongoing automation, LiteSpeed relies on WP-Cron by default. If DISABLE_WP_CRON is set to true in wp-config.php, set up a real server cron job to hit wp-cron.php every few minutes, otherwise the crawler never fires on schedule.

How to Set Up a Warmup Cache Request With a Free Plugin

If you are not on LiteSpeed and do not want to pay for WP Rocket, a dedicated free plugin like Warmer or Warm Up Cache handles the basics. Install the plugin, go to its settings screen, and point it at your sitemap or select specific post types to include.

Set a request delay of at least 200 to 500 milliseconds between URLs to avoid overwhelming shared hosting. Choose a schedule, hourly, daily, or event-based after a post publish, then run a manual test batch before trusting the automated schedule. Review the plugin’s log after the first run to catch redirect loops or non-200 responses that stall the queue.

How to Set Up a Warmup Cache Request Manually With Cron and WP-CLI

Developers managing multiple sites often skip plugin UIs entirely and script the warmup cache request directly.

A basic server cron entry using wget against your sitemap looks like this:

0 */6 * * * wget -q -O /dev/null "https://yoursite.com/sitemap.xml" --spider

That command alone only checks the sitemap exists. To actually warm every URL listed in it, pipe the sitemap through a small script that extracts each <loc> tag and requests it with a delay:

#!/bin/bash
SITEMAP="https://yoursite.com/sitemap.xml"
curl -s "$SITEMAP" | grep -oP '(?<=<loc>)[^<]+' | while read url; do
  curl -s -o /dev/null -w "%{http_code} $url\n" "$url"
  sleep 0.3
done

Save this as warmup.sh, make it executable with chmod +x warmup.sh, then schedule it with cron to run after your regular cache purge window, for example every night at 3 AM.

If you use WP-CLI, you can pair this with a cache clear command first, so cache clearing and warmup run as one atomic job:

wp cache flush && bash /path/to/warmup.sh

This approach gives full control over batch size, request interval, and logging, at the cost of needing SSH access and basic shell scripting knowledge.

Best Practices to Avoid Server Overload During Cache Warmup

Warming too aggressively can take a site offline faster than the cold cache problem it solves. Keep these limits in mind.

Batch your requests. Sending 5 to 10 URLs per second is a reasonable ceiling for shared or mid-tier VPS hosting. Hitting a 50,000-URL site all at once can spike CPU to 100% and crash the server.

Never warm logged-in-only pages. A WooCommerce checkout page, account dashboard, or membership area should never appear in your warmup URL list. Caching these pages risks serving one visitor’s session data to another.

Match warmup frequency to your cache TTL. If your cache expires every 10 minutes, a scheduled warmup runs constantly and burns CPU for little benefit. A TTL of 10 to 24 hours works well for most blogs and marketing sites, paired with event-based warmup on publish or purge rather than tight scheduled intervals.

Cover both desktop and mobile if your setup uses separate cache files per device. A crawler that only sends a desktop user agent leaves the mobile cache cold, and mobile traffic is often the majority of visits.

Disable duplicate warmup systems. Running your caching plugin’s built-in preload alongside a separate cron-based crawler doubles the load for no added benefit. Pick one method and turn the other off.

How to Verify Your Warmup Cache Request Worked

Check response headers on a few key URLs after a warmup run. Use curl:

curl -I https://yoursite.com/

Look for cache-status headers specific to your stack: x-litespeed-cache: hit, cf-cache-status: HIT for Cloudflare, or plugin-specific headers like X-WP-Super-Cache. A hit means the warmup cache request succeeded for that URL. A miss means either the crawler has not reached it yet or the page failed to cache.

For LiteSpeed, the Crawler Map tab gives a visual breakdown by color instead of manual curl checks. For WP Rocket, checking the wp_wpr_rocket_cache database table or the physical cache folder confirms file generation directly.

Track cache hit ratio over time using your CDN or reverse proxy dashboard if you run Cloudflare, Varnish, or a similar layer in front of WordPress. A healthy warmup setup should show hit ratio recovering to 90% or higher within minutes of a purge, not hours.

Common Cache Warmup Mistakes and Fixes

Crawling stalls at a specific URL. This usually means a redirect loop, a password-protected page, or a page returning a non-200 status. Check the plugin log or blocklist and exclude the offending URL.

Preload never completes on a large site. Reduce scope to your most visited pages instead of the full sitemap, or increase timeout settings if pages are simply slow to render on first load.

Crawler shows no progress at all. On LiteSpeed, this often means the server-level crawler engine is disabled by the host. Contact support to enable it or switch to a plugin-based fallback.

Cache warmup causes visible CPU spikes during business hours. Move scheduled warmup to low-traffic windows and reduce concurrent request rate. Pair this with auto-pacing if your tool supports it, since fixed-rate crawlers do not adapt to real-time server load.

FAQ

What is the difference between cache warming and cache preloading?

There is no practical difference between the two. Cache warming and cache preloading both refer to sending automated requests that generate cached pages before real visitors arrive. The terminology varies between caching plugins and platforms, but the underlying process remains the same.

Does a warmup cache request slow down my server?

It can if it runs without proper rate limiting. A well-configured warmup cache request that sends around 5 to 10 requests per second creates a controlled workload instead of a sudden traffic spike. This short-lived load helps reduce server strain when real visitors begin accessing your site.

How often should I run cache warmup on WordPress?

Run cache warmup whenever your cache is cleared or new content is published. Matching warmup to your cache TTL and update frequency is more efficient than using a fixed schedule. Event-based warmup avoids unnecessary crawls while ensuring important pages remain cached.

Can I set up a warmup cache request without a plugin?

Yes. You can create a cron job that uses tools like curl or wget to crawl URLs from your XML sitemap automatically. This approach provides the same functionality as many cache warming plugins but requires SSH access and basic shell scripting knowledge.

Does cache warmup work with Cloudflare?

Yes. Cache warming works with Cloudflare, but it is important to understand the caching layers involved. A warmup cache request first populates your origin server’s cache, and as Cloudflare retrieves that response, it also stores it in its edge cache. This allows both your server and Cloudflare’s global network to serve faster responses to future visitors.