Teknisk SEO-tjekliste før en hjemmeside går live

Crawl, indeks og adgang

Hvis Google ikke kan crawle eller forstå, hvilke URL’er der er de foretrukne, hjælper hverken flot design eller skarpe tekster. Verificér med URL-inspektion i Search Console efter go-live.

• Production er ikke noindex ved en fejl (tjek meta robots og HTTP-header)
• Staging/preview er noindex eller adgangsbeskyttet
• robots.txt blokerer ikke vigtige stier ved en fejl
• XML-sitemap findes, er opdateret og indsendt i Search Console
• Sitemap indeholder kun kanoniske, indexérbare URL’er (ingen 404/redirects)
• Vigtige sider er nåbare via interne links — ikke kun sitemap
• CSS/JS nødvendige for indhold er ikke utilsigtet blokeret for crawlere

Statuskoder, redirects og HTTPS

Redirects er obligatoriske ved URL-ændringer, men hver ekstra hop koster tid og øger risiko for fejl. Map de vigtigste gamle URL’er bevidst — ikke kun “catch-all til forsiden”.

• Forside og kerne sider returnerer 200
• Fjernede sider returnerer 404 eller 410 — ikke soft-404 med 200
• Gamle URL’er har 301 til relevante nye destinationer (ved migration)
• Ingen unødvendige redirect-kæder (A→B→C→D)
• HTTP redirecter til HTTPS
• www / non-www er konsistent (én kanonisk host)
• Mixed content (HTTP-ressourcer på HTTPS-sider) er ryddet
• Gyldigt TLS-certifikat uden browseradvarsler

Canonicals og dubletter

Sørg for, at hver primær side har en klar kanonisk URL. Parametre, tracking-varianter og printervenlige dubletter må ikke skabe et virvar af indexérbare kopier. Hvis I bruger canonical-tags, skal de pege korrekt — ikke på den forkerte sprogversion eller en gammel slug.

• Self-canonical på primære sider (eller konsistent CMS-logik)
• Facetter/filtre er bevidst index/noindex efter strategi
• HTTP/HTTPS og trailing slash følger én regel

Titles, meta descriptions og headings

Title og H1 skal hjælpe brugeren med at genkende siden. Skriv til den intention, siden ejer. Undgå at alle servicesider hedder “Velkommen | Firmanavn”.

• Unik title per vigtig side — beskrivende, ikke keyword-stuvning
• Meta description er hjælpsom (den er ikke en direkte rankingfaktor, men påvirker klik)
• Én tydelig H1, der matcher sidens emne
• H2/H3 spejler indholdets struktur — ikke kun design-styling
• Ingen “lorem ipsum” eller placeholder-titles i produktion

Billeder, alt-tekster og medier

• Vigtige billeder har meningsfulde alt-tekster (ikke “image1”)
• Dekorative billeder er håndteret fornuftigt ift. tilgængelighed
• Store hero-billeder er komprimeret / korrekt dimensioneret
• Lazy-loading ødelægger ikke LCP-billedet (ofte det største above-the-fold)

Strukturerede data

Tilføj kun schema, der matcher synligt indhold: Organization/LocalBusiness, Article/BlogPosting på artikler, FAQ hvor FAQ faktisk findes, Product/Offer kun ved rigtige produkter. Valider markup. Forkert schema er værre end ingen schema.

• JSON-LD er gyldig og spejler siden
• Ingen fake ratings eller opdigtede aggregateRating
• FAQ-schema kun på sider med synlige spørgsmål/svar

Interne links og informationsarkitektur

Kerne sider skal kunne nås på få klik fra forsiden. Brug beskrivende ankertekster. Undgå at al vigtig SEO-side kun findes i en footer-kolonne med 40 ens links. En klar struktur hjælper både brugere og crawlere — og gør sitemap’en til en backup, ikke den eneste opdagelsesvej.

Mobil, Core Web Vitals og formularer

Hastighed og stabilitet er både brugeroplevelse og en del af den tekniske kvalitet, Google dokumenterer under page experience / Core Web Vitals. Se artiklen om hjemmesidehastighed for en dansk forklaring af LCP, CLS og INP.

• Layout fungerer på almindelige telefonbredder
• Knapper og formularfelter er lette at ramme
• LCP, CLS og INP er vurderet på mobil (lab + gerne felt, når I har data)
• Formularer sender korrekt og viser fejltydeligt
• Takkeside / bekræftelse er trackbar uden at lække persondata unødigt

404, analytics, consent og Search Console

Måling uden samtykke, hvor samtykke kræves, er både juridisk og datamæssigt problematisk. Få consent-flowet på plads før I “bare lige smider pixels ind”.

• Brugerdefineret 404 med vej videre (søg, populære sider, kontakt)
• Google Search Console-ejerskab verificeret på det korrekte property
• Analytics / tag manager kun efter gyldigt consent-setup, hvor det kræves
• Konverteringshændelser testet (submit, klik-to-call, køb/booking start)
• Cookie-banner blokerer ikke indhold eller skaber stort CLS

Migration: ekstra punkter når URL’er skifter

Ved redesign eller CMS-skift er redirect-kortet lige så vigtigt som det nye design. Eksportér gamle URL’er (crawl, Search Console, sitemap), map til nærmeste relevante nye side, og test stikprøver efter cutover. Undgå at sende al trafik til forsiden — det fortynder relevans og frustrerer brugere med bogmærker.

Planlæg også, hvad der sker med parametre, gamle kampagnelinks og PDF’er. En “ren” ny struktur uden redirects er ofte en dyr SEO-regning seks måneder senere.

• Redirect-map for top-URL’er efter trafik og backlinks
• Intern linkopdatering, så I ikke linker til gamle slugs unødigt
• Search Console: overvåg dækning og 404 efter lancering
• Behold vigtige landingssider, Ads lander på — eller ret kampagner samme dag

Sikkerhed, backup og go-live-rutine

• Gyldigt TLS-certifikat og fornuftig HTTPS-konfiguration
• Backup før og lige efter lancering (filer + database, hvor relevant)
• DNS TTL og cutover-plan ved domæneskift
• Overvåg crawl-fejl i Search Console de første uger
• Fjern testbrugere, debug-flags og midlertidige “coming soon”-blokeringer

Kort prioritering lige før release

Hos CPH WebDesigners indgår teknisk SEO i lancering og redesign, så I ikke går live med de mest kostbare blinde vinkler. Brug tjeklisten som fælles sprog mellem marketing og udvikling — og gentag de P0-punkter efter enhver større release.

Ofte stillede spørgsmål

Hvornår skal tjeklisten bruges?

Før første publicering, før et større redesign går live, og efter migration til nyt domæne eller CMS. Mange punkter er også nyttige som kvartalsvis sundhedstjek.

Er teknisk SEO nok til at rangere?

Nej. Teknisk SEO fjerner forhindringer. Synlighed kræver stadig relevant indhold, tillid og ofte lokal eller kommerciel styrke. Men tekniske fejl kan forhindre selv godt indhold i at blive fundet.

Skal staging-sites blokeres?

Ja. Staging og preview-miljøer bør være noindex eller på anden måde afskåret fra indeksering, så Google ikke indekserer kladder, testindhold eller duplicate URL’er.

Kan vi skippe schema ved lancering?

Ja, hvis I hellere vil gå live rent og tilføje structured data bagefter. Nej, hvis I allerede har aftalt typer, der matcher synligt indhold. Forkert schema er værre end intet schema.

Kilder

• Google Search Central
• Google Search Central — Crawl and index
• Google Search Central — SEO Starter Guide