Website «Nicht sicher»: Ursachen erkennen und HTTPS-Probleme beheben

Das Wichtigste in Kürze

• «Nicht sicher» bedeutet: Die Verbindung zwischen Browser und Server ist nicht oder nicht vollständig verschlüsselt. Ob die Website selbst Schadsoftware enthält, sagt die Meldung nicht aus.
• Die häufigsten Ursachen sind: kein Zertifikat, ein abgelaufenes oder falsch ausgestelltes Zertifikat, Mixed Content und fehlende oder fehlerhafte HTTP-zu-HTTPS-Weiterleitungen.
• Seit Oktober 2026 warnt Chrome ab Version 154 standardmässig, bevor Nutzer eine öffentliche Website ohne HTTPS zum ersten Mal aufrufen.
• Zertifikatslaufzeiten werden kürzer: Seit dem 15. März 2026 sind höchstens 200 Tage erlaubt, ab 2029 nur noch 47 Tage. Ohne automatische Erneuerung geht es künftig nicht mehr.
• HTTPS ist ein Ranking-Signal bei Google, allerdings ein leichtes. Deutlich grösser ist der indirekte Schaden durch abspringende Besucher und Fehler bei der Umstellung.

Was bedeutet die Browser-Warnung «Nicht sicher»?

Browser prüfen bei jedem Seitenaufruf, ob die Verbindung verschlüsselt ist und ob sich der Server mit einem gültigen Zertifikat ausweist. Fällt eine der Prüfungen negativ aus, zeigt der Browser je nach Schwere des Problems eine von mehreren Warnstufen an.

Die letzte Zeile ist wichtig für die Diagnose. Eine Safe-Browsing-Warnung lässt sich nicht mit einem SSL-Zertifikat beheben. Sie deutet auf eine kompromittierte Website hin und erfordert eine Malware-Bereinigung.

Neu seit Oktober 2026: Chrome warnt vor HTTP-Seiten

Google hat angekündigt, mit Chrome 154 im Oktober 2026 die Einstellung «Immer sichere Verbindungen verwenden» (Always Use Secure Connections) standardmässig zu aktivieren. Chrome fragt dann vor dem ersten Zugriff auf jede öffentliche Website ohne HTTPS um Erlaubnis. Für Nutzer mit «Erweitertem Schutz» war die Funktion bereits seit Chrome 147 im April 2026 aktiv. Seiten im lokalen Netzwerk, etwa ein Router-Interface, sind ausgenommen. Regelmässig besuchte HTTP-Seiten werden nicht bei jedem Aufruf erneut beanstandet. Für Website-Betreiber heisst das trotzdem: Wer heute noch ohne HTTPS arbeitet, verliert neue Besucher bereits vor dem ersten Seitenaufbau.

HTTP vs. HTTPS: Welche Rolle spielt das SSL-Zertifikat?

HTTP überträgt Daten im Klartext. Jeder, der den Datenverkehr mitlesen kann, etwa in einem öffentlichen WLAN, sieht Formulareingaben und Cookies und kann Inhalte unbemerkt verändern. HTTPS ist HTTP über eine TLS-Verbindung und erfüllt drei Schutzziele:

• Vertraulichkeit: Die übertragenen Daten sind verschlüsselt.
• Integrität: Manipulationen auf dem Übertragungsweg werden erkannt.
• Authentizität: Der Server beweist, dass er tatsächlich zur aufgerufenen Domain gehört.

Für die Authentizität sorgt das Zertifikat. Es verknüpft Ihren Domainnamen mit einem öffentlichen Schlüssel und ist von einer Zertifizierungsstelle (Certificate Authority, CA) signiert, der die Browser vertrauen. Beim Verbindungsaufbau (TLS-Handshake) weist der Server mit seinem privaten Schlüssel nach, dass er der rechtmässige Inhaber des Zertifikats ist. Anschliessend handeln Browser und Server gemeinsame Sitzungsschlüssel aus, mit denen die eigentlichen Daten symmetrisch und damit performant verschlüsselt werden.

Wichtig: HTTPS schützt die Verbindung, nicht die Website selbst. Auch Phishing-Seiten verfügen häufig über gültige Zertifikate. Woran Sie betrügerische Adressen erkennen, lesen Sie im Beitrag Gefälschte Links erkennen.

SSL oder TLS?

Umgangssprachlich ist meist von «SSL-Zertifikaten» die Rede. Technisch verwenden Sie heute TLS, idealerweise in den Versionen 1.3 und 1.2. Die Vorgänger SSL 2.0/3.0 sowie TLS 1.0 und 1.1 gelten als unsicher und werden von aktuellen Browsern nicht mehr unterstützt. Das Zertifikat selbst ist vom Protokoll unabhängig.

Welche Zertifikatstypen gibt es?

Für die Verschlüsselung selbst gibt es zwischen den drei Typen keinen Unterschied. Ein kostenloses DV-Zertifikat, etwa von Let’s Encrypt, schützt die Verbindung technisch genauso gut wie ein kostenpflichtiges EV-Zertifikat. Die aktuellen Browser heben EV-Zertifikate auch nicht mehr besonders in der Adressleiste hervor.

Zertifikate laufen künftig deutlich schneller ab

Die Browserhersteller und Zertifizierungsstellen haben im CA/Browser Forum eine schrittweise Verkürzung der maximalen Laufzeit beschlossen:

Let’s Encrypt geht noch weiter. Die Standardlaufzeit sinkt am 10. Februar 2027 von 90 auf 64 Tage und am 16. Februar 2028 auf 45 Tage. Auch kostenpflichtige Zertifikate mit einem Jahresabo müssen inzwischen innerhalb dieses Zeitraums neu ausgestellt werden. Manuelle Erneuerungen im Kalender sind damit ein echtes Betriebsrisiko. Eine automatische Erneuerung gehört zum Pflichtprogramm.

Die häufigsten Ursachen für die Warnung «Nicht sicher»

1. Kein Zertifikat: Die Website läuft nur über HTTP

Der einfachste Fall: Für die Domain ist kein Zertifikat installiert, oder HTTPS ist im Hosting nicht aktiviert. Der Browser zeigt den Hinweis in der Adressleiste. Chrome warnt ab Version 154 zusätzlich vor dem Aufruf.

2. Abgelaufenes Zertifikat

Ein Zertifikat ist nur bis zu seinem Ablaufdatum gültig. Danach blockieren Browser den Zugriff mit einer Vollbild-Warnung. Häufige Ursachen sind eine fehlgeschlagene automatische Erneuerung, zum Beispiel weil sich der DNS-Eintrag geändert hat, oder eine Erneuerung, die zwar erfolgte, aber nicht auf dem Server eingespielt wurde. Lädt Ihre Website überhaupt nicht, statt nur eine Warnung anzuzeigen, finden Sie weitere mögliche Ursachen im Beitrag «Website nicht erreichbar».

3. Zertifikat passt nicht zum Hostnamen

Das Zertifikat muss jeden aufgerufenen Hostnamen abdecken. Klassischer Fehler: Das Zertifikat gilt für example.ch, Besucher rufen aber www.example.ch auf. Dasselbe passiert bei neu angelegten Subdomains, die im Zertifikat fehlen.

4. Nicht vertrauenswürdige Zertifizierungsstelle oder unvollständige Kette

Selbstsignierte Zertifikate werden von Browsern grundsätzlich abgelehnt und gehören höchstens in interne Testumgebungen. Ebenso häufig fehlt bei einer manuellen Installation das Zwischenzertifikat (Intermediate). Manche Browser kompensieren das, andere nicht. Deshalb funktioniert die Seite dann scheinbar «nur manchmal».

5. Mixed Content

Die Seite selbst wird per HTTPS geladen, einzelne Ressourcen aber noch über HTTP. Moderne Browser reagieren je nach Art der Ressource unterschiedlich:

Mixed Content entsteht typischerweise nach einer HTTPS-Umstellung, wenn in Datenbank, Theme, Page-Builder oder externen Einbettungen noch absolute http://-Adressen stehen.

6. Fehlende oder fehlerhafte HTTPS-Weiterleitungen

Ist HTTPS eingerichtet, die Website aber parallel noch per HTTP erreichbar, landen Besucher über alte Links, Bookmarks oder manuell eingetippte Adressen auf der unsicheren Variante. Weitere typische Fehler:

• Weiterleitungsschleifen (Fehler ERR_TOO_MANY_REDIRECTS), oft weil ein vorgeschalteter Proxy oder ein CDN per HTTP mit dem Server spricht, während der Server auf HTTPS umleitet, oder weil in WordPress die Website-Adresse nicht zur Server-Konfiguration passt.
• Weiterleitungsketten wie http://example.ch → https://example.ch → https://www.example.ch. Das kostet Ladezeit und Crawl-Budget.
• Temporäre statt permanenter Weiterleitungen (302 statt 301), was Suchmaschinen ein schwächeres Signal für die neue Adresse gibt.

7. Ursachen auf Seiten der Besucher

Tritt die Warnung nur bei einzelnen Personen auf, liegt das Problem häufig auf deren Gerät: eine falsch eingestellte Systemuhr, eine Antiviren-Software mit HTTPS-Scan, ein Firmen-Proxy oder ein öffentliches WLAN mit Login-Seite. In diesem Fall ist an Ihrer Website nichts zu reparieren.

Fehlermeldungen richtig deuten

Die Fehlercodes in Chrome und Edge führen direkt zur Ursache. Sie sehen sie auf der Warnseite, nachdem Sie auf «Erweitert» geklickt haben.

Schritt für Schritt: Ursache finden und HTTPS-Probleme beheben

Schritt 1: Warnung und Fehlercode erfassen

Rufen Sie die betroffene Seite in einem privaten Browserfenster auf, damit Cache und Erweiterungen das Ergebnis nicht verfälschen. Notieren Sie die genaue Meldung und den Fehlercode. Bei einer normal geladenen Seite klicken Sie in Chrome auf das Symbol links neben der Adresse (Websiteinformationen) und öffnen die Details zur Verbindung und zum Zertifikat. Prüfen Sie zusätzlich, ob die Warnung in einem anderen Browser und einem anderen Netzwerk, etwa im Mobilfunknetz, ebenfalls erscheint.

Schritt 2: Zertifikat prüfen

Kontrollieren Sie drei Punkte: Gültigkeitszeitraum, abgedeckte Hostnamen (Subject Alternative Names) und vollständige Zertifikatskette. Komfortabel geht das mit dem kostenlosen Server-Test von Qualys SSL Labs. Wer Zugriff auf eine Kommandozeile hat, prüft direkt mit OpenSSL:

echo | openssl s_client -connect www.example.ch:443 -servername www.example.ch 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Die Ausgabe zeigt Aussteller, Ablaufdatum (notAfter) und alle im Zertifikat enthaltenen Hostnamen.

Schritt 3: Zertifikat ausstellen oder erneuern und Erneuerung automatisieren

Bei einem Hosting-Paket aktivieren Sie das Zertifikat in der Regel mit wenigen Klicks im Control Panel. Im METANET-Webhosting richten Sie das SSL-Zertifikat direkt in Plesk ein. Achten Sie darauf, dass sowohl die Hauptdomain als auch die www-Variante und alle genutzten Subdomains enthalten sind. Auf einem eigenen Server mit nginx und Certbot sieht das so aus:

sudo certbot --nginx -d example.ch -d www.example.ch
sudo certbot renew --dry-run

Der zweite Befehl testet die automatische Erneuerung. Ergänzen Sie ein Monitoring, das Sie vor dem Ablauf eines Zertifikats warnt. Bei den kürzeren Laufzeiten fällt eine fehlgeschlagene Erneuerung sonst erst auf, wenn Kunden die Warnseite sehen.

Schritt 4: Mixed Content aufspüren und beheben

Öffnen Sie die Entwicklertools des Browsers (<kbd>F12</kbd>) und laden Sie die Seite neu. Die Konsole listet alle Mixed-Content-Warnungen mit der betroffenen Adresse auf. Ersetzen Sie anschliessend jede http://-Ressource durch die HTTPS-Variante. Bei externen Quellen müssen Sie gegebenenfalls einen anderen Anbieter wählen oder die Datei lokal hosten.

Bei WordPress gehen Sie so vor:

1. Erstellen Sie ein vollständiges Backup von Dateien und Datenbank.
2. Stellen Sie unter Einstellungen → Allgemein die WordPress-Adresse und die Website-Adresse auf https:// um.
3. Ersetzen Sie alte Adressen in der Datenbank, zum Beispiel mit dem Plugin Better Search Replace oder per WP-CLI mit wp search-replace 'http://example.ch' 'https://example.ch' --all-tables. Testen Sie den Befehl zuerst mit --dry-run. Ersetzen Sie immer die vollständige Domain, nie nur «http», sonst verändern Sie auch externe Links.
4. Prüfen Sie Theme, Custom CSS und Page-Builder auf fest eingetragene HTTP-Adressen und leeren Sie danach alle Caches.

Eine ausführliche Schritt-für-Schritt-Anleitung mit Screenshots finden Sie im Tutorial WordPress auf HTTPS/SSL umstellen.

Als zusätzliches Sicherheitsnetz können Sie den HTTP-Header Content-Security-Policy: upgrade-insecure-requests setzen. Er weist Browser an, HTTP-Ressourcen automatisch per HTTPS anzufordern. Die saubere Bereinigung der Quellen ersetzt er aber nicht.

Schritt 5: HTTP-zu-HTTPS-Weiterleitung korrekt einrichten

Ziel ist eine einzige permanente Weiterleitung (301) von jeder Variante direkt auf die bevorzugte HTTPS-Adresse. Bei Apache-basiertem Hosting mit .htaccess, hier mit der Variante ohne www als Hauptadresse:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.ch%{REQUEST_URI} [L,R=301]

Auf einem nginx-Server:

server {
    listen 80;
    listen [::]:80;
    server_name example.ch www.example.ch;
    return 301 https://example.ch$request_uri;
}

Läuft Ihre Website hinter einem Proxy oder CDN, erkennt der Server HTTPS-Anfragen möglicherweise nicht direkt. In diesem Fall die Weiterleitung im CDN konfigurieren oder den Header X-Forwarded-Proto auswerten, sonst entsteht eine Schleife. Prüfen Sie das Ergebnis anschliessend per Kommandozeile:

curl -sIL http://www.example.ch

Die Ausgabe sollte genau eine 301-Antwort mit Location: https://example.ch/ und danach den Status 200 zeigen.

Schritt 6: HSTS aktivieren, aber erst ganz zum Schluss

Mit HTTP Strict Transport Security (HSTS) teilt Ihr Server dem Browser mit, die Domain künftig ausschliesslich per HTTPS aufzurufen:

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

Setzen Sie den Header erst, wenn HTTPS auf allen Seiten und Subdomains fehlerfrei funktioniert. Starten Sie mit einem kurzen max-age, etwa 300 Sekunden, und erhöhen Sie den Wert schrittweise. Solange HSTS aktiv ist, können Besucher eine Zertifikatswarnung nicht mehr wegklicken. Ein Konfigurationsfehler macht die Website dann für sie unerreichbar.

Schritt 7: Suchmaschinen-Signale nachziehen

• Canonical-Tags, hreflang-Angaben und interne Links auf die HTTPS-Adressen umstellen.
• Die XML-Sitemap nur mit HTTPS-Adressen ausliefern und in der Google Search Console einreichen.
• In der Search Console idealerweise eine Domain-Property verwenden, die HTTP und HTTPS gemeinsam abdeckt.
• Wichtig: Das Tool «Adressänderung» der Search Console ist für den Wechsel von HTTP auf HTTPS bei gleicher Domain nicht vorgesehen. Die 301-Weiterleitungen genügen.

Checkliste: Ist Ihre Website korrekt abgesichert?

• Jede Seite lädt per HTTPS, ohne Warnung in Chrome, Firefox, Safari und Edge.
• Das Zertifikat stammt von einer anerkannten Zertifizierungsstelle und deckt alle genutzten Hostnamen ab, inklusive www und Subdomains.
• Die Zertifikatskette ist vollständig, der SSL-Labs-Test zeigt keine Kettenfehler.
• Die automatische Erneuerung ist eingerichtet und getestet, ein Monitoring warnt vor dem Ablauf.
• Der Server unterstützt TLS 1.2 und 1.3, ältere Protokolle sind deaktiviert.
• Die Browser-Konsole zeigt auf keiner Seite Mixed-Content-Warnungen.
• Alle Formulare senden ihre Daten an HTTPS-Adressen.
• Jede HTTP- und Hostnamen-Variante leitet mit einer einzigen 301-Weiterleitung auf die Hauptadresse.
• Es gibt keine Weiterleitungsschleifen oder -ketten.
• Canonical-Tags, interne Links und XML-Sitemap verweisen auf HTTPS.
• HSTS ist aktiv, nachdem alle vorherigen Punkte erfüllt sind.
• Die Website erscheint nicht in einer Safe-Browsing-Warnung (prüfbar im Bericht «Sicherheitsprobleme» der Search Console).

Warum die Warnung mehr als ein Schönheitsfehler ist

Vertrauen und Conversion

Eine Vollbild-Warnung stoppt Besucher, bevor sie Ihr Angebot überhaupt sehen. Auch der dezentere Hinweis in der Adressleiste wirkt besonders dort abschreckend, wo Daten eingegeben werden: im Kontaktformular, beim Login oder im Checkout. Zahlungsdienstleister und viele moderne Browserfunktionen, etwa Standortabfrage, Service Worker oder Push-Benachrichtigungen, setzen ohnehin HTTPS voraus.

Datenschutz in der Schweiz

Das Schweizer Datenschutzgesetz (DSG, in der Praxis oft noch revDSG genannt) verlangt in Art. 8, dass Verantwortliche durch geeignete technische und organisatorische Massnahmen eine dem Risiko angemessene Datensicherheit gewährleisten. HTTPS ist dort nicht wörtlich vorgeschrieben. Wer jedoch über Formulare oder Logins Personendaten entgegennimmt, wird eine unverschlüsselte Übertragung kaum als angemessen begründen können. Die vorsätzliche Missachtung der Mindestanforderungen an die Datensicherheit kann nach Art. 61 DSG mit einer Busse von bis zu CHF 250'000 geahndet werden. Diese richtet sich gegen die verantwortlichen natürlichen Personen. Richtet sich Ihr Angebot auch an Personen in der EU, kann zusätzlich die DSGVO anwendbar sein.

Auswirkungen auf SEO

Google nutzt HTTPS seit 2014 als Ranking-Signal und zählt es heute zu den Aspekten der Page Experience. Das Signal ist allerdings leicht. Eine Umstellung auf HTTPS allein bringt keinen spürbaren Ranking-Sprung. Relevanter sind die indirekten Effekte: Nutzer, die eine Warnseite sehen, verlassen die Website, und eine schlecht umgesetzte Umstellung mit Weiterleitungsketten, 302-Weiterleitungen, gemischten Canonicals oder blockierten Ressourcen kann Rankings vorübergehend kosten. Eine saubere Migration nach der obigen Anleitung vermeidet genau diese Risiken.

So unterstützt Sie METANET bei einer sicheren Website

Der zuverlässigste Schutz vor «Nicht sicher»-Warnungen ist eine Infrastruktur, in der HTTPS von Anfang an zum Standard gehört. Gerade mit den kürzeren Zertifikatslaufzeiten ab 2026 ist das entscheidend.

• Webhosting mit SSL-Zertifikat: Bei METANET ist das SSL-Zertifikat Bestandteil des Webhostings. Sie aktivieren es direkt in Plesk für Ihre Domains und Subdomains, die Installation ist kostenlos.
• WordPress Hosting: Eine für WordPress optimierte Umgebung, in der die HTTPS-Umstellung reibungslos gelingt.
• Website-Baukasten: Wer seine Website ohne eigene Server-Konfiguration erstellen möchte, findet im Website-Baukasten einen einfachen Einstieg.
• VPS: Für technisch versierte Anwender bietet ein VPS volle Kontrolle über Webserver, TLS-Konfiguration, HSTS und Weiterleitungen. Let’s Encrypt lässt sich, etwa über Plesk, bequem einbinden.
• Managed Cloud Server und Server-Lösungen: Möchten Sie den Betrieb auslagern, übernimmt METANET mit Managed Cloud Servern Monitoring, Updates und SSL. Für komplexe Umgebungen mit vielen Domains und Diensten bieten sich das Virtual Data Center und individuelle Server-Lösungen an.
• Domains: Ob mit oder ohne www: Mit Ihren Domains bei METANET verwalten Sie DNS-Einträge und Hostnamen zentral. So stellen Sie sicher, dass jede Variante korrekt auf Ihre HTTPS-Website zeigt.