TECHNISCHE SEO PROTOCOL & STANDAARDEN 02 jan. 2026 8 min leestijd

HTTPS en HSTS: beveiligingssignalen die AI waardeert

Bas Vermeer
Bas Vermeer SEO/AEO Specialist
HTTPS en HSTS: beveiligingssignalen die AI waardeert — Technische SEO

Waarom beveiliging een AI-signaal is

Wanneer een AI-model bronnen selecteert voor het genereren van een antwoord, weegt het tientallen factoren mee. Een van die factoren is de betrouwbaarheid van de technische infrastructuur. Een website die draait op HTTPS met strikte beveiligingsheaders straalt meer vertrouwen uit dan een site die nog op HTTP draait of beveiligingsheaders mist. Dit is geen theorie: onderzoek naar hoe taalmodellen bronnen selecteren toont aan dat protocolveiligheid een van de signalen is die indirect het vertrouwen in een bron bepaalt.

Voor zoekmachines is HTTPS al jaren een rankingfactor. Google bevestigde dit in 2014. Maar het belang ervan reikt nu verder dan SEO — bibliotheekterm. AI-crawlers en taalmodellen die het web indexeren, markeren HTTP-sites als potentieel onveilig. Dit kan ertoe leiden dat je content minder vaak wordt geselecteerd als bron voor AI-gegenereerde antwoorden. In combinatie met andere vertrouwenssignalen, zoals E-E-A-T signalen, vormt HTTPS een basisvoorwaarde voor een geloofwaardige online aanwezigheid.

BELANGRIJK

In 2026 zou geen enkele serieuze website meer op HTTP moeten draaien. Toch draait volgens metingen nog steeds een significant percentage sites zonder geldige SSL-configuratie of met beveiligingsheaders die ontbreken.

HTTPS correct configureren

HTTPS implementeren begint bij het verkrijgen van een SSL/TLS-certificaat. Dankzij diensten als Let's Encrypt is dit gratis en geautomatiseerd mogelijk. Maar alleen een certificaat installeren is niet genoeg. De configuratie moet ook correct zijn om daadwerkelijk vertrouwen te wekken.

Een veelgemaakte fout is het installeren van een certificaat zonder de volledige certificaatketen correct in te stellen. Wanneer het intermediate certificaat ontbreekt, tonen sommige browsers een beveiligingswaarschuwing terwijl andere het certificaat wel accepteren. Dit leidt tot een inconsistente ervaring en kan ertoe leiden dat AI-crawlers je site als onbetrouwbaar markeren. Controleer altijd of de volledige keten correct is geconfigureerd met een tool als SSL Labs.

HTTP naar HTTPS redirect instellen

Een correcte redirect van HTTP naar HTTPS is essentieel. Zonder redirect is je site op beide protocollen bereikbaar, wat leidt tot duplicaat-content problemen en verwarrende signalen voor AI-crawlers.

# Nginx: redirect all HTTP traffic to HTTPS
server {
    listen 80;
    server_name example.nl www.example.nl;
    return 301 https://example.nl$request_uri;
}

# Apache: redirect all HTTP traffic to HTTPS
<VirtualHost *:80>
    ServerName example.nl
    Redirect permanent / https://example.nl/
</VirtualHost>

# .htaccess (als je geen toegang hebt tot de vhost configuratie)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  • Gebruik TLS 1.2 of hoger. TLS 1.0 en 1.1 worden beschouwd als onveilig en worden door moderne browsers geblokkeerd.
  • Configureer een automatische redirect van HTTP naar HTTPS op serverniveau zodat geen enkele bezoeker op de onbeveiligde versie terechtkomt.
  • Zorg dat alle interne links — bibliotheekterm, afbeeldingen en scripts via HTTPS worden geladen om mixed-content waarschuwingen te voorkomen.
  • Vernieuw certificaten automatisch. Een verlopen certificaat veroorzaakt een beveiligingswaarschuwing die zowel bezoekers als bots afschrikt.
  • Test je configuratie met SSL Labs (ssllabs.com/ssltest) en streef naar een A+ score.

HSTS: de volgende stap in transportbeveiliging

HTTP Strict Transport Security (HSTS) is een beveiligingsmechanisme dat browsers instrueert om uitsluitend via HTTPS met je website te communiceren. Zodra een browser de HSTS-header ontvangt, zal deze gedurende de opgegeven periode elke HTTP-verbinding automatisch upgraden naar HTTPS, nog voordat het verzoek wordt verstuurd. Dit beschermt tegen man-in-the-middle aanvallen en protocol-downgrade aanvallen.

# Strict-Transport-Security header
# max-age: duur in seconden (31536000 = 1 jaar)
# includeSubDomains: geldt ook voor alle subdomeinen
# preload: meld je aan voor de HSTS preload lijst

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

# Nginx configuratie
server {
    listen 443 ssl;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

# Apache configuratie
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

De max-age parameter bepaalt hoe lang browsers de HSTS-instructie onthouden. Een waarde van 31536000 seconden komt overeen met een jaar. Begin bij een korte periode zoals 300 seconden om te testen of alles correct werkt en verhoog vervolgens naar een jaar.

HSTS preload lijst

De HSTS preload lijst is een register dat wordt onderhouden door het Chromium-project en wordt gebruikt door alle grote browsers. Websites op deze lijst worden altijd via HTTPS geladen, zelfs bij het allereerste bezoek. Dit elimineert de kwetsbaarheid van het eerste HTTP-verzoek voordat de HSTS-header is ontvangen. Je kunt je site aanmelden op hstspreload.org.

Stapsgewijs HSTS implementeren

Het is verstandig om HSTS gefaseerd in te voeren om problemen te voorkomen. Als je site nog niet volledig op HTTPS werkt (mixed content, subdomeinen op HTTP), kan een te snelle HSTS-implementatie bezoekers buitensluiten.

  1. Start met max-age=300 (5 minuten) zonder includeSubDomains. Test of alle pagina's correct laden via HTTPS.
  2. Verhoog naar max-age=86400 (1 dag). Monitor op mixed-content waarschuwingen in de browser console.
  3. Voeg includeSubDomains toe zodra alle subdomeinen correct op HTTPS draaien.
  4. Verhoog naar max-age=31536000 (1 jaar) wanneer alles stabiel draait.
  5. Voeg preload toe en meld je aan op hstspreload.org voor opname in de preload lijst.

Aanvullende beveiligingsheaders voor vertrouwen

Naast HSTS zijn er meer beveiligingsheaders die het vertrouwensprofiel van je website versterken. AI-crawlers en scanners evalueren deze headers als onderdeel van de technische kwaliteit van een site. Voor een uitgebreide behandeling van alle relevante headers, zie ons artikel over security headers die AI-vertrouwen opbouwen.

# Content Security Policy: beperkt bronnen die de pagina mag laden
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

# Voorkomt dat de browser MIME-types raadt
X-Content-Type-Options: nosniff

# Voorkomt dat je site in een iframe wordt geladen (clickjacking)
X-Frame-Options: DENY

# Stuurt referrer-informatie alleen naar eigen domein
Referrer-Policy: strict-origin-when-cross-origin

# Beperkt toegang tot browser-API's
Permissions-Policy: camera=(), microphone=(), geolocation=()

Headers die AI-crawlers evalueren

  • Strict-Transport-Security bevestigt dat de site consequent HTTPS afdwingt.
  • Content-Security-Policy toont aan dat de site actief beschermt tegen cross-site scripting en data-injectie.
  • X-Content-Type-Options voorkomt MIME-sniffing en toont technische zorgvuldigheid.
  • Referrer-Policy beschermt de privacy van bezoekers en laat zien dat de site privacybewust is.
  • Permissions-Policy beperkt onnodige browser-API toegang, wat wijst op een doordachte beveiligingsstrategie.

De relatie tussen HTTPS en robots.txt

Je robots.txt configuratie moet rekening houden met je HTTPS-implementatie. Als je site zowel via HTTP als HTTPS bereikbaar is, moeten beide versies een robots.txt — bibliotheekterm bevatten. AI-crawlers halen de robots.txt op van het protocol waarop ze je site ontdekken. Een ontbrekende robots.txt op de HTTPS-versie kan betekenen dat AI-bots geen crawl-instructies hebben en je site mogelijk overslaan.

Beveiliging testen en monitoren

Het is niet genoeg om beveiligingsheaders eenmalig in te stellen. Regelmatige controle is essentieel om te waarborgen dat je configuratie actueel en correct blijft.

  1. Gebruik SSL Labs (ssllabs.com/ssltest) om je TLS-configuratie te testen. Streef naar een A+ beoordeling.
  2. Controleer je beveiligingsheaders met securityheaders.com. Deze tool geeft een score van A+ tot F en toont precies welke headers ontbreken.
  3. Monitor je certificaatverloop en stel automatische vernieuwing in via Let's Encrypt of je hostingprovider.
  4. Scan je site op mixed-content problemen met de browser-console (zoek naar "Mixed Content" waarschuwingen).
  5. Test de HSTS preload status van je domein op hstspreload.org.

Impact op de AI-Ready score

In onze AEO — bibliotheekterm-scanner controleren we zowel de aanwezigheid van HTTPS als de kwaliteit van de beveiligingsheaders. Een site die HTTPS correct implementeert met een geldige HSTS-header scoort significant hoger op het vertrouwensprofiel dan een site die alleen een basis SSL-certificaat heeft. De combinatie van HTTPS, HSTS met preload en aanvullende beveiligingsheaders is een sterk signaal naar zowel zoekmachines als AI-modellen dat je site professioneel wordt beheerd. Dit sluit direct aan bij de bredere AEO-principes die we eerder beschreven.

Samenvatting: de belangrijkste punten

  • HTTPS is een basisvereiste voor AI-vertrouwen: AI-crawlers markeren HTTP-sites als potentieel onveilig.
  • HSTS voorkomt protocol-downgrade aanvallen en dwingt HTTPS af op browserniveau, zelfs voor het eerste verzoek (met preload).
  • Implementeer HSTS stapsgewijs: begin met een korte max-age en bouw op naar een jaar met preload.
  • Aanvullende beveiligingsheaders zoals CSP, X-Content-Type-Options en Permissions-Policy versterken het vertrouwensprofiel bij AI-modellen.
  • Regelmatige monitoring via SSL Labs en securityheaders.com is essentieel om je configuratie actueel te houden.

Veelgestelde vragen

Is HTTPS echt een rankingfactor voor AI-modellen?

Ja. Hoewel AI-modellen geen expliciete "rankingfactoren" hebben zoals Google, wegen ze de betrouwbaarheid van bronnen mee. HTTPS is een van de technische signalen die bijdragen aan het vertrouwensprofiel van je site. Sites op HTTP worden als minder betrouwbaar gezien, wat leidt tot een lagere kans op citatie in AI-gegenereerde antwoorden.

Kan een verlopen SSL-certificaat mijn AI-zichtbaarheid schaden?

Absoluut. Een verlopen certificaat genereert een browserwarning die AI-crawlers afschrikt. De meeste crawlers breken de verbinding af bij een SSL-fout en indexeren de pagina niet. Stel altijd automatische vernieuwing in via Let's Encrypt of je hostingprovider om dit te voorkomen.

Wat is het verschil tussen HSTS en een gewone HTTPS-redirect?

Een HTTPS-redirect vangt het verkeer op serverniveau op en stuurt bezoekers door. Maar bij de eerste request wordt nog steeds een onbeveiligd HTTP-verzoek gestuurd. HSTS instrueert de browser om toekomstige verzoeken direct via HTTPS te doen, zonder de HTTP-omweg. Met HSTS preload geldt dit zelfs voor het allereerste bezoek.

Heeft HSTS preload nadelen waar ik rekening mee moet houden?

Het belangrijkste nadeel is dat opname in de preload lijst moeilijk ongedaan te maken is. Als je site na opname toch problemen heeft met HTTPS (bijvoorbeeld door mixed content op subdomeinen), kunnen bezoekers je site niet meer bereiken via HTTP als fallback. Test daarom grondig voordat je preload activeert.

Welke beveiligingsheaders zijn het belangrijkst voor mijn AI-score?

Strict-Transport-Security (HSTS) is de belangrijkste. Daarna volgen Content-Security-Policy, X-Content-Type-Options en Referrer-Policy. Deze vier headers samen vormen een solide basis. Permissions-Policy is een waardevolle toevoeging maar minder kritiek. Begin met HSTS en bouw van daaruit verder.

Beveiliging is geen kostenpost, het is een investering in vertrouwen. En vertrouwen is precies wat AI-modellen zoeken bij het selecteren van bronnen.

Hoe scoort jouw website op AI-gereedheid?

Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.

Gratis scan

DEEL DIT ARTIKEL

LINKEDIN X

GERELATEERDE ARTIKELEN