DNS er infrastruktur. Og infrastrukturfejl er de farligste fejl i SEO — fordi de sjældent råber på dig.

En kapøt JavaScript-blok giver en konsolfejl. En manglende robots.txt giver et 404. Men en DNS-fejl der bremser Googlebot? Den viser sig måske som lavere crawl-frekvens i Google Search Console tre uger efter migrationen. Måske opdager du det aldrig.

Her er hvad der faktisk sker, og hvad du konkret skal tjekke.

Sådan bruger Googlebot DNS

Når Googlebot besøger dit site, starter processen ikke med en HTTP-request. Den starter med et DNS-opslag: Googlebot slår IP-adressen op for dit domæne, ligesom enhver anden klient.

Men Googlebot gør noget ekstra. Af sikkerhedshensyn udfører Google også et reverse DNS-lookup — det vil sige, at Google tjekker om den IP-adresse, som en crawler udgiver sig for at komme fra, faktisk peger tilbage på Googles eget netværk. Det er en mekanisme til at forhindre, at falske Googlebots crawler dine sider.

Implikationen: hvis din DNS-konfiguration er ufuldstændig — fx fordi din PTR-record (reverse DNS) ikke peger korrekt — kan Google markere din crawler-trafik som mistænkelig eller i edge cases nægte at bekræfte legitime Googlebots. Det handler ikke om at blokere Google i at crawle dit site, men det berører reverse DNS og Googlebot som verifikationsmekanisme.

Det direkte DNS-opslag er dog det kritiske. Hvis dit DNS ikke svarer, eller svarer langsomt, venter Googlebot — og den venter ikke evigt.

De 4 DNS-fejl der faktisk påvirker crawling

1. DNS-propagation-ventetid efter migration

Når du skifter hosting og opdaterer dine DNS-records, er der en propagation-periode. TTL-værdien (Time to Live) på dine records bestemmer, hvor lang tid nameservere rundt om i verden cacher den gamle IP.

Har du en TTL på 86.400 sekunder (24 timer) — som er default hos mange registrarer — kan det tage op til et døgn, inden alle DNS-servere ser den nye IP. I den periode vil noget Googlebot-trafik ende hos den gamle server, noget hos den nye.

Løsningen er at sænke TTL til 300-600 sekunder 48 timer inden du migrerer. Når migrationen er gennemført, kan du hæve TTL igen. Denne enkle handling reducerer DNS propagation-vinduet fra timer til minutter.

2. Forkert reverse DNS

Google bruger PTR-records til at verificere at en crawler-IP faktisk tilhører Googles net. Konfigurerer du reverse DNS forkert — eller glemmer det helt ved en ny server — er du teknisk set ok, men du eliminerer Googles mulighed for at verificere sig selv, hvilket kan påvirke, hvordan tredjeparts security-lag (WAF’er, CDN’er med bot-protection) behandler Googlebots requests.

Tjek altid at PTR-recorden for din servers IP peger på en genkendelig Google-hostname-struktur, hvis du konfigurerer den selv.

3. DNSSEC-fejl

DNSSEC tilføjer kryptografisk signering til DNS-records for at forhindre DNS spoofing. Det er en god ting. Men en forkert konfigureret DNSSEC er potentielt katastrofal: resolvers der understøtter DNSSEC vil afvise hele DNS-responsen, hvis signaturen ikke validerer.

Det betyder: intet svar → ingen IP → Googlebot kan ikke nå dit site overhovedet.

DNSSEC-fejl opstår typisk ved hosting-migrationer, hvor DNSKEY-records ikke overføres korrekt til den nye nameserver. Resultatet er en SERVFAIL-fejl, som Googlebot vil logge og opgive for det pågældende request.

Tjek din DNSSEC-validering med DNSViz efter enhver migration.

4. TTL for høj under og efter migrationen

Som nævnt under punkt 1 er en høj TTL problematisk under migrationer. Men TTL er også relevant i en anden situation: hvis dit site af en eller anden grund bliver utilgængeligt (servernedbrud, ekspireret certifikat, fejlkonfigureret firewall), og dit DNS caches med en lang TTL, vil Googlebot fortsætte med at forsøge at nå den ikke-fungerende IP i hele cache-perioden.

Det er ikke DNS’s “skyld” — men en lav TTL giver dig fleksibilitet til hurtigere at rette op.

Hvad sker der med dit crawl budget når DNS svarer for langsomt?

Crawl budget er Googles ressourcetildeling til dit site: hvor mange sider Googlebot crawler, og hvor hurtigt. Det er ikke en fast størrelse — det justeres løbende baseret på bl.a. serverresponstid og crawl-fejlraten.

Langsom DNS-respons tæller som langsom responstid. Googlebot måler den samlede tid fra request til svar, inklusive DNS-lookup-tid. Svarer din nameserver konsekvent langsomt (over 200-300ms), vil Googlebot sænke sin crawl-rate for at undgå at overbelaste din infrastruktur — det er en automatisk beskyttelse der er tænkt som en fordel, men som i praksis reducerer din crawl-frekvens.

For store sites med mange sider — eller sites der netop har publiceret en masse nyt indhold — er det et reelt problem. Googlebot crawler færre sider per dag end den kunne, og nye sider kommer langsommere i indekset.

Se på DNS-fejl og crawling for en dybere gennemgang af sammenhængen, og crawling i dybden for at forstå crawl-mekanikken generelt.

Hvad du tjekker i Google Search Console og DNS-tools

Google Search Console:

• Gå til Indstillinger → Crawl-statistik. Se på “Downloadtid” over de seneste 90 dage. Er der et tydeligt knæk efter en dato der matcher en migration? Det er et signal.
• Tjek Dækning → Crawlfejl. DNS-fejl vises som “DNS-fejl” i crawlfejl-rapporten, ikke som 404 eller 5xx. De er nemme at overse, fordi de ikke har en URL tilknyttet.

DNS-tools:

• DNSChecker.org — tjek DNS-propagation fra 100+ lokationer
• MXToolbox — hurtigt overblik over alle record-typer
• DNSViz — visualisering af DNSSEC-kæden
• Google Admin Toolbox dig — Googles eget DNS-debug-tool

Tjek også din robots.txt efter en migration. Ikke fordi det er DNS — men fordi hosting-migrationer og flytning af filer er det tidspunkt, hvor robots.txt oftest utilsigtet blokkerer hele sitet.

DNS er SEO — tjek det inden du skifter hosting

Det er en kort tjekliste, men den er værd at følge slavisk ved enhver hosting-migration:

1. Sænk TTL til 300-600 sekunder mindst 48 timer inden migrationen
2. Verificer DNSSEC-konfigurationen — brug DNSViz efter cut-over
3. Tjek PTR-records for nye server-IP’er
4. Tjek crawlfejl og crawl-statistik i Google Search Console 7 og 14 dage efter migrationen
5. Tjek robots.txt er intakt og tilgængelig

DNS er sjældent første sted SEO’ere kigger, når rangeringer falder. Det burde det oftere være.

Infrastrukturfejl er usynlige i SERPs. Det gør dem farligere, ikke ligegyldige.