Sidestørrelsessjekk: test Googles grense for crawling på 2MB

En sjekk for sidestørrelse svarer på et presist spørsmål: vil Google lese hele siden din? Google opplyser at når Googlebot crawler for Søk, crawler den de første 2 MB av en støttet filtype og de første 64 MB av en PDF, stopper hentingen ved grensen og sender bare den delen som allerede er lastet ned til indeksering (Google Search Central, Googlebot). Alt etter det punktet, enten en produktbeskrivelse, en FAQ, lenker i bunnteksten eller en JSON-LD-blokk, finnes rett og slett ikke for Google Søk.

Hva gjelder egentlig grensen på 2 MB for?

Den gjelder for hver fil Googlebot henter, én etter én, og den måles på ukomprimerte data. Gzip eller Brotli gjør overføringen mindre, men de endrer ikke tellingen. HTML-dokumentet har sitt eget budsjett på 2 MB, og hver CSS- eller JavaScript-fil som det refererer til, hentes separat med samme grense.

Derfor blir tallet 2 MB ofte misforstått. I 2025 var en medianforside for mobil 2,6 MB totalt, men bare 22 KB av det var HTML; bilder og JavaScript utgjorde mesteparten av resten (HTTP Archive Web Almanac 2025, sidevekt). En tung side er ikke et problem for denne grensen. En tung HTML-fil er det.

Verdien 2 MB gjelder spesifikt for Google Søk. Googles generelle dokumentasjon sier at crawlerne og hentingsverktøyene leser de første 15 MB av en fil som standard, og at enkelte produkter kan sette en mindre grense (Google, oversikt over crawlere og hentingsverktøy). Eldre artikler som oppgir 15 MB for Googlebot beskriver den standarden, ikke crawleren for Søk.

Hvordan bruker du sjekken for sidestørrelse?

Lim inn hele URL-en til en offentlig side, fullfør bot-sjekken og kjør analysen. Verktøyet laster ned siden slik en crawler gjør, følger viderekoblinger og måler HTML-en slik serveren sender den, før noe JavaScript kjører.

1. Les måleren. Den viser den ukomprimerte HTML-størrelsen, grensen for Googlebot (2 MB, eller 2097152 byte) og prosentandelen du bruker, med plassen som gjenstår.
2. Sjekk de fire kortene: rå HTML-størrelse, vekt på innebygd JS og CSS med deres andel av HTML-en, antall HTML-tagger og HTTP-status.
3. Åpne HTML-fordelingen: innebygde skript, innebygde stiler, eksterne skript, eksterne stilark, bilder og kommentarer, hver med antall, størrelse og andel.
4. Se på serverdetaljene: tittel, metabeskrivelse, endelig URL etter viderekoblinger, brukt komprimering og servertype.
5. Bruk anbefalingene, som bare vises når en grense er overskredet.

Gratisversjonen tillater tre analyser per dag. Test de tyngste malene dine først: en kategoriside med hundrevis av produkter eller en lang artikkel med innbygde widgeter sier mer enn forsiden din.

Hvordan leser du resultatet?

Statusen avhenger bare av andelen av grensen på 2 MB som den ukomprimerte HTML-en bruker.

Anbefalingene bruker faste terskler: innebygde skript over 50 KB, innebygde stiler over 30 KB og kommentarer over 5 KB blir flagget, og det samme gjelder en server som sender HTML uten komprimering. Komprimering reduserer ikke størrelsen Google teller, men den kutter overføringstiden for crawlere og besøkende.

Hva gjør en HTML-side for tung?

Sider når sjelden 2 MB på grunn av tekst. En artikkel på 3000 ord er omtrent 20 KB. Vekten kommer fra det malene og rammeverkene setter inn i dokumentet:

• Serialisert rammeverkstilstand. Serverrenderte JavaScript-apper legger ofte inn alle sidedata som et JSON-objekt i en skriptkode, noen ganger med duplisering av hvert produkt eller hver artikkel på siden.
• Innebygde SVG-ikoner gjentatt i hvert kort i en liste, og base64-bilder limt inn i HTML-en.
• Innebygd CSS fra sideprogrammer som skriver stilene til hver blokk inn i dokumentet.
• Lange lister: kategorisider, taggarkiver eller interne søkesider som skriver ut hundrevis av varer med alle variantene deres.
• Overdimensjonerte strukturerte data, for eksempel en Product-blokk som lister hver variant med fulle beskrivelser.
• Kommentarer og feilsøkingsmarkup som er igjen i produksjon.

Fordelingen i verktøyet viser hvilken av disse som dominerer. Hvis innebygde skript tar 70% av HTML-en, start der; hvis antall tagger er i titusenvis, er det malen eller størrelsen på listen som er problemet.

Hvordan reduserer du HTML-størrelsen uten å miste innhold?

Jobb fra den største blokken og ned, og behold det Google trenger høyt oppe i dokumentet.

1. Flytt innebygd JavaScript og CSS til eksterne filer. De får sitt eget budsjett på 2 MB, og nettlesere kan mellomlagre dem.
2. Kutt den serialiserte tilstanden: send bare feltene siden trenger, ikke hele API-svaret.
3. Erstatt gjentatt innebygd SVG med en ekstern sprite eller bildefiler, og base64-bilder med vanlige bilde-URL-er. Bildekomprimereren holder disse filene lette.
4. Del opp lange lister i sider, eller last flere varer på forespørsel, og sørg for at hver paginert URL fortsatt kan crawles via lenker.
5. Plasser kritisk innhold tidlig: hovedtekst, interne lenker og strukturerte data bør ikke ligge etter megabyte med skript. Schema-generatoren lager kompakt JSON-LD.
6. Minifiser HTML-en og fjern kommentarer i produksjon.

Etter hver endring, kjør sjekken på nytt og bekreft i Search Console. Verktøyet for URL-inspeksjon viser HTML-en Google faktisk hentet via «Vis gjennomsøkt side» (Search Console Hjelp, verktøyet for URL-inspeksjon), som lar deg kontrollere at slutten av siden din er med.

Hva er begrensningene for denne sjekken?

Verktøyet måler én URL, én gang, slik den serveres til en crawler. Husk tre punkter.

• Ingen JavaScript-rendering. Verktøyet måler HTML-en serveren returnerer. Innhold som legges til senere med JavaScript, telles ikke her, og Google indekserer bare den delen av HTML-en den hentet innenfor grensen.
• Én brukeragent. Hvis serveren din sender ulik HTML til Googlebot, til mobilenheter eller til innloggede brukere, kan størrelsen variere.
• Én side om gangen. Et malproblem rammer hver side bygget på malen, så test én URL per mal, og revider deretter hele nettstedet med revisjonen av SEO på siden.

Betyr sidestørrelse også noe for AI-crawlere?

Ja, og ofte mer. Web Almanac påpeker at nøkkelinformasjon bør være til stede i den første rå HTML-en, fordi AI-crawlere ikke rendrer JavaScript. En slank HTML-fil med hovedinnholdet høyt oppe tjener både Google og AI-assistenter. Revisjonen av AI-crawlbarhet sjekker om AI-roboter kan få tilgang til og lese sidene dine, og crawl-budsjett forklarer hvorfor lettere sider også blir crawlet mer effektivt.

For å følge med over tid viser GEO- og SEO-dashbordet sidene der klikkene fra Google synker, ofte det første tegnet på et indekseringsproblem, og SEO Chat kan revidere en side og forklare løsningen med enkle ord.

Hold hver HTML-fil godt under 2 MB, med det viktige innholdet først. Sjekk de tyngste malene dine ovenfor, og se deretter Sorank-abonnementene for å overvåke synligheten din i Google og AI på autopilot.