Crawling, indeksering & bot-kontroll

En side som ikke er indeksert, finnes ikke i search. Den kan være velskrevet, den kan ha lenker, og den kan ligge i menyen. Er den ikke tatt opp i indeksen, kan den ikke rangere på et eneste keyword. Derfor er dette det første vi ser på i et teknisk SEO-arbeid, og det er også der vi oftest finner tapt synlighet som er raskt å hente tilbake.

Tre trinn, ikke ett

Det som ofte omtales som "å bli funnet av Google", er egentlig tre atskilte prosesser.

Crawling er oppdagelsen. Googlebot og de andre robotene følger lenker, leser sitemapet deres og henter sider ned. Indeksering er vurderingen: innholdet blir analysert, forstått og lagt inn i indeksen, eller lagt til side. Servering er det siste trinnet, der indeksen brukes til å sette sammen et søkeresultat for et konkret søk.

Feilene oppstår sjelden i det siste trinnet. De oppstår i de to første, og de har hver sin kur. En side som ikke blir crawlet, har et tilgangsproblem. En side som blir crawlet, men ikke indeksert, har et kvalitets- eller duplikatproblem. Å behandle de to likt er den vanligste bortkastede innsatsen vi ser.

Google crawler mindre enn før

Crawl er ikke en ubegrenset ressurs. Google har selv beskrevet at de vil redusere mengden refresh-crawl, altså de gjentatte besøkene på sider som sjelden endrer seg, av hensyn til energibruk. Personvernerklæringen og "om oss"-siden deres blir ikke hentet ned like ofte som en nyhetsside.

Samtidig håndterer Googlebot tempoet selv. Verktøyet for å begrense crawl-raten manuelt ble fjernet fra Search Console i januar 2024, fordi Googlebot nå oppdager når en server går tom for kapasitet og justerer seg ned automatisk.

Konsekvensen for dere er praktisk: crawl-budsjettet skal brukes på sidene som skal rangere. Går det til filtre, sorteringsparametre, søkeresultatsider og tusenvis av varianter av samme kategori, er det de sidene som spiser oppmerksomheten. Rydding i den typen URL-er er ofte det enkleste tekniske grepet på et større nettsted, og det henger tett sammen med taksonomi og nettstedarkitektur.

Siden må være verdt å indeksere

Statusen "Oppdaget, men foreløpig ikke indeksert" i Search Console frustrerer de fleste som har sett den. Forklaringen fra Google er direkte: de indekserer ikke alt, og de er bevisst kritiske til hva de tar inn.

John Mueller har formulert det slik at når de ikke har en forståelse av URL-en, må de vurdere resten av nettstedet for å forstå konteksten, og spørsmålet blir om dette er noe internett har ventet på, eller bare én ny variant av det samme. Han har også vært klar på at statusen kan vare svært lenge, særlig på nyere nettsteder med mye innhold.

Det er ikke en straff. Det er en prioritering, og dere kan påvirke den. Sider som er lenket til internt fra relevante steder, som ligger i sitemapet, som har et innhold ingen andre sider hos dere dekker, og som ikke er en tynn variant av noe annet, blir tatt inn. Er indekseringsproblemene omfattende, er rådet fra Google faktisk å stoppe publiseringen av nytt innhold en periode og heve kvaliteten på det som finnes.

Slik styrer dere botene

Fire mekanismer gjør jobben, og de brukes til ulike ting.

Sitemap.xml er listen over URL-ene dere vil at søkemotorene skal kjenne. Den skal ligge i roten, den skal være med i robots.txt, og den skal sendes inn i Search Console. Én fil kan inneholde 50 000 URL-er og være maksimalt 50 MB, så større nettsteder deler den opp. De fleste moderne CMS-er genererer den dynamisk, og det er den løsningen dere skal ha: et statisk sitemap er et øyeblikksbilde som blir feil den dagen dere publiserer noe nytt.

Robots.txt styrer hva botene får hente. Den er et tilgangsdokument, ikke et indekseringsdokument, og det er en forskjell som velter mange oppsett. Blokkerer dere en side i robots.txt, kan Google fortsatt indeksere URL-en hvis andre lenker til den, men de får aldri sett innholdet eller noindex-taggen deres.

Noindex er det riktige verktøyet når en side ikke skal ligge i indeksen. Den må være tilgjengelig for å virke, altså ikke blokkert i robots.txt.

Canonical-tagger peker duplikater mot den versjonen som skal rangere. Sammen med redirects er de kjernen i det løpende vedlikeholdet, som vi går grundig gjennom i site health, redirects og canonicalization.

Én tag færre kjenner, er indexifembedded. Den lar dere holde en medieside uindeksert samtidig som innholdet fra den kan indekseres der det er bygget inn via iframe på en annen side. Nyttig for podkast- og videospillere.

Sjekk statusen selv

To metoder tar fem minutter til sammen.

I Google Search Console gir URL-inspeksjonen svaret for en enkelt side: er den indeksert, når ble den sist crawlet, og hvilken canonical valgte Google. Sider-rapporten gir samme bilde for hele nettstedet, gruppert etter årsak, og det er den listen dere jobber ned.

Kommandoen site:domene.no i søkefeltet gir en rask indikasjon på hva som er tatt inn, og den fungerer også i Bing. Tallet er omtrentlig, men mønsteret er nyttig: ser dere hundrevis av parametervarianter og gamle testsider, vet dere hvor crawl-budsjettet forsvinner.

Fremskynd en re-indeksering

Det finnes ingen knapp for å be om full re-indeksering av et nettsted. Google gjør en dypere gjennomgang når nettstedet har vært gjennom en større endring, og oppdaterer seg ellers over tid. Vil dere skyve på prosessen, er det fire grep som faktisk hjelper:

• Bruk 301 når en URL flyttes permanent, slik at søkemotoren vet hvor siden ble av.
• Bruk 404 når en side er borte for godt, framfor å la den svare 200 med et tomt skall.
• Styrk de interne lenkene til sidene som skal prioriteres. Det er det tydeligste signalet dere selv kontrollerer, og metoden står i intern lenkebygging.
• Oppdater reell informasjon på hovedsidene, som adresse, kontaktopplysninger og priser.

Er innholdet skrevet fullstendig om, tar det lengre tid. Google må vurdere kvaliteten på nytt før siden kan rangere på nytt.

Bot-kontroll i 2026

Det nye laget er at Googlebot ikke lenger er den eneste roboten som betyr noe. GPTBot og OAI-SearchBot henter for OpenAI, ClaudeBot for Anthropic, PerplexityBot for Perplexity, og Google-Extended styrer om innholdet deres kan brukes til Gemini og AI-svarene. Alle respekterer robots.txt, og alle kan blokkeres separat.

Det er et reelt valg, ikke en teknikalitet. Blokkerer dere dem, holder dere innholdet unna treningsdata og AI-svar. Da forsvinner dere også fra flatene der en stadig større del av kundene deres nå leter. Vi anbefaler som hovedregel å slippe dem inn og heller sørge for at innholdet er tydelig nok til å bli sitert riktig, men beslutningen hører hjemme hos dere og bør tas bevisst framfor å bli arvet fra et gammelt oppsett.

Sjekk derfor robots.txt-filen deres nå. Vi finner jevnlig blokkeringer ingen husker å ha satt inn, arvet fra et utviklingsmiljø eller et tidligere byrå.

Videre herfra

Crawling og indeksering er fundamentet i teknisk SEO, og feilene her koster mer enn nesten alt annet, fordi de gjør resten av arbeidet usynlig. Vil dere ha gjennomgangen gjort systematisk, er det kjernen i et teknisk audit. Vil dere først se hvor dere står, gir en gratis SEO-analyse dere bildet på tvers av teknikk, innhold og synlighet.