Robots.txt: Styr crawling uden at blokere det forkerte

Robots.txt er et adgangssignal til crawlere, ikke en kontakt til at slukke for indeksering. En forkert regel kan derfor skjule vigtige ressourcer for Googlebot uden at fjerne URL'en fra søgeresultaterne. Begynd med forskellen mellem crawling og indeksering i denne guide til tekniske SEO-problemer, før du ændrer filen.

Robots.txt styrer crawling – ikke indeksering

En robots.txt-fil ligger offentligt på en host og beskriver, hvilke stier bestemte crawlere må hente. Google Search Central fremhæver, at formålet primært er at styre crawlertrafik og undgå unødige forespørgsler. Det er en vigtig afgrænsning, fordi en blokeret URL stadig kan være kendt gennem links og andre signaler.

Skeln derfor mellem den tekniske handling og det resultat, du ønsker:

• Brug Disallow, når en crawler ikke bør hente en bestemt sti.
• Brug noindex, når en tilgængelig side ikke bør vises i Googles resultater.
• Brug login eller anden adgangskontrol, når indholdet reelt er privat.
• Brug en korrekt fejlkode, når indholdet ikke længere findes.

Hvis du vælger robots.txt for at løse et indekseringsproblem, gør du det samtidig sværere for Google at se et eventuelt noindex-signal på siden. Google kan i stedet vise URL'en uden uddrag, hvis den opdages gennem et link. Filer og stier i robots.txt er desuden synlige for alle, der åbner filen. Den må derfor aldrig fungere som en liste over hemmelige områder.

Disallow er ikke det samme som noindex

Google skal kunne crawle en side for at læse et noindex-tag eller en X-Robots-Tag-header. Blokerer robots.txt først, kan indekseringsreglen ikke aflæses. Beslut derfor i denne rækkefølge: Skal indholdet være offentligt? Skal siden kunne vises i søgning? Skal en bestemt crawler kunne hente den? Først det sidste spørgsmål hører hjemme i robots.txt. Den rækkefølge forhindrer, at ét signal spærrer for et andet.

Placér filen rigtigt og skriv få klare regler

Filens placering bestemmer dens rækkevidde. https://example.dk/robots.txt gælder kun for samme protokol, host og port; den styrer ikke automatisk http, en subdomain eller en anden port. Google kræver en UTF-8-kodet tekstfil i roden og behandler stiernes store og små bogstaver som forskellige tegn.

En enkel fil behøver normalt kun fire typer linjer:

• User-agent vælger den crawler eller gruppe, reglerne gælder for.
• Disallow afviser crawling af en sti eller et bestemt mønster.
• Allow åbner en mere specifik undtagelse i et blokeret område.
• Sitemap angiver den fulde URL til et sitemap eller sitemap-indeks.

Et sikkert udgangspunkt er ikke at kopiere en lang standardfil fra en generator. Start med de URL-mønstre, der faktisk skaber unødvendig crawling, og dokumentér hvorfor de findes. En tom Disallow-værdi blokerer intet, mens Disallow: / blokerer hele hosten for den valgte crawler. Den ene skråstreg er derfor en ændring med meget stor konsekvens.

User-agent, Disallow og Allow skal læses som en gruppe

Crawlers matcher regler inden for en User-agent-gruppe. For Googles fortolkning vinder den mest specifikke matchende sti mellem Allow og Disallow; rækkefølgen alene redder ikke en uklar regel. Skriv derfor stier, der svarer til det faktiske URL-mønster, og kontrollér både den ønskede blokering og nærmeste undtagelse. Kommentarer med # kan forklare hensigten, men de ændrer ikke selve matchningen.

Vælg blokering efter årsagen – ikke efter URL-typen

En parameter, filtervisning eller intern søgeside er ikke automatisk et robots.txt-problem. Nogle URL'er skal crawles, så Google kan forstå canonical, statuskode eller noindex. Andre skaber så mange gentagne kombinationer, at adgangsstyring kan være rimelig. Beslutningen kræver derfor konkrete crawlbeviser og en ansvarlig side for hvert indholdssæt.

Brug denne korte diagnose før du tilføjer en regel:

• Find URL-mønstret i logs, crawlrapporter eller Search Console.
• Beskriv den ressource, crawleren bruger, og hvilken værdi crawling giver.
• Kontrollér om URL'erne bærer canonical, noindex eller interne links, der skal ses.
• Afgræns den mindst mulige sti, der løser problemet.
• Udpeg hvilke tilladte URL'er der kan rammes ved en fejl.

Store websites med mange gentagelser kan have et reelt behov for at styre crawlertrafik. På et mindre website er crawlbudget sjældent den første flaskehals; en aggressiv blokering kan skabe mere usikkerhed end den fjerner. Google peger selv på meget store sites med hundredtusindvis af URL'er eller omfattende dubletmængder som typiske situationer, hvor fokus på mindre vigtigt indhold kan være relevant.

Et sitemap løser den modsatte opgave: det fremhæver URL'er, der bør opdages og crawles. Hold derfor sitemap og robots.txt som to forskellige signaler. En sitemap-linje i robots.txt er nyttig, men den ophæver ikke en Disallow-regel. Hvis de to filer peger i hver sin retning, har du skabt en konflikt, der bør ryddes op ved kilden.

Test konkrete URL'er før og efter udgivelse

En robots.txt-fil kan se korrekt ud som tekst og stadig ramme det forkerte URL-mønster. Test derfor ikke kun, om filen svarer med status 200. Kontrollér, hvordan den valgte crawler matcher repræsentative URL'er, og gentag testen efter udgivelse. Googles robots.txt-rapport i Search Console er lavet til filer, der allerede er offentligt tilgængelige.

En praktisk accepttest indeholder mindst disse URL'er:

• En URL, der bevidst skal blokeres af den nye regel.
• En nærliggende URL, der fortsat skal være tilladt.
• En vigtig landingsside i samme mappe eller template.
• En CSS- eller JavaScript-ressource, der kræves for korrekt rendering.
• En URL med store bogstaver, parametre eller slutskråstreg, hvis mønstret bruger dem.

Åbn også filen i et privat browservindue og bekræft, at den rigtige host leverer ren tekst. Test derefter med den crawleridentitet, reglen gælder for. Et resultat for * beviser ikke nødvendigvis, hvad en særskilt Googlebot-gruppe gør. Gem testlisten sammen med ændringen, så en senere oprydning ikke fjerner en vigtig undtagelse uden at kende konsekvensen.

Test forskellen mellem blokering og rendering

Når CSS eller JavaScript blokeres, kan den centrale HTML stadig være tilgængelig, mens Google ser en ufuldstændig side. Sammenlign derfor ikke kun tilladt eller afvist. Brug URL-inspektion til at se den leverede side og dens ressourcer, og kontrollér om Google kan forstå indhold, navigation og strukturerede elementer. En god test beviser både, at den uønskede sti er lukket, og at den ønskede oplevelse stadig kan gengives.

Håndtér caching, statuskoder og ændringer som drift

Robots.txt er en driftskritisk fil, selv om den kun fylder få linjer. Google cacher normalt filen i op til 24 timer, og serverfejl behandles anderledes end en manglende fil. En rettelse kan derfor være korrekt på serveren, mens crawleren midlertidigt bruger en tidligere kopi eller sætter crawling på pause.

Overvåg især disse situationer efter en ændring:

• Et 4xx-svar kan blive tolket som ingen crawlbegrænsninger, bortset fra 429.
• Ved 5xx stopper Google først crawling og forsøger at hente filen igen.
• Redirects til robots.txt bør være korte, stabile og ende i ren tekst.
• En ændret host, protokol eller port kræver sin egen korrekte fil.
• En fil over Googles grænse på 500 KiB bliver kun behandlet frem til grænsen.

IETF's RFC 9309 beskriver, at crawlere bør følge mindst fem sammenhængende redirects og normalt ikke bruge en cachet kopi i mere end 24 timer, medmindre filen er utilgængelig. Google beskriver sin konkrete fejlhåndtering mere detaljeret: ved 5xx stopper crawling først i 12 timer og kan derefter bruge den senest fungerende version i op til 30 dage.

Gør ændringen reversibel og observerbar

Gem filen i versionsstyring, knyt hver regel til et kendt URL-mønster, og planlæg en tilbagerulning før udgivelse. Kontroller serverlogs, Search Console og de vigtigste landingssider efter ændringen. Hvis du ikke kan forklare, hvilken crawleradfærd reglen skal ændre, er den ikke klar til produktion. Når en blokering påvirker flere templates eller hosts, kan et afgrænset SEO- og websprint være mere sikkert end en løs rettelse.

Brug robots.txt som et præcist signal – ikke som oprydning

Den bedste robots.txt-fil er ikke den længste. Den er afgrænset, forståelig og knyttet til en dokumenteret årsag. Den forsøger ikke at reparere dubletindhold, fjerne gamle URL'er eller beskytte private data. De opgaver kræver andre signaler og ofte en rettelse i CMS, routing eller informationsarkitektur.

Før en regel bliver permanent, bør du kunne svare ja til disse punkter:

• URL-mønstret er dokumenteret med faktiske eksempler.
• Den ønskede effekt handler specifikt om crawling.
• Nærliggende vigtige sider og ressourcer er testet som tilladte.
• Indeksering og adgangskontrol løses med deres egne mekanismer.
• En ansvarlig person ved, hvordan reglen kontrolleres og fjernes igen.

Det kommercielle spørgsmål er ikke, om du kan få en crawler til at hente færre URL'er. Det er, om ændringen beskytter kapacitet og gør de rigtige sider lettere at finde uden at øge risikoen for tabt synlighed. En lille fil kan påvirke hele sitet, så konsekvensen skal veje tungere end ønsket om teknisk oprydning.

Vurder derfor robots.txt sammen med logs, interne links, sitemap, statuskoder og de sider, der faktisk skaber efterspørgsel eller henvendelser. Når signalerne peger samme vej, bliver filen en præcis del af driften. Når de modsiger hinanden, er robots.txt ofte kun det sted, hvor et større strukturproblem bliver synligt.