Migrera till CDN utan att blockera Googlebot eller krascha ursprungsservern
Google Search Central har publicerat en detaljerad guide om vad som händer med crawltrafiken när en webbplats migreras bakom ett CDN, och varför Googlebot paradoxalt nog kan öka sin crawlfrekvens precis när man vill minska belastningen på ursprungsservern. Artikeln förklarar mekanismerna bakom crawl capacity limit, kalla cacher och felkonfigurerade botskydd, samt erbjuder konkreta åtgärder för att undvika att tappa synlighet i sökmotorn under övergångsfasen.
Nyckelpunkter
- När DNS-pekaren ändras till ett CDN tolkar Googles crawlinfrastruktur de snabbare svarstiderna som ett tecken på förbättrad serverkapacitet, vilket automatiskt höjer crawlhastigheten och ökar antalet förfrågningar mot ursprungsservern.
- En ny CDN startar med en helt tom (kall) cache, vilket innebär att varje unik URL som crawlas för första gången genererar ett cache-miss och skickar förfrågan rakt igenom till ursprungsservern, precis som om CDN:et inte existerade.
- Mänskliga besökare tenderar att koncentrera sig på ett fåtal populära sidor som snabbt värmer upp CDN-cachen, medan crawlers systematiskt genomsöker hela URL-inventariet och därmed genererar ett stort antal cache-missar under uppvärmningsfasen.
- Generella botskyddsregler i CDN-dashboards eller WAF-lösningar, utan undantag för verifierade crawlers, blockerar Googlebot med CAPTCHA-utmaningar som roboten inte kan lösa, vilket leder till att sidor faller ur sökresultaten.
- Google rekommenderar att använda HTTP-statuskoderna 429 (Too Many Requests) eller 503 (Service Unavailable) som tillfälliga bromsar under cache-uppvärmningen, men aldrig längre än några timmar eller maximalt ett till två dygn.
- Det går att förvärma CDN-cachen proaktivt genom att programmatiskt hämta de mest besökta och mest crawlade URL:erna via CDN:et i kontrollerad takt innan all trafik dirigeras om, vilket minskar antalet cache-missar avsevärt.
Analys
Googles crawlinfrastruktur justerar kontinuerligt crawlhastigheten baserat på ursprungsserverns svarstider. Lägre latens tolkas som ett hälsotecken och leder automatiskt till att crawl capacity limit höjs. När ett CDN aktiveras sjunker anslutnings- och svarstiderna dramatiskt, och Googlebots system reagerar som om servern precis fått en massiv hårdvaruuppgradering. Resultatet är en omedelbar ökning av crawlförfrågningar, vilket är raka motsatsen till vad många webbansvariga förväntar sig av en CDN-migrering.
Problemet förstärks av att CDN-cachen är helt tom vid lanseringen. Varje cache-miss innebär att edge-servern måste hämta innehållet från ursprungsservern, lagra en kopia och sedan leverera svaret. Under den period då cachen värms upp fungerar CDN:et därför inte som en sköld mot trafik, utan snarare som ett extra lager i kedjan som fortfarande belastar ursprungsservern lika hårt som tidigare. Kombinationen av ökad crawlhastighet och ett stort antal cache-missar kan under migrationsfasens första timmar eller dygn generera en belastning som är högre än före migreringen.
En vanlig reaktion från systemadministratörer som ser oväntade trafiktoppar i loggarna är att aktivera generella botskyddsregler i CDN:ets eller WAF:ens kontrollpanel. Dessa regler är ofta konfigurerade för att fånga upp all automatiserad trafik utan åtskillnad, vilket innebär att Googlebot ställs inför CAPTCHA-utmaningar som roboten inte kan lösa. Ur Googles perspektiv framstår webbplatsen då som medvetet begränsad eller trasig. Om blockaden kvarstår backar crawlers och de berörda sidorna börjar succesivt försvinna ur sökresultaten, vilket kan ha direkta konsekvenser för organisk trafik och intäkter.
Det finns en tydlig åtskillnad mellan att tillfälligt bromsa crawling med semantiskt korrekta HTTP-svar och att blockera crawlers helt. Statuskoderna 429 och 503 signalerar till Googlebot att servern är tillfälligt överbelastad och att roboten bör återkomma senare. Det är ett accepterat och dokumenterat sätt att hantera akut belastning under exempelvis en CDN-migrering. En 403-sida eller en CAPTCHA-utmaning ger däremot signalen att åtkomst är förbjuden, vilket Googles system tolkar som en permanent restriktion.
Vad du bör göra
- Konfigurera CDN:ets och WAF:ens botskyddsregler med specifika undantag för verifierade crawlers genom att använda Googles publicerade IP-intervall, så att Googlebot aldrig utsätts för CAPTCHA-utmaningar eller blockeras av generella automatiseringsfilter.
- Förvärm CDN-cachen proaktivt innan all trafik dirigeras om, genom att programmatiskt hämta de mest besökta sidorna, kampanjsidor och de URL:er som historiskt sett crawlas mest frekvent, i en kontrollerad takt via CDN:et.
- Använd tillfälliga HTTP 429- eller 503-svar under cache-uppvärmningsfasen om ursprungsservern visar tecken på överbelastning, men begränsa denna åtgärd till maximalt ett till två dygn för att undvika negativa crawling-effekter på sikt.
- Undvik generella botblockeringsregler och välj istället riktade regler mot specifika oönskade bottar, exempelvis baserat på User-Agent-strängar eller robots.txt-direktiv, för att behålla kontrollen utan att påverka önskad crawltrafik.
- Övervaka ursprungsserverns belastning, CDN-cachens träffkvot (cache hit ratio) samt Googles crawlfrekvens i Google Search Console under migrationens första dagar för att kunna reagera snabbt om obalans uppstår.
- Planera CDN-migreringen utanför perioder med hög affärstrafik, till exempel säsongskampanjer, för att minimera risken att en temporär crawl-störning eller cache-uppvärmning sammanfaller med kritiska trafikökningar.
En felaktigt konfigurerad CDN-migrering kan leda till att Googlebots crawlförfrågningar blockeras av CAPTCHA-utmaningar eller brandväggsregler, vilket gör att sidor gradvis försvinner ur Googles sökresultat. Att förstå hur crawl capacity limit fungerar i samband med CDN-latens är avgörande för att bevara indexering och organisk synlighet.