HTTPS og SSL-certifikat
En krypteret forbindelse er ikke længere en luksus. Det er et minimumskrav for at blive taget alvorligt af Chrome, Safari og Google.
Nøglefakta
Hvad er HTTPS egentlig?
HTTPS står for HyperText Transfer Protocol Secure. Det er ikke en ny protokol, men den almindelige HTTP-protokol pakket ind i et lag af kryptering. Krypteringen håndteres af TLS (Transport Layer Security), som er efterfølgeren til den ældre SSL-protokol. I daglig tale bruges navnene SSL og TLS i flæng, men teknisk set er SSL forældet og udfaset siden 2015. Det du køber eller henter gratis i dag er et TLS-certifikat — selvom det stadig hedder "SSL-certifikat" i marketing-materialet.
Når en bruger besøger en HTTPS-side, sker der tre ting før den første byte indhold sendes: serveren beviser sin identitet med et certifikat udstedt af en certifikatudbyder (CA), browseren og serveren forhandler en sessionsnøgle, og resten af kommunikationen krypteres. Det betyder at en angriber på samme WiFi ikke kan læse formularer, cookies eller URL'er. Det betyder også at internetudbydere ikke kan injicere reklamer i indholdet.
For SEO er den krypterede transport kun halvdelen af pointen. Den anden halvdel er, at Chrome siden 2018 markerer alle HTTP-sider som "Not Secure" i adresselinjen. En bruger der ser den advarsel klikker tilbage. Bounce rate stiger, dwell time falder, og Google bemærker.
SSL-certifikat: tre typer
Domain Validated (DV)
Bekræfter at du ejer domænet. Udstedes på minutter. Gratis via Let's Encrypt.
Brug: Blogs, SaaS, småbutikker.
Organization Validated (OV)
Bekræfter at virksomheden findes. Manuel verifikation. Tager 1 til 3 dage.
Brug: Virksomhedssites med login.
Extended Validation (EV)
Mest grundig kontrol. Tidligere markeret med grønt firmanavn i adresselinjen — fjernet af Chrome i 2019.
Brug: Banker, betalingsudbydere.
For 95% af danske websites er et DV-certifikat fra Let's Encrypt nok. Det fornyes automatisk hver 90. dag og koster ingenting. Søgemaskinerne skelner ikke mellem DV, OV og EV. En bruger gør det heller ikke længere.
Migrering fra HTTP til HTTPS
En migrering fra HTTP til HTTPS er teknisk set en site-flytning. Hver URL får en ny adresse, og hvert internt link, hvert backlink og hvert canonical-tag skal afspejle det. En halv migrering er værre end ingen — den efterlader duplicates som Google ikke kan vælge imellem.
# Apache: tving alle requests til HTTPS via .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Nginx: samme via server block
server {
listen 80;
server_name www.example.dk example.dk;
return 301 https://www.example.dk$request_uri;
}Brug 301 (permanent) — ikke 302. En 302 fortæller Google at flytningen er midlertidig, og link-equity overføres ikke fuldt ud. Efter migrering: opdater alle interne links til at pege på HTTPS-versionen direkte. Et internt link via en 301 redirect tæller stadig, men hver redirect koster crawl-budget og latenstid.
Mixed content — den lumske fejl
Mixed content opstår når en HTTPS-side henter ressourcer (billeder, scripts, CSS) over almindelig HTTP. Browseren markerer siden som usikker, og "passive" mixed content (billeder) loades stadig, mens "active" mixed content (JavaScript) blokeres helt. En blokeret tracking-pixel betyder ingen data i Analytics. Et blokeret script betyder ødelagt funktionalitet.
Find mixed content med Chrome DevTools (Console-fanen) eller med Lighthouse. Det mest almindelige er hardcodede billed-URL'er i WordPress-indlæg fra før migreringen. En enkelt SQL-query kan rette tusindvis af dem:
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://example.dk', 'https://example.dk')
WHERE post_content LIKE '%http://example.dk%';HSTS: tving HTTPS for evigt
HTTP Strict Transport Security (HSTS) er en header der fortæller browseren: "næste gang du besøger dette domæne, brug HTTPS direkte uden at spørge". Det fjerner den korte HTTP-til-HTTPS redirect i starten af hver session, og det forhindrer downgrade-angreb hvor en angriber forsøger at narre browseren tilbage til HTTP.
# Send denne header på alle responses
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadForsigtig: HSTS er sticky. Når en browser har modtaget headeren, nægter den at besøge HTTP-versionen i ét år. Hvis du derefter mister dit certifikat, er sitet utilgængeligt. Test først med en kort max-age (f.eks. 300 sekunder), bekræft at alt virker, og forhøj derefter til et år. Først derefter tilføjes preload, som kræver indsendelse til hstspreload.org.
Google Search Console efter migrering
HTTPS-versionen af et site er en separat ejendom i Search Console. Tilføj den nye HTTPS-property før migreringen, og hold begge åbne i mindst tre måneder. På den måde kan du sammenligne impressions og klik direkte og fange de URL'er der ikke blev redirected korrekt. Indsend også et opdateret sitemap der kun indeholder HTTPS-URL'er.
Forvent et lille midlertidigt fald i trafik de første 1 til 4 uger. Det er normalt og skyldes at Google skal genfinde og genindeksere alle URL'er. Hvis trafikken ikke er tilbage på niveau efter 6 uger, er der noget galt — typisk en 301-kæde, manglende canonical-opdatering eller blokerede ressourcer i robots.txt.
Best practices
Gør dette
- • Brug Let's Encrypt med automatisk fornyelse
- • 301-redirect alle HTTP-URL'er til HTTPS
- • Opdater interne links til at pege direkte på HTTPS
- • Tilføj HSTS efter en testperiode
- • Indsend opdateret sitemap til Search Console
- • Hold den gamle HTTP-property åben i 90 dage
Undgå dette
- • Selvsignerede certifikater i produktion
- • 302-redirect til HTTPS (skal være 301)
- • Hardcodede HTTP-billeder i CMS-indhold
- • HSTS preload uden testperiode først
- • At glemme certifikatfornyelse (Let's Encrypt udløber efter 90 dage)
- • At blokere /.well-known/acme-challenge/ i robots.txt