Braucht deine Website HTTPS? Ja – und zwar überall

Wichtig ist das Wort „vollständig“: Ein Zertifikat auf der Startseite genügt nicht. Unterseiten, Bilder, Schriften, Skripte, Formulare, Downloads, APIs und wichtige Subdomains müssen ebenfalls sicher erreichbar sein.

HTTPS beweist aber nicht, dass ein Unternehmen ehrlich ist oder eine Website frei von Schadsoftware ist. Auch eine Phishing-Seite kann ein gültiges Zertifikat besitzen. Ich würde HTTPS deshalb als Sicherheitsgurt betrachten: unverzichtbar, aber kein Ersatz für sichere Software, Updates, starke Passwörter und Backups.

Was HTTPS einfach erklärt bedeutet

HTTP ist die Sprache, mit der Browser und Webserver Daten austauschen. Bei HTTPS wird diese Verbindung mit TLS geschützt. Viele Menschen sagen noch „SSL-Zertifikat“. Gemeint ist heute normalerweise ein Zertifikat für modernes TLS; die alten SSL-Protokolle gelten als überholt.

Dabei leistet HTTPS drei Dinge:

• Vertraulichkeit: Andere im Netzwerk sollen den Inhalt nicht einfach mitlesen können.
• Unversehrtheit: Daten sollen unterwegs nicht unbemerkt verändert werden.
• Server-Zuordnung: Das Zertifikat verbindet die aufgerufene Domain mit einem kryptografischen Schlüssel.

Stell dir einen Brief in einem verschlossenen Umschlag vor, dessen Empfängeradresse geprüft wurde. Das schützt den Transport. Es sagt aber noch nichts darüber aus, ob der Empfänger gute Absichten hat.

Welche Website braucht HTTPS?

Die Antwort ist in jeder Zeile dieselbe: HTTPS gehört dazu. Nur der mögliche Schaden unterscheidet sich.

Warum „nur das Formular absichern“ nicht reicht

Früher wurden manchmal nur Login oder Bezahlseite verschlüsselt. Das ist heute keine saubere Lösung. Eine unverschlüsselte Seite kann unterwegs verändert werden. Ein Angreifer könnte zum Beispiel einen Link, ein Skript oder den Weg zum Login austauschen. Sitzungs-Cookies können ebenfalls gefährdet sein, wenn die ganze Sitzung nicht geschützt wird.

Darum empfiehlt OWASP TLS auf allen Seiten. Für eine normale öffentliche Website darf HTTP noch Anfragen annehmen, sollte sie aber sofort dauerhaft zur passenden HTTPS-Adresse weiterleiten. Bei reinen APIs ist es sicherer, unverschlüsselte Anfragen abzulehnen statt sie weiterzuleiten.

Mixed Content: Wenn das Schloss nur Fassade ist

Mixed Content entsteht, wenn die Seite selbst über HTTPS kommt, aber einzelne Dateien noch über HTTP lädt. Browser können solche Bilder automatisch auf HTTPS umstellen. Aktive Inhalte wie Skripte, Stylesheets, Webfonts oder eingebettete Frames werden häufig blockiert. Dann sieht die Seite kaputt aus oder wichtige Funktionen fallen aus.

Prüfe deshalb nicht nur die URL im Browser. Öffne auch die Entwicklerkonsole und suche nach Mixed-Content-Fehlern. Ersetze hart codierte HTTP-Adressen in Templates, CSS, Datenbankfeldern und externen Einbindungen.

Was bringt HTTPS deinem Unternehmen?

1. Schutz für Besucher und Inhalte

HTTPS schützt Daten während der Übertragung. Das betrifft nicht nur Passwörter. Auch gelesene Seiten, Suchbegriffe, Formulare, Downloads und Sitzungsdaten können etwas über eine Person oder ein Unternehmen verraten. Ohne Verschlüsselung können Daten auf dem Transportweg eingesehen oder verändert werden.

2. Keine vermeidbare Browserwarnung

Chrome kennzeichnet Verbindungen ohne HTTPS als nicht privat oder „Nicht sicher“. Ein gültiges Zertifikat verhindert diese konkrete Warnung. Es ist trotzdem kein Gütesiegel für den Inhalt. Besucher sollten weiterhin Domainname und Kontext prüfen.

3. Zugriff auf moderne Browserfunktionen

Viele leistungsfähige Webfunktionen stehen nur in einem „sicheren Kontext“ bereit. Dazu gehören etwa Service Worker, die Credential Management API und Teile der Zwischenablage- oder Gerätefunktionen. Für lokale Entwicklung gelten Ausnahmen wie localhost; für eine öffentliche Website ist HTTPS der normale Weg.

4. Eine saubere Grundlage für SEO – kein Ranking-Trick

Google verwendet HTTPS seit 2014 als Ranking-Signal. Bei konsistenter Konfiguration kann Google die HTTPS-Version als kanonische URL wählen. Daraus folgt aber kein garantierter Rankingsprung. Inhalt, Suchintention, Qualität und technische Stabilität bleiben wichtiger.

Der echte SEO-Hebel liegt in einer fehlerfreien Umstellung: Jede alte HTTP-Adresse muss direkt auf ihr HTTPS-Gegenstück führen. Canonicals, interne Links, hreflang-Angaben und XML-Sitemap dürfen nicht widersprechen. Google behandelt den Wechsel von HTTP zu HTTPS als URL-Umzug und kann die neuen Adressen vorübergehend stärker crawlen.

5. Datenschutz: wichtig, aber nicht allein ausreichend

Die DSGVO nennt in Artikel 32 Verschlüsselung als mögliche angemessene technische Maßnahme. Sie schreibt nicht mit einem einzigen Satz „jede Website muss HTTPS nutzen“. Welche Maßnahmen nötig sind, hängt vom Risiko und von der Verarbeitung ab.

Sobald personenbezogene Daten übertragen werden – etwa über Kontaktformular, Kundenkonto oder Bestellung – ist HTTPS in der Praxis meist eine naheliegende Mindestmaßnahme. HTTPS allein macht eine Website jedoch nicht DSGVO-konform. Einwilligungen, Datensparsamkeit, Auftragsverarbeitung, Zugriffsrechte und sichere Speicherung bleiben eigene Themen. Das ist eine sachliche Einordnung, keine Rechtsberatung.

Was kostet HTTPS?

Das Zertifikat selbst muss nichts kosten. Let’s Encrypt stellt kostenlose Zertifikate über das automatisierte ACME-Verfahren bereit. Viele Hosting-Anbieter beantragen und erneuern sie für ihre Kunden automatisch.

Kosten können trotzdem durch Einrichtung, Fehlersuche und laufende Überwachung entstehen. Bei einem Baukasten oder Managed Hosting ist HTTPS oft nur eine Einstellung. Bei einem eigenen Server musst du Zertifikat, Webserver, Weiterleitungen, Erneuerung und Monitoring selbst betreiben. Wenn du noch vor der Hosting-Wahl stehst, hilft unser Vergleich Website-Hosting zum Start: Was du wirklich brauchst bei der Einordnung der Betriebsverantwortung.

Website auf HTTPS umstellen: sichere Reihenfolge

1. Bestand aufnehmen

Notiere alle Hostnamen: Hauptdomain, www-Variante, Shop, Kundenportal, API, Bild- oder Download-Domain. Prüfe außerdem externe Skripte, Fonts, Videos, Zahlungswege, Webhooks und OAuth-Rücksprungadressen.

Wenn die Domain nach einer Änderung nicht am erwarteten Server landet, liegt das oft nicht am Zertifikat. Unser Guide DNS einfach erklärt: Wenn Website oder E-Mail haken hilft, Domain und Zielsystem auseinanderzuhalten.

2. Zertifikat passend ausstellen und Erneuerung automatisieren

Das Zertifikat muss alle tatsächlich genutzten Hostnamen abdecken und von gängigen Browsern akzeptiert werden. Teste die automatische Erneuerung und richte eine Warnung vor Ablauf oder Erneuerungsfehlern ein. Ein Zertifikat, das heute gültig ist, ist noch kein verlässlicher Betrieb.

3. Website und Abhängigkeiten zuerst über HTTPS testen

Stelle Seiten, Bilder, Skripte, CSS, Schriften, Formulare, Downloads und API-Aufrufe auf HTTPS um. Prüfe Login, Warenkorb, Zahlung, Suche und externe Einbettungen in einer Testumgebung, wenn das Projekt geschäftskritisch ist.

Ein CDN kann TLS am Rand beenden, doch auch die Verbindung zum Ursprungsserver muss sinnvoll geschützt und richtig eingestellt sein. Ob ein CDN überhaupt dein Problem löst, ordnet der Vergleich CDN oder schnelleres Hosting ein.

4. HTTP dauerhaft auf das genaue HTTPS-Ziel leiten

Leite jede alte Adresse serverseitig und dauerhaft auf dieselbe Seite unter HTTPS um. Eine alte Produktseite gehört also auf die neue Produktseite, nicht pauschal auf die Startseite. 301 und 308 sind dafür übliche permanente Statuscodes.

Vermeide Ketten wie HTTP → HTTPS mit www → HTTPS ohne www. Eine direkte Weiterleitung ist leichter zu prüfen und verursacht weniger Fehler. Ändere veröffentlichte Pfade nicht gleichzeitig, wenn es keinen guten Grund gibt; sonst vermischst du zwei Migrationen.

5. Alle internen Signale auf HTTPS setzen

Aktualisiere:

• interne Links und Navigation,
• Canonical-URLs und hreflang,
• XML-Sitemap und absolute Angaben in robots.txt,
• strukturierte Daten und Open-Graph-URLs,
• Bild-, CSS-, JavaScript- und Download-Adressen,
• Formulare, APIs, Webhooks und OAuth-Callbacks,
• Analyse-, Werbe- und E-Mail-Kampagnen-URLs.

Melde die HTTPS-Property in der Search Console an beziehungsweise prüfe die Domain-Property. Der HTTPS-Bericht zeigt unter anderem ungültige Zertifikate, HTTP-Canonicals und Sitemaps mit alten HTTP-Adressen.

6. Cookies und HSTS erst bewusst härten

Sitzungs-Cookies sollten das Secure-Attribut tragen, damit der Browser sie nur über HTTPS sendet. HSTS weist Browser an, die Domain künftig ausschließlich per HTTPS aufzurufen.

HSTS ist sinnvoll, aber kein erster Schalter. Teste zuerst Zertifikat, Weiterleitungen und alle benötigten Subdomains. Aktiviere includeSubDomains nur, wenn wirklich jede heutige und künftige Subdomain HTTPS kann. Ein zu aggressiver HSTS-Start kann erreichbare Seiten aussperren.

Die 5-Minuten-Abnahme: Woran erkennst du eine fertige Umstellung?

Teste nicht nur die Startseite. Nimm mindestens die Startseite, eine tiefe Inhaltsseite, ein Formular sowie Login oder Checkout, falls vorhanden.

1. Rufe jede Testadresse einmal mit http:// auf. Sie muss direkt bei der passenden https://-adresse/ landen.
2. Prüfe im Browser die Verbindungsinformationen: Domain passend, Zertifikat gültig, keine Warnung.
3. Öffne Entwicklerkonsole und Netzwerkansicht. Es dürfen keine benötigten HTTP-Ressourcen blockiert oder unsicher nachgeladen werden.
4. Prüfe Quelltext oder SEO-Tool: Canonical, hreflang, strukturierte Daten und interne Links zeigen auf HTTPS.
5. Öffne die XML-Sitemap. Indexierbare URLs stehen dort ausschließlich mit HTTPS.
6. Sende ein Testformular und führe die wichtigsten Abläufe durch. Ein grüner Browserstatus hilft nicht, wenn Zahlung oder Login kaputt sind.
7. Prüfe nach dem Start Search Console, Serverfehler und Weiterleitungen. Beobachte auch, ob alte HTTP-URLs noch intern verlinkt werden.

Mein praktischer Abnahmesatz für Agenturen lautet: „Eine repräsentative Stichprobe leitet in genau einem Schritt auf dieselbe HTTPS-Seite, lädt ohne Mixed Content, nennt HTTPS als Canonical und besteht die wichtigsten Geschäftsabläufe.“ Dieser Satz ist messbarer als „SSL wurde installiert“.

Häufige Fehler und ihre Ursache

„HTTPS funktioniert, aber manche Bilder fehlen“

Meist laden Bild, Schrift, Stylesheet oder Skript noch über HTTP. Suche in Browserkonsole, Quellcode, CSS und Inhaltsdatenbank nach alten Adressen. Verlasse dich nicht darauf, dass der Browser alles automatisch repariert.

„Die Website hängt in einer Weiterleitungsschleife“

Oft widersprechen sich Webserver, CMS, Proxy oder CDN darüber, ob die ursprüngliche Anfrage schon per HTTPS kam. Prüfe die Zuständigkeit jeder Schicht und die weitergereichten Protokoll-Header. Schalte Regeln nicht blind mehrfach ein.

„Das Zertifikat ist gültig, aber nur ohne www“

Dann deckt das Zertifikat nicht alle aufgerufenen Hostnamen ab oder ein Host zeigt auf das falsche System. Entscheide, welche Variante die Hauptadresse ist, sichere beide erreichbaren Varianten ab und leite die Nebenvariante direkt weiter.

„Nach der Umstellung sinkt der Suchtraffic“

Kurze Schwankungen sind bei einem URL-Umzug möglich. Prüfe zuerst harte Fehler: falsche oder fehlende Weiterleitungen, HTTP-Canonicals, blockierte HTTPS-Seiten, alte Sitemap, 404-Fehler und Redirect-Ketten. HTTPS wieder abzuschalten wäre meist die falsche Reaktion.

Häufige Fragen

Reicht HTTPS nur für Login und Kontaktformular?

Nein. Die ganze Sitzung und alle Seiten sollten geschützt sein. Sonst bleiben Umleitungen, Cookies und unverschlüsselte Seitenteile angreifbar.

Braucht eine rein statische Website HTTPS?

Ja. Auch eine statische Seite kann unterwegs verändert werden, verrät aufgerufene Inhalte und kann ohne sicheren Kontext Browserfunktionen verlieren. Außerdem warnen Browser bei ungeschützten Verbindungen.

Ist ein kostenloses Zertifikat weniger sicher?

Nicht allein wegen des Preises. Entscheidend sind eine vertrauenswürdige Zertifizierungsstelle, passende Domainnamen, sichere Serverkonfiguration und zuverlässige Erneuerung. Ein teures Zertifikat repariert keine schlechte Konfiguration.

Ist HTTPS dasselbe wie eine sichere Website?

Nein. HTTPS schützt den Transport. Es verhindert weder Phishing noch unsicheren Code, schwache Passwörter, gestohlene Administratorkonten oder Datenlecks auf dem Server.

Muss jede Subdomain HTTPS haben?

Jede öffentlich genutzte Subdomain sollte sicher erreichbar sein. Besonders vor HSTS mit includeSubDomains musst du auch alte, seltene und von Drittanbietern betriebene Subdomains prüfen.

Fazit: Ja, überall – aber überprüfbar

Eine Website braucht heute HTTPS auf jeder öffentlich erreichbaren Seite. Der Nutzen beginnt bei Schutz und Browserkompatibilität; SEO ist ein zusätzlicher, aber kein magischer Effekt.

Ich halte die Zertifikatsinstallation für den kleinsten Teil der Aufgabe. Wirklich fertig ist die Umstellung erst, wenn Weiterleitungen, Ressourcen, Canonicals, Sitemap, Formulare, Cookies, Erneuerung und Monitoring zusammenpassen. Nutze die 5-Minuten-Abnahme als klare Grenze zwischen „HTTPS eingeschaltet“ und „HTTPS sauber betrieben“.