I Februar 2026 lavede Google en ændring for deres crawler, som betyder at der nu “kun” læses 2MB af HTML sider. Det lyder måske som en teknisk detalje, men det er en ændring med reel betydning for synlighed i søgning. Hvis vigtig tekst, interne links eller struktureret data ligger efter den grænse, er der en risiko for, at Google aldrig ser det.
For de fleste websites bliver det ikke et problem. For nogle bliver det meget konkret. Især større løsninger med tunge templates, page builders, store datablokke og lange sider kan blive ramt uden at opdage det med det samme.
Hvad betyder 2 MB-grænsen i praksis?
Det afgørende er, at der er tale om HTML-koden, som Google læser, ikke hvor “tung” siden føles visuelt. En side kan godt se enkel ud i browseren og stadig have oppustet HTML under overfladen. Det sker ofte, når CMS’et genererer mange wrapper-elementer, når der ligger store inline scripts i koden, eller når en løsning sender store JSON-data direkte med siden.
Hvis HTML-dokumentet overstiger 2 MB, bliver indholdet efter grænsen i praksis ikke taget med i den del, der går videre til indeksering. Det betyder ikke nødvendigvis, at hele siden forsvinder fra Google. Det betyder bare, at Google vurderer siden på baggrund af en afkortet version.
Hvilke elementer er mest udsatte?
Det meste i Head ligger typisk sikkert. Title-tag, meta description og canonical fylder ikke meget og kommer tidligt i dokumentet. Risikoen opstår ofte længere nede på siden, hvor mange teams har vænnet sig til at placere “det ekstra”.
Det gælder især struktureret data, footerlinks, lange FAQ-sektioner, ekstra tekstblokke, relaterede ressourcer og scripts, der ligger sent i koden. Hvis det først kommer efter 2 MB, hjælper det ikke meget, at det er tænkt som vigtig SEO-understøttelse.
Det ændrer også prioriteringen i arbejdet med indhold. Hvis Google kun læser den første del af HTML’en, bliver rækkefølgen pludselig central. Det, der ligger først, får større sandsynlighed for at påvirke indeksering og synlighed. Det, der ligger sent, kan i værste fald være usynligt.
Efter en indledende teknisk gennemgang giver det mening at fokusere på disse punkter:
- Korte, semantiske templates
- Eksterne CSS- og JS-filer
- Tidlig placering af vigtig tekst
- Begrænset brug af inline data
- Tydelig prioritering af interne links
Hvorfor bliver HTML så stor?
Den klassiske årsag er ikke selve indholdet, men måden det pakkes ind på. Pagebuilders og store themes kan generere overraskende meget kode for at vise relativt lidt information. Et enkelt tekstafsnit kan ende inde i mange lag af -elementer, komponentklasser og data-attributter.
Typiske kilder til oppustet HTML er ofte disse:
- Page builders: Mange wrappers, inline styling og overflødige moduler
- Store JSON-blokke: Data til apps, søgning eller filtrering direkte i HTML
- Inline CSS og JS: Praktisk på kort sigt, dyrt i HTML-størrelse
- Meget lange lister: Produkter, events, kurser, publikationer eller lokationer
- Skjult indhold: Faner, accordions eller flere sprogversioner i samme dokument
Det er værd at bemærke, at komprimering ikke løser selve problemet. Gzip og Brotli er godt for performance, men Google vurderer den ukomprimerede HTML. Derfor er det den faktiske dokumentstørrelse, der skal ned under 2MB.
