Sprachen

SSL/TLS-Zertifikate

DV vs. OV vs. EV, Wildcard vs. SAN, Let's Encrypt und kostenlose automatisierte Ausstellung, Fehler in der Zertifikatskette, Ablauf und automatische Verlängerung sowie was für Nutzer vs. Crawler kaputt geht, wenn ein Zertifikat ungültig ist – der tiefe Einblick auf Zertifikatsebene unter dem HTTPS-Hub.

Erstveröffentlicht: 3. Juli 2026 · Zuletzt aktualisiert: 21. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Google dokumentiert keinen Ranking-Unterschied zwischen DV-, OV- und EV-Zertifikaten oder zwischen kostenlosen Let's-Encrypt-Zertifikaten und kostenpflichtigen – solange HTTPS gültig ist, werden alle gleich behandelt; ein teureres Zertifikat kauft menschliches/organisatorisches Vertrauen, nicht Ranking. Validierungstiefe (DV/OV/IV/EV) und Abdeckungsumfang (Einzeldomain, Wildcard, SAN) sind separate Entscheidungen, und keine davon ist ein dokumentierter Ranking-Faktor. Wo Zertifikate tatsächlich SEO beeinflussen, ist bei Fehlern: Ein abgelaufenes, selbstsigniertes, hostname-falsches oder kettenunterbrochenes Zertifikat erzeugt Browserwarnungen, die Nutzer vertreiben, kann Googles normale HTTPS-über-HTTP-Kanonpräferenz zurück auf HTTP kippen (HSTS kann das nicht überschreiben) – und wenn HTTPS-Fehler sich häufen, kann Google dazu veranlasst werden, Ihre HTTPS-Seiten ganz nicht mehr zu crawlen. Da die Zertifikatslebensdauer bis 2029 auf ein Maximum von 47 Tagen schrumpft, ist die automatische Verlängerung jetzt Pflicht, nicht optional.

TL;DR — Google dokumentiert keinen Ranking-Unterschied zwischen DV/OV/EV-Validierungstiefe oder kostenloser vs. kostenpflichtiger Ausstellung – ein teureres Zertifikat kauft menschliches/organisatorisches Vertrauen, nicht Rankings. Validierungstiefe (DV/OV/IV/EV) und Abdeckungsumfang (einzeln/Wildcard/SAN) sind zwei unabhängige Entscheidungen; keine davon ist ein dokumentierter Ranking-Faktor. Let’s Encrypt und kostenlose automatisierte (ACME) Ausstellung sind kein Kompromiss – gleiche Verschlüsselung, gleiche Behandlung. Wo Zertifikate SEO beeinflussen, ist das Versagen: Ein abgelaufenes, selbstsigniertes, hostname-inkonsistentes oder kettengebrochenes Zertifikat bricht die Seite für Nutzer, kann Googles normale HTTPS-über-HTTP-Kanonisierungspräferenz zurück zur HTTP-Version kippen (HSTS kann das nicht überschreiben) und – laut Googles eigener Dokumentation – genug HTTPS-Probleme “können Google dazu veranlassen, das Crawlen Ihrer HTTPS-Seiten” ganz einzustellen. Da das CA/Browser Forum die maximale Gültigkeit bis 2029 auf 47 Tage senkt, ist die automatisierte Erneuerung jetzt Pflicht. Der HTTPS-Hub führt ein, dass ein kostenloses DV-Zertifikat dasselbe Signal erhält wie OV/EV; hier wird das vollständig behandelt.

Der HTTPS-Hub argumentiert, dass HTTPS höchstens ein Tiebreaker-Signal ist, dass Google das Schema und nicht das Zertifikat prüft, und dass ein kostenloses DV-Zertifikat dasselbe Signal verdient wie ein teures OV/EV. Dieser Artikel setzt genau dort an und geht eine Ebene tiefer – in das Zertifikat selbst. Ich werde nicht erneut argumentieren, ob HTTPS Rankings hilft; nehmen Sie an, Sie haben den Hub gelesen. Hier möchte ich die Fragen beantworten, die der Hub nur andeutet: Was DV/OV/EV tatsächlich bedeuten, wie der Abdeckungsumfang funktioniert, warum kostenlose automatisierte Zertifikate in Ordnung sind, wie Zertifikatsketten auf eine Weise brechen, die sich Ihrem eigenen Testen entzieht, und was wirklich mit dem Crawlen passiert – nicht nur mit Nutzern –, wenn ein Zertifikat schlecht wird.

”SSL-Zertifikat” ist eigentlich ein TLS-Zertifikat

SSL ist veraltete Terminologie für moderne TLS-Bereitstellungen. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 8446: TLS 1.3 Suchanleitungen konzentrieren sich auf gültiges, zugängliches HTTPS statt auf kommerzielle Zertifikatsstufen. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: HTTPS

Kurzer Hinweis zur Benennung, dann fahre ich fort: SSL (Secure Sockets Layer) ist das veraltete Protokoll; alles, was heute ausgestellt wird, läuft auf TLS (Transport Layer Security). “SSL-Zertifikat” überlebt als umgangssprachlicher Name – Googles eigene Search Console-Strings sagen immer noch “SSL certificate problems.” Ich verwende für den Rest dieses Artikels “Zertifikat”.

Validierungstiefe: DV vs. OV vs. IV vs. EV

Zertifikate werden auf verschiedenen Validierungsstufen ausgestellt, die beschreiben, wie viel die Zertifizierungsstelle (CA) geprüft hat, bevor sie für Sie bürgt. Laut SSL.coms Aufschlüsselung:

  • DV (Domain Validation) ist “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (Übersetzung) „die niedrigste Validierungsstufe und bestätigt, dass die Person, die das Zertifikat anfordert, die geschützte Domain kontrolliert.“ DV ist schnell, günstig oder kostenlos und meist automatisiert: Die Domainkontrolle wird etwa über einen DNS-Eintrag oder eine von der Zertifizierungsstelle abrufbare Datei nachgewiesen.
  • OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.” (Übersetzung) „bestätigt die Identität der im Zertifikat als Antragsteller genannten Organisation, etwa eines Unternehmens, einer gemeinnützigen Organisation oder einer Behörde, sowie deren Standort.“
  • IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (Übersetzung) „bestätigt die Identität der natürlichen Person, die im Zertifikat als Antragsteller genannt ist.“
  • EV (Extended Validation) “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (Übersetzung) „bestätigt wie OV die Identität einer Organisation. EV steht jedoch für einen höheren Vertrauensstandard als OV und erfordert strengere Validierungsprüfungen.“

Hier ist der SEO-relevante Punkt: Google dokumentiert keinen Ranking-Unterschied zwischen den Validierungsstufen. Der Hub stellt fest, dass das Basissignal das URL-Schema liest – Illyes beschrieb es als Blick auf die ersten fünf Zeichen vor der URL. Solange das HTTPS gültig und funktionsfähig ist, werden ein DV-Zertifikat, ein OV-Zertifikat und ein EV-Zertifikat alle gleich behandelt. Der Preisunterschied zwischen ihnen spiegelt den Prüfaufwand und die Haftung der CA wider, nicht eine Google-Präferenz – web.dev sagt klar: “different CAs charge different amounts of money for the service of vouching for your public key.” (Übersetzung) „Verschiedene CAs verlangen unterschiedliche Beträge für den Dienst, für Ihren öffentlichen Schlüssel zu bürgen.“ Das zusätzliche Geld kauft menschliches und organisatorisches Vertrauen, Punkt.

Und das eine verbleibende, auf Menschen ausgerichtete Argument für EV ist weitgehend hinfällig: Die spezielle Behandlung von EV in der Browser-Adressleiste ist de facto verschwunden. Chrome entfernte die grüne Benutzeroberfläche mit dem Firmennamen ab Chrome 77 (2019), und Firefox 70 folgte im selben Jahr. Das Argument „Kunden sehen unseren Firmennamen in der Leiste“, mit dem der EV-Preis früher gerechtfertigt wurde, gilt in gängigen Browsern also nicht mehr – überprüfen Sie das aktuelle Browserverhalten, wenn Sie eine Kaufentscheidung treffen, aber derzeit ist dieses visuelle Signal nicht vorhanden.

Abdeckungsumfang: Einzeldomäne vs. Wildcard vs. SAN

Die Validierungstiefe ist eine Achse. Der Abdeckungsumfang – welche Hostnamen ein Zertifikat tatsächlich absichert – ist eine völlig separate. Jeder Umfang kann in der Regel als DV oder OV ausgestellt werden (Wildcards werden bei EV gemäß der CA/B-Richtlinie normalerweise nicht angeboten):

  • Einzeldomäne – deckt genau einen Hostnamen ab, z. B. www.example.com.
  • Wildcard – deckt ein Hostnamen-Muster eine DNS-Ebene tief ab. web.dev ist präzise in Bezug auf die Grenze: “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (Übersetzung) „Bei Wildcard-Zertifikaten gilt das Platzhalterzeichen nur für ein DNS-Label. Ein Zertifikat für *.example.com funktioniert für foo.example.com und bar.example.com, aber nicht für foo.bar.example.com.“ Dieser letzte Satz ist die Falle – eine Wildcard deckt keine Subdomains der zweiten Ebene ab.
  • SAN / Multi-Domain (UCC) – eine explizite Liste bestimmter Hostnamen in den Subject Alternative Names des Zertifikats. web.dev merkt an, dass Sie “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” (Übersetzung) „Optionen bieten, Ihren Schlüssel mehr als einem DNS-Namen zuzuordnen, darunter mehrere unterschiedliche Namen, beispielsweise die vier zuvor genannten Hosts.“ Ein SAN-Zertifikat kann sogar völlig verschiedene Domänen abdecken, was nützlich ist, wenn Sie eine Handvoll verwandter Eigenschaften haben und keine Wildcard-Abdeckung überdimensionieren möchten.

Der praktische SEO-Fehlermodus versteckt sich in der Einzel-Label-Grenze der Wildcard. Angenommen, Sie betreiben *.example.com und jemand startet staging.blog.example.com – das ist zwei Ebenen tief, außerhalb der Wildcard, und es wird einen Zertifikatsfehler liefern oder auf ein nicht passendes Zertifikat zurückfallen. Wenn Google oder ein Benutzer darauf stößt, erleben sie eine fehlerhafte Zertifikatserfahrung auf einer Seite, von der Sie dachten, sie sei abgedeckt.

Noch eine Abdeckungsfalle: Ein bestandener Test auf Ihrem Apex-Hostnamen beweist keine Abdeckung überall. Ein Client muss den genauen Hostnamen anfordern, mit dem er sich verbindet, und ein Zertifikat zurückerhalten, das diesen Hostnamen tatsächlich benennt (über SNI) – bei CDNs, Load Balancern und SNI-basiertem Shared Hosting können verschiedene Edges, Regionen oder Ursprünge hinter derselben Domäne legitimerweise unterschiedliche Zertifikate ausliefern. Testen Sie jeden öffentlichen Hostnamen unabhängig, anstatt anzunehmen, dass ein sauberes SSL-Labs- Ergebnis für example.com auch für www., eine regionale Edge oder eine Subdomain hinter einem anderen Ursprung spricht.

Let’s Encrypt und kostenlose automatisierte Ausstellung

Let’s Encrypt und andere kostenlose CAs stellen DV-Zertifikate über das ACME- Protokoll aus – eine automatisierte Anfrage-/Herausforderungs-/Ausstellungsschleife, die Clients wie Certbot für Sie ausführen. Zwei Dinge, die hier oft falsch verstanden werden:

  1. Kostenlos bedeutet nicht schwächer. Ein Let’s-Encrypt-Zertifikat bietet die gleiche TLS-Verschlüsselungsstärke wie ein kostenpflichtiges und, da Googles Signal schemabasiert ist, die exakt gleiche Ranking-Behandlung. Die einzigen echten Kompromisse sind, dass es nur DV (ohne OV/EV-Identitätsprüfung) ist und kurzlebig.
  2. Die kurze Lebensdauer ist ein Vorteil, sobald sie automatisiert ist. Kurzlebige Zertifikate bedeuten ein kleineres Zeitfenster der Gefährdung, falls ein Schlüssel jemals kompromittiert wird, und – entscheidend – kein Mensch muss sich an die Verlängerung erinnern. Automatisierung verwandelt die kürzeste Lebensdauer in die sicherste.

Dieser zweite Punkt wird bald für alle relevant, nicht nur für Let’s-Encrypt-Nutzer.

Die Verschiebung der Zertifikatslebensdauer (2026–2029) – jetzt automatisieren

Die Branche verkürzt die Lebensdauer von Zertifikaten nach einem festen Zeitplan. Das CA/Browser Forum hat Ballot SC-081v3 verabschiedet (Abstimmung endete am 11. April 2025), das die maximale Gültigkeitsdauer von TLS-Zertifikaten in Phasen reduziert:

  • 398 Tage heute
  • 200 Tage ab dem 15. März 2026
  • 100 Tage ab dem 15. März 2027
  • 47 Tage ab dem 15. März 2029

Let’s Encrypt bewegt sich auch auf einer eigenen, schnelleren Spur: Laut seinem Update vom Februar 2026 reduziert es die Standardlebensdauer seiner Zertifikate in zwei Schritten über die folgenden zwei Jahre – „von 90 Tagen auf 64 Tage und dann auf 45 Tage“ – wobei sich der Verlängerungszeitpunkt von etwa Tag 60 eines 90-Tage-Zertifikats heute auf etwa Tag 30 verschiebt, sobald die Zertifikate auf 45 Tage reduziert sind. Dieses Update ersetzte eine frühere, spezifischere Zeitachse; behandeln Sie die genauen Einführungsdaten für jeden Schritt als noch nicht festgelegt und prüfen Sie das eigene Änderungsprotokoll von Let’s Encrypt, bevor Sie sich auf ein bestimmtes Datum verlassen.

Die operative Schlussfolgerung ist deutlich: Wenn Ihre Verlängerung nicht bereits automatisiert ist, beheben Sie das vor 2027. Ein manueller Verlängerungsrhythmus, der bei 398 Tagen überlebbar war, wird bei 47–100 Tagen zu einem nahezu garantierten Ausfall. DigiCerts Berichterstattung über den Abstimmungspunkt bringt es gut auf den Punkt – manuelle Revalidierung bleibt technisch möglich, aber „dies zu tun wäre ein Rezept für Fehler und Ausfälle.“ Automatisierung hört auf, ein nettes Extra zu sein, und wird zur einzig vernünftigen Option.

Zertifikatskette / Fehler bei Zwischenzertifikaten

Dies ist der untererklärte Punkt, und Googles Dokumentation behandelt ihn nicht mechanisch, also hier ist, wie es tatsächlich funktioniert.

Ein Browser vertraut nur einer kleinen Menge von Root-Zertifikaten, die in seinem Vertrauensspeicher eingebettet sind. Das Zertifikat Ihres Servers – das Blatt- oder Endentitätszertifikat – ist fast nie direkt von einer Root signiert. Stattdessen gibt es eine Kette: Blatt → ein oder mehrere Zwischenzertifikate → vertrauenswürdige Root. Damit ein Client Ihrem Blatt vertraut, muss Ihr Server das Blatt plus die Zwischenzertifikate senden, damit der Client den Pfad bis zu einer Root aufbauen kann, der er bereits vertraut.

Die klassische Fehlkonfiguration ist ein Server, der nur das Blatt sendet und das Zwischenzertifikat weglässt. Und hier ist, warum das tückisch ist: Desktop-Chrome funktioniert oft weiterhin, weil es Zwischenzertifikate zwischenspeichert, die es auf anderen Websites gesehen hat, und die Lücke füllen kann. Die Person, die auf ihrem Laptop testet, sieht also ein grünes Schloss und nimmt an, dass alles in Ordnung ist. In der Zwischenzeit schlagen mobile Browser, viele API/HTTP-Clients und andere Tools, die dieses zwischengespeicherte Zwischenzertifikat nicht haben, den Handshake vollständig fehl. Es ist ein „Funktioniert auf meinem Rechner“-Fehler auf der TLS-Ebene.

Um es zu erkennen, verlassen Sie sich nicht auf eine Stichprobe mit Desktop-Chrome. Verwenden Sie ein Tool, das die Kette von Grund auf aufbaut:

  • SSL Labs’ Server Test kennzeichnet „Extra-Download“-/unvollständige-Ketten-Probleme explizit.
  • openssl s_client -connect example.com:443 -showcerts auf der Befehlszeile zeigt jedes Zertifikat, das der Server tatsächlich sendet, sodass Sie bestätigen können, dass das Zwischenzertifikat vorhanden ist.

Was passiert, wenn ein Zertifikat ungültig, abgelaufen oder selbstsigniert ist

Dies ist der Abschnitt, der am wichtigsten ist, und er teilt sich sauber in zwei Teile – denn Benutzer und Crawler erleben ein defektes Zertifikat unterschiedlich.

Was Nutzer und Browser tun. Ein schwerwiegender Zertifikatsfehler – etwa ein abgelaufenes oder selbstsigniertes Zertifikat, ein nicht passender Hostname oder eine nicht vertrauenswürdige Zertifizierungsstelle – löst eine bildschirmfüllende Warnung aus, nicht nur den unaufdringlichen HTTP-Hinweis „Nicht sicher“. Nutzer springen ab. Der am besten dokumentierte Fall ist Glenn Gabes „A Wolf in Panda’s Clothing“: Der Traffic eines Onlineshops brach an dem Tag ein, an dem ein Google-Panda-Update erschien, weshalb der Betreiber zunächst eine Abstrafung vermutete. Tatsächlich erzeugte ein abgelaufenes Zertifikat Browserwarnungen; Besucher brachen ab, bevor die Seite überhaupt geladen wurde. Gabe fasste die Diagnose so zusammen: “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (Übersetzung) „Manchmal sind vermeintliche SEO-Probleme gar keine SEO-Probleme. Technische Störungen, die zeitgleich mit Algorithmus-Updates auftreten, können in die Irre führen.“ Nach der Zertifikatserneuerung erholte sich der Traffic innerhalb von etwa acht Tagen. Selbstsignierte Zertifikate führen in der Praxis zur gleichen harten Warnung: Für interne, Entwicklungs- oder Staging-Systeme sind sie vertretbar, für eine öffentliche Produktionswebsite nicht.

Was Google tut. Hier liegt eine wichtige Nuance, die fast alle Konkurrenzseiten übersehen. Googles eigene Kanonisierungsrichtlinien erklären ausdrücklich, dass ein defektes Zertifikat für die Suche nicht unsichtbar ist: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (Übersetzung) „Google bevorzugt HTTPS-Seiten gegenüber gleichwertigen HTTP-Seiten als kanonische Version, außer wenn Probleme oder widersprüchliche Signale vorliegen“, und nennen fehlerhafte Zertifikate direkt als eine solche Ausnahme: “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (Übersetzung) „Vermeiden Sie fehlerhafte TLS/SSL-Zertifikate und Weiterleitungen von HTTPS zu HTTP, weil Google dadurch HTTP sehr deutlich bevorzugt. Selbst HSTS kann diese starke Präferenz nicht aufheben.“ Ein tatsächlich defektes Zertifikat kann also bewirken, dass Google statt der HTTPS-Seite wieder die unverschlüsselte HTTP-Version als kanonisch behandelt. Das beeinflusst, was in der Suche erscheint, und ist nicht bloß eine Randnotiz zum Crawl-Budget.

Unabhängig davon nennt die Dokumentation der Google Search Console auch eine Folge für das Crawling: Ein ungültiges Zertifikat “typically affects an entire site,” (Übersetzung) „betrifft normalerweise eine gesamte Website“, und “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (Übersetzung) „wenn eine Website viele HTTPS-Probleme aufweist, kann dies Google dazu veranlassen, ihre HTTPS-Seiten nicht mehr zu crawlen.“ Verbleibende URLs werden dann als “HTTPS not evaluated.” (Übersetzung) „HTTPS nicht bewertet“ gekennzeichnet. Es wirken somit zwei getrennte Mechanismen: die Rückkehr zur HTTP-Version als kanonische Seite und eine eigenständige Einschränkung des Crawl-Zugriffs. Beide können dazu führen, dass Seiten aus dem Index verschwinden, obwohl sich am grundlegenden https://-Ranking-Signal nichts ändert. Beheben Sie das Zertifikat. Einen Ranking-Faktor gibt es hier nicht zu optimieren; harmlos ist der Fehler deshalb trotzdem nicht.

Googles Fehlerliste entspricht dieser Taxonomie. Dazu gehören ein Hostname, der nicht zu den Namen im Zertifikat passt – “The host name of your site does not match any of the Subject Names in your SSL certificate” (Übersetzung) „Der Hostname Ihrer Website stimmt mit keinem der Antragstellernamen in Ihrem SSL-Zertifikat überein“ – sowie Zertifikate, die “not recognized by major web browsers” (Übersetzung) „von den wichtigsten Webbrowsern nicht erkannt werden“. Darunter fallen selbstsignierte Zertifikate, nicht vertrauenswürdige Zertifizierungsstellen sowie beschädigte, abgelaufene oder noch nicht gültige Zertifikate.

Ablaufüberwachung und automatische Verlängerung

Der Ablauf ist der häufigste und am besten vermeidbare Zertifikatsfehler, und sein Schadensradius ist asymmetrisch – er bricht normalerweise die gesamte Website auf einmal (Google: „Typically this affects an entire site“ (Übersetzung) „Typischerweise betrifft dies eine gesamte Website“), nicht eine Seite nach der anderen. Die Lösung ist niemals eine Kalendererinnerung. Richten Sie echte Automatisierung ein:

  • ACME / Certbot auf Ihrem eigenen Server oder das Äquivalent, das Ihre Plattform mitbringt.
  • Host- oder CDN-verwaltete Zertifikate (Cloudflare, die meisten verwalteten Hosts, viele PaaS-Plattformen), die automatisch für Sie ausstellen und erneuern.
  • Ein Drittanbieter-Zertifikats-/Uptime-Monitor, der bei nahendem Ablauf und Handshake-Fehlern alarmiert, als Sicherheitsnetz, auch wenn die Erneuerung automatisiert ist.

Da die Laufzeiten auf 47 Tage sinken, werden manuelle Erinnerungen mathematisch untragbar – Automatisierung ist der einzige Ansatz, der skaliert.

Gemischte Zertifikats-Setups über Subdomains hinweg

Dies unterscheidet sich von Mixed Content (einer HTTPS-Seite, die HTTP-Subressourcen lädt – im Hub behandelt). Mixed-Cert liegt vor, wenn verschiedene Teile Ihrer Website von verschiedenen Zertifikaten mit unterschiedlichen Zeitplänen oder Plattformen geschützt werden. Das häufige Muster: Ihre Hauptdomain hat ein solides Zertifikat, aber blog.example.com läuft auf einer anderen Plattform mit einem eigenen Zertifikat, das nach einem eigenen Zeitplan abläuft, oder eine Marketing-Subdomain auf einem separaten CDN wurde nie von der Single-Label-Grenze des Wildcards abgedeckt, oder SNI-basiertes Multi-Tenant-Hosting unterbricht leise die Erneuerung einer Subdomain, während die Hauptdomain bei einer Stichprobe perfekt aussieht.

Die Lehre: Ein gültiges Vorhängeschloss auf Ihrer Startseite sagt nichts über die Abdeckung anderswo aus. Erstellen Sie ein Subdomain-Inventar, bestätigen Sie, dass jeder Host über eine gültige, überwachte Zertifikatsabdeckung verfügt (über ein eigenes Zertifikat, ein Wildcard, das ihn erreicht, oder ein SAN-Zertifikat, das ihn auflistet), und verlassen Sie sich nicht auf einen einzelnen Hostnamen-SSL-Labs-Check, um das gesamte Eigentum zu zertifizieren.

Häufige Mythen

  • „Ein kostenpflichtiges oder EV-Zertifikat rankt besser als ein kostenloses DV-Zertifikat.“ Nein – das Signal ist schemabasiert; die Validierungstiefe ist für Google unsichtbar.
  • „Wildcard-Zertifikate decken alle Subdomains ab, einschließlich Sub-Subdomains.“ Nein – nur ein DNS-Label; *.example.com deckt foo.bar.example.com nicht ab.
  • „Ein abgelaufenes Zertifikat schadet direkt meinen Rankings.“ Nicht über das Basis-Ranking-Signal – aber es kann Googles normale HTTPS-über-HTTP-Kanonisierungspräferenz zurück auf HTTP kippen (HSTS kann das nicht überschreiben), und separat können genügend HTTPS-Probleme Google dazu veranlassen, das Crawlen Ihrer HTTPS-Seiten ganz einzustellen. Beides sind reale Effekte; keiner läuft über das Ranking-Signal selbst.
  • „Let’s-Encrypt-Zertifikate sind von geringerer Qualität als kostenpflichtige.“ Nein – gleiche Verschlüsselung, gleiche Ranking-Behandlung; der Unterschied ist DV-only-Validierung und kurze (bald Branchenstandard) Laufzeiten.
  • „Wenn meine Startseite ein gültiges Vorhängeschloss zeigt, sind die Zertifikate meiner gesamten Website in Ordnung.“ Nein – Subdomains tragen separate, unterschiedlich terminierte Zertifikate.
  • „Kettenfehler sind selten oder ein Legacy-Problem.“ Nein – sie sind häufig bei jedem Stack, der nur das Blatt ausliefert, und Desktop-Chrome-Caching versteckt sie vor der testenden Person.

Dies ist der tiefe Einblick auf Zertifikatsebene unter dem HTTPS-Hub; für den Migrations-Playbook, Mixed Content und HSTS beginnen Sie dort.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.