Skip to main content
← Tilbage til blog

SEO-guide Trin 7: Sikkerhed — Den baseline Google forventer i 2026

·11 min. læsetid·af LANGR SEO

SEO-guide Trin 7: Sikkerhed

Dette er Trin 7 af 13-trins SEO-guiden. Sikkerhed handler ikke kun om at beskytte brugere — det påvirker direkte dine søgerangeringer. Google har brugt HTTPS som rankingsignal siden 2014, og forventningerne er kun steget.

De fleste site-ejere tænker på sikkerhed som binært: "Vi har SSL, så vi er sikre." I virkeligheden evaluerer Google snesevis af sikkerhedssignaler. Sites med korrekte sikkerhedsheaders, gyldige certifikater og ingen mixed content ranker højere end sites med bare et basalt SSL-certifikat — alt andet lige.

Den gode nyhed: de fleste sikkerhedsrettelser er engangskonfigurationer. Sæt dem op én gang, og de beskytter dine rankings permanent.

SSL-konfiguration

SSL (teknisk set TLS) krypterer forbindelsen mellem din server og besøgende. Siden 2014 har Google eksplicit bekræftet HTTPS som et rankingsignal. I 2026 er manglen på HTTPS ikke bare et ranking-problem — Chrome markerer HTTP-sites som "Ikke sikker" i adresselinjen, hvilket ødelægger brugertillid.

Krav til korrekt SSL:

| Krav | Hvorfor | Sådan tjekker du | |------|---------|------------------| | Gyldigt certifikat | Udløbet = browser-advarsel = brugere der forlader | Tjek udløbsdato | | Fuld kæde | Ufuldstændige kæder fejler på nogle enheder | SSL Labs test | | TLS 1.2+ | Ældre versioner har kendte sårbarheder | SSL Labs test | | Ingen SHA-1 | Forældet, browsere afviser det | Certifikatdetaljer | | SAN-dækning | Både www og non-www skal dækkes | Certifikatdetaljer | | Auto-fornyelse | Forhindrer udløbskatastrofer | Let's Encrypt / udbyder config |

SSL-scoring:

100% = Gyldigt cert + Fuld kæde + TLS 1.3 + Stærk cipher + Auto-fornyelse
  0% = Udløbet eller manglende certifikat

Typiske SSL-fejl:

  1. Certifikat udløber uden varsel — Opsæt overvågning (Trin 6) minimum 30 dage før udløb
  2. Ufuldstændig certifikatkæde — Serveren skal sende mellemliggende certifikater, ikke kun bladcertifikatet
  3. Mixed content — HTTPS-side indlæser HTTP-ressourcer (billeder, scripts, stylesheets)
  4. Redirect-løkker — HTTP → HTTPS → HTTP cyklusser forårsaget af forkert CDN/proxy-konfiguration
  5. Non-www vs www mismatch — Certifikatet dækker det ene men ikke det andet

Quick win: Kør dit domæne gennem SSL Labs (ssllabs.com/ssltest). Alt under "A"-rating har handlingsbare problemer. De fleste hosting-udbydere fikser disse med ét klik.

Sikkerhedsheaders

Sikkerhedsheaders er HTTP response-headers der instruerer browsere i hvordan de skal opføre sig når de indlæser dit site. De forhindrer hele kategorier af angreb — og Googles crawlere tjekker for dem.

De essentielle sikkerhedsheaders:

Content-Security-Policy (CSP)

CSP er den mest kraftfulde sikkerhedsheader. Den fortæller browsere præcis hvilke ressourcer (scripts, stylesheets, billeder, fonte) der er tilladt at indlæse på dine sider.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.eksempel.dk; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.eksempel.dk; frame-ancestors 'none';

Hvad CSP forhindrer:

  • Cross-site scripting (XSS) angreb
  • Data-injektionsangreb
  • Clickjacking (via frame-ancestors)
  • Uautoriseret script-eksekvering (cryptominere, ad-injektorer)

CSP-udrulningsstrategi:

  1. Start med Content-Security-Policy-Report-Only (logger overtrædelser uden at blokere)
  2. Overvåg rapporter i 1-2 uger
  3. Whitelist legitime kilder
  4. Skift til håndhævende tilstand
  5. Tilføj report-uri eller report-to for løbende overtrædelseslogning

X-Frame-Options

Forhindrer dit site i at blive indlejret i iframes på andre domæner (clickjacking-beskyttelse).

X-Frame-Options: DENY

Eller hvis du har brug for at tillade same-origin framing:

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

Forhindrer browsere i MIME-type sniffing (at fortolke filer som andre typer end erklæret).

X-Content-Type-Options: nosniff

Denne ene linje forhindrer angreb hvor en .jpg-fil indeholder skjult JavaScript som browseren måske eksekverer.

Referrer-Policy

Styrer hvor meget referrer-information der sendes når brugere klikker links fra dit site.

Referrer-Policy: strict-origin-when-cross-origin

Dette sender fuld URL for same-origin requests men kun origin (domæne) for cross-origin requests. Balancerer analyse-behov med privatliv.

Permissions-Policy

Styrer hvilke browser-features (kamera, mikrofon, geolokation, etc.) der kan bruges på dit site.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

At deaktivere features du ikke bruger forhindrer tredjepartsscripts i at misbruge dem.

Header-implementering (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

Header-implementering (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Header-implementering (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Quick win: Tilføj alle 5 headers ovenfor til din serverkonfiguration. Det tager 5 minutter og forbedrer øjeblikkeligt din sikkerhedsprofil i ethvert scanningsværktøj.

HSTS Preload

HTTP Strict Transport Security (HSTS) fortæller browsere at de altid skal bruge HTTPS for dit domæne — selv før den første request. Uden HSTS kan det første besøg på dit site stadig bruge HTTP (sårbart for aflytning) før redirectet til HTTPS sker.

HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

De tre direktiver:

| Direktiv | Betydning | |----------|-----------| | max-age=31536000 | Husk dette i 1 år (i sekunder) | | includeSubDomains | Gælder også for alle subdomæner | | preload | Anmod om inkludering i browser preload-lister |

HSTS preload-listen:

Den ultimative HSTS-beskyttelse. Browsere leveres med en indbygget liste over domæner der altid skal bruge HTTPS. At indsende dit domæne til hstspreload.org betyder:

  • Førstegangsbesøgende får HTTPS med det samme (ingen HTTP → HTTPS redirect)
  • Umuligt for angribere at nedgradere forbindelser
  • Permanent (svært at fjerne når det er indsendt)

Krav for HSTS preload:

  1. Gyldigt HTTPS-certifikat
  2. Redirect alt HTTP til HTTPS (inklusive subdomæner)
  3. HSTS header med max-age >= 31536000
  4. HSTS header inkluderer includeSubDomains
  5. HSTS header inkluderer preload
  6. Alle subdomæner skal understøtte HTTPS

Advarsel: Indsend kun til preload hvis ALLE dine subdomæner understøtter HTTPS. includeSubDomains-direktivet betyder at ethvert HTTP-only subdomæne bliver utilgængeligt.

Quick win: Hvis du allerede har HTTPS på alle subdomæner, tilføj den fulde HSTS header og indsend til hstspreload.org. Behandling tager et par uger men beskyttelsen er permanent.

Sårbarhedsscanning

Automatiseret sårbarhedsscanning identificerer kendte sikkerhedsproblemer i din stack før angribere udnytter dem.

Hvad sårbarhedsscanning tjekker:

  • Forældet software: WordPress, plugins, JavaScript-biblioteker med kendte CVE'er
  • Eksponerede filer: .env, .git, wp-config.php, database-dumps
  • Informationslækage: Server-versionsheaders, debug-tilstand, stack traces
  • Standardlegitimationsoplysninger: Admin-sider uden auth, standardadgangskoder
  • Åbne porte/services: Unødvendige services eksponeret mod internettet
  • Injektionspunkter: Formularer uden CSRF-beskyttelse, uvaliderede inputs

Typiske sårbarheder per platform:

| Platform | Top-sårbarhed | Fix | |----------|---------------|-----| | WordPress | Forældede plugins | Auto-opdatering + WAF | | Shopify | Tredjeparts app-tilladelser | Auditér app-liste kvartalsvist | | Next.js | Eksponerede API-routes | Auth middleware + rate limiting | | Statiske sites | CDN-fejlkonfiguration | Gennemgå cache-regler | | Custom | SQL injection | Parametriserede queries |

Scanning-frekvens:

  • Dagligt: Automatiseret overfladescan (SSL, headers, eksponerede filer)
  • Ugentligt: Afhængigheds-sårbarhedstjek (npm audit, WordPress plugin-scanner)
  • Månedligt: Dyb scan med autentificeret test
  • Efter hvert deploy: Regressionstjek

Quick win: Kør npm audit (Node.js) eller tjek din CMS plugin-liste for forældede komponenter. Fix kritiske/høje sårbarheder med det samme.

Mixed Content

Mixed content opstår når en HTTPS-side indlæser ressourcer (billeder, scripts, stylesheets, iframes) over HTTP. Dette bryder delvist krypteringen og udløser browser-advarsler.

Typer af mixed content:

| Type | Alvorlighed | Eksempel | Browser-opførsel | |------|-------------|----------|------------------| | Aktivt | Høj | HTTP script, iframe, CSS | Blokeret som standard | | Passivt | Medium | HTTP billede, video, audio | Indlæst med advarsel |

Aktivt mixed content blokeres af moderne browsere — det betyder at dine scripts og stylesheets simpelthen ikke indlæses. Passivt mixed content indlæses men viser sikkerhedsadvarsler.

Find mixed content:

  1. Åbn Chrome DevTools → Console
  2. Kig efter "Mixed Content"-advarsler
  3. Alternativt, scan med en crawler (Screaming Frog, LANGR)

Typiske mixed content-kilder:

  • Hardkodede http://-URL'er i indhold (blogindlæg, produktbeskrivelser)
  • Tredjeparts-widgets der indlæser HTTP-ressourcer
  • Indlejret indhold (gamle YouTube-embeds, sociale medie-widgets)
  • CSS background-image med HTTP-URL'er
  • Fonte indlæst over HTTP

Fix mixed content:

<!-- Dårligt -->
<img src="http://eksempel.dk/billede.jpg" />

<!-- Godt -->
<img src="https://eksempel.dk/billede.jpg" />

<!-- Bedst (protokol-relativ, tilpasser sig sidens protokol) -->
<img src="//eksempel.dk/billede.jpg" />

Database-fix (WordPress):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://ditdomaene.dk', 'https://ditdomaene.dk');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://ditdomaene.dk', 'https://ditdomaene.dk');

Quick win: Åbn din forside i Chrome, tryk F12, tjek Console-fanen for mixed content-advarsler. Fix alle der vises — disse er direkte synlige for Google.

Tredjeparts-script-risici

Hvert eksternt script du indlæser er en potentiel sikkerheds- (og performance-) belastning. Tredjeparts-scripts kan:

  • Blive kompromitteret (forsyningskæde-angreb)
  • Tracke dine brugere uden samtykke (GDPR-overtrædelse)
  • Gøre dit site langsommere (render-blokering, netværks-latency)
  • Bryde funktionalitet (versionsopdateringer, nedbrud)
  • Injicere uønsket indhold (annoncescripts der går galt)

Auditér dine tredjeparts-scripts:

| Script | Nødvendigt? | Risikoniveau | Alternativ | |--------|-------------|--------------|------------| | Google Analytics | Ofte ja | Lav | Server-side tracking | | Chat-widgets | Måske | Medium | Selvhostede løsninger | | Sociale dele-knapper | Sjældent | Medium | Statiske dele-links | | A/B-testing | Sommetider | Høj | Server-side testing | | Retargeting-pixels | Forretningsbeslutning | Høj | First-party data | | Font-CDN'er | Bekvemt | Lav | Selvhost fonte |

Risikominimering for essentielle tredjeparts-scripts:

  1. Subresource Integrity (SRI): Hash-verifikation forhindrer manipulerede scripts i at indlæses
<script src="https://cdn.eksempel.dk/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. CSP-begrænsninger: Tillad kun scripts fra kendte domæner
  2. Sandboxede iframes: Isolér tredjeparts-widgets
  3. Regelmæssige audits: Kvartalsvis gennemgang af alle eksterne ressourcer
  4. Overvågning: Alarm ved nye eksterne domæner i dine sider

Quick win: List hvert