No Edge Caching Means Your Server Is the Bottleneck

Published on June 08, 2026

Edge caching keeps a copy of your page on servers around the world, so a request gets answered from the one nearest the visitor instead of traveling back to your origin every time. With no edge cache, every request, from every human and every bot, hits your origin and waits for it to build the page from scratch. That's slower, and it's slower in the exact way that costs you AI traffic.

If this action item showed up in your audit, the agent saw your HTML served dynamically with no CDN cache in front of it. The telltale sign is a cf-cache-status: DYNAMIC header, or its equivalent on other CDNs. Here's what that means and how to decide whether to fix it.

Why no edge caching kills AI traffic

Getting cited by ChatGPT, Perplexity, or Google's AI Mode is a retrieval game, and retrieval starts with a crawler actually fetching your page. AI crawlers are far less patient than humans. They make one request, read whatever comes back, and move on. Reporting from technical SEO practitioners puts AI crawler timeouts under 10 seconds, sometimes less, well below what a browser would tolerate. If your origin is slow to respond, the crawler bails and your page never enters the pool of things an AI engine can cite.

The metric that matters is TTFB, Time to First Byte: how long the visitor waits before your server starts sending the page. Google says most sites should aim for 0.8 seconds or less. TTFB isn't a Core Web Vitals metric itself, but it's the floor under Largest Contentful Paint: LCP can never be faster than the first byte. A slow server eats the budget for everything after it, so a bad TTFB drags LCP down with it.

It costs you crawl coverage too. Google says outright that if it can load your pages faster, it might read more content from your site, and crawl health works both ways: respond quickly and Google raises the number of connections it uses; slow down and it backs off. No edge cache means every crawl hit pays full origin render cost, so you get fewer pages crawled per visit. Fewer crawled pages means fewer pages in the index, human or AI.

What approving this fix does

Approving this action item tells the agent to put an edge cache in front of your HTML, so a CDN node near the visitor answers requests instead of your origin rebuilding the page every time. In practice that means setting cache rules and Cache-Control headers so your pages return HIT from the edge instead of DYNAMIC.

The win is mechanical. A cached page skips the origin round trip and the render entirely. TTFB drops from "however long your server takes" to "however long the nearest edge node takes," usually tens of milliseconds. Every visitor and every crawler gets the fast path.

When to approve, and when to skip

Approve this when:

  • Your pages are mostly the same for everyone. Marketing pages, blog posts, docs, product pages: content that doesn't change per visitor is the ideal cache candidate, and it's exactly the content you want AI to cite.
  • Your audit shows a slow TTFB or cf-cache-status: DYNAMIC on pages that should be public and static. This is the common case, and it's usually a config change, not a rewrite.

Think twice when:

  • The page is genuinely per-user. A logged-in dashboard, a cart, a personalized feed: caching the wrong version and serving it to someone else is a real bug. These pages should stay dynamic, or use a strategy that keys on the user.
  • You have content that changes by the second and must be exact, like live pricing or inventory. You can still cache these with short TTLs or cache invalidation, but that's a more careful setup than a blanket rule.
  • You don't control the CDN or the headers. If your hosting doesn't expose cache configuration, this becomes a hosting decision, not a header tweak.

The effort is usually low. The risk is all about scoping: cache the public pages, leave the personalized ones alone. That's the line to check before you approve.

How the fix gets applied

Once you approve, the agent configures caching for the pages that should be cached, sets the appropriate Cache-Control and edge cache rules through your site's connection, and leaves dynamic or per-user routes uncached. It's a configuration change, not a content change, so your pages read identically. They just arrive faster, fast enough that an impatient AI crawler actually waits for them.

Frequently asked questions

What does cf-cache-status: DYNAMIC mean? It means Cloudflare did not cache that response and served it straight from your origin. On Cloudflare, DYNAMIC means the asset wasn't considered cacheable by default and no rule told it otherwise, so every request pays full origin cost. HIT is what you want: served from the edge.

Is TTFB a Google ranking factor? Not directly. TTFB is not one of the Core Web Vitals. But it sets the floor for Largest Contentful Paint, which is a ranking signal: LCP can never be faster than the first byte. Google also ties crawl rate to how fast your server responds. A slow TTFB hurts you through both, even though Google doesn't score it on its own.

Why do AI crawlers care more about speed than Google does? Because they're built to skip slow pages. AI crawlers run tight timeouts and generally don't execute JavaScript, so they take one quick request and bail if your origin is slow. Googlebot is more patient and renders more. An origin that's "fine for Google" can still be too slow for ChatGPT or Perplexity to bother with.

Will edge caching break personalized pages? Only if you cache them. The fix scopes caching to pages that are the same for everyone and leaves per-user routes dynamic. Caching is a per-route decision, not an all-or-nothing switch.

Sources