HTTPS-only komt eraan: zorg dat je site 100% op slot zit vóór Chrome 154

Herkenbaar? Het slotje staat aan, maar toch niet helemaal veilig

Veel websites draaien al op HTTPS, maar missen net die laatste 10 procent: een oude afbeelding via http, een subdomein zonder certificaat of een scriptje dat nog naar een onveilige URL wijst. Vandaag levert dat soms een waarschuwing op. Vanaf Chrome 154 (gepland in 2026) zet Google standaard HTTPS-only aan. Dat betekent: browsers proberen altijd een beveiligde verbinding. Als iets alleen via http te bereiken is of mixed content laadt, kan het hard stuklopen.

Het goede nieuws: met een gerichte checklist zet je je website en WordPress-installatie echt 100 procent op slot. Je voorkomt storingen, behoudt je vindbaarheid en je geeft klanten vertrouwen.

Waarom dit nu belangrijk is

HTTPS-only verandert de standaard. Een enkele http-link, een vergeten subdomein of een verouderde plugin die een script via http inlaadt kan ervoor zorgen dat delen van je site niet meer werken. Denk aan formulieren die niet verstuurd worden of afbeeldingen die ontbreken. Bovendien blokkeert moderne browserbeveiliging steeds agressiever onveilige onderdelen, waardoor fouten onduidelijk en tijdrovend kunnen zijn.

Een migratie naar echt-alleen-HTTPS kost vaak weinig tijd als het al goed ingeregeld is: domeinen in kaart gebracht, certificaten geautomatiseerd, headers & redirects netjes ingericht en mixed content opschonen.

Wat wordt vaak over het hoofd gezien

Bij Rendar zien we drie terugkerende oorzaken van gedoe:

  • Subdomeinen die niet in het certificaat zitten of geen redirect hebben, zoals cdn.jouwdomein.nl of files.jouwdomein.nl.
  • Hardgecodeerde http-links in thema’s, e-mailsjablonen en landingspagina’s.
  • Externe formulieren, scripts of iframes die alleen via http beschikbaar zijn.

Stel dat je contactformulier naar http://forms.voorbeeld-verkoper.com/submit post. In HTTPS-only blokkeert de browser die call en lijkt het formulier “niets te doen”. Niet fijn als je een campagne live hebt.

De praktische checklist voor HTTPS-only (met uitleg)

1. Breng alle hostnames en paden in kaart

Schrijf op welke domeinen en subdomeinen je gebruikt. Denk aan www en het apex-domein (zonder www), maar ook assets zoals cdn.jouwdomein.nl, media.jouwdomein.nl of api.jouwdomein.nl. Noteer ook externe bronnen: betaalproviders, formuliertools, fonts, analytics en chatwidgets. Dit is je werklijst voor certificaten, redirects en mixed content.

2. Certificaatbeheer: automatisch en volledig

Zorg dat elk hostname een geldig certificaat heeft en automatisch verlengt.

  • Gebruik ACME/Let’s Encrypt of je hostingplatform voor auto-renew. Stel e-mailalerts of monitoring in op vervaldatums.
  • Heb je veel subdomeinen die wisselen? Overweeg een wildcardcertificaat met DNS-01-validatie, of laat TLS termineren op je CDN.
  • Controleer de volledige certificaatketen. Een onjuiste intermediate kan in oudere clients problemen geven.

Waarom: verlopen of onvolledige certificaten zorgen direct voor blokkades. Met auto-renew en monitoring verklein je die kans tot bijna nul.

3. Forceer HTTPS met één strakke 301-redirect

Richt een vaste redirect in van http naar https op het punt waar verkeer als eerste binnenkomt (bijv. bij je CDN of load balancer). Kies één canoniek hostnaamformaat (met of zonder www) en laat alle varianten in één stap daarheen verwijzen. Behoud pad en querystring.

Waarom: één-hop 301’s geven duidelijkheid aan zoekmachines, voorkomen snelheidsverlies en verkleinen de kans op foutjes. Een redirect-keten is kwetsbaar en traag.

4. Zet HSTS aan en plan richting preload

Activeer Strict-Transport-Security (HSTS) zodat browsers jouw domein voortaan alleen via HTTPS bezoeken.

  • Begin conservatief: max-age een paar dagen, zonder includeSubDomains.
  • Verleng naar 6–12 maanden zodra alles stabiel is en voeg daarna pas includeSubDomains toe.
  • Als je 100% zeker bent dat álle subdomeinen HTTPS correct ondersteunen, voeg preload toe.

Waarom: HSTS sluit de achterdeur (http) definitief. Preload zorgt dat zelfs het allereerste bezoek al veilig is, maar vraagt discipline: elk subdomein moet kloppen.

5. Ruim mixed content op (zeker in WordPress)

Mixed content ontstaat als je pagina via https laadt, maar onderdelen (afbeeldingen, CSS, JS, iframes) via http binnenhaalt. Dat wordt steeds vaker geblokkeerd.

Pak het aan in deze volgorde:

  • Controleer de WordPress-instellingen: zet WordPress-adres (URL) en Site-adres (URL) op https.
  • Doe een zoek-en-vervang in de database om oude http-verwijzingen te vervangen door https. Met WP-CLI kan dat bijvoorbeeld met: wp search-replace 'http://jouwdomein.nl' 'https://jouwdomein.nl' --all-tables.
  • Controleer thema’s en child themes op hardgecodeerde http-URL’s in templates, CSS en JS. Gebruik liever relatieve of expliciete https-URL’s.
  • Ga plugins langs die assets injecteren (bijv. sliders, formulieren, analytics). Update ze of pas de instellingen aan.
  • Externe bronnen: vervang http door https of kies een leverancier die wel via https levert. Voor Google Fonts of iconen is zelf hosten een robuuste optie.

Waarom: mixed content is de nummer 1 oorzaak van “het werkt soms niet”-klachten na een HTTPS-migratie. Opruimen geeft rust en voorkomt onduidelijke browserfouten.

6. Check formulieren, iframes en API-calls

Loop alle contact- en checkoutformulieren na, inclusief embeds via een derde partij. Test of de submit-URL en eventuele webhooks via https gaan. Controleer ook AJAX-calls van je thema of plugins; zet CORS en cookies goed zodat alles onder https blijft functioneren.

Waarom: in HTTPS-only modus kan een http-submit onzichtbaar stukgaan. Een gerichte testronde voorkomt conversieverlies.

7. Canonicals, sitemaps en e-mailtemplates

Werk SEO-details bij zodat zoekmachines het juiste adres begrijpen:

  • Pas canonical-tags aan naar https.
  • Zorg dat sitemaps https-URL’s bevatten en meld de https-versie in Search Console aan.
  • Update linkjes in e-mailtemplates, QR-codes, pdf’s en marketingtools naar https.

Waarom: consistentie voorkomt dubbele indexatie en houdt je analytics schoon.

8. Content Security Policy: vang de laatste restjes

Als je bijna klaar bent, kan een Content Security Policy helpen de laatste mixed content te vinden of automatisch om te zetten:

  • upgrade-insecure-requests forceert http-verzoeken naar https.
  • block-all-mixed-content blokkeert resterende onveilige onderdelen, handig in test.

Waarom: CSP is een extra veiligheidsnet dat problemen zichtbaar maakt voordat je bezoekers er last van hebben. Begin met report-only om impact te meten.

9. Prestaties: maak HTTPS ook snel

HTTPS is niet per definitie sneller of langzamer. Maar als je dan toch bezig bent: schakel HTTP/2 of HTTP/3 in op je hosting of CDN, zorg voor TLS-resumptie en zet caching headers goed. Combineer dat met een CDN op een paar strategische locaties. Zo voelt de overstap niet alleen veilig maar ook vlot.

10. Test systematisch en blijf monitoren

Test in meerdere browsers, met en zonder ingelogde sessie, en op mobiel. Handige checks:

  • Chrome DevTools Security-tab en de Console voor mixed content-meldingen.
  • Lighthouse/Pagespeed en SSL Labs voor TLS-details.
  • SecurityHeaders.com voor HSTS en CSP.
  • Uptimemonitoring op de https-URL en certificaatvervalalerts.

Waarom: een uur testen nu voorkomt dagen zoeken bij liveproblemen.

Kleine scenario’s uit de praktijk

Stel: op je homepage staat een hero-afbeelding die ooit via http://cdn.oudehoster.nl/hero.jpg werd geladen. In de meeste browsers krijg je nu al een waarschuwing, maar het werkt soms nog. In HTTPS-only wordt die afbeelding niet meer geladen. Oplossing: host het bestand zelf of vraag de leverancier om een https-endpoint, en pas je template aan.

Een ander voorbeeld: je had ooit blog.jouwdomein.nl en hebt die subsite uitgezet. Met HSTS includeSubDomains en preload verplicht je browsers alsnog https op die subdomein. Zorg dat je een redirect of minimaal een 410 Gone via https aanbiedt, anders lopen bezoekers vast.

Veelgemaakte keuzes in WordPress

Voor mkb-sites is eenvoud de beste vriend. Een paar nuchtere keuzes die wij vaak zien slagen:

  • HTTPS-forcering in je edge-laag (CDN of webserver) en niet in tien verschillende plugins.
  • Een eenmalige, grondige search-replace op de database in plaats van vele “on-the-fly” rewrites.
  • HSTS gefaseerd uitrollen: eerst normaal, dan pas preload.
  • Externe assets minimaliseren of zelf hosten waar zinvol (fonts, kritieke scripts).

Wij richten ons op risico’s vermijden die ook daadwerkelijk kunnen voorkomen, zonder onnodige complexiteit. Klein beginnen en goed documenteren helpt.

Samengevat: maak het veilig, hou het simpel

Chrome’s HTTPS-only als standaard is geen dreiging, maar een mooie stok achter de deur om je site echt af te ronden. De kern is eenvoudig: certificaten automatisch, één nette 301, HSTS gefaseerd, mixed content weg en formulieren testen. Daarna houd je het bij met monitoring.

Bij Rendar zien we dat veel organisaties met een paar gerichte ingrepen in een mum van tijd klaar zijn voor HTTPS-only, ook met WordPress en bestaande hosting. Wil je een snelle, kwalitatieve, controle van domeinen, certificaten en mixed content? Plan dan een praktische review. Je kunt ons bereiken via de contactpagina.

Begin klein, één goed ingesteld formulier is vaak het verschil tussen rust en ruis.