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. 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. 2

    Name it for your future self

    “Main site”, “Shop — categories”, “Docs”. The name is only ever shown to you and your teammates.

  3. 3

    Add entry URLs

    Full absolute URLs including https://. Your homepage is the usual choice.

  4. 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. 5

    Set exclusions if you need them

    Keep admin paths, carts, and endless filter URLs out of the queue.

  6. 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. 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:

text
https://www.example.com/sitemap.xml
https://www.example.com/sitemap_index.xml
https://www.example.com/post-sitemap.xml

Sitemap 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:

ExcludeWhy
/cart, /checkout, /my-accountPersonalised per visitor. Warming them is pointless and risks caching one person's session.
/wp-admin, /admin, /loginAdmin areas. Never cached, and warming them is wasted requests.
Filter and sort query stringsFaceted URLs like ?color=red&sort=price combine endlessly and will flood your queue.
/searchInfinite URL space. Search result pages are rarely worth caching.
Feeds and endpoints you do not serve to humansUsually 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:

FigureMeaning
Total URLsHow many URLs the run touched.
Total successHow many returned a successful status code.
Total failedHow many errored. A handful is normal on a big site; a lot means something is wrong.
Average first loadMean cold response time, in seconds.
Average second loadMean warm response time. Should be substantially lower.
Total durationWall-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

SymptomLikely cause
Lots of 403 or 429A bot filter, WAF, or rate limiter is blocking the crawler. Lower your rate limit and consider allow-listing.
Lots of 301 / 302Your entry URLs or internal links point at redirecting addresses.
Lots of 404Broken internal links, or exclusions that are not catching a bad URL family.
5xx errorsYour origin is struggling. Lower max URLs per minute immediately.
Both load times equally slowThe pages are not being cached at all. This is a caching configuration problem, not a warming one.
Far fewer URLs than expectedDepth is too low, sitemaps are off, or exclusions are too broad.
Far more URLs than expectedDepth 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.