Cache warmers
Create, run, and manage the website warmers that crawl your pages and keep them cached.
11 min read
A cache warmer crawls your website over HTTP and keeps its pages cached. This page covers creating one, running it, and reading the results. For a field-by-field explanation of every option on the form, see Warmer settings.
Warmers live under Account → Warmers.
Before you start
You need a verified hostname. Entry URLs on an unverified domain are rejected. See Hostname verification.
Creating a warmer
Click Add warmer. The form is grouped into sections, and only two fields are genuinely required: a name and one entry URL.
- 1
Leave Active off while you configure
Turn it on deliberately once you are happy with the settings. An inactive warmer never runs and never costs you anything.
- 2
Name it for your future self
“Main site”, “Shop — categories”, “Docs”. The name is only ever shown to you and your teammates.
- 3
Add entry URLs
Full absolute URLs including
https://. Your homepage is the usual choice. - 4
Turn on Include sitemaps if available
The single highest-value option for most sites. Your CMS already maintains the list of pages worth warming.
- 5
Set exclusions if you need them
Keep admin paths, carts, and endless filter URLs out of the queue.
- 6
Sanity-check the limits
Depth and max URLs per minute decide how big and how aggressive this warmer is. Defaults suit most sites.
- 7
Save, then activate
Create the warmer, run it once by hand, check the results, and only then leave it running on a schedule.
Choosing entry URLs
An entry URL is where a run begins. Most sites need exactly one — the homepage — because sitemaps and link discovery find everything else.
Add extra entry URLs when a section is not reachable within your depth limit from the homepage:
- A campaign landing page that is only linked from adverts.
- A deep category that sits four clicks from the homepage.
- A second verified subdomain, such as
blog.example.com. - A sitemap index, if you prefer to point directly at it.
Match the URL your site actually serves
If https://example.com redirects to https://www.example.com, use the www form. Otherwise every request spends its time following a redirect instead of warming the real page, and your results will be full of 301 rows.
Using sitemaps
Sitemaps are the most reliable way to cover a site completely, because your CMS or SEO plugin keeps them up to date automatically. When a new page is published it appears in the sitemap, and the next warm run picks it up without you touching anything.
Turn on Include sitemaps, and optionally add the sitemap URL itself as an entry URL:
https://www.example.com/sitemap.xml
https://www.example.com/sitemap_index.xml
https://www.example.com/post-sitemap.xmlSitemap indexes that point at other sitemaps are followed. This matters on large WordPress and WooCommerce sites, where the index typically splits into separate post, page, and product sitemaps.
Tip
With sitemaps enabled you can usually *lower* your depth setting. The sitemap lists deep pages directly, so there is no need to crawl link-by-link down to them.
Excluding URLs
Some URLs should never be warmed. Add them to Excluded URLs:
| Exclude | Why |
|---|---|
/cart, /checkout, /my-account | Personalised per visitor. Warming them is pointless and risks caching one person's session. |
/wp-admin, /admin, /login | Admin areas. Never cached, and warming them is wasted requests. |
| Filter and sort query strings | Faceted URLs like ?color=red&sort=price combine endlessly and will flood your queue. |
/search | Infinite URL space. Search result pages are rarely worth caching. |
| Feeds and endpoints you do not serve to humans | Usually not worth the request budget. |
On plans that include it, Use regex lets exclusions be patterns rather than literal strings, which is far more practical for query-string families.
Running a warmer
Once Active, a warmer starts a fresh run every auto start interval seconds. You can also start one immediately from the warmers list, which is what you want when testing a configuration change.
Runs can also be triggered externally — after a deploy, or as part of a CDN purge. See Deploy triggers and CDN integrations.
Reading the results
Open a warmer to see what it did. Summary figures across the top cover the whole run:
| Figure | Meaning |
|---|---|
| Total URLs | How many URLs the run touched. |
| Total success | How many returned a successful status code. |
| Total failed | How many errored. A handful is normal on a big site; a lot means something is wrong. |
| Average first load | Mean cold response time, in seconds. |
| Average second load | Mean warm response time. Should be substantially lower. |
| Total duration | Wall-clock time for the run. |
| Speed (pages/minute) | Actual throughput achieved, which may be below your configured ceiling. |
Below that is a row per URL, showing hostname, URL, depth, status code, user agent, content type, content length, when it was last crawled, and both load times.
What good looks like
- Status codes are overwhelmingly
200. - Second load times are a fraction of first load times.
- The URL count roughly matches how many pages you expect to have.
- Failures are rare and explainable.
What to investigate
| Symptom | Likely cause |
|---|---|
Lots of 403 or 429 | A bot filter, WAF, or rate limiter is blocking the crawler. Lower your rate limit and consider allow-listing. |
Lots of 301 / 302 | Your entry URLs or internal links point at redirecting addresses. |
Lots of 404 | Broken internal links, or exclusions that are not catching a bad URL family. |
5xx errors | Your origin is struggling. Lower max URLs per minute immediately. |
| Both load times equally slow | The pages are not being cached at all. This is a caching configuration problem, not a warming one. |
| Far fewer URLs than expected | Depth is too low, sitemaps are off, or exclusions are too broad. |
| Far more URLs than expected | Depth is too high, or faceted query-string URLs are being discovered. Add exclusions. |
How many warmers should you have?
One warmer per site is the normal starting point. Split into several when different parts of your site deserve genuinely different treatment:
- By priority — a small, frequent warmer for your homepage and top landing pages, and a larger, slower one for the long tail.
- By section — a store warmer with tight exclusions, and a separate blog warmer with sitemaps and deeper crawling.
- By hostname — separate subdomains are usually clearer as separate warmers.
- By client — agencies should use one workspace per client rather than mixing everything together.
The high-frequency / low-frequency pattern
A very effective setup: one warmer covering your ten most important URLs at depth 0, running every few minutes; and a second covering everything else via sitemaps, running hourly. Your critical pages are never cold, without warming the entire catalog constantly.
Editing and deleting
Editing a warmer takes effect on the next run; a run already in progress finishes with its previous settings. Deleting removes the configuration and its history, and cannot be undone — if you only want to stop it temporarily, switch Active off instead.