SEO-udvikling

SEO-udvikling: det tekniske arbejde bag gode placeringer

Indhold rangerer kun, hvis Google kan hente, forstå og indlæse det hurtigt. Her er de områder, en udvikler skal have styr på.

Udviklerskærm med HTML-markup og et performance-panel åbent ved siden af hinanden
Teknisk SEO er målbart: markup i kilden og tal i performance-panelet.

Indeksering og crawl

Robots.txt må ikke blokere det, der skal findes. Hver side skal have en selvrefererende canonical, og sitemap.xml skal kun indeholde sider, der returnerer 200 og må indekseres. Tjek også, at der ikke ligger et gammelt noindex-metatag tilbage fra udviklingsfasen — det er den hyppigste årsag til, at en relancering mister trafik.

Server-rendering af indhold

Titler, tekst og strukturerede data skal ligge i det HTML, serveren sender. Indhold, der først dukker op efter JavaScript, bliver opdaget senere og nogle gange slet ikke. Test ved at hente siden med curl eller slå JavaScript fra: kan du læse artiklen, kan Google også.

Core Web Vitals

LCP under 2,5 sekunder, stabilt layout og hurtig reaktion på input. I praksis: billeder i rigtige størrelser med width/height, lazy loading under folden, prioritering af det øverste billede og få blokerende scripts. Mål på feltdata i Search Console, ikke kun på en enkelt Lighthouse-kørsel.

Billeder og medier

Moderne formater, responsive sizes-attributter og unikke alt-tekster. Sæt altid width og height, så pladsen reserveres og layoutet ikke hopper. Det forbedrer både hastighed og synligheden i billedsøgning.

Struktureret data

Article på artikler, Organization eller LocalBusiness på virksomheden, BreadcrumbList på dybe sider og ItemList på oversigter. Markeringen skal svare til det, siden faktisk viser — ellers risikerer du at miste de udvidede resultater helt.

URL-struktur og redirects

Læsbare danske URL'er uden parametre, én URL pr. side, og 301-redirects når noget flyttes. Duplikater mellem www og apex samt http og https afklares én gang for alle på serverniveau.

Et performance-budget du kan holde

Aftal målene, inden siden bygges. Så bliver hastighed en del af leverancen i stedet for en efterfølgende oprydning:

MåltalGrænseSådan holder du den
LCPunder 2,5 sServerrenderet HTML, prioriteret hero-billede, ingen webfont der blokerer.
CLSunder 0,1width/height på alle billeder, reserveret plads til bannere og annoncer.
INPunder 200 msMindre JavaScript på forsiden, tunge widgets indlæses efter interaktion.
TTFBunder 600 msCaching, hosting i Europa og databasekald uden for render-stien.

Rækkefølgen betyder noget

Ret indeksering og canonical først, dernæst hastighed, og til sidst struktureret data. Har du ikke lagt planen for hvilke sider der skal findes, så start i SEO-strategi. Skal teksterne skrives om samtidig, følger du SEO-tekster.

Migrering uden at miste trafik

  • Lav en fuld liste over gamle URL'er, før den nye side går live.
  • Kortlæg hver gammel URL til én ny med 301 — undgå kæder af redirects.
  • Behold titler og indhold på de sider, der allerede rangerer.
  • Indsend et nyt sitemap dagen efter launch og følg dækningsrapporten i to uger.
  • Gennemgå hele forløbet i guiden til flytning af hosting.

Sådan tester du

  • Hent siden uden JavaScript og se, om indholdet er der.
  • Kør en hastighedsmåling på mobil, ikke desktop.
  • Kontrollér at sitemap.xml og canonical peger på samme URL-form.
  • Valider struktureret data, og se om typen matcher sidens indhold.
  • Følg dækningsrapporten i Search Console efter hver større ændring.

Fejl vi retter oftest

  • Canonical peger på forsiden fra alle undersider.
  • Sitemap indeholder redirects, 404'er eller sider med noindex.
  • Billeder på 2-4 MB skaleres ned i browseren i stedet for på serveren.
  • Både www og apex svarer 200 uden redirect, så alt findes i to versioner.
  • Paginering uden unikke titler, så side 2-10 konkurrerer med side 1.

Læs videre