
Kort fortalt
Google Search Central skrev 11. november 2026, at et skift til CDN kan få Googlebot til at crawle hurtigere, fordi svartiderne falder, mens den kolde cache sender hver første forespørgsel videre til din origin. Rådet er at forvarme cachen, undtage verificerede crawlere fra bot-beskyttelse og bruge 429 eller 503 i højst 1-2 dage som nødbremse. Det, indlægget ikke siger: en CDN-cache ligger pr. datacenter, og Googlebot crawler ifølge Googles egen dokumentation primært fra IP-adresser i USA. Cloudflare cacher desuden ikke HTML som standard. Uden tiered cache fylder en forvarmning fra Danmark en edge, Googlebot sjældent spørger.
Forvarmning hjælper kun, hvis den fylder den cache, Googlebot spørger, og på et dansk site gør den sjældent det: din forvarmning går gennem en edge i Norden, mens Googlebot primært kommer fra USA og rammer en anden. Løsningen er at gøre HTML cachebar og samle cache-missene i ét lag tæt på origin, før du forvarmer.
Hvad Google skrev 11. november
Gary Illyes og Cherry Prommawin lukkede første sæson af videoserien The Non-Canonical Cabinet med et afsnit om CDN'er og et ledsagende indlæg på Search Central-bloggen. Mekanikken er enkel. Googles crawlere justerer hastigheden efter, hvor hurtigt og stabilt serveren svarer, det Google kalder crawl capacity limit. Når DNS peger på et CDN, falder svartiderne, og for crawleren ligner det en hardwareopgradering. Den skruer op.
Problemet er, at et nyt CDN starter med en tom cache. Hver URL, der ikke er hentet før, er et cache miss, som edge-serveren må hente fra origin. Besøgende samler sig om få populære sider, som hurtigt bliver varme. Crawlere gør det modsatte og går systematisk gennem hele URL-beholdningen. Google skriver det selv ligeud: under en CDN-lancering er origin stadig flaskehalsen.
Rådene er tre. Tillad verificerede bots i CDN og firewall frem for at slå generel bot-beskyttelse til. Forvarm cachen med de mest besøgte, de kommende kampagnesider og de mest crawlede URL'er, før al trafik flyttes. Og brug 429 eller 503 som midlertidig bremse i nogle timer, højst 1-2 dage, som beskrevet i Googles guide til at sænke crawl rate. Samme side advarer om, at statuskoderne over flere dage kan få URL'er droppet fra indekset.
Forbeholdet: cachen er ikke ét sted
Indlægget taler om "the CDN cache", som om det var én beholder. Det er det ikke. Et CDN består af mange datacentre, og hvert af dem har sin egen cache. Cloudflare beskriver det i sin dokumentation af standardcaching: request collapsing, der forhindrer dobbelte origin-kald ved samtidige misses, virker inden for ét datacenter ad gangen.
Læg det sammen med en anden af Googles egne sider. I dokumentationen af Googlebot står der, at Googlebot primært crawler fra IP-adresser i USA. En forespørgsel fra en amerikansk IP lander typisk på en amerikansk edge.
Så forestil dig den forvarmning, Google anbefaler, kørt af et dansk bureau fra et kontor i Aarhus eller en server i Frankfurt. Den fylder caches i København, Hamborg eller Frankfurt. Googlebot spørger i Ashburn eller Chicago, finder en tom cache og går videre til din origin i Danmark. Forvarmningen er gennemført, og din origin får alligevel hele crawlet, nu i højere tempo.
Cloudflare cacher ikke din HTML af sig selv
Der er et lag mere. Cloudflare cacher efter filendelse, og standardlisten er billeder, CSS, JavaScript, fonte og den slags. HTML og JSON caches ikke som standard, og et svar med en Set-Cookie-header caches slet ikke. Robots.txt bliver til gengæld cachet. På en standardopsætning går hver eneste HTML-forespørgsel fra Googlebot derfor direkte til origin, uanset hvor meget du forvarmer. Forvarmning af HTML er spildt arbejde, indtil du har lavet en Cache Rule, der gør siderne cachebare.
Det er ikke en kritik af Googles råd. Det er en påmindelse om, at "flyt til CDN" i praksis betyder fire forskellige ting afhængigt af, hvad der caches, hvor det caches, og hvem der spørger.
Rækkefølgen, der virker
Her er strukturen, jeg ville følge før en flytning. Den beskriver arbejdsgangen, ikke en færdig konfiguration, fordi detaljerne afhænger af CMS, cookies og hosting.
- Gør HTML cachebar. Find ud af, hvilke sider der sætter cookies for anonyme besøgende, og fjern dem eller lav en Cache Rule, der ser bort fra dem. Uden det er resten ligegyldigt for crawl-belastningen.
- Slå tiered cache til. Cloudflares Smart Tiered Cache vælger ét upper tier-datacenter med lavest latenstid til din origin, og kun det må hente fra origin. Funktionen er gratis på alle planer. Forbeholdet står i Cloudflares egen beskrivelse: ligger din origin bag en anycast-adresse, falder den tilbage til flere upper tiers, og så når flere forespørgsler origin.
- Vælg URL'erne fra data, ikke fra menuen. Google nævner de mest crawlede URL'er. Dem finder du i serverloggen eller i Search Consoles crawlstatistik, ikke i sitemappen. Tilføj kampagnesider, der skal leve i den periode, flytningen sker.
- Forvarm i roligt tempo og kontrollér svaret. Hent hver URL gennem CDN'et og tjek, at
cf-cache-statusgår fra MISS til HIT ved andet kald. Står der DYNAMIC eller BYPASS, er punkt 1 ikke på plads. - Undtag verificerede crawlere, før du slår beskyttelse til. En generel bot-udfordring stopper også Googlebot. Verificér mod Googles IP-lister og ikke mod user agent-navnet, som jeg har skrevet om i artiklen om falske Googlebots.
- Hav nødbremsen klar, men hold robots.txt udenfor. En regel, der svarer 429 eller 503, skal ramme sider, ikke robots.txt. Hvorfor står i artiklen om 503 under PHP-patchen.
Hvor stor risikoen er for dig
Mine egne sites bygges statisk og serveres bag Cloudflare. Der er origin en filserver, og et koldt cache-miss koster næsten ingenting. Risikoen sidder hos sites, hvor hver sidevisning er et PHP- eller databasekald: WordPress med mange plugins, webshops med filtrerede kategorisider, kalendere med en URL pr. dato. Det er netop de URL-mønstre, Google selv nævner som de typiske årsager til pludselige crawl-spidser. Har du mange af dem, er tiered cache og cachebar HTML ikke en optimering. Det er forudsætningen for, at CDN'et beskytter noget.
Forvarm laget, ikke byen
Googles råd er rigtigt, men det forudsætter én cache, som både du og Googlebot rammer. Det har du først, når HTML kan caches, og alle edges deler ét lag foran din origin. Indtil da er en forvarmning fra Danmark mest en test af din egen forbindelse.