HTTPS: hvad det er og hvorfor det er vigtigt

Hvad er HTTPS?

HTTPS er en kombination af HTTP og Transport Layer Security (TLS). Det leverer kryptering (fortrolighed), integritetskontroller og serverautentifikation, så data, der udveksles mellem en browser (eller anden klient) og en webserver, er beskyttet mod opsnapning og manipulation. I praksis serverer et site, der bruger HTTPS, HTTP-trafik over en TLS-sikret socket og præsenterer et certifikat udstedt af en betroet certifikatmyndighed (CA).

Hvorfor HTTPS betyder noget for SEO

HTTPS er nu en baseline-forventning både for brugere og browsere. For SEO inkluderer de praktiske effekter øget brugertryghed og færre browser-sikkerhedsadvarsler, bevaret referral-data ved secure→secure-overgange og kompatibilitet med funktioner, der kræver secure contexts (fx mange moderne web-API'er og progressive web app-funktioner). Historisk har Google brugt HTTPS som et letvægts ranking-signal; vigtigere er, at en brudt eller forkert konfigureret HTTPS-implementering kan forårsage crawl-fejl eller indekseringsproblemer, som indirekte skader synligheden. Husk: crawling, indeksering og ranking er separate faser — HTTPS påvirker, hvordan sider hentes og anses for indeksering, men rankingbeslutninger kombinerer mange signaler ud over transport-sikkerhed.

Hvordan HTTPS fungerer

På et højt niveau bruger HTTPS TLS til at etablere en sikker kanal, før HTTP-payloads udveksles. Typiske trin i TLS-handshaken er: klienten sender en ClientHello, serveren svarer med sit certifikat og valgte parametre, klienten validerer certifikatkæden og forhandler nøgler, og begge parter afleder symmetriske nøgler, der bruges for sessionen. Moderne udrulninger bruger TLS 1.3 hvor det er understøttet; ældre TLS-versioner udfases gradvist. Yderligere elementer at være opmærksom på inkluderer certifikatkæden (leaf, intermediate, root), OCSP/OCSP stapling til tilbagekaldelsestjek og understøttelse af HTTP/2 eller HTTP/3, som kører over TLS og kan forbedre performance, når de er korrekt konfigureret.

Typer af HTTPS-certifikater

Almindelige certifikattyper og deres tradeoffs:

• Domain-validated (DV) — udstedes efter bevis for kontrol over et domæne. Fordele: hurtigt og ofte gratis (fx Let's Encrypt); ulemper: giver kun identitet på domæneniveau.
• Organization-validated (OV) — tilføjer virksomhedsidentitetskontroller; Fordele: viser organisationsinfo i certifikatmetadata; ulemper: højere pris og længere udstedelsestid.
• Extended Validation (EV) — historisk strengere tjek og særskilt UI i nogle klienter; Fordele: stærkere identitetschecks; ulemper: mange browsere viser ikke længere speciel UI for EV.
• Wildcard og SAN (multi-domain) certifikater — dækker flere subdomæner eller hostnavne; Fordele: enklere management for mange hostnavne; ulemper: wildcard-nøgler øger blast radius, hvis privat nøgle eksponeres.
• Self-signed — ikke betroet af browsere og uegnet til offentlige sites.

Sådan kommer du i gang med HTTPS

Kernetrin til at implementere HTTPS på et offentligt website:

1) Obtain a certificate from a trusted CA (including free CAs such as Let's Encrypt) or from your hosting/CDN provider. 2) Install the certificate and related intermediate chain on your origin or edge servers. 3) Configure secure TLS settings (prefer modern versions and strong cipher suites) and enable OCSP stapling. 4) Implement server-side 301 redirects from HTTP to HTTPS and ensure canonical tags point to the preferred HTTPS URL. 5) Update internal links, sitemaps, hreflang entries and any hard-coded references. 6) Test for mixed content and fix insecure asset URLs. 7) Optionally enable HSTS after testing (carefully consider the preload option).

Almindelige HTTPS-fejl

Hold øje med disse hyppige fejl, der påvirker både UX og synlighed i søgeresultater:

• Missing or broken redirect chains — some pages remain accessible over HTTP while canonical and sitemap entries point to HTTPS.
• Mixed content — pages served over HTTPS include subresources loaded over HTTP, which browsers block or warn about.
• Expired or incomplete certificate chain — browsers or crawlers may refuse the connection.
• HSTS misconfiguration — enabling preload before validating every variant (www, non-www, IPv6) can cause lock-in.
• Blocking crawlers at TLS level — strict firewall/TLS policies that block Googlebot or other search crawlers can prevent indexing.
• Forgetting third-party services — update CDN, analytics, tag managers and API endpoints to use HTTPS.

HTTPS-tjek: teknisk tjekliste

**Certificate validity** — hvor du kan tjekke: browserens hængelås > certifikatoplysninger, SSL Labs eller openssl — bestået når certifikatet er udstedt af en betroet CA, kæden er komplet, og datoerne er gyldige.

**Redirects to HTTPS** — hvor du kan tjekke: curl -I -L https://example.com (replace with your host) — bestået når HTTP-forespørgsler returnerer 301/308-redirects, der ender på den kanoniske HTTPS URL.

**Mixed content** — hvor du kan tjekke: browserens DevTools Console eller en automatiseret scanner — bestået når der ikke er aktivt mixed content (scripts, iframes) der blokeres, og alle kritiske assets indlæses over HTTPS.

**TLS protocol and cipher support** — hvor du kan tjekke: SSL Labs eller openssl s_client -connect example.com:443 -servername example.com — bestået når moderne TLS-versioner (TLS 1.2/1.3) er aktiveret og usikre ciphers er deaktiveret.

**HSTS header** — hvor du kan tjekke: curl -I https://example.com — bestået når Strict-Transport-Security header er til stede med de tilsigtede direktiver (test før preloading).

**Search engine access** — hvor du kan tjekke: serverlogs og Google Search Console (for sites du ejer) — bestået når Googlebot og andre store crawlers kan hente HTTPS-respons uden TLS-fejl.

Praktiske kommandoer og værktøjer

Nyttige tjek du kan køre fra din arbejdsstation eller din CI-pipeline:

• View headers and redirects: curl -I -L https://example.com (use -I to fetch headers only; -L follows redirects).
• Inspect TLS certificate chain: openssl s_client -connect example.com:443 -servername example.com (check the certificate details shown).
• Quick browser check: open the page, click the padlock and view certificate information.
• Automated grading: run SSL Labs (Qualys SSL Labs) or your CI TLS scanner to get a report on protocol support, cipher suites and chain issues.
• For owned properties: use Google Search Console URL Inspection to confirm Google can fetch and index the HTTPS page; remember URL Inspection is authoritative only for sites you own.

Note on crawlers: Google crawls sites with Googlebot Smartphone by default; ensure your TLS stack, SNI and firewall rules allow access by major crawler user-agents so that crawling og indeksering bliver ikke afbrudt.

Læs Technical SEO Guide

Ofte stillede spørgsmål

Q: Does HTTPS directly improve rankings?
A: HTTPS has been treated as a lightweight ranking signal, but it is only one of many ranking factors. More importantly, an incorrect HTTPS deployment can cause fetch or indexation problems that indirectly harm visibility.

Q: Are free certificates (Let's Encrypt) sufficient?
A: Yes — free, DV certificates from trusted CAs are widely accepted for public websites. Choose an issuance and renewal process that fits your operational model; managed or commercial certificates may add features like longer validity windows, warranty or extra validation checks.

Q: What is HSTS and should I enable it?
A: HSTS (Strict-Transport-Security) tells browsers to always use HTTPS for a host. It increases security but must be tested thoroughly before enabling the preload list because it can make recovery harder if misconfigured.

Q: How do I detect mixed content?
A: Open the page in a browser, check DevTools Console for mixed content warnings, or use an automated scanner. Fix insecure asset URLs to ensure pages are fully secure.

Q: If a page is accessible over HTTPS but not indexed, is HTTPS to blame?
A: Not necessarily. Indexation depends on many factors (canonical tags, noindex, crawlability, content quality). A correct HTTPS setup removes a common source of indexing errors, but indexing decisions remain multifactorial.