Google Crawl Budget – sådan prioriterer Google dit website

Google besøger ikke nødvendigvis alle sider på et website, hver gang Googlebot kommer forbi. Crawl budget handler om, hvordan Google prioriterer sine ressourcer, og hvilke URL’er der bliver crawlet.

Kort fortalt om Google Crawl Budget

Google Crawl Budget er et udtryk for det antal URL’er på et website, som Googlebot kan og ønsker at crawle inden for en given periode.

For de fleste mindre websites er crawl budget sjældent et alvorligt problem. Det får først for alvor betydning på store websites, webshops og tekniske løsninger, hvor der kan opstå meget store mængder URL’er.

Arbejdet med crawl budget handler ikke blot om at få Google til at crawle mere. Det handler om at sikre, at Google bruger sine ressourcer på de sider, der faktisk har betydning.

Google gennemgår ikke nødvendigvis hele dit website

Mange forestiller sig, at Google regelmæssigt gennemgår et website fra den ene ende til den anden.

Sådan fungerer det ikke.

Googlebot skal hver dag besøge enorme mængder af sider på internettet. Derfor foretager Google hele tiden en prioritering af, hvilke websites der skal besøges, hvilke URL’er der skal crawles, og hvor ofte det skal ske.

På et mindre website med 50 eller 100 velforbundne sider vil Google normalt kunne finde rundt uden større problemer. Her vil det sjældent give mening at bruge mange timer på at optimere et teoretisk crawl budget.

Situationen kan være en helt anden på en webshop med titusindvis af produkter, filtreringer, sorteringer, søgesider, parametre og gamle URL’er. Her kan Googlebot ende med at bruge en stor del af sine besøg på adresser, der ikke bør have nogen selvstændig værdi i søgeresultaterne.

Det er dér, crawl budget bliver interessant.

Hvad er Google Crawl Budget?

Google beskriver crawl budget som det antal URL’er, Googlebot både kan og ønsker at crawle.

Det betyder, at crawl budget i praksis består af to forskellige forhold:

• Crawl capacity: Hvor meget crawling kan websitet og serveren håndtere?
• Crawl demand: Hvor stor interesse har Google i at crawle URL’erne?

De to forhold hænger sammen, men de er ikke det samme.

En hurtig server kan gøre det muligt for Googlebot at hente mange sider. Det betyder ikke nødvendigvis, at Google ønsker at hente dem. Omvendt kan Google have stor interesse i et website, men reducere hastigheden, hvis serveren begynder at svare langsomt eller returnerer mange fejl.

Crawl capacity – hvor meget kan serveren håndtere?

Google ønsker ikke at overbelaste et website. Googlebot tilpasser derfor sin aktivitet efter, hvordan serveren reagerer.

Hvis siderne svarer hurtigt og stabilt, kan Google som udgangspunkt sende flere forespørgsler uden at skabe problemer. Hvis serveren bliver langsom, afviser forbindelser eller returnerer mange serverfejl, vil Googlebot normalt reducere sin aktivitet.

Det er fornuftigt. En søgemaskine får ikke noget ud af at presse en server så hårdt, at almindelige besøgende ikke længere kan bruge websitet.

Serverkapaciteten kan blandt andet påvirkes af:

• langsomme svartider
• utilstrækkelig hosting
• tunge databaseforespørgsler
• fejl i CMS, plugins eller udvidelser
• mange 500- og 503-fejl
• timeouts og afbrudte forbindelser
• store mængder unødvendige dynamiske URL’er

En forbedring af serverens hastighed kan derfor gøre det lettere for Googlebot at crawle websitet effektivt.

Men en hurtigere server er ikke i sig selv en garanti for, at Google begynder at crawle flere sider. Der skal også være en efterspørgsel efter URL’erne.

Crawl demand – hvilke sider ønsker Google at besøge?

Den anden side af crawl budgettet er Googles vurdering af, hvor stort behov der er for at besøge bestemte URL’er.

Nogle sider bliver besøgt ofte, mens andre kun bliver besøgt med lange mellemrum. Det kan blandt andet hænge sammen med, hvor vigtige siderne virker, hvor ofte de ændres, og om Google tidligere har fundet nyt eller opdateret indhold på dem.

En nyhedsside, der opdateres mange gange dagligt, har et andet behov end en side med virksomhedens åbningstider, som stort set aldrig ændrer sig.

Google kan også øge sin aktivitet i forbindelse med større ændringer. Det kan for eksempel være ved en flytning til et nyt domæne eller efter omfattende ændringer af websitets URL-struktur.

Det er derfor ikke muligt at fastsætte ét bestemt antal daglige crawls, som alle websites bør opnå.

Et stort antal forespørgsler er heller ikke automatisk et kvalitetsstempel. Hvis Googlebot bruger hovedparten af dem på dubletter, parametre og gamle URL’er, er den høje aktivitet ikke nødvendigvis en fordel.

Hvornår er crawl budget vigtigt?

Crawl budget bliver ofte omtalt, som om det er et problem for alle websites. Det er efter min vurdering en forkert måde at gribe emnet an på.

Har et website nogle få hundrede sider, en fornuftig intern linkstruktur og ingen teknisk produktion af tusindvis af ekstra URL’er, vil Google normalt kunne finde og crawle de relevante sider.

Her er det ofte vigtigere at arbejde med indholdets kvalitet, interne links, sidernes formål og den generelle tekniske kvalitet.

Crawl budget bør især undersøges på:

• store webshops med mange produkter og kategorier
• websites med filtreret navigation
• portaler med mange tusinde af URL’er
• nyhedssites og andre websites med hyppige opdateringer
• websites med mange URL-parametre
• websites med omfattende duplicate content
• websites efter større migreringer eller ændringer af URL-strukturen
• websites, hvor vigtige nye sider bliver opdaget eller opdateret langsomt

Det afgørende er altså ikke kun, hvor mange rigtige sider et website har. Det afgørende er også, hvor mange forskellige URL’er den tekniske løsning kan producere.

Ét produkt kan blive til mange forskellige URL’er

En af de klassiske årsager til et unødvendigt stort URL-univers er, at det samme indhold kan åbnes gennem flere forskellige adresser.

Et produkt kan eksempelvis være tilgængeligt gennem:

• den normale produktadresse
• en adresse med sporingsparametre
• en adresse med sorteringsparametre
• en adresse fra en intern søgning
• flere forskellige kategoristier
• en printversion
• en adresse med sessionsdata

For den besøgende kan siderne se ens ud. For en crawler kan de i udgangspunktet fremstå som forskellige URL’er, der hver især skal vurderes.

Hvis strukturen gentages på tusindvis af produkter, kan et website med 20.000 reelle produktsider pludselig have hundredtusindvis eller millioner af teknisk mulige adresser.

Det er et godt eksempel på, at problemet ikke nødvendigvis ligger i mængden af indhold. Problemet ligger i mængden af URL’er.

Filtreringer og facetteret navigation

Facetteret navigation bruges især på webshops, hvor brugeren kan filtrere produkter efter eksempelvis størrelse, farve, pris, mærke og materiale.

Det er nyttigt for brugeren, men kan være teknisk vanskeligt.

Hvis hvert valg og hver kombination opretter en ny crawlbar URL, vokser antallet meget hurtigt. Ti filtre giver ikke kun ti ekstra sider. Filtrene kan kombineres på kryds og tværs og skabe et næsten ubegrænset antal adresser.

Nogle af disse sider kan have en selvstændig søgeværdi. En kategori med eksempelvis en bestemt produkttype og et bestemt mærke kan være relevant for brugerne.

Andre kombinationer er så smalle eller tilfældige, at de ikke bør være selvstændige landingssider.

Løsningen er derfor ikke nødvendigvis at blokere alle filtre. Der skal foretages en konkret vurdering af, hvilke kombinationer der har et formål, og hvilke der blot udvider websitets URL-univers.

Duplicate content og canonical

Når det samme eller næsten det samme indhold findes på flere URL’er, skal Google forsøge at vælge den adresse, der bedst repræsenterer indholdet.

Et korrekt canonical-tag kan hjælpe Google med at forstå, hvilken URL ejeren foretrækker som den primære version.

Canonical er dog ikke en erstatning for en fornuftig teknisk arkitektur.

Hvis interne links konsekvent peger på dubletter, mens canonical peger et andet sted hen, sender websitet modsatrettede signaler. Google skal stadig finde og crawle URL’erne for at se canonical-oplysningen.

Den bedste løsning er derfor normalt en kombination af:

• én tydelig primær URL
• konsekvente interne links til den primære URL
• korrekte canonical-tags
• redirects, hvor alternative adresser ikke længere skal eksistere
• en URL-struktur, der ikke producerer unødvendige dubletter

Redirects og redirect-kæder

En redirect er ikke i sig selv et problem. Redirects er en nødvendig del af driften af mange websites, især når sider flyttes eller URL-strukturen ændres.

Problemet opstår, når en gammel URL sender Googlebot videre til en anden URL, som derefter sender videre til en tredje eller fjerde adresse.

Det kaldes en redirect-kæde.

Hvert ekstra trin kræver en ny forespørgsel og gør processen mere kompliceret. Lange kæder kan også opstå over tid, hvis redirects bliver lagt oven på gamle redirects uden at blive ryddet op.

En gammel adresse bør derfor som udgangspunkt pege direkte på den endelige destination.

Interne links bør samtidig opdateres, så de ikke fortsat sender både brugere og crawlere gennem redirects.

404- og 410-sider

Det er normalt, at et website med tiden får URL’er, som ikke længere eksisterer. En korrekt 404- eller 410-status fortæller Google, at indholdet ikke er tilgængeligt.

Enkelte 404-fejl ødelægger ikke et websites crawl budget.

Problemet opstår, hvis systemet skaber meget store mængder ugyldige URL’er, eller hvis Googlebot konstant bliver ledt frem til adresser, der ikke findes.

Det bør derfor undersøges, hvorfor URL’erne bliver fundet:

• Findes der stadig interne links til dem?
• Står de i XML-sitemap?
• Bliver de genereret af filtre eller scripts?
• Er der eksterne links til gamle adresser?
• Er de opstået efter en migrering?

En gammel URL skal ikke automatisk redirectes til forsiden. Hvis der findes en reel erstatning, kan den gamle adresse viderestilles dertil. Hvis indholdet er fjernet uden en relevant erstatning, er en korrekt 404- eller 410-status ofte det rigtige svar.

Soft 404 kan skabe uklarhed

En soft 404 opstår typisk, når en side reelt fortæller, at indholdet ikke findes, men serveren stadig returnerer statuskode 200.

For en almindelig besøgende kan siden ligne en fejlside. Teknisk fortæller serveren imidlertid, at forespørgslen lykkedes, og at der findes en normal side på adressen.

Det skaber uklarhed.

Hvis et produkt eller en artikel er permanent fjernet, bør serverens statuskode passe til den situation, som brugeren og Googlebot møder.

XML-sitemap hjælper Google med at finde de rigtige URL’er

Et XML-sitemap er en liste over de URL’er, som websitet ønsker at gøre søgemaskiner opmærksomme på.

Et sitemap garanterer ikke, at Google crawler eller indekserer alle adresserne. Det er et signal og en hjælp til opdagelsen af siderne.

Sitemappet bør derfor ikke bruges som en losseplads for alle teknisk mulige URL’er.

Det bør som udgangspunkt indeholde de primære URL’er, der:

• returnerer statuskode 200
• må indekseres
• har korrekt canonical til sig selv
• har et reelt formål i søgeresultaterne

Redirects, 404-sider, noindex-sider og dubletter bør normalt ikke stå i det sitemap, der skal præsentere websitets aktive og foretrukne sider.

Robots.txt er ikke et værktøj til at fjerne sider fra Google

Robots.txt kan bruges til at fortælle crawlere, hvilke områder de ikke må hente.

Det er vigtigt at skelne mellem crawling og indeksering.

Hvis en URL blokeres i robots.txt, kan Googlebot ikke hente siden og dermed heller ikke læse et eventuelt noindex-tag i sidens HTML.

En blokeret URL kan i visse situationer stadig blive kendt gennem links og optræde i Googles indeks uden den normale beskrivelse af indholdet.

Hvis formålet er at få en side fjernet fra søgeresultaterne, skal Google normalt kunne crawle siden og se et noindex-direktiv. Robots.txt bør derfor ikke anvendes som en tilfældig erstatning for noindex.

På meget store websites kan robots.txt bruges til at begrænse crawling af bestemte tekniske URL-mønstre, men det kræver, at man på forhånd har taget stilling til konsekvenserne.

Noindex løser ikke nødvendigvis et stort crawlproblem

Noindex fortæller Google, at en side ikke skal vises i søgeresultaterne.

Googlebot skal imidlertid crawle siden for at finde og genlæse direktivet. Hvis et website producerer millioner af crawlbare noindex-sider, eksisterer URL-universet stadig.

Noindex er derfor nyttigt til at styre indekseringen af konkrete sider, men det bør ikke bruges som eneste løsning på en teknisk arkitektur, der ukontrolleret opretter URL’er.

Det er ofte bedre at forhindre, at værdiløse adresser bliver genereret eller gjort tilgængelige gennem crawlbare links.

Interne links viser, hvilke sider der er vigtige

Google finder mange sider ved at følge links.

Den interne linkstruktur er derfor en central del af arbejdet med crawling. Vigtige sider bør ikke ligge gemt så langt nede i strukturen, at de næsten kun kan findes gennem et sitemap.

En vigtig side bør normalt:

• kunne nås gennem almindelige HTML-links
• indgå naturligt i websitets struktur
• have links fra relevante sider
• ikke kræve en intern søgning eller formular for at blive fundet
• ikke ligge bag unødvendigt mange klik

Interne links gør mere end blot at føre Googlebot fra én adresse til en anden. De hjælper også med at forklare sidernes sammenhæng og relative betydning.

JavaScript, CSS og andre ressourcer bruger også crawling

Google crawler ikke kun selve HTML-dokumentet. Ved rendering kan Google også have behov for at hente JavaScript, CSS, billeder og andre ressourcer.

På moderne websites kan disse filer være nødvendige for at fremstille den side, som brugeren ser.

Det betyder ikke, at JavaScript i sig selv er forkert. Men en unødvendigt kompliceret løsning kan gøre crawling og rendering mere ressourcekrævende.

Det bør derfor sikres, at vigtigt indhold og vigtige links kan findes og behandles på en stabil måde, og at nødvendige ressourcer ikke fejlagtigt blokeres.

Crawling og indeksering er ikke det samme

En af de mest udbredte misforståelser er, at en side automatisk bliver indekseret, fordi Googlebot har besøgt den.

Crawling betyder, at Google har hentet siden eller en ressource.

Ved indekseringen analyserer Google blandt andet indholdet, sidens relation til andre sider og spørgsmålet om, hvilken URL der skal være den kanoniske version.

En side kan derfor være crawlet uden at blive indekseret.

Det kan eksempelvis skyldes:

• noindex-direktiv
• duplicate content
• valg af en anden canonical URL
• meget begrænset eller værdiløst indhold
• tekniske fejl
• at Google endnu ikke har færdigbehandlet siden

Et højt antal crawls er derfor ikke et mål i sig selv. Målet er, at de relevante sider kan findes, forstås og vurderes korrekt.

Google Search Console viser en del af billedet

I Google Search Console findes rapporten om crawlstatistik. Her kan man blandt andet se:

• det samlede antal crawlforespørgsler
• den samlede downloadmængde
• serverens gennemsnitlige svartid
• fordelingen på forskellige svarkoder
• fordelingen på filtyper
• hvilke Googlebot-typer der har besøgt websitet
• om formålet var opdagelse eller genbesøg

Rapporten kan vise udviklingen og afsløre ændringer i Googles aktivitet.

Den fortæller dog ikke nødvendigvis hele historien om hver enkelt forespørgsel. Skal man helt ned i detaljen, er serverens logfiler ofte nødvendige.

Serverlogfilerne viser, hvad der faktisk er sket

SEO-værktøjer kan crawle et website og fortælle, hvordan strukturen ser ud fra deres synspunkt. Google Search Console kan vise udvalgte oplysninger fra Googles side.

Serverlogfilerne viser derimod de forespørgsler, som serveren faktisk har modtaget.

Her kan man blandt andet undersøge:

• hvilke URL’er Googlebot har besøgt
• hvornår URL’erne blev besøgt
• hvilke statuskoder serveren returnerede
• om Googlebot rammer mange parametre eller dubletter
• om vigtige sider bliver crawlet regelmæssigt
• om redirects og fejl fylder unødvendigt meget
• om serverens svartider varierer

Det er forskellen mellem at gætte på, hvordan Google bevæger sig gennem websitet, og at undersøge de spor, som besøgene efterlader.

Man skal dog være opmærksom på, at en user-agent kan forfalskes. En crawler kan kalde sig Googlebot uden at komme fra Google. Ved en seriøs loganalyse bør trafikken derfor verificeres gennem Googles offentliggjorte IP-områder eller ved korrekt DNS-kontrol.

Typiske tegn på et crawlproblem

Et enkelt udsving i Search Console er ikke nødvendigvis udtryk for et problem. Crawling varierer naturligt over tid.

Der kan dog være grund til en nærmere undersøgelse, hvis:

• nye vigtige sider bliver opdaget meget langsomt
• opdateringer først ses af Google efter lang tid
• Googlebot bruger mange forespørgsler på URL-parametre
• store dele af aktiviteten ender i redirects eller fejl
• serverens svartid stiger markant
• Googlebot gentagne gange crawler værdiløse søge- og filtersider
• XML-sitemappet indeholder mange URL’er, som ikke bør indekseres
• websitet har et langt større URL-univers end det reelle antal sider

Først når problemet er dokumenteret, giver det mening at vælge en løsning.

Sådan arbejder jeg med crawl budget

Jeg begynder ikke med at forsøge at få Googlebot til at besøge websitet oftere.

Jeg begynder med at undersøge, hvad Google allerede bruger tiden på.

Det sker typisk ved at sammenholde:

• websitets tekniske crawl
• indekseringsoplysninger fra Google Search Console
• crawlstatistik fra Search Console
• XML-sitemaps
• robots.txt og robots-direktiver
• canonical-tags
• interne links
• serverens logfiler, når de er tilgængelige

Herefter kan URL’erne opdeles efter formål.

Hvilke sider skal kunne findes i Google? Hvilke er nødvendige for brugeren, men ikke for søgeresultaterne? Hvilke er dubletter? Og hvilke adresser burde slet ikke blive produceret?

Den opdeling er vigtigere end et tilfældigt mål om flere crawls.

Sådan forbedres brugen af crawl budgettet

Der findes ikke én knap, der løser alle crawlproblemer. Den rigtige løsning afhænger af, hvorfor Googlebot bruger ressourcerne forkert.

Arbejdet kan blandt andet bestå i at:

• reducere unødvendige URL-parametre
• begrænse værdiløse filterkombinationer
• samle dubletter på tydelige canonical URL’er
• fjerne unødvendige redirect-kæder
• opdatere interne links til de endelige URL’er
• rydde fejl og forældede adresser ud af XML-sitemap
• forbedre serverens stabilitet og svartid
• sikre, at vigtige sider har crawlbare interne links
• stoppe teknisk produktion af endeløse URL-varianter
• anvende korrekte HTTP-statuskoder

På nogle websites er det en forholdsvis enkel oprydning. På andre kræver det ændringer i CMS, webshop, database eller den måde, filtre og parametre bliver håndteret på.

Man kan ikke optimere crawl budget uden at forstå årsagen

Crawl budget bliver let gjort til en disciplin, hvor løsningen altid er at blokere flere sider i robots.txt.

Det er efter min opfattelse for enkelt.

Hvis Googlebot crawler millioner af unødvendige URL’er, er det nødvendigt at finde ud af, hvor adresserne kommer fra. Bliver de oprettet af interne links, filtre, scripts, kalenderfunktioner, søgninger eller forkert håndtering af parametre?

En blokering kan skjule en del af problemet for crawleren, men den ændrer ikke nødvendigvis den tekniske årsag.

Den holdbare løsning er at forstå websitets arkitektur og få kontrol over de URL’er, systemet producerer.

Crawl budget handler om prioritering

Det vigtigste ved crawl budget er ikke at opnå det højest mulige antal besøg fra Googlebot.

Det vigtigste er at gøre det tydeligt, hvilke sider der betyder noget.

Et website med en overskuelig struktur, konsekvente interne links, korrekte statuskoder og styr på dubletter gør opgaven lettere for både søgemaskiner og brugere.

På mindre websites vil crawl budget normalt ikke være det første sted, jeg leder efter en SEO-fejl.

På store og teknisk komplekse websites kan analysen derimod afsløre, at Google bruger en væsentlig del af sine ressourcer på de forkerte adresser.

Og så handler løsningen ikke om at bede Google om mere tid.

Det handler om at sørge for, at tiden bliver brugt rigtigt.

Få undersøgt, hvordan Google crawler dit website

Har du et større website, en webshop eller en teknisk løsning med mange URL’er, kan en gennemgang vise, om Googlebot bruger sine ressourcer på de rigtige sider.

Hos Online Marketing arbejder jeg med teknisk SEO, websitearkitektur, indeksering og analyse af de spor, som søgemaskinernes crawlere efterlader.

Kontakt Online Marketing