Purge URL

The documentation only applies to instances deployed on Alokai@Edge.

Purge URL removes a single cached object from the CDN by its exact URL. This is the most precise purging option — only the specified URL is invalidated, leaving all other cached content untouched.

Use this when you need to refresh one specific page or asset without affecting anything else.

How URL purging works

Every object in the CDN cache is identified by a cache key derived from the request URL (and optionally query parameters or cookies — depending on your caching rules). When you purge a URL, the CDN looks up the object matching that exact URL and invalidates it. The next request for that URL will be a cache miss and will be served directly from your origin.

The URL you enter must match what the CDN has cached. This includes the domain, path, and any query parameters that are part of the cache key.

When to use purge URL

Purge URL is appropriate when a change affects a single, known page or asset. Typical scenarios include:

Fixing a typo or error on a specific product page, landing page, or CMS page.
Refreshing a single asset such as a static image, stylesheet, or script file.
Testing a change on one page before rolling out a broader purge.

If the change affects multiple pages (e.g., a product update that appears on listing pages, detail pages, and search results), purge by keys is a better fit. If everything needs to go, use purge all.

Purging a URL from the Console

In the Alokai Console, navigate to your instance.
Open Caching Layer.
Click CDN Cache.
Click Purge URL.
In the URL input, enter the full URL of the page or asset you want to purge, including the domain.
Optionally, enable Soft purge to mark the object as outdated (stale) instead of removing it from cache. The CDN can then serve stale content while fetching a fresh version from the origin in the background.
Click Purge.

Example inputs:

Goal	Input
Purge a product page	`https://store.example.com/product/blue-sneakers`
Purge the homepage	`https://store.example.com/`
Purge a static asset	`https://store.example.com/assets/logo.svg`
Purge a page with query params	`https://store.example.com/search?q=shoes`

Purging typically propagates across the CDN within a few seconds.

URL matching and cache keys

The URL you enter must match the cache key the CDN uses for that object. Keep the following in mind:

Include the full URL with protocol and domain — e.g., https://store.example.com/product/blue-sneakers, not just /product/blue-sneakers.
Query parameters matter if they are part of the cache key. If your caching rules include certain query parameters in the cache key (via the allow list), the purge URL must include them too. For example, if lang is in your allow list, then https://store.example.com/product/shoes?lang=en and https://store.example.com/product/shoes?lang=de are two separate cached objects and must be purged individually.
Ignored parameters don't matter. If a parameter is excluded from the cache key (via the deny list), you do not need to include it in the purge URL.
REGEX patterns are not supported. The purge URL must be an exact match to the cached object. You cannot use wildcards or regex to purge multiple URLs at once — for that, use purge by keys instead.

Soft purge vs. hard purge

	Hard purge (default)	Soft purge
Behavior	Immediately removes the object from cache. The next request triggers a full origin fetch.	Marks the object as stale. The CDN can serve stale content while revalidating with the origin.
Origin impact	Minimal for a single URL — the origin handles one extra request.	Even lower — the stale object absorbs traffic during revalidation.
When to use	Content must be removed immediately (e.g., incorrect information, compliance).	Routine updates where brief staleness is acceptable.

For a single URL, the origin impact of either mode is negligible. Soft purge becomes more valuable when you are purging many URLs in succession.

Best practices

Use the exact URL. Double-check the protocol, domain, path, and any query parameters that form part of the cache key. A mismatched URL will result in the purge having no effect.
Check your cache key configuration first. Review your caching rules to understand which query parameters, cookies, and headers are included in the cache key — this determines what the purge URL needs to look like.
Prefer purge by keys for bulk changes. If the same content change affects more than a handful of URLs, tagging your responses with surrogate keys and purging by key is faster and less error-prone than purging URLs one by one.
Combine with cache rules. URL purging works alongside your existing caching rules — after the purge, the response is re-cached according to your configured TTL and cache key settings.

For more background on how Fastly handles URL-level purging, see the Fastly documentation on purging a URL.