Sidestørrelsestjek: Tjek Googles crawlgrænse på 2 MB

Et sidestørrelsestjek besvarer et præcist spørgsmål: Læser Google hele din side? Google oplyser, at Googlebot ved crawling til Søgning crawler de første 2 MB af en understøttet filtype og de første 64 MB af en PDF, stopper hentningen ved grænsen og sender kun den del, der allerede er downloadet, til indeksering (Google Search Central, Googlebot). Alt efter det punkt, uanset om det er en produktbeskrivelse, en FAQ, links i sidefoden eller en JSON-LD-blok, findes simpelthen ikke for Google Søgning.

Hvad gælder grænsen på 2 MB præcist for?

Den gælder for hver fil, Googlebot henter, én ad gangen, og den måles på ukomprimerede data. Gzip eller Brotli gør overførslen mindre, men ændrer ikke tallet. HTML-dokumentet har sit eget budget på 2 MB, og hver CSS- eller JavaScript-fil, der henvises til i det, hentes separat med den samme grænse.

Derfor misforstås 2 MB-tallet ofte. I 2025 vejede den typiske mobile forside 2,6 MB i alt, men kun 22 KB af det var HTML; billeder og JavaScript udgjorde det meste af resten (HTTP Archive Web Almanac 2025, page weight). En tung side er ikke et problem for denne grænse. En tung HTML-fil er det.

Værdien på 2 MB gælder særligt for Google Søgning. Googles generelle dokumentation siger, at deres crawlere og hentere læser de første 15 MB af en fil som standard, og at enkelte produkter kan sætte en lavere grænse (Google, oversigt over crawlere og hentere). Ældre artikler, der nævner 15 MB for Googlebot, beskriver den standard, ikke Søgningens crawler.

Hvordan bruger du sidestørrelsestjekket?

Indsæt den fulde URL på en offentlig side, gennemfør anti-bot-tjekket og kør analysen. Værktøjet henter siden, som en crawler gør, følger omdirigeringer og måler HTML'en, som serveren sender den, før noget JavaScript kører.

1. Læs måleren. Den viser den ukomprimerede HTML-størrelse, Googlebots grænse (2 MB, eller 2.097.152 bytes) og den procentdel, du bruger, med den resterende plads.
2. Tjek de fire kort: rå HTML-størrelse, vægt af inline JS og CSS med deres andel af HTML, antal HTML-tags og HTTP-status.
3. Åbn HTML-opdelingen: inline scripts, inline stilarter, eksterne scripts, eksterne typografiark, billeder og kommentarer, hver med antal, størrelse og andel.
4. Kig på serverdetaljerne: titel, metabeskrivelse, endelig URL efter omdirigeringer, anvendt komprimering og servertype.
5. Følg anbefalingerne, som kun vises, når en grænseværdi overskrides.

Den gratis version tillader tre analyser pr. dag. Test dine tungeste skabeloner først: en kategoriside med hundredvis af produkter eller en lang artikel med indlejrede widgets siger mere end din forside.

Hvordan læser du resultatet?

Statussen afhænger kun af den andel af grænsen på 2 MB, som den ukomprimerede HTML bruger.

Anbefalingerne bruger faste grænseværdier: inline scripts over 50 KB, inline stilarter over 30 KB og kommentarer over 5 KB markeres, ligesom en server, der sender HTML uden komprimering. Komprimering reducerer ikke den størrelse, Google tæller, men den forkorter overførselstiden for både crawlere og besøgende.

Hvad gør en HTML-side for tung?

Sider når sjældent 2 MB på grund af tekst. En artikel på 3.000 ord fylder cirka 20 KB. Vægten kommer fra det, skabeloner og frameworks indsætter i dokumentet:

• Serialiseret framework-state. Server-renderede JavaScript-apps indlejrer ofte hele sidens data som et JSON-objekt i et script-tag, nogle gange med hvert produkt eller hver artikel gentaget på siden.
• Inline SVG-ikoner, der gentages i hvert kort på en liste, og base64-billeder indsat direkte i HTML'en.
• Inline CSS fra sidebyggere, der skriver stilene for hver blok ind i dokumentet.
• Lange lister: kategorisider, tagarkiver eller interne søgesider, der udskriver hundredvis af varer med alle deres varianter.
• Overdimensioneret struktureret data, for eksempel en Product-blok, der lister hver variant med fulde beskrivelser.
• Kommentarer og fejlsøgningsmarkup, der er efterladt i produktion.

Opdelingen i værktøjet viser, hvilken af disse der dominerer. Hvis inline scripts fylder 70% af HTML'en, så start der; hvis antallet af tags er i titusindvis, er problemet skabelonen eller listens størrelse.

Hvordan reducerer du HTML-størrelsen uden at miste indhold?

Arbejd fra den største blok og ned, og hold det, Google har brug for, højt oppe i dokumentet.

1. Flyt inline JavaScript og CSS over i eksterne filer. De får deres eget budget på 2 MB, og browsere kan cache dem.
2. Beskær det serialiserede state: send kun de felter, siden har brug for, ikke hele API-svaret.
3. Erstat gentagen inline SVG med en ekstern sprite eller billedfiler, og base64-billeder med almindelige billed-URL'er. billedkomprimeringsværktøjet holder disse filer lette.
4. Del lange lister op på sider eller indlæs flere varer ved behov, mens hver sideinddelt URL stadig kan crawles via links.
5. Placer vigtigt indhold tidligt: hovedteksten, interne links og struktureret data bør ikke ligge efter megabytes af scripts. skemageneratoren producerer kompakt JSON-LD.
6. Minificér HTML'en og fjern kommentarer i produktion.

Kør tjekket igen efter hver ændring, og bekræft det i Search Console. Værktøjet URL-inspektion viser den HTML, Google faktisk hentede, under „Vis gennemsøgt side” (Search Console Hjælp, værktøjet URL-inspektion), så du kan kontrollere, at slutningen af din side er med.

Hvad er begrænsningerne ved dette tjek?

Værktøjet måler én URL, én gang, som den serveres til en crawler. Husk tre punkter.

• Ingen JavaScript-rendering. Værktøjet måler den HTML, serveren returnerer. Indhold, der tilføjes senere af JavaScript, tælles ikke med her, og Google indekserer kun den del af HTML'en, den hentede inden for grænsen.
• Ét brugeragent. Hvis din server sender forskellig HTML til Googlebot, til mobile enheder eller til indloggede brugere, kan størrelsen variere.
• Én side ad gangen. Et skabelonproblem rammer alle sider bygget på den, så test én URL pr. skabelon, og revider derefter hele siden med on-page SEO-revisionen.

Betyder sidestørrelsen også noget for AI-crawlere?

Ja, og ofte mere. Web Almanac nævner, at det vigtigste indhold skal være til stede i den første rå HTML, fordi AI-crawlere ikke renderer JavaScript. En slank HTML-fil med hovedindholdet højt oppe betjener både Google og AI-assistenter. AI-crawlbarhedsrevisionen tjekker, om AI-bots kan tilgå og læse dine sider, og crawlbudget forklarer, hvorfor lettere sider også bliver crawlet mere effektivt.

For at følge med over tid viser GEO- og SEO-dashboardet de sider, hvis klik fra Google falder, ofte det første tegn på et indekseringsproblem, og SEO Chat kan revidere en side og forklare rettelsen med enkle ord.

Hold hver HTML-fil klart under 2 MB, med det vigtige indhold først. Tjek dine tungeste skabeloner ovenfor, og se derefter Sorank-abonnementerne for at overvåge din synlighed i Google og AI på autopilot.