Kontroll av sidstorlek: kontrollera Googles genomsökningsgräns på 2MB

En kontroll av sidstorlek besvarar en precis fråga: kommer Google att läsa hela din sida? Google anger att Googlebot vid genomsökning för Google Sök läser de första 2 MB av en filtyp som stöds och de första 64 MB av en PDF, avbryter hämtningen vid gränsen och skickar bara den del som redan laddats ner för indexering (Google Search Central, Googlebot). Allt efter den punkten, vare sig en produktbeskrivning, en FAQ, länkar i sidfoten eller ett JSON-LD-block, finns helt enkelt inte för Google Sök.

Vad gäller gränsen på 2 MB egentligen för?

Den gäller för varje fil som Googlebot hämtar, en i taget, och den mäts på okomprimerad data. Gzip eller Brotli minskar överföringen, men de ändrar inte räkningen. HTML-dokumentet har sin egen budget på 2 MB, och varje CSS- eller JavaScript-fil som refereras i det hämtas separat med samma gräns.

Det är därför siffran 2 MB ofta missförstås. År 2025 vägde den typiska mobila startsidan 2,6 MB totalt, men bara 22 KB av det var HTML; bilder och JavaScript utgjorde största delen av resten (HTTP Archive Web Almanac 2025, sidvikt). En tung sida är inget problem för den här gränsen. En tung HTML-fil är det.

Värdet 2 MB gäller specifikt för Google Sök. Googles allmänna dokumentation säger att dess sökrobotar och hämtare läser de första 15 MB av en fil som standard, och att enskilda produkter kan ha en lägre gräns (Google, översikt över sökrobotar och hämtare). Äldre artiklar som anger 15 MB för Googlebot beskriver den standarden, inte sökrobotens gräns för Google Sök.

Hur använder du kontrollen av sidstorlek?

Klistra in hela URL:en för en offentlig sida, slutför kontrollen mot bottrafik och kör analysen. Verktyget hämtar sidan på det sätt en sökrobot gör, följer omdirigeringar och mäter HTML:en så som servern skickar den, innan något JavaScript körs.

1. Läs mätaren. Den visar HTML-storleken okomprimerad, gränsen för Googlebot (2 MB, eller 2 097 152 byte) och andelen du använder, med utrymmet som återstår.
2. Kontrollera de fyra korten: rå HTML-storlek, vikt för inline-JS och CSS med deras andel av HTML:en, antal HTML-taggar och HTTP-status.
3. Öppna HTML-fördelningen: inline-skript, inline-stilar, externa skript, externa formatmallar, bilder och kommentarer, var och en med antal, storlek och andel.
4. Titta på serverdetaljerna: titel, metabeskrivning, slutlig URL efter omdirigeringar, använd komprimering och servertyp.
5. Tillämpa rekommendationerna, som bara visas när en gräns passeras.

Den kostnadsfria versionen tillåter tre analyser per dag. Testa dina tyngsta mallar först: en kategorisida med hundratals produkter eller en lång artikel med inbäddade widgetar säger mer än din startsida.

Hur läser du resultatet?

Statusen beror bara på andelen av gränsen på 2 MB som den okomprimerade HTML:en använder.

Rekommendationerna använder fasta gränsvärden: inline-skript över 50 KB, inline-stilar över 30 KB och kommentarer över 5 KB flaggas, liksom en server som skickar HTML utan komprimering. Komprimering minskar inte storleken som Google räknar, men den minskar överföringstiden för både sökrobotar och besökare.

Vad gör en HTML-sida för tung?

Sidor når sällan 2 MB på grund av texten. En artikel på 3,000 ord är cirka 20 KB. Vikten kommer från det mallar och ramverk lägger in i dokumentet:

• Serialiserat ramverkstillstånd. Serverrenderade JavaScript-appar bäddar ofta in hela sidans data som ett JSON-objekt i ett skriptblock, ibland med en dubblering av varje produkt eller artikel på sidan.
• Inline-SVG-ikoner som upprepas i varje kort i en lista, och bilder i base64 inklistrade i HTML:en.
• Inline-CSS från sidbyggare som skriver ut stilen för varje block i dokumentet.
• Långa listor: kategisidor, taggarkiv eller interna sökresultatsidor som skriver ut hundratals objekt med alla deras varianter.
• Överdimensionerad strukturerad data, till exempel ett produktblock som listar varje variant med fullständiga beskrivningar.
• Kommentarer och felsökningsmärkning som ligger kvar i produktion.

Fördelningen i verktyget visar vilket av dessa som dominerar. Om inline-skript tar 70% av HTML:en, börja där; om antalet taggar ligger i tiotusentals är det mallen eller listans storlek som är problemet.

Hur minskar du HTML-storleken utan att förlora innehåll?

Arbeta från det största blocket och nedåt, och håll det Google behöver nära början av dokumentet.

1. Flytta inline-JavaScript och CSS till externa filer. De får sin egen budget på 2 MB, och webbläsare kan cacha dem.
2. Minska det serialiserade tillståndet: skicka bara de fält sidan behöver, inte hela API-svaret.
3. Ersätt upprepad inline-SVG med en extern sprite eller bildfiler, och bilder i base64 med vanliga bildadresser. bildkomprimeringsverktyget håller de filerna lätta.
4. Dela upp långa listor på sidor eller ladda fler objekt vid behov, och se till att varje sidnumrerad URL går att genomsöka via länkar.
5. Placera det kritiska innehållet tidigt: huvudtext, interna länkar och strukturerad data ska inte ligga efter megabyte skript. schemageneratorn skapar kompakt JSON-LD.
6. Minifiera HTML:en och ta bort kommentarer i produktion.

Kör kontrollen igen efter varje ändring och bekräfta i Search Console. URL-inspektionsverktyget visar den HTML som Google faktiskt hämtade under ”Visa genomsökt sida” (Search Console Hjälp, URL-inspektionsverktyget), vilket låter dig kontrollera att slutet av din sida finns med.

Vilka är gränserna för den här kontrollen?

Verktyget mäter en URL, en gång, så som den serveras till en sökrobot. Tre saker bör du tänka på.

• Ingen JavaScript-rendering. Verktyget mäter den HTML servern returnerar. Innehåll som JavaScript lägger till senare räknas inte här, och Google indexerar bara den del av HTML:en som den hämtade inom gränsen.
• En användaragent. Om din server skickar olika HTML till Googlebot, till mobila enheter eller till inloggade användare kan storleken skilja sig.
• En sida i taget. Ett mallproblem påverkar varje sida som byggs på den, så testa en URL per mall och granska sedan hela webbplatsen med granskningen av SEO på sidan.

Spelar sidstorleken roll även för AI-sökrobotar?

Ja, och ofta mer. Web Almanac noterar att nyckelinformation ska finnas i den inledande råa HTML:en, eftersom AI-sökrobotar inte renderar JavaScript. En lätt HTML-fil med huvudinnehållet nära början tjänar både Google och AI-assistenter. granskningen av genomsökbarhet för AI kontrollerar om AI-robotar kan nå och läsa dina sidor, och genomsökningsbudget förklarar varför lättare sidor också genomsöks mer effektivt.

För att följa utvecklingen över tid visar instrumentpanelen för GEO och SEO de sidor vars klick från Google minskar, ofta det första tecknet på ett indexeringsproblem, och SEO Chat kan granska en sida och förklara åtgärden med enkla ord.

Håll varje HTML-fil långt under 2 MB, med det viktiga innehållet först. Kontrollera dina tyngsta mallar ovan, se sedan Sorank:s abonnemang för att övervaka din synlighet i Google och AI på autopilot.