Was ist SSL/HTTPS? Unterschied zu TLS

Google bestätigte im August 2014 im offiziellen Search-Central-Blog, dass HTTPS ab sofort als Rankingsignal zählt. Beschrieben wurde es damals als „leichtes" Signal, mit geringerem Gewicht als Inhaltsrelevanz oder Linkqualität, aber mit der erklärten Absicht, die gesamte Branche zur Verschlüsselung zu bewegen. Über ein Jahrzehnt später hat dieser Anstoß gewirkt: HTTPS ist heute de facto Standard, eine relevante Seite, die noch über HTTP ausgeliefert wird, ist die Ausnahme.

Der eigentliche Wendepunkt kam nicht über den Suchalgorithmus, sondern über den Browser. Im Februar 2018 kündigte das Chromium-Team an, dass ab Chrome 68, veröffentlicht im Juli desselben Jahres, jede über HTTP geladene Seite die Markierung „Nicht sicher" neben der URL anzeigt, ohne dass wie bisher erst ein Passwort- oder Kreditkartenfeld auf der Seite vorhanden sein musste. Diese Warnung erscheint, bevor der Besucher auch nur eine Zeile Inhalt gelesen hat. Spätere Chrome-Versionen verschärften die Darstellung sogar noch: Bei reinen Formularseiten färbte sich das „Nicht sicher" zeitweise rot statt grau, um die Warnung zusätzlich hervorzuheben.

Genau darin liegt der praktische Unterschied: Der Rankingbonus durch HTTPS ist klein und wirkt vor allem als Zünglein an der Waage zwischen gleich relevanten Seiten. Die „Nicht sicher"-Warnung dagegen ist ein sichtbarer, expliziter Hinweis, den ein Besucher sofort als „dieser Seite traue ich nicht" liest, ganz ohne Algorithmus dazwischen. Dieser Vertrauensschaden, sofortiger Absprung, verlassene Warenkörbe, nicht ausgefüllte Formulare, wiegt in der Praxis schwerer als der zusätzliche Rankingpunkt, und ist meist das Argument, das einen zögerlichen Kunden überzeugt, wenn SEO allein nicht reicht. Für ein Unternehmen zählt am Ende weniger die Position in den Suchergebnissen als die Frage, ob ein Besucher überhaupt bereit ist, seine Daten in ein Formular einzutragen, sobald er die Warnung gesehen hat.

Der Wechsel von HTTP zu HTTPS wirkt wie eine kleine technische Anpassung, ist aber einer der Schritte, die bei zu schneller Umsetzung am meisten Traffic kosten. Der erste und am häufigsten übersprungene Punkt: Jede HTTP-URL braucht ihren eigenen 301-Redirect auf die exakt passende HTTPS-Version, nicht nur die Startseite. Ein pauschaler Redirect der ganzen Domain auf die neue Startseite zerstört jede indexierte URL und verschenkt die Linkkraft, die diese Seiten bereits hatten.

Das zweite Problem, kaum vermeidbar ohne vorherige Prüfung, ist Mixed Content: Bilder, Stylesheets, Skripte oder iFrames, die die neue Seite weiterhin über eine http://-Adresse statt https:// laden. Der Browser kann diese Ressourcen direkt blockieren oder zumindest das Schlosssymbol in der Adressleiste entfernen, was den Sinn der Migration optisch wieder zunichtemacht. Ressourcen sollten deshalb einzeln geprüft werden, nicht nur der HTML-Code der Hauptseiten.

Der dritte Punkt betrifft die Signale, mit denen Google die kanonische Version erkennt: Canonical-Tags und interne Links müssen auf https zeigen, nicht weiter auf die alte Version verweisen. Canonicals, die nach der Migration noch auf http zeigen, senden ein widersprüchliches Signal genau in dem Moment, in dem Google der neuen Version vertrauen soll. Dasselbe gilt für Angaben in der Sitemap, in strukturierten Daten und in fest verlinkten Ressourcen wie Open-Graph-Bildern: Auch dort bleibt oft die alte http-Adresse stehen, weil sie in Templates oder Konfigurationsdateien hartcodiert war, statt sich dynamisch am aktuellen Protokoll zu orientieren.

Zuletzt behandelt die Search Console http und https als getrennte Properties. Die https-Property muss deshalb als neue Property verifiziert werden, und die aktualisierte Sitemap mit den korrekten URLs muss erneut eingereicht werden. Die „Adressänderung"-Funktion von Google ist bei einer reinen Protokolländerung nicht nötig, trotzdem sollten beide Properties parallel verifiziert und während der Übergangszeit beobachtet werden. Die Redirects sollten mindestens ein Jahr aktiv bleiben, damit der Index vollständig nachziehen kann. In dieser Übergangszeit lohnt sich ein regelmäßiger Blick in den Abdeckungsbericht beider Properties: Ein plötzlicher Anstieg von Crawling-Fehlern oder ausgeschlossenen Seiten in der neuen https-Property fällt dort meist schneller auf als über den organischen Traffic allein.

Nicht jedes Zertifikat prüft dasselbe, auch wenn das Schlosssymbol im Browser überall gleich aussieht. Ein Domain-Validated-Zertifikat (DV) bestätigt lediglich, dass der Antragsteller die Kontrolle über die Domain hat. Es ist innerhalb von Minuten ausgestellt, oft kostenlos über Let's Encrypt, und reicht für die überwiegende Mehrheit von Blogs, Firmenwebsites und Landingpages völlig aus.

Ein Organization-Validated-Zertifikat (OV) prüft zusätzlich, ob hinter der Domain tatsächlich ein reales Unternehmen steht, mit entsprechendem Papierkram und manueller Prüfung. Ein Extended-Validation-Zertifikat (EV) geht noch einen Schritt weiter und verifiziert die rechtliche Identität der Organisation mit der striktesten Prüftiefe der Branche.

Jahrelang wurde EV damit beworben, dass der Unternehmensname grün neben der URL erscheint. Chrome hat diese visuelle Anzeige jedoch mit Version 77 im Jahr 2019 entfernt, nachdem eigene Usability-Studien zeigten, dass fast niemand sie bemerkte oder verstand, was sie bedeutete. Firefox zog kurz darauf nach. Diese Information ist heute nur noch sichtbar, wenn jemand auf das Schlosssymbol klickt und sich die Verbindungsdetails anzeigen lässt. Ein EV-Zertifikat kauft also kein sichtbares Vertrauenssymbol mehr, sondern eine strengere rechtliche Prüfung, relevant vor allem aus Compliance- oder Haftungsgründen in Branchen wie Banking oder Hochvolumen-E-Commerce, nicht wegen eines Unterschieds in der Adressleiste.

Unabhängig vom Validierungstyp lohnt sich außerdem ein Blick auf die Abdeckung des Zertifikats: Ein Single-Domain-Zertifikat gilt nur für eine Domain, ein Wildcard-Zertifikat deckt zusätzlich alle Subdomains ab (etwa shop.beispiel.de oder blog.beispiel.de), und ein Multi-Domain-Zertifikat (SAN) bündelt mehrere unterschiedliche Domains in einem einzigen Zertifikat. Welche Variante sinnvoll ist, hängt weniger vom Validierungsgrad als von der Struktur der eigenen Website ab.

• Leite jede HTTP-URL per 301 auf ihre exakte HTTPS-Entsprechung um, nicht nur auf die Root-Domain, und vermeide Redirect-Ketten über mehrere Sprünge.
• Prüfe alle Ressourcen der Seite (Bilder, CSS, JavaScript, iFrames), bevor die Migration als abgeschlossen gilt, um jede verbliebene http://-Referenz zu entfernen.
• Aktualisiere Canonical-Tags, hreflang und interne Links so, dass sie direkt auf die https-Version zeigen, statt sich auf einen Zwischen-Redirect zu verlassen.
• Verifiziere die https-Property als neue Property in der Search Console und lade die aktualisierte Sitemap hoch, sobald die Änderung live ist.
• Richte die automatische Erneuerung des Zertifikats ein; ein abgelaufenes Zertifikat entfernt nicht nur das Schlosssymbol, sondern ersetzt in vielen Browsern die ganze Seite durch eine Vollbild-Warnung.
• Setze den HSTS-Header, sobald bestätigt ist, dass alles über https funktioniert, damit der Browser bei künftigen Besuchen gar nicht erst versucht, die http-Version zu laden.

• Nur die Startseite auf https migrieren und den Rest der Website auf http belassen, oder alle alten URLs pauschal auf die neue Startseite statt auf ihre exakte Entsprechung umleiten.
• Mixed-Content-Ressourcen nicht korrigieren, wodurch einzelne Elemente blockiert werden oder das Schlosssymbol verschwindet, obwohl die Haupt-URL bereits https ist.
• Vergessen, Canonical-Tags und interne Links zu aktualisieren, sodass sie nach der Migration weiterhin auf http zeigen.
• Die https-Property in der Search Console nicht verifizieren, wodurch Google wochenlang keine Performance-Daten zur neuen Version sammelt.
• Das Zertifikat ablaufen lassen, weil die Erneuerung nicht automatisiert wurde, wodurch die „Nicht sicher"-Warnung auf einer bereits migrierten Seite zurückkehrt.
• Für ein EV-Zertifikat draufzahlen in der Annahme, es zeige weiterhin den Firmennamen grün an, eine Funktion, die Chrome und Firefox bereits 2019 entfernt haben.