Een website zonder SSL lijkt op het eerste gezicht vaak “gewoon te werken”, totdat bezoekers waarschuwingen in hun browser zien, formulieren minder goed converteren of je merkt dat bepaalde functionaliteit niet meer lekker samenwerkt met moderne webstandaarden. SSL, in de praktijk vrijwel altijd TLS genoemd, is de techniek die het verkeer tussen de browser van je bezoeker en jouw website versleutelt en de identiteit van je domein helpt bevestigen. Zonder die versleuteling is data onderweg in principe af te luisteren of te manipuleren, en dat risico wil je als organisatie, webshop, vereniging of dienstverlener simpelweg niet nemen.
In dit artikel leggen we uit wat het concreet betekent om een website zonder SSL te draaien, waarom dat anno nu bijna altijd een slecht idee is, wat de impact is op security, SEO en vertrouwen, en hoe je het oplost. Ook gaan we in op een praktische route binnen Plesk, omdat we in de praktijk zien dat veel websites daar worden beheerd. We houden het helder en toepasbaar, zonder onnodige complexiteit.
Wat betekent een website zonder SSL precies?
Met “SSL” bedoelen mensen meestal het ontbreken van HTTPS. HTTPS is HTTP over TLS: de versleutelde variant van het webprotocol waarmee pagina’s, afbeeldingen, scripts en formulieren worden geladen. Een website zonder SSL draait dus via http:// in plaats van https://.
Het gevolg is dat het verkeer tussen bezoeker en server niet end to end versleuteld is. Dat betekent niet alleen dat gevoelige gegevens zoals inloggegevens of formulierdata onderschept kunnen worden, maar ook dat de inhoud onderweg aangepast kan worden. Denk aan het injecteren van ongewenste advertenties of het manipuleren van een downloadlink, afhankelijk van het netwerk waar je bezoeker zich bevindt.
SSL en TLS: korte uitleg in gewone taal
SSL is de oude term. TLS is de moderne opvolger en de standaard die browsers en servers gebruiken. In de praktijk blijft “SSL-certificaat” de gangbare naam, ook als het technisch gezien om TLS gaat. Het certificaat is een digitaal bewijsstuk dat bij jouw domeinnaam hoort en waarmee de browser kan controleren of hij echt met jouw server praat.
Waarom een website zonder SSL vandaag bijna altijd problemen geeft
Waar HTTPS vroeger vooral “voor webshops” was, is het nu de norm voor vrijwel iedere website, ook als je “alleen maar informatie” publiceert. Een website zonder SSL loopt tegen een combinatie aan van security risico’s, browsergedrag en verwachtingen van bezoekers.
1) Beveiliging: afluisteren en manipulatie van verkeer
Op een website zonder SSL kan verkeer in theorie worden onderschept op wifi-netwerken, op bedrijfsnetwerken, in hotels, of onderweg bij tussenliggende knooppunten. Zelfs als je geen betaalgegevens verwerkt, zijn er vaak nog steeds gegevens die je liever niet “open” verzendt, zoals e-mailadressen in formulieren, interne zoekopdrachten of sessiecookies.
Bovendien gaat het niet alleen om afluisteren. Zonder TLS is er ook minder bescherming tegen het aanpassen van content onderweg. Dat is extra relevant bij websites die scripts laden, bijvoorbeeld voor analytics, chatwidgets of formulieren.
2) Vertrouwen: browserwaarschuwingen en afhakers
Moderne browsers maken het duidelijk wanneer een site geen HTTPS gebruikt. Zeker zodra je een formulier toont (contact, offerte, login), kan een browser aangeven dat de verbinding “niet beveiligd” is. Bezoekers zijn dan sneller weg, en terecht. Je kunt nog zo’n mooie dienst hebben, maar als de eerste indruk een waarschuwing is, verlies je vertrouwen voordat je inhoud gezien wordt.
3) SEO en performance: HTTPS is de basis voor moderne webstandaarden
Zoekmachines en browsers sturen al jaren aan op “secure by default”. HTTPS is een lichte rankingfactor en vooral een randvoorwaarde voor een goede gebruikerservaring. Daarnaast werken diverse moderne browserfeatures en performance-optimalisaties beter of uitsluitend goed via een beveiligde context (HTTPS). Daarmee wordt een website zonder SSL indirect ook een rem op technische optimalisatie.
Voor achtergrond over het belang van encryptie in transport en hoe TLS-certificate issuance werkt, is de documentatie van Let’s Encrypt een nuttige, betrouwbare bron: How Let’s Encrypt works.
Risico’s van een website zonder SSL: praktisch uitgelegd
Het helpt om de risico’s concreet te maken. Hieronder staan situaties die we in de praktijk regelmatig tegenkomen.
Formulieren en loginpagina’s
Een contactformulier zonder HTTPS kan e-mailadressen, telefoonnummers en berichten in leesbare tekst over het netwerk sturen. Bij een login geldt dat nog sterker: gebruikersnaam en wachtwoord kunnen onderschept worden. Ook als je “maar één beheeraccount” hebt, kan dat account vervolgens gebruikt worden om je website te wijzigen of malware te plaatsen.
Sessies en cookies
Veel websites gebruiken cookies voor sessiebeheer, bijvoorbeeld om ingelogd te blijven. Zonder TLS kunnen sessiecookies makkelijker worden buitgemaakt, waarna een aanvaller sessies kan overnemen. Dat is vooral relevant bij CMS’en zoals WordPress, Joomla of Drupal, maar geldt net zo goed voor maatwerkapplicaties.
Integraties en externe scripts
Een website zonder SSL kan tegen “mixed content” problemen aanlopen zodra je wél HTTPS probeert te gebruiken maar nog onderdelen via HTTP laadt. Browsers blokkeren steeds vaker onveilige onderdelen, waardoor pagina’s breken of bepaalde scripts niet meer werken. Dat kan subtiel zijn, bijvoorbeeld een formulier dat niet meer verstuurt of een tracking script dat niet meer laadt.
Hoe los je een website zonder SSL op?
De oplossing bestaat bijna altijd uit drie onderdelen:
- Een SSL certificaat regelen en installeren op je hostingomgeving.
- Zorgen dat je website via HTTPS wordt aangeboden.
- Controleren of alles goed werkt: redirects, mixed content, en externe koppelingen.
Afhankelijk van je platform en controlpanel verschilt de uitvoering. Hieronder geven we vooral richting, en we lichten één praktisch pad toe dat veel voorkomt: certificaatinstallatie in Plesk.
Stap 1: Kies het juiste type certificaat
Voor veel websites is een domeinvalidatiecertificaat (DV) voldoende: het bevestigt dat jij controle hebt over het domein. Voor organisaties die extra zichtbaarheid of validatie willen, bestaan er uitgebreidere varianten. Welke je nodig hebt hangt af van je use case, governance-eisen en hoe je bezoekers je merk laten vertrouwen.
Wil je je oriënteren op mogelijkheden en toepassingen, bekijk dan onze pagina over SSL certificaten. Dat helpt om een keuze te maken die past bij je domeinstructuur en scenario, zoals één domein, meerdere subdomeinen of meerdere domeinen.
Stap 2: Installeer het certificaat op je hosting
Gebruik je Plesk, dan kun je een certificaat installeren via de SSL/TLS certificaten sectie en het daarna koppelen aan je hostinginstellingen. In hoofdlijnen komt het erop neer dat je inlogt op Plesk, naar SSL/TLS Certificates gaat, een certificaatnaam kiest, de certificaatbestanden uploadt (certificaat en CA root, en de private key als die niet al aanwezig is), en vervolgens bij Hosting Settings SSL/TLS support inschakelt en het juiste certificaat selecteert.
Belangrijk hierbij is dat de private key bij het certificaat hoort. Als die niet klopt of ontbreekt, werkt het certificaat niet en krijg je browserfouten. In dat geval is het verstandiger om dit gecontroleerd op te pakken in plaats van te “proberen tot het werkt”, omdat je anders makkelijk in een mismatch of onvolledige chain terechtkomt.
Stap 3: Zorg dat alles echt via HTTPS gaat
Een certificaat installeren is stap één, maar je wilt ook dat bezoekers automatisch op de veilige variant landen. Vaak betekent dat dat je HTTP verkeer doorstuurt naar HTTPS. Daarnaast wil je nagaan of je website geen content meer via http:// laadt, want dat veroorzaakt mixed content meldingen.
Test bij voorkeur op een paar niveaus: de homepage, een pagina met formulieren, en een paar pagina’s die scripts en afbeeldingen laden. Controleer ook of je canonical tags, sitemaps en interne links netjes naar HTTPS wijzen. Dit soort details maakt het verschil tussen “HTTPS werkt” en “HTTPS werkt goed en stabiel”.
Website zonder SSL en hosting: waar moet je op letten?
Een certificaat is één onderdeel. De hostingomgeving en het beheer bepalen hoe soepel dit blijft draaien, zeker als je meerdere sites, omgevingen of klanten beheert. Een paar punten die we belangrijk vinden om mee te nemen:
Beheerbaarheid en herhaalbaarheid
Als je één keer een website zonder SSL oplost, wil je niet dat je over drie maanden weer handmatig dezelfde acties moet doen. Zeker in een omgeving met meerdere domeinen is het belangrijk dat je proces herhaalbaar is en dat vernieuwingen niet “vergeten” worden. Denk aan eigenaarschap: wie bewaakt dit en wie grijpt in bij foutmeldingen?
Schaalbaarheid en continuïteit
Heb je groei in verkeer, meerdere applicaties, of bedrijfskritische e-mail en web? Dan wil je een hostingfundament dat meegroeit. In veel gevallen is Cloud Hosting dan de logische richting, omdat je hiermee makkelijker kunt schalen en beheren, zonder telkens een migratie “omdat de server vol zit”.
Wil je kijken welke hostingvorm past bij je website en beheerwensen, bekijk dan onze pagina over webhosting en hosting voor websites. Het helpt om de juiste basis te kiezen, zeker als je niet alleen HTTPS wilt, maar ook stabiele performance en voorspelbaar beheer.
Monitoring en signalering
Veel problemen met certificaten komen niet door “installatie”, maar door verlopen certificaten, ontbrekende intermediate certificaten of wijzigingen in de site waardoor mixed content terugkomt. Goede monitoring en periodieke checks voorkomen dat bezoekers de eerste zijn die een fout ontdekken.
Praktische signalen dat je nog (deels) een website zonder SSL hebt
Soms is de migratie “half” gedaan. Dan staat er wel een certificaat, maar is de ervaring voor bezoekers nog niet overal veilig. Let op deze signalen:
- De browser toont “Niet beveiligd” op sommige pagina’s, maar niet op allemaal.
- Je ziet waarschuwingen over mixed content in de browserconsole.
- Formulieren werken niet goed na de overstap naar HTTPS.
- Externe embeds, afbeeldingen of scripts laden niet meer.
- Je analytics tonen ineens dubbele URL-varianten (http en https) of dalende conversie.
Een goede aanpak is om eerst te zorgen dat HTTPS technisch correct is (certificaat en koppeling), en daarna door te pakken op consistentie: redirects, interne links, assets en SEO-signalen.
Compliance en beleid: waarom “alleen maar een informatiesite” niet opgaat
Ook wanneer je geen betalingen verwerkt, verwerk je vaak persoonsgegevens: via contactformulieren, nieuwsbriefinschrijvingen, analytics of embedded tools. Encryptie in transport is dan een basismaatregel. Daarnaast zien we dat steeds meer organisaties interne security-eisen hanteren: geen uitzonderingen meer voor “kleine” sites, omdat het risico op reputatieschade of misbruik niet in verhouding staat tot de relatief eenvoudige oplossing.
Voor algemene securityrichtlijnen en best practices in Nederland is het NCSC een relevante autoriteit. Hun informatie over basismaatregelen en weerbaarheid is een nuttige leidraad: NCSC.
Veelgemaakte fouten bij het oplossen van een website zonder SSL
Dit zijn de valkuilen die we het vaakst zien, inclusief wat je eraan kunt doen.
Alleen het certificaat plaatsen, maar geen HTTPS afdwingen
Als beide varianten bereikbaar blijven, blijven bezoekers en bots de oude HTTP links vinden. Dat kan leiden tot inconsistentie in indexatie en tracking. Daarnaast blijven sommige bezoekers onbewust onversleuteld browsen, zeker als ze een oude bookmark hebben.
Onvolledige certificaatketen (chain)
Bij het installeren hoort vaak ook een CA root of intermediate certificaat. Als die ontbreekt, kunnen sommige clients het certificaat niet valideren, met foutmeldingen als gevolg. Dit zie je soms pas in specifieke browsers, oudere devices of bepaalde bedrijfsnetwerken.
Mixed content niet oplossen
Een pagina kan prima via HTTPS laden, maar alsnog onveilig zijn als afbeeldingen, scripts of fonts via HTTP worden ingeladen. Browsers worden hier strenger in en blokkeren steeds vaker “actieve content” zoals scripts. Daardoor kun je functionele problemen krijgen die niet direct als “SSL-probleem” aanvoelen.
Verkeerde domeinvarianten vergeten
Denk aan www versus non-www, subdomeinen, en alternatieve domeinen die naar dezelfde site wijzen. Als je één variant vergeet, blijven er gaten in de configuratie. Dat merk je vaak pas als iemand via een oude link binnenkomt.
Veelgestelde vragen over website zonder SSL
1) Is een website zonder SSL verboden?
Er is niet één simpele regel die zegt dat het altijd “verboden” is, maar in veel situaties is het wel onverstandig en moeilijk te verdedigen. Zodra je persoonsgegevens verwerkt via formulieren, accounts of tracking, is versleuteling een logische basismaatregel. Ook los van regelgeving verwachten browsers en bezoekers tegenwoordig HTTPS, waardoor je zonder SSL al snel tegen praktische problemen aanloopt.
2) Heeft een website zonder SSL altijd invloed op SEO?
Indirect bijna altijd. HTTPS is een licht signaal voor zoekmachines, maar belangrijker is het effect op gebruikerservaring en vertrouwen. Als bezoekers afhaken door waarschuwingen of als pagina’s door mixed content deels niet werken, zie je dat terug in engagement en conversies, wat je organische prestaties uiteindelijk kan raken.
3) Kan ik een website zonder SSL laten draaien als ik geen formulieren heb?
Technisch kan het, maar het blijft risicovol. Ook zonder formulieren kunnen bezoekersgedrag, sessies of analytics data onversleuteld verstuurd worden, en content kan onderweg aangepast worden. Bovendien kan je situatie veranderen: een contactformulier, chat of klantportaal is vaak een latere toevoeging, en dan loop je alsnog achter de feiten aan.
4) Wat is het verschil tussen een SSL certificaat en HTTPS?
Het certificaat is een onderdeel van de beveiligde verbinding: het helpt bij identificatie en het opzetten van encryptie. HTTPS is het protocol waarmee de website vervolgens beveiligd wordt aangeboden. Je kunt een certificaat hebben, maar als je website nog steeds via HTTP bereikbaar is en niet doorstuurt naar HTTPS, dan ben je nog niet “klaar”.
5) Ik heb HTTPS aangezet, maar ik krijg nog waarschuwingen. Hoe kan dat?
Dat is vaak mixed content: de pagina zelf komt via HTTPS, maar onderdelen zoals afbeeldingen, scripts of stylesheets worden nog via HTTP geladen. Browsers laten dat soms zien als een waarschuwing of blokkeren onderdelen, waardoor functies kapot lijken. Het oplossen vraagt meestal om het nalopen van je thema, templates, CMS-instellingen en hardcoded links, en daarna opnieuw testen.
6) Hoe pak ik dit aan in Plesk zonder in details te verdwalen?
Houd het bij de kern: certificaat uploaden, SSL/TLS support inschakelen en het juiste certificaat selecteren in de hostinginstellingen. Let extra op de private key en de CA chain, omdat fouten daar veel browsermeldingen veroorzaken. Als je twijfelt of de juiste bestanden bij elkaar horen, is het verstandig om dit gecontroleerd te laten verifiëren voordat je live gaat.
Van website zonder SSL naar netjes en toekomstbestendig
Een website zonder SSL is in 2026 vooral een onnodig risico: voor je bezoekers, je conversie, je reputatie en de technische doorontwikkeling van je website. Het goede nieuws is dat de oplossing meestal overzichtelijk is, zeker als je gestructureerd werkt: certificaat op orde, HTTPS consistent maken, en daarna alles nalopen op mixed content en redirects.
Wil je dat we met je meekijken naar jouw situatie, of wil je dit in één keer goed en beheersbaar inrichten? Neem contact met ons op. We leggen je helder uit wat er nodig is, helpen je bij de juiste keuze rond certificaten en hosting, en ondersteunen waar het technisch even precies moet. Zo maak je de stap weg van een website zonder SSL zonder gedoe, en met een resultaat dat je kunt blijven vertrouwen.
