Googlebot læser kun de første 2 MB af en HTML-fil. Grænsen gælder den ukomprimerede kode, så det hjælper ikke, at serveren sender siden komprimeret over nettet. Står din produkttekst, dine interne links eller dit strukturerede data efter de 2 MB, kommer det simpelthen ikke med, når Google vurderer siden. For en almindelig artikel er det rigeligt, men en kategoriside med 300 produkter, inline-CSS og en sidebygger, der skriver al sin data direkte ind i koden, når grænsen hurtigere, end de fleste regner med. Problemet er let at overse, for siden ser helt normal ud i browseren. Typisk viser det sig først, når produkterne nederst på listen aldrig dukker op i søgeresultaterne, mens dem øverst gør.
Teknisk SEO er den del af søgemaskineoptimeringen, der sørger for, at Google kan hente, forstå og indeksere dine sider. Hvor on page seo handler om, hvad der står på siden, handler teknisk SEO om, hvordan siden bliver leveret: serverens svar, kodens størrelse, hastigheden og de signaler, der fortæller Google, hvilken version af en side der er den rigtige. Fejl her rammer typisk hundredvis af sider på én gang. Derfor koster de mere end en svag tekst på en enkelt underside.
Heldigvis har Google selv sat tal på de vigtigste grænser. Med dem i hånden skelner du de fejl, der koster placeringer, fra tjeklistepunkter uden betydning.
Kan Google overhovedet hente dine sider?
Alt starter med crawling. Får Googlebot en fejl, en blokering eller en omvej, når den beder om en side, hjælper hverken hastighed eller gode tekster. Åbn rapporten om sideindeksering i Search Console og se, hvilke sider Google har valgt fra og hvorfor.
Tre fejl går ofte igen:
- Blokeret mappe: en linje i robots.txt lukker en hel sektion, fx /produkter/, ude.
- Glemt noindex: testserverens noindex-tag er fulgt med ved lanceringen.
- Forkert canonical: tagget peger på en anden side end den, du vil have vist i søgeresultatet.
Blokering og noindex spiller sammen på en måde, mange overser. En side, der er blokeret i robots.txt, kan Google ikke læse, og derfor ser Google heller ikke det noindex-tag, du har sat på den. Vil du have en side ud af indekset, skal den altså kunne crawles, ellers bliver den måske liggende i søgeresultaterne med en tom beskrivelse. Statuskoderne kræver samme disciplin: slettede sider skal svare 404 eller 410, flyttede sider skal have én 301 direkte til målet, og en tom side, der svarer 200, er en såkaldt soft 404, som Google bruger tid på uden at få noget ud af det.
Hvornår er en side hurtig nok?
Google måler oplevelsen af hastighed med tre Core Web Vitals. Målingen foregår ved 75. percentil af alle sidevisninger, opdelt på mobil og computer. Det betyder i praksis, at mindst tre ud af fire besøg skal ligge under grænsen, før siden tæller som god. Et hurtigt resultat på din egen computer siger derfor meget lidt, hvis en stor del af dine besøgende sidder på en ældre telefon på 4G.
| Måling | Hvad den måler | God værdi |
|---|---|---|
| LCP (Largest Contentful Paint) | Hvornår sidens største element er vist | 2,5 sekunder eller mindre |
| INP (Interaction to Next Paint) | Hvor hurtigt siden reagerer på klik og tryk | 200 millisekunder eller mindre |
| CLS (Cumulative Layout Shift) | Hvor meget layoutet hopper under indlæsningen | 0,1 eller mindre |
Årsagerne er sjældent mystiske. Et stort topbillede uden angivet størrelse trækker LCP op og får layoutet til at hoppe, når det endelig lander. Chatbobler, trackingscripts og cookiebannere fra tredjeparter er de typiske syndere, når INP er dårlig, fordi de optager browseren, i det øjeblik brugeren trykker. Mobilmålingen er næsten altid den svageste, og derfor overlapper mobil seo og teknisk SEO i praksis næsten helt: retter du de tunge elementer på mobilen, følger computeren som regel med.
Hvor meget fylder din kode?
Tilbage til de 2 MB. Grænsen gælder hver fil for sig, og PDF-filer har et loft på 64 MB.
Problemet opstår, når alt bliver skrevet direkte ind i selve HTML-filen i stedet for at ligge i egne filer. Billeder kodet som base64, store SVG-ikoner indsat i koden og sidebyggere, der lægger hele sidens data som JSON i bunden, får en side med et par hundrede ord til at fylde flere megabyte ukomprimeret. Nogle visuelle sidebyggere gør netop det som standard, fordi det gør siden lettere at redigere. For Googlebot betyder det, at den skal igennem en stor mængde kode, før den når frem til den tekst, siden faktisk skal ranke på, og jo længere ned i koden indholdet står, jo tættere kommer det på grænsen.
Tjek det i browserens udviklerværktøjer. Netværksfanen viser både den overførte størrelse og den reelle størrelse af dokumentet, og det er den reelle størrelse, der tæller. Ligger dine vigtigste sider over 1 MB, er det værd at flytte scripts og styles ud i egne filer, så indholdet står tidligt i koden. Sider med lange produktlister kan også deles op med paginering, så hver side holder sig godt under grænsen.
Skal du bekymre dig om crawl budget?
Crawl budget er et af de mest overvurderede emner i dansk teknisk SEO. Googles egen vejledning er skrevet til sites med over 1 million unikke sider, der ændres cirka ugentligt, eller sites med over 10.000 unikke sider, der ændres dagligt. Google understreger selv, at tallene er et groft skøn og ikke eksakte grænser. Et typisk dansk firmasite med 50-500 sider ligger langt under, og her er crawl budget ikke grunden til, at en side ikke ranker.
Undtagelsen er webshops med filtre. Hver kombination af farve, størrelse og sortering bliver en ny URL, og så vokser 2.000 produkter hurtigt til titusindvis af adresser, som Googlebot skal igennem. Ser du mange sider med status “Fundet, ikke indekseret” i Search Console, er det tegnet på, at Google ikke når rundt. Løsningen er at lukke filter-URL’erne med canonical, noindex eller robots.txt, så crawlingen bruges på de sider, der skal sælge.
Hvad gør en hacket side ved din tekniske SEO?
Et af de sværeste problemer at opdage er indhold, du ikke selv har lagt der. Hackede WordPress-sites får tit indsat skjulte tekstblokke, der er placeret tusindvis af pixels uden for skærmen, med links til casinoer eller medicin. Den besøgende ser intet, men Googlebot læser det hele, og skjult tekst og skjulte links er direkte i strid med Googles spampolitik. Placeringerne falder bredt, og det ligner en algoritmeopdatering, indtil nogen kigger i kildekoden.
Rens først, optimer bagefter.
Søg i din egen kildekode efter ord som casino og efter stilarter med store negative koordinater, og tjek rapporten om sikkerhedsproblemer i Search Console. Spam-sider, som hackeren har oprettet, skal svare 404 eller 410, ikke sendes videre til forsiden med en redirect, for så arver forsiden problemet. Tøm også cachen bagefter, da et cache-plugin ellers bliver ved med at servere den inficerede version i dagevis.
Prioritér efter, hvor mange sider en fejl rammer. En forkert robots.txt, en sidebygger, der sprænger 2 MB-grænsen, eller skjult spam på alle sider slår igennem på hele sitet og skal rettes først. Langsomme billeder og enkelte døde links kommer bagefter, og crawl budget lader de fleste roligt ligge, indtil sitet passerer 10.000 sider.