
Observe
Googlebot lives at the edge
Crawl budget, Core Web Vitals, and cache hits are the same system. Search engines fetch you from PoPs — and most SEO tools never see the log line.
Search Console will tell you that a page is slow, or that it is not indexed, or that crawl is down. It will not tell you which point of presence answered Googlebot, whether that PoP had a warm cache, or whether a WAF challenge turned a crawler into a 403 with good posture.
The edge is where those facts live. SEO that ignores the CDN is astrology with a better UI.
Googlebot has favorite neighborhoods
Crawlers do not arrive evenly from “the internet.” They arrive from particular networks and particular regions. On many stacks, a very large share of Googlebot hits a small set of US PoPs even when the audience is European. If those PoPs are cold, misconfigured, or busy applying a bot rule that cannot tell a crawler from a scraper, the index is downstream of a cache miss.
This is why log-file SEO still matters in an age of dashboards. Sampled analytics lie. Edge logs, if you keep them, do not.
Core Web Vitals are a delivery problem wearing a UX badge
LCP is often an image, a font, or a hero that traveled too far, too encoded, too uncached. INP is often JavaScript that should have been someone else’s problem. CLS is usually a slot you forgot to reserve.
A CDN will not write a better template. It will:
- Put the bytes closer to the session.
- Compress and resize images so the hero is not a 4 MB apology.
- Hold HTML that is actually cacheable (fewer teams have this than claim it).
- Terminate TLS without a tour of the origin.
If your lab scores are green and your field scores are not, you do not have a Lighthouse problem. You have a real-user geography problem. That is what RUM is for — Core Web Vitals from the people who pay you, not from a datacenter in Iowa.
Crawl budget is cache policy
Every uncacheable HTML response is an origin hit you donated to a crawler. Every soft-404 you keep serving is a budget you spent on nothing. Every challenge page you showed a bot is a page that will not be in the index tomorrow.
The boring checklist, which outperforms most content strategies:
- Make the templates you care about cacheable, with keys that do not explode on tracking parameters.
- Warm the URLs search engines actually request, not the ones in the sitemap you meant to prune.
- Do not put the WAF in front of Googlebot unless you can identify Googlebot.
- Watch which PoP serves the crawler. If it is always the same one, treat that PoP as production for SEO.
Cache warming sounds like a trick. It is closer to hospitality: be dressed when the guest arrives. Over-warming, like over-failover, can knock over the origin. Sequence it. Sitemap first. Learned URLs second. Wait.
GEO is not a replacement for this
Generative engines still fetch. They still need a document that exists, loads, and is not blocked. “GEO” — showing up in answers — sits on top of the same crawl and performance substrate. If the page is slow or invisible to bots, no amount of structured prose will get you cited.
Write for humans and machines. Then make sure both of them hit a warm edge.
One system, three tickets
The unfashionable truth is that crawl, cache, and Core Web Vitals are the same system. Operators who sit across performance and technical SEO — Optimi among them — tend to notice Googlebot’s PoP habits before the ranking drop shows up in Search Console.
If you are still choosing a network, there is no best CDN. If your network is also your only network, that is a single point of failure. Neither essay will index itself.