Egen platformTjekliste
enRead in EnglishTeknisk SEO: 12 ting udvikleren skal bygge ind fra start
Teknisk SEO der skal bygges ind fra start: 12 punkter om rendering, URL'er, redirects, sitemap, structured data og Core Web Vitals, og hvordan du tjekker dem.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 8 min.
Indhold i indlægget7
Teknisk SEO er det arbejde i koden der sørger for at Google kan finde, læse og indeksere dine sider. Det meste koster næsten ingenting at bygge ind fra start, men er dyrt at eftermontere, fordi det rører ved skabeloner, adresser og serveropsætning. Her er de 12 ting jeg mener enhver udvikler skal bygge ind i en ny hjemmeside, og hvordan du selv tjekker dem.
Jeg bygger selv hjemmesider for virksomheder, så læs listen med det forbehold.
Den korte version: 12 punkter og prisen for at glemme dem
| # | Punkt | Pris at rette bagefter |
|---|---|---|
| 1 | Indholdet ligger i HTML'en fra serveren | Høj |
| 2 | Rene og stabile URL'er | Høj |
| 3 | Rigtige statuskoder | Mellem |
| 4 | Redirects styret i systemet | Mellem |
| 5 | Én adresse pr. side (canonical) | Mellem |
| 6 | Title, beskrivelse og delingsbillede pr. side | Lav |
| 7 | Automatisk XML-sitemap | Lav |
| 8 | Robots og noindex styret pr. miljø | Lav at rette, dyr at overse |
| 9 | Structured data genereret fra data | Lav |
| 10 | Hurtige billeder, skrifttyper og scripts | Mellem |
| 11 | Semantisk HTML og links Google kan følge | Høj |
| 12 | Sprogversioner med hreflang | Mellem |
Min tommelfingerregel er at punkterne med høj pris skal være besluttet, før første skabelon bliver kodet. Har du endnu ikke valgt hvordan siden skal laves, så start med valget mellem at bygge selv, bruge no-code eller få en udvikler.
Rendering, URL'er og statuskoder (punkt 1-4)
De fire punkter afgør om Google overhovedet kan læse dine sider, og især de to første er dyre at ændre bagefter.
Rendering, URL'er og statuskoder
- 1. Indholdet ligger i HTML'en fra serveren: Google kan køre JavaScript, men gør det i et separat trin, og ikke alle andre bots kan det. Google skriver selv i sin guide til JavaScript-SEO at rendering på serveren stadig er en god idé. Tjek: Vælg "Vis sidekilde" i browseren. Står overskrifter og brødtekst i koden, er det i orden.
- 2. Rene og stabile URL'er: /ydelser/hjemmesider i stedet for /side?id=42, små bogstaver og én fast regel for skråstreg til sidst. Filtre i en webshop må ikke skabe tusindvis af nye adresser. Hver adresse du ændrer senere, kræver en redirect. Tjek: Kan du gætte hvad siden handler om ud fra adressen?
- 3. Rigtige statuskoder: En side der ikke findes, skal svare med 404 (eller 410, hvis den er fjernet for altid), ikke med en pæn fejlside og status 200. Ellers kan tomme sider ende i Googles indeks som såkaldte soft 404'er. Tjek: Skriv en adresse der ikke findes, og se statuskoden under Netværk i browserens udviklerværktøjer.
- 4. Redirects styret i systemet: Systemet skal kunne lave permanente 301-redirects, helst fra administrationen, og uden kæder hvor A peger på B, som peger på C. Google anbefaler at beholde redirects i mindst et år efter en flytning. Tjek: Spørg hvor redirects oprettes, og om systemet logger adresser der giver 404.
WordPress og de fleste moderne frameworks leverer HTML fra serveren som standard, så punkt 1 går typisk galt i browser-apps og hjemmelavede løsninger. Afvejningerne står i min sammenligning af WordPress og en custom-kodet hjemmeside. Skifter du en gammel side ud, er redirects det vigtigste enkeltpunkt, og det har fået sin egen guide til relaunch uden at miste trafik.
Signaler til Google: canonical, metadata, sitemap og robots (punkt 5-8)
De næste fire punkter er billige at bygge, men skal genereres automatisk. Ellers er de forkerte efter et halvt år.
Signaler til Google
- 5. Én adresse pr. side (canonical): Den samme side kan ofte nås med og uden www, via http eller med sporingsparametre. Vælg én version, send resten videre med en 301, og sæt et canonical-tag på hver side. Tjek: Prøv dit domæne med og uden www. Begge skal ende samme sted.
- 6. Title, beskrivelse og delingsbillede pr. side: Hver side skal have sin egen title, meta-beskrivelse og delingsbillede, som du selv kan redigere, og fornuftige standarder når feltet er tomt. Tjek: Har dit CMS felter til det?
- 7. Automatisk XML-sitemap: Sitemappet skal opdatere sig selv, når du udgiver eller sletter indhold. Ifølge Googles vejledning om sitemaps ignorerer Google felterne priority og changefreq, men bruger lastmod, når datoen er korrekt. Den skal altså være den reelle ændringsdato. Tjek: Åbn /sitemap.xml, og se om dine nyeste sider står der.
- 8. Robots og noindex styret pr. miljø: Testmiljøet (staging) skal være lukket for Google med adgangskode eller noindex. Robots.txt er ikke nok, for ifølge Googles introduktion til robots.txt holder filen ikke en side ude af Google. Lukningen skal styres pr. miljø, så den aldrig følger med i produktion. Tjek: Søg efter "noindex" i kildekoden på lanceringsdagen.
Punkt 8 er efter min mening den farligste fejl på listen, fordi intet ser forkert ud: siden virker for alle besøgende, mens Google har fået besked på at holde sig væk.
Bruger du et headless CMS, skal frontenden bygge title, sitemap og canonical ud fra CMS'ets data. Afklar det, når du vælger headless CMS.
Struktur og hastighed (punkt 9-12)
De sidste fire handler om at Google forstår siden, og at den er hurtig på en telefon.
Struktur og hastighed
- 9. Structured data genereret fra data: Et lille stykke kode, typisk JSON-LD, der fortæller Google at siden er en artikel, et produkt eller en virksomhed. Det skal genereres ud fra de samme data som siden viser, så pris og adresse aldrig er forkerte. Tjek: Kør en side gennem Googles Rich Results Test.
- 10. Hurtige billeder, skrifttyper og scripts: Core Web Vitals kræver at det største element er indlæst inden for 2,5 sekunder (LCP), at siden reagerer på klik inden for 200 millisekunder (INP), og at layoutskift (CLS) højst scorer 0,1. Ifølge web.dev skal grænserne holde for 75 % af sidevisningerne. Det kræver billeder i rigtige størrelser, skrifttyper fra eget domæne og få tredjepartsscripts. Tjek: Kør siden i PageSpeed Insights, og kig på tallene fra rigtige brugere.
- 11. Semantisk HTML og links Google kan følge: Én H1 pr. side, overskrifter i logisk rækkefølge og rigtige links. Google finder kun links der er almindelige HTML-links med en href (det står i guiden fra punkt 1), så menuer der navigerer via JavaScript-klik, kan være usynlige. Tjek: Kan du komme rundt på hele siden med tabulatortasten? Så er links og knapper som regel bygget rigtigt.
- 12. Sprogversioner med hreflang: Har siden flere sprog, skal hver version have sin egen adresse, fx /en/, og henvise til de andre med hreflang-tags. Send ikke besøgende automatisk videre ud fra browserens sprog, for så risikerer Google kun at se én version. Tjek: Har hver sprogversion sin egen URL, og henviser de til hinanden?
Punkt 10 glider lettest efter lancering, når chat-widget, tag manager og cookiebanner kommer til. Det er sjældent frameworkets skyld. Hvordan jeg har grebet det an på min egen side, kan du se i casen om hvordan simonij.com er bygget.
Hvad teknisk SEO ikke løser
Teknisk SEO fjerner forhindringer, men skaber ikke efterspørgsel. En teknisk perfekt side uden indhold nogen søger efter, får stadig ingen trafik. Har du en lille side på Squarespace, Wix eller Webflow, klarer platformen det meste af listen: sitemap, HTTPS, statuskoder og felter til metadata. Så skal du ikke betale en udvikler for teknisk SEO. Brug hellere pengene på gode tekster.
Listen betyder mest ved en side bygget til formålet, en relaunch af en side med trafik eller en side med mange undersider, fx en webshop. Her rammer én fejl i en skabelon hundredvis af sider på én gang.
Til selve lanceringen har jeg samlet 40 ting du skal tjekke, før en ny hjemmeside går live.
Næste skridt
- Skriv de 12 punkter ind i din kravspecifikation, så de er med i prisen og ikke kommer som ekstraregning.
- Spørg din udvikler hvordan hvert punkt bliver løst: hvilken pakke, hvilken indstilling, hvor i administrationen.
- Tjek selv punkt 1, 3, 5 og 8 på testmiljøet og igen på lanceringsdagen.
- Tilføj siden i Google Search Console den dag den går live.
Skal du have bygget en ny hjemmeside, kan du se hvordan jeg arbejder med hjemmesider kodet til formålet. Du taler direkte med den udvikler der skriver koden, og du ejer koden fra første dag.
Ofte stillede spørgsmål
Hvad er forskellen på teknisk SEO og almindelig SEO?
Teknisk SEO handler om koden og serveren: om Google kan crawle, læse og indeksere dine sider. Den øvrige SEO handler om hvad der står på siderne, og om andre sider linker til dig. Teknisk SEO er typisk udviklerens ansvar, mens indhold og links ligger hos dig eller dit marketingbureau.
Kan man rette teknisk SEO på en eksisterende hjemmeside?
Ja, de fleste punkter kan rettes bagefter. Metadata, sitemap, structured data og redirects er som regel overkommelige. Rendering og URL-struktur er sværere, fordi de kan kræve at store dele af siden bygges om. Start med rapporterne i Search Console, så du ved hvilke fejl der faktisk koster trafik.
Hvor lang tid går der, før Google opdager tekniske rettelser?
Det varierer fra få dage til flere uger, afhængigt af hvor ofte Google besøger siden. Du kan bede om indeksering af enkelte adresser via URL-inspektion i Search Console. Større ændringer, som et skift af domæne, kan tage måneder om at falde på plads.
Er Next.js eller Laravel bedst til teknisk SEO?
Begge kan levere alt på listen. Next.js renderer på serveren som standard med App Router, og Laravel leverer HTML fra serveren via Blade. Bruger et Laravel-projekt React via Inertia, skal server-side rendering slås til særskilt. Problemerne opstår typisk, når en side bygges som en ren browser-app, uanset værktøj.