diff --git a/src/content/docs/cache/concepts/cache-control.mdx b/src/content/docs/cache/concepts/cache-control.mdx
index b2734e95698671c..cfdfcb0d792b8ad 100644
--- a/src/content/docs/cache/concepts/cache-control.mdx
+++ b/src/content/docs/cache/concepts/cache-control.mdx
@@ -294,7 +294,7 @@ With this configuration, Cloudflare attempts to revalidate the content with the
 
 `Cache-Control: max-age=600, stale-while-revalidate=30`
 
-This configuration indicates the asset is fresh for 600 seconds. The asset can be served stale for up to an additional 30 seconds to parallel requests for the same resource while the initial synchronous revalidation is attempted.
+This configuration indicates the asset is fresh for 600 seconds. The asset can be served stale for up to an additional 30 seconds while Cloudflare revalidates the asset with the origin in the background. For more information, refer to [Revalidation](/cache/concepts/revalidation/).
 
 
 </Details>
diff --git a/src/content/docs/cache/concepts/cache-responses.mdx b/src/content/docs/cache/concepts/cache-responses.mdx
index 36b53011f80599c..7e8ed6512d2a971 100644
--- a/src/content/docs/cache/concepts/cache-responses.mdx
+++ b/src/content/docs/cache/concepts/cache-responses.mdx
@@ -51,11 +51,13 @@ The origin web server instructed Cloudflare to bypass cache via a `Cache-Control
 
 ## REVALIDATED
 
-The resource is served from Cloudflare's cache but is stale. The resource was revalidated by either an `If-Modified-Since` header or an `If-None-Match` header.
+The origin confirmed the cached resource was unchanged via a conditional request (`If-Modified-Since` or `If-None-Match`), and the response is served from Cloudflare's cache. This status reflects the synchronous validation path — the request waits for the origin to respond before being served.
+
+With [asynchronous `stale-while-revalidate`](/cache/concepts/revalidation/#asynchronous-revalidation), most revalidations now return `UPDATING` or `HIT` instead. `REVALIDATED` is seen in the following situations: `stale-while-revalidate` is not set; directives like `must-revalidate` or `no-cache` (with [Origin Cache Control](/cache/concepts/cache-control/) enabled) prevent stale content from being served; or the zone is an Enterprise zone that has not yet been migrated (refer to [Synchronous revalidation](/cache/concepts/revalidation/#synchronous-revalidation-legacy)).
 
 ## UPDATING
 
-The resource was served from Cloudflare's cache and was expired, but the origin web server is updating the resource. `UPDATING` is typically only seen for very popular cached resources.
+The resource was expired but served from Cloudflare's cache while the origin updates it in the background. `UPDATING` is the expected status during [asynchronous `stale-while-revalidate`](/cache/concepts/revalidation/#asynchronous-revalidation) revalidation — all requests during the revalidation window receive `UPDATING` or `HIT` rather than waiting for the origin.
 
 ## DYNAMIC
 
diff --git a/src/content/docs/cache/concepts/retention-vs-freshness.mdx b/src/content/docs/cache/concepts/retention-vs-freshness.mdx
index 6af03e3c22c3b4f..2782ab6cddfb785 100644
--- a/src/content/docs/cache/concepts/retention-vs-freshness.mdx
+++ b/src/content/docs/cache/concepts/retention-vs-freshness.mdx
@@ -18,4 +18,4 @@ The time window that an object should be considered safe for a cache to use is d
 
 * Use [Cache Rules](/cache/how-to/cache-rules/) or [Workers](/cache/interaction-cloudflare-products/workers/).
 
-If an object in cache is no longer fresh and Cloudflare receives a request for it, we ask the origin to revalidate the object we have in cache. The Origin can then either send a new version of the object which will replace the old in cache, or tell us the object we have is valid and to refresh its TTL. This revalidation will happen any time an object’s retention period is greater than its freshness period.
+If an object in cache is no longer fresh, Cloudflare revalidates it with the origin. When [`stale-while-revalidate`](/cache/concepts/cache-control/#revalidation) is set, revalidation happens asynchronously at expiry — visitors continue to be served from cache while Cloudflare fetches a fresh copy in the background. Without this directive, incoming requests wait for the origin to respond before receiving content. The origin can either confirm the cached object is still valid (refreshing its TTL) or return a new version to replace it. Refer to [Revalidation](/cache/concepts/revalidation/) for details.