HTTPS schützt die Verbindung zwischen Besuchern und einer Website. Trotzdem reicht ein gültiges Zertifikat allein nicht aus: Weiterleitungen, gemischte Inhalte, fehlerhafte Verweise oder abgelaufene Zertifikate können dazu führen, dass Browser Warnungen anzeigen oder Suchmaschinen wichtige Seiten nicht zuverlässig erreichen. Dieser Ratgeber zeigt, wie Sie HTTPS systematisch prüfen, typische Fehler einordnen und Korrekturen sauber umsetzen.
Was HTTPS tatsächlich absichert
HTTPS basiert auf TLS, einem Verschlüsselungsprotokoll für die Datenübertragung zwischen Browser und Webserver. Beim Aufruf einer HTTPS-Adresse prüft der Browser unter anderem, ob das Zertifikat zur Domain gehört, von einer vertrauenswürdigen Zertifizierungsstelle stammt und noch gültig ist. Ist die Prüfung erfolgreich, werden die übertragenen Daten gegen das einfache Mitlesen auf dem Transportweg geschützt.
HTTPS beweist jedoch nicht, dass der Betreiber einer Website seriös ist oder dass die Inhalte korrekt sind. Auch die Sicherheit des Servers, des Content-Management-Systems und der eingesetzten Erweiterungen wird dadurch nicht automatisch gewährleistet. HTTPS ist deshalb eine wichtige technische Grundlage, aber kein vollständiges Sicherheitskonzept.
Die wichtigsten Prüfbereiche im Überblick

Die Darstellung macht deutlich, dass eine Prüfung mehrere Ebenen umfasst: die aufgerufene Adresse, das Zertifikat und mögliche Meldungen in der Konsole. So lässt sich schneller unterscheiden, ob ein Verbindungs- oder ein Ressourcenproblem vorliegt.
Eine zuverlässige Prüfung betrachtet mehrere Ebenen. Prüfen Sie nicht nur die Startseite, sondern auch typische Unterseiten, Formulare und technische Dateien.
- Erreichbarkeit: Lädt die Website unter HTTPS ohne Browserwarnung?
- Zertifikat: Passt es zur Domain, ist es gültig und wird die Zertifikatskette akzeptiert?
- Weiterleitungen: Wird HTTP eindeutig und dauerhaft auf HTTPS umgeleitet?
- Interne Verweise: Verwenden Links, Bilder, Stylesheets und Skripte die HTTPS-Adresse?
- Technische Signale: Stimmen Canonical-URLs, Sitemap, Robots-Datei und strukturierte Daten?
- Formulare und Ressourcen: Werden Eingaben und eingebundene Inhalte sicher über HTTPS geladen?
Die Bereiche hängen zusammen. Eine Website kann beispielsweise ein gültiges Zertifikat besitzen und trotzdem wegen gemischter Inhalte oder einer fehlerhaften Weiterleitung problematisch wirken.
HTTPS prüfen: Eine praktische Schritt-für-Schritt-Anleitung
1. Mehrere URL-Varianten aufrufen
Rufen Sie zunächst die wichtigsten Varianten der Domain auf: die HTTP-Adresse, die HTTPS-Adresse sowie – falls relevant – die Version mit und ohne www. Idealerweise führt nur eine bevorzugte Variante direkt zum Inhalt. Alle anderen Varianten sollten mit einer dauerhaften Weiterleitung auf die kanonische HTTPS-Adresse verweisen.
Prüfen Sie zusätzlich einige typische Unterseiten, zum Beispiel einen Beitrag, eine Produktseite, eine Kontaktseite und eine nicht mehr vorhandene URL. So erkennen Sie, ob die Weiterleitungslogik nur auf der Startseite funktioniert oder für die gesamte Website konsistent eingerichtet ist.
2. Browserwarnungen genau lesen
Das Schloss-Symbol im Browser ist ein erster Hinweis, ersetzt aber keine genaue Diagnose. Klicken Sie auf die Verbindungsinformationen und sehen Sie sich Zertifikat, Gültigkeitszeitraum und ausstellende Stelle an. Moderne Browser formulieren Warnungen unterschiedlich; entscheidend ist die konkrete Ursache.
Häufige Hinweise betreffen ein abgelaufenes Zertifikat, einen nicht passenden Domainnamen oder eine nicht vertrauenswürdige Zertifikatskette. Auch eine falsch eingestellte Serverzeit kann zu einer scheinbaren Gültigkeitsabweichung führen. Ignorieren Sie Sicherheitswarnungen nicht dauerhaft, sondern klären Sie die Ursache vor der Veröffentlichung oder Weiterleitung an Besucher.
3. Zertifikat und Zertifikatskette kontrollieren
Ein Zertifikat muss alle relevanten Hostnamen abdecken. Wenn die Website sowohl unter der Hauptdomain als auch unter einer Subdomain erreichbar ist, ist zu prüfen, ob jede tatsächlich verwendete Adresse abgesichert ist. Das betrifft auch spezielle Subdomains für Bilder, Downloads oder APIs.
Die Zertifikatskette besteht aus dem Serverzertifikat und den erforderlichen Zwischenzertifikaten. Fehlt ein Zwischenzertifikat, können manche Browser oder ältere Systeme die Verbindung ablehnen, obwohl das Zertifikat auf dem Server zunächst korrekt aussieht. Lassen Sie die Serverkonfiguration durch die zuständige Hosting- oder Administrationsperson prüfen, wenn die Kette unvollständig erscheint.
4. HTTP-zu-HTTPS-Weiterleitungen testen
Geben Sie eine HTTP-URL direkt in den Browser ein und beobachten Sie, wohin sie führt. Die Weiterleitung sollte möglichst ohne unnötige Zwischenschritte bei der endgültigen HTTPS-URL ankommen. Eine dauerhafte Weiterleitung signalisiert, dass die alte Adresse nicht mehr die bevorzugte Variante ist.
Prüfen Sie auch URLs mit Pfaden, Parametern und Dateiendungen. Eine Regel, die nur die Startseite berücksichtigt, kann Unterseiten auf HTTP belassen oder in eine falsche Zieladresse schicken. Achten Sie außerdem auf Weiterleitungsketten und Schleifen. Eine Kette aus mehreren Weiterleitungen verlängert den Aufruf und erschwert die Fehlersuche; eine Schleife macht die Seite unerreichbar.
5. Gemischte Inhalte aufspüren
Von gemischten Inhalten spricht man, wenn eine HTTPS-Seite Ressourcen weiterhin über HTTP lädt. Betroffen sein können Bilder, CSS-Dateien, JavaScript, Schriftarten, Videos, iframes oder externe Schnittstellen. Aktive Inhalte wie Skripte werden von Browsern häufig blockiert, während passive Inhalte je nach Browser verändert, blockiert oder mit einer Warnung geladen werden können.
Öffnen Sie die Entwicklerwerkzeuge des Browsers und prüfen Sie die Konsole. Dort werden blockierte oder unsichere Ressourcen meist mit ihrer URL genannt. Suchen Sie außerdem im Quelltext, in den Theme-Dateien und in den Einstellungen des Content-Management-Systems nach absoluten http://-Verweisen.
Ersetzen Sie eigene Ressourcen durch HTTPS-URLs. Bei externen Diensten müssen Sie klären, ob der Anbieter eine sichere Adresse bereitstellt. Wenn nicht, sollte die Ressource möglichst entfernt oder durch eine sichere Alternative ersetzt werden. Ein pauschales Ersetzen ohne Prüfung kann jedoch Funktionen beschädigen, insbesondere bei APIs oder eingebundenen Zahlungs- und Analysekomponenten.
6. Formulare und externe Dienste kontrollieren
Formulare sollten über HTTPS angezeigt und an eine HTTPS-Adresse gesendet werden. Prüfen Sie dies besonders bei Login-, Kontakt-, Newsletter- und Zahlungsprozessen. Achten Sie auch auf Fehlermeldungen, Weiterleitungen nach dem Absenden und die Darstellung in einem privaten Browserfenster.
Externe Dienste wie Schriften, Karten, Videos, Chats oder Analysewerkzeuge können zusätzliche Verbindungsprobleme verursachen. Dokumentieren Sie, welche Drittanbieter eingebunden sind, und prüfen Sie deren aktuelle HTTPS-Unterstützung. Neben der technischen Sicherheit können für solche Einbindungen weitere Datenschutzanforderungen gelten; die technische Prüfung ersetzt keine rechtliche Bewertung.
Typische HTTPS-Fehler und ihre Lösungen
Das Zertifikat ist abgelaufen
Ein abgelaufenes Zertifikat führt zu einer deutlichen Browserwarnung. Prüfen Sie zuerst, ob die automatische Verlängerung aktiv ist und ob der zuständige Dienst die erforderlichen DNS- oder Serverzugriffe besitzt. Nach der Erneuerung muss das neue Zertifikat auf dem tatsächlich verwendeten Server installiert werden. Bei mehreren Servern oder einem CDN ist zu kontrollieren, ob alle relevanten Endpunkte aktualisiert wurden.
Planen Sie Erinnerungen und eine Überwachung des Ablaufdatums ein. Verlassen Sie sich nicht ausschließlich auf eine einzelne E-Mail, da Nachrichten verloren gehen oder an eine ehemalige Kontaktadresse gesendet werden können.
Der Domainname passt nicht zum Zertifikat
Ein Namensfehler entsteht, wenn die aufgerufene Adresse nicht in den gültigen Namen des Zertifikats aufgenommen wurde. Das kann die www-Variante, eine Subdomain oder eine falsch geschriebene Domain betreffen. Korrigieren Sie entweder die Serverzuordnung oder stellen Sie ein Zertifikat bereit, das alle tatsächlich benötigten Namen abdeckt.
Die Weiterleitung erzeugt eine Schleife
Eine Weiterleitungsschleife entsteht häufig, wenn Webserver, Content-Management-System und Reverse Proxy unterschiedliche Informationen über das verwendete Protokoll erhalten. Der vorgeschaltete Dienst erkennt HTTPS, der interne Server glaubt jedoch, die Anfrage sei HTTP, und leitet sie erneut um.
Prüfen Sie die Weiterleitungsregeln an jeder Schicht und klären Sie, wie der Proxy das ursprüngliche Protokoll weitergibt. Ändern Sie Konfigurationen schrittweise und testen Sie danach Startseite, Unterseiten und Administrationsbereich. Bei verwalteten Hosting-Angeboten sollte die technische Unterstützung des Anbieters einbezogen werden.
Interne Links verweisen weiterhin auf HTTP
Alte absolute URLs können in Menüs, Beiträgen, Widgets, Datenbankfeldern oder Vorlagen gespeichert sein. Aktualisieren Sie zunächst die Basis-URL des Systems. Suchen und ersetzen Sie anschließend kontrolliert weitere interne HTTP-Verweise. Erstellen Sie vorher eine Sicherung und vermeiden Sie ungetestete Massenänderungen an serialisierten Daten, da diese Datenstrukturen beschädigen können.
Relative URLs können die Wartung vereinfachen, sind aber nicht in jeder Umgebung die beste Lösung. Entscheidend ist, dass alle öffentlich erreichbaren Seiten dauerhaft auf der bevorzugten HTTPS-Adresse verlinken.
Eine Ressource wird blockiert
Wenn CSS oder JavaScript blockiert wird, kann sich das Layout verändern oder eine Funktion ausfallen. Ermitteln Sie die genaue Ressource in der Browserkonsole. Prüfen Sie dann, ob sie intern aktualisiert, beim Drittanbieter sicher eingebunden oder entfernt werden kann. Nach der Korrektur sollten Sie Cache-Einstellungen, Content-Delivery-Netzwerke und minimierte Dateien berücksichtigen, damit nicht weiter eine alte Version ausgeliefert wird.
HTTPS und SEO: Was nach der Umstellung wichtig ist
Eine HTTPS-Umstellung sollte wie eine technische URL-Änderung behandelt werden. Suchmaschinen müssen erkennen, welche URL die bevorzugte Version ist. Achten Sie deshalb auf dauerhafte Weiterleitungen von HTTP zu HTTPS, konsistente Canonical-Tags und interne Links.
- Die XML-Sitemap sollte ausschließlich die bevorzugten HTTPS-URLs enthalten.
- Die Robots-Datei darf wichtige HTTPS-Seiten und Ressourcen nicht versehentlich blockieren.
- Canonical-Tags sollten nicht auf HTTP-Versionen zeigen.
- Strukturierte Daten, Open-Graph-Angaben und hreflang-Verweise sollten die richtigen Protokolle verwenden.
- In Analyse- und Webmaster-Werkzeugen sollten die relevanten HTTPS-Propertys geprüft werden.
Überarbeiten Sie nicht gleichzeitig viele andere URL-Strukturen, wenn es sich vermeiden lässt. Eine klar abgegrenzte Umstellung erleichtert die Zuordnung möglicher Crawling- oder Indexierungsprobleme. Beobachten Sie nach Änderungen die Serverprotokolle, den Indexierungsstatus und wichtige Zielseiten.
Werkzeuge für eine gründliche Prüfung
Für eine erste Kontrolle genügen oft Browser und Entwicklerwerkzeuge. Für umfangreichere Websites helfen zusätzliche Werkzeuge, die viele URLs automatisiert untersuchen. Nutzen Sie nur Dienste, deren Datenschutz- und Zugriffsbedingungen zu Ihrem Projekt passen.
- Browser und Entwicklerwerkzeuge: Sie zeigen Zertifikatsinformationen, Konsolenfehler und blockierte Ressourcen.
- HTTP-Header-Prüfung: Sie hilft bei der Kontrolle von Statuscodes, Weiterleitungen und wichtigen Sicherheits-Headern.
- Crawler: Sie finden interne HTTP-Links, Weiterleitungsketten, Canonical-Widersprüche und fehlerhafte Zielseiten.
- Serverprotokolle: Sie zeigen, welche URLs und Ressourcen tatsächlich angefordert werden.
- Zertifikatsüberwachung: Sie erinnert an bevorstehende Abläufe und kann mehrere Hostnamen beobachten.
Automatisierte Prüfer liefern Hinweise, aber keine vollständige Bewertung. Ein Werkzeug kann beispielsweise einen HTTP-Verweis finden, ohne zu wissen, ob der externe Dienst bewusst so eingebunden wurde. Bewerten Sie jeden Befund im Kontext der Website und testen Sie Änderungen anschließend praktisch.
Zusätzliche Sicherheitsmaßnahmen mit Augenmaß
Nach der grundlegenden Umstellung können weitere Maßnahmen sinnvoll sein. Der Header Strict-Transport-Security weist Browser an, eine Domain für einen festgelegten Zeitraum nur über HTTPS aufzurufen. Aktivieren Sie ihn erst, wenn alle erforderlichen Subdomains und Anwendungsfälle zuverlässig über HTTPS funktionieren. Eine zu aggressive Einstellung kann sonst den Zugriff auf vergessene oder noch nicht vorbereitete Subdomains erschweren.
Optionen wie die Einbeziehung aller Subdomains oder eine Aufnahme in eine spezielle Browserliste sollten daher bewusst geplant werden. Testen Sie die Auswirkungen zunächst in einer kontrollierten Umgebung und dokumentieren Sie, wer die Konfiguration zurücknehmen kann.
Weitere Sicherheits-Header können je nach Website sinnvoll sein. Sie gehören jedoch in ein abgestimmtes Sicherheitskonzept und sollten nicht blind aus Vorlagen übernommen werden. Prüfen Sie immer, ob sie mit eingebundenen Diensten, Inhaltsrichtlinien und den Funktionen Ihrer Website kompatibel sind.
Prüfplan für laufenden Betrieb und Relaunches
HTTPS ist keine einmalige Aufgabe. Zertifikate laufen ab, Hosting-Strukturen ändern sich und neue Erweiterungen können unsichere Ressourcen einführen. Legen Sie deshalb einen wiederkehrenden Prüfplan fest.
- Überwachen Sie Zertifikatsabläufe und prüfen Sie die automatische Erneuerung.
- Testen Sie wichtige Seiten nach Updates des CMS, Themes, Servers oder CDN.
- Überprüfen Sie regelmäßig Startseite, Login, Formulare, Medien und zentrale Conversion-Seiten.
- Scannen Sie interne Verweise nach HTTP-Adressen und unerwarteten Weiterleitungsketten.
- Kontrollieren Sie Sitemap, Canonical-Tags und Robots-Datei nach größeren Änderungen.
- Dokumentieren Sie Befund, Ursache, Änderung und abschließenden Test.
Bei einem Relaunch sollte die HTTPS-Prüfung Bestandteil der Abnahme sein. Erstellen Sie eine Liste wichtiger alter URLs und vergleichen Sie deren erwartete Ziele mit den tatsächlichen Antworten. Prüfen Sie außerdem, ob stagingbezogene Einstellungen oder Testdomains versehentlich in die Live-Umgebung gelangt sind.
FAQ
Woran erkenne ich, ob eine Website korrekt über HTTPS läuft?
Rufen Sie die endgültige HTTPS-Adresse auf und prüfen Sie, ob der Browser keine Sicherheitswarnung ausgibt. Testen Sie zusätzlich einige Unterseiten, Formulare und Ressourcen. Eine korrekte Verbindung allein reicht nicht aus, wenn interne Inhalte weiterhin über HTTP geladen werden.
Reicht ein gültiges SSL-Zertifikat für eine sichere Website?
Nein. Das Zertifikat schützt die Verbindung und bestätigt die Zuordnung zur Domain, sagt aber nichts über die Sicherheit des Servers, des CMS oder der Inhalte aus. Auch Weiterleitungen, Updates, Zugriffsrechte und sichere Formulare müssen separat geprüft werden.
Warum zeigt der Browser trotz HTTPS eine Warnung?
Mögliche Ursachen sind ein abgelaufenes oder unpassendes Zertifikat, eine unvollständige Zertifikatskette, eine falsche Serverzeit oder gemischte Inhalte. Lesen Sie die genaue Browsermeldung und prüfen Sie anschließend Zertifikat, Serverkonfiguration und eingebundene Ressourcen.
Wie finde ich gemischte Inhalte?
Öffnen Sie die Entwicklerwerkzeuge des Browsers und sehen Sie in der Konsole nach Warnungen zu unsicheren Ressourcen. Ergänzend kann ein interner Crawler HTTP-Verweise in vielen Seiten finden. Prüfen Sie auch Vorlagen, Datenbankfelder und externe Einbindungen.
Soll jede HTTP-URL auf HTTPS umgeleitet werden?
Für öffentlich bekannte oder verlinkte HTTP-Adressen ist eine dauerhafte Weiterleitung auf die entsprechende HTTPS-URL meist sinnvoll. Die Regel sollte für Pfade und Parameter korrekt funktionieren und keine Schleifen oder unnötigen Ketten erzeugen. Sonderfälle wie APIs, Downloads oder spezielle Subdomains müssen separat getestet werden.
Kann ich HTTP-Verweise einfach automatisch ersetzen?
Bei eigenen internen URLs kann eine kontrollierte Ersetzung hilfreich sein. Sichern Sie die Daten vorher und prüfen Sie die Datenstruktur des Systems. Externe URLs, API-Endpunkte und eingebundene Dienste sollten nicht blind geändert werden, weil dadurch Funktionen ausfallen können.
Wie oft sollte ich HTTPS prüfen?
Überwachen Sie Zertifikate kontinuierlich und prüfen Sie die Website nach technischen Änderungen. Zusätzlich ist eine regelmäßige manuelle Kontrolle wichtiger Seiten sinnvoll. Bei häufigen Veröffentlichungen oder vielen Drittanbietern sollten automatisierte Prüfungen durch Stichproben ergänzt werden.
Fazit
HTTPS prüfen und Fehler vermeiden bedeutet mehr, als das Schloss-Symbol zu kontrollieren. Eine belastbare Prüfung umfasst Zertifikat, Zertifikatskette, Weiterleitungen, gemischte Inhalte, Formulare, externe Dienste sowie SEO-relevante URL-Signale. Gehen Sie systematisch vor, dokumentieren Sie Änderungen und testen Sie nicht nur die Startseite. So werden Probleme früh erkannt und die HTTPS-Konfiguration bleibt auch nach Updates, Umzügen und Relaunches zuverlässig.

