Warmer settings
A field-by-field reference for every option on the cache warmer form, and when to change it.
14 min read
This is the complete reference for the cache warmer form. Each setting lists what it does, when to change it, and anything worth watching out for.
Missing a field?
Options your plan does not include are hidden or disabled. If a setting described here is not on your form, it is gated by your subscription — see Plans and limits.
Basics
- Active
- Whether the warmer runs. When enabled it crawls according to your intervals. Leave it off while configuring, and use it to pause during maintenance instead of deleting the warmer.
- Name
- A label for you — never shown to site visitors. Use something you will recognise in a list later.
- Team
- Which workspace owns this warmer. Only members of that team can see and manage it. Only appears when your plan includes teams.
- Crawler region
- Which regional crawler instance runs this warmer. Business plans only. See Advanced warming.
Entry points
- Entry URLs
- Full URLs including
https://, on a verified hostname. One starting point is enough for most sites. Your plan caps how many a single warmer may have. - Include sitemaps
- Discover URLs from XML sitemaps in addition to following links. Strongly recommended when available — it keeps coverage in sync with what you publish, without manual maintenance.
- Include public posts
- Include publicly published posts in discovery. Useful on content platforms where posts are not otherwise well linked.
Exclusions and parameters
- Excluded URLs
- Paths the warmer must skip. Use for carts, checkouts, account pages, admin areas, search, and faceted filter URLs. Your plan caps how many exclusions a warmer may have.
- Use regex
- Treat URL rules as regular expressions rather than literal strings. Far more practical for excluding whole families of query-string URLs in one rule.
- URL parameters
- Name/value pairs appended to requested URLs. Occasionally needed to reach a specific cache variant or bypass a splash screen.
- Name/value cookies sent with every request. Use with care — a session cookie can make responses uncacheable, or cache a personalised page for everyone.
- Request headers
- Custom headers sent with every request. Common uses are an API token, a bypass header for a staging protection layer, or a header your CDN varies on.
Cookies and headers change what gets cached
Many caches vary their stored copy by cookie or by specific headers. If you warm with a cookie that real visitors do not send, you may fill a cache variant nobody ever requests — the warming appears to work while doing nothing useful.
Crawl limits
| Setting | Unit | What it controls |
|---|---|---|
| Depth | hops | How far from an entry URL the warmer follows links. 0 warms only your entry URLs. |
| Max URLs per minute | URLs/min | Hard ceiling on request rate. The main protection for your origin server. |
| Request timeout | milliseconds | How long to wait for a response before giving up on a URL. |
| Auto start interval | seconds | How often a new run begins. 3600 is hourly. |
| Enqueue interval | seconds | How often URLs are re-queued within the warming cycle. Leave at default unless you have a reason. |
Choosing a depth
Start at 2. Raise it one level at a time, checking total URL counts after each change. If you have sitemaps enabled you often need less depth, because deep pages are listed directly.
Choosing a rate limit
This is the setting most worth getting right. Too high and warming competes with real visitors for your server's attention; too low and a large site never finishes a pass.
- Start conservative — 10 URLs per minute is a safe opening bid on almost any hosting.
- Watch your origin's CPU and response times during a run.
- Raise gradually while things stay healthy.
- Back off immediately if you see
5xxor429responses appearing.
Tip
Work out whether a full pass can even finish. A 5,000-URL site at 10 URLs per minute needs over eight hours. If your auto start interval is one hour, runs will overlap and never complete. Either raise the rate or narrow the warmer's scope.
Choosing a request timeout
The default suits most sites. Raise it if genuinely slow pages are timing out before your origin can finish building them — remember the *first* load is the slow one by design. Lower it if you would rather skip pathological pages quickly than wait. Your plan caps the maximum.
Choosing an auto start interval
Match it to your cache lifetime. If your CDN caches pages for an hour, warming hourly keeps everything continuously warm. Warming far more frequently than your TTL adds load without benefit. Your plan sets both a minimum and a maximum.
Options
- Use canonical
- Follow the
rel="canonical"URL rather than the address that was linked. Helps avoid warming several duplicate addresses for the same page, which wastes your URL budget. - Rewrite to HTTPS
- Upgrade discovered
http://links tohttps://. Useful on sites with legacy internal links, and avoids warming a redirect instead of the real page. - Warm mobile version
- Crawl using mobile user agents as well. Important if your CDN varies its cache by device class, or you serve distinct mobile templates.
- User agents
- Custom user-agent strings for requests. Use when your site or CDN behaves differently for specific agents.
- Mobile user agents
- Specific mobile user-agent strings, used when mobile warming is enabled.
- Browser / SSR warming
- Warm with a real browser engine rather than a plain HTTP fetch, for routes that only populate their cache after a full render. Business plans. See Advanced warming.
Warm schedule
Restricts scheduled auto-starts to defined peak and off-peak windows. Outside those windows, scheduled runs are skipped; manual and webhook-triggered runs still work.
The field takes JSON. Full syntax and examples are in Advanced warming.
{
"timezone": "Europe/Amsterdam",
"windows": [
{ "days": [1, 2, 3, 4, 5], "startHour": 8, "endHour": 20, "intensity": 1 }
]
}Recommended starting points
| Site type | Depth | URLs/min | Auto start | Notes |
|---|---|---|---|---|
| Small brochure site | 2 | 10 | 3600 | Defaults are fine. Sitemaps optional at this size. |
| Blog or news site | 2 | 30 | 1800 | Enable sitemaps so new posts are picked up quickly. |
| WooCommerce store | 2 | 15 | 3600 | Sitemaps on. Exclude cart, checkout, account, and filter URLs. |
| Large catalog | 3 | 60+ | 3600 | Sitemaps essential. Consider splitting into several warmers. |
| Critical landing pages | 0 | 10 | 300 | A short explicit entry-URL list, warmed very frequently. |
Note
These are starting points, not prescriptions. Run once, read Cache health, and adjust from what you actually see.