HSTS: HTTP Strict Transport Security für SEO

TL;DR — HSTS ist eine kleine Anweisung, die Ihr Server an Browser sendet und die besagt: “Verwenden Sie für meine Website immer HTTPS – niemals einfaches HTTP.” Es schließt ein winziges Sicherheitsloch, das eine normale HTTP→HTTPS-Weiterleitung offen lässt, und es schadet SEO nicht. Aber es ist absichtlich streng: Ist es erst einmal aktiv, führt ein defektes Zertifikat dazu, dass Ihre Website ausfällt, ohne dass Besucher die Warnung umgehen können. Aktivieren Sie es nur, wenn Ihre HTTPS-Einrichtung wirklich solide ist.

Was HSTS ist

Sie wissen bereits, dass Sie HTTPS verwenden sollten – die verschlüsselte, mit Schloss versehene Version Ihrer Website. Die übliche Methode, dies zu erzwingen, ist eine Weiterleitung: Wenn jemand http://yoursite.com eingibt, sendet Ihr Server eine 301-Weiterleitung an https://yoursite.com. Das funktioniert, aber es gibt eine winzige Lücke. Diese allererste Anfrage – die vor der Weiterleitung – läuft weiterhin über unsicheres HTTP. Ein Angreifer im selben Wi-Fi kann in diesem Fenster zuschlagen.

HSTS – HTTP Strict Transport Security – schließt diese Lücke. Es ist eine kurze Anweisung (ein “Header”), die Ihr Server seinen Antworten hinzufügt – aber nur denen, die über eine tatsächlich sichere Verbindung bereitgestellt werden; derselbe Header, der über einfaches HTTP gesendet wird, wird ignoriert, da sonst ein Angreifer ihn einschleusen oder entfernen könnte – die diesem einen Browser mitteilt: für die nächsten wie auch immer vielen Monate versuchen Sie es für diese Website nie wieder mit HTTP – gehen Sie direkt zu HTTPS. Es ist eine Richtlinie, die jeder Browser für sich selbst lernt und speichert, nicht etwas, das Ihren Server verändert. Sobald ein Browser sie gesehen hat, stuft er http://-Links automatisch auf https:// hoch, bevor irgendetwas das Gerät verlässt. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

Hilft oder schadet HSTS SEO?

Weder direkt. HSTS ist eine Sicherheits- und Vertrauensfunktion, kein Ranking-Hebel. Es wird Sie nicht in den Ergebnissen nach oben bringen – aber richtig gemacht schadet es Ihnen auch nicht. Das Einzige, was Sie verstehen müssen, ist, dass HSTS kein Ersatz für Ihre Weiterleitungen ist. Sie benötigen weiterhin Ihre echten serverseitigen 301-Weiterleitungen von HTTP auf HTTPS, denn das ist es, was Google und Bing tatsächlich sehen und verwenden. HSTS funktioniert im Browser für echte menschliche Besucher; Crawler verlassen sich nicht darauf. Behalten Sie beides.

Die eine große Warnung

HSTS ist bewusst unnachgiebig. Sobald ein Browser “gelernt” hat, dass Ihre Website nur über HTTPS erreichbar ist, wird er sich weigern, die Website überhaupt zu laden, wenn Ihr Zertifikat jemals abläuft oder falsch konfiguriert ist – ohne “Trotzdem fortfahren”-Schaltfläche. Das ist der ganze Sinn (es verhindert, dass Angreifer Menschen auf eine gefälschte HTTP-Version locken), aber es bedeutet, dass ein abgelaufenes Zertifikat von “lästige Warnung” zu “Website ist für alle, die sie zuvor besucht haben, nicht erreichbar” wird.

Es gibt auch eine leistungsgesteigerte Version namens Preload, die Ihre Domain direkt in den Browser selbst einbettet. Sie ist großartig, aber später von der Preload-Liste herunterzukommen ist langsam und mühsam – denken Sie an Monate. Preload ist also eine Einbahnstraße: Gehen Sie nur hindurch, wenn Sie sicher sind. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

Möchten Sie die Header-Syntax, die nur im Browser stattfindende interne Weiterleitung, die Crawler nie sehen, die Preload-Anforderungen und die realen Sperrszenarien? Wechseln Sie zum Erweitert-Tab.

TL;DR — HSTS ist der Strict-Transport-Security-Response-Header, der nur beachtet wird, wenn ein Browser ihn über eine sichere Verbindung empfängt, und pro Client als zukünftige Richtlinie für diesen Host gespeichert wird. Er schließt das „Problem der ersten Anfrage“, das eine 301-Weiterleitung allein offen lässt: Die erste HTTP-Anfrage eines neuen Besuchers ist unsicher, bis die Weiterleitung greift – und genau dieses Fenster will ein SSL-Stripping-Angreifer nutzen. Drei Direktiven: max-age (erforderlich, Sekunden), includeSubDomains, preload. Wenn ein Browser HSTS durchsetzt, schreibt er die URI intern auf HTTPS um, bevor irgendeine Anfrage einen Server erreicht – RFC 6797 schreibt keinen bestimmten Statuscode für diese Umschreibung vor, auch wenn Tools sie oft als 307 anzeigen – daher sind Ihre serverseitigen 301-Weiterleitungen weiterhin Pflicht für Suchmaschinen und Linkäquität; HSTS kommt obendrauf, nicht stattdessen. Preload bäckt Ihre Domain über hstspreload.org in den Browser ein (erfordert max-age ≥ 31536000, includeSubDomains und preload) und ist nahezu irreversibel – die Entfernung ist eine separate Einreichung, die Monate braucht, um Nutzer zu erreichen. Und HSTS ist darauf ausgelegt, bei jedem Zertifikatsfehler hart zu scheitern. Aktivieren Sie es also nur, wenn HTTPS auf jeder Subdomain robust ist.

Der HTTPS-Hub stellt HSTS als Schutz auf Browser-Ebene vor, der auf Ihren 301-Weiterleitungen aufbaut. Diese Seite ist der Deep Dive: die exakte Header-Syntax, die interne Weiterleitung, die SEOs verwirrt, die nahezu Irreversibilität der Preload-Liste und die realen Wege, auf denen HSTS Menschen aussperrt.

Das Problem, das HSTS tatsächlich löst: die erste Anfrage

Stellen Sie sich eine ordnungsgemäß migrierte Website vor. Jede http://-URL leitet per 301 auf ihr https://-Pendant weiter, das Zertifikat ist gültig, Kanonische verweisen auf HTTPS. Sieht wasserdicht aus. Ist es aber nicht ganz.

Wenn ein brandneuer Besucher yoursite.com (ohne Schema) eintippt oder auf einen alten http://yoursite.com-Link klickt, geht die erste Anfrage des Browsers über reines HTTP raus. Ihr Server antwortet mit der 301, und jede Anfrage danach ist sicher. Aber dieser eine anfängliche Round-Trip fand im Klartext statt – und genau das ist das Fenster, das ein SSL-Stripping-Angreifer im selben Netzwerk will. Er fängt die HTTP-Anfrage ab, hält das Opfer auf HTTP, während er HTTPS zu Ihrem Server proxyt, und liest oder schreibt alles um.

HSTS eliminiert dieses Fenster für alle, die zuvor zu Besuch waren. web.dev ist direkt zum Mechanismus: “use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (Übersetzung) „Verwenden Sie Strict Transport Security, um Clients mitzuteilen, dass sie sich immer über HTTPS mit Ihrem Server verbinden sollten, auch wenn sie einer http://-Referenz folgen. Das schlägt Angriffe wie SSL-Stripping und vermeidet die Round-Trip-Kosten der 301-Weiterleitung.“ (web.dev). Dieser letzte Satz ist auch für die Leistung wichtig: Ein zurückkehrender Browser überspringt den HTTP→HTTPS-Round-Trip komplett. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: 2026-07-14 MDN: Strict-Transport-Security header

Zwei Randbedingungen, bei denen Präzision wichtig ist. Erstens ist HSTS gespeicherte Richtlinie pro Client – sie lebt im eigenen Zustand dieses einen Browsers für diesen Host, gelernt aus einem Header, der über eine sichere Verbindung geliefert wurde; der gleiche Header, der auf einer HTTP-Antwort gesendet wird, wird schlicht ignoriert (ein Angreifer, der auf reinem HTTP Header injizieren oder entfernen könnte, könnte ihn sonst neutralisieren), und ein Client, der ihn nie empfangen hat – eine frische Installation, ein anderer Browser, ein Crawler – hat keine Richtlinie, die er durchsetzen könnte. Zweitens ist die Umschreibung schema- und portbewusst: Eine implizite Port-80-Anfrage wird zu einer impliziten Port-443-Anfrage, aber wenn die ursprüngliche URI einen expliziten Nicht-Standard-Port nannte, behält der Browser dieselbe Portnummer bei und kontaktiert ihn einfach über HTTPS.

Die Header-Syntax

HSTS ist ein Response-Header mit bis zu drei Direktiven. Laut MDN lauten die Formen:

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

• max-age=<seconds> — erforderlich. “The time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS” (Übersetzung) „Die Zeit in Sekunden, während der sich der Browser merken soll, dass ein Host ausschließlich über HTTPS aufgerufen werden darf.“ (MDN). 31536000 ist ein Jahr; 63072000 sind zwei. Die Uhr setzt sich bei jeder Antwort zurück, die den Header enthält, sodass eine aktive Website ihre Richtlinie kontinuierlich erneuert. Dies ist ein relativer, pro-Client-Zustand: Das bloße Entfernen des Headers löscht ihn nicht sofort – ein Browser, der die Richtlinie bereits gelernt hat, setzt sie weiterhin durch, bis seine gespeicherte max-age abläuft. Um HSTS für Clients, die es bereits gelernt haben, zu deaktivieren, müssen Sie aktiv max-age=0 über eine sichere Antwort ausliefern; der Browser vergisst die Richtlinie dann bei seinem nächsten sicheren Besuch. (max-age=0 löscht nur eine gelernte Richtlinie – es entfernt keine Domain von der separaten Preload-Liste.)
• includeSubDomains — optional. “If this directive is specified, the HSTS policy applies to all subdomains of the host’s domain as well” (Übersetzung) „Wenn diese Direktive angegeben ist, gilt die HSTS-Richtlinie auch für alle Subdomains der Domain des Hosts.“ (MDN). Mächtig und gefährlich in gleichem Maße – siehe die Lockout-Szenarien unten.
• preload — optional. Ein Flag, das Ihre Absicht signalisiert, auf der Browser-Preload-Liste zu stehen. Es bewirkt allein nichts; es ist eine Voraussetzung für die Einreichung bei hstspreload.org. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: 2026-07-17 Chromium: HSTS Preload List Submission

Das Verhalten, wiederum von MDN: “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (Übersetzung) „Vor dem Laden einer http-URL prüft der Browser den Domainnamen gegen seine HSTS-Hosts-Liste. Wenn der Domainname ohne Beachtung der Groß-/Kleinschreibung mit einem HSTS-Host übereinstimmt oder ein Subdomain eines Hosts ist, der includeSubDomains angegeben hat, ersetzt der Browser das URL-Schema durch https.“

Das interne Upgrade, das Crawler nie sehen (das ist der SEO-Kernpunkt)

Hier ist das am meisten missverstandene Detail über HSTS und der Grund, warum es Ihre Redirects nicht ersetzen kann.

Wenn ein Browser eine http://-Anfrage unter HSTS upgradet, schreibt er die URI intern auf HTTPS um, bevor eine Netzwerkanfrage gestellt wird – RFC 6797 verlangt die Schema-Substitution selbst, schreibt aber keinen bestimmten Statuscode dafür vor (RFC 6797 §8.3), sodass ein bestimmter Browser oder ein Crawling-Tool diesen internen Schritt darstellen kann, wie es möchte – viele zeigen ihn als internen 307 an, aber das ist client-/tool-spezifisch, keine Protokollgarantie. Was für SEO zählt, ist einfacher und gilt unabhängig vom Label: Für die HTTP-Version wird kein Server kontaktiert, also sieht kein Crawler sie jemals. Googlebot und Bingbot tragen keine gelernte HSTS-Richtlinie herum, wie es das Chrome eines zurückkehrenden Menschen tut – sie treffen Ihren Server frisch, und was sie dort sehen müssen, ist eine echte, serverseitige 301. Evidence for this claim RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. Scope: RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. Confidence: high · Verified: 2026-07-17 RFC 6797 §8.3 — URI Loading and Port Mapping

Die Regel ist also klar: HSTS ersetzt Ihre serverseitigen 301s nicht. Die 301 ist das, was Suchmaschinen verwenden, um den Protokollwechsel zu verstehen und Signale zu konsolidieren. Google formuliert es so: “301 and other permanent redirects don’t cause a loss in PageRank” (Übersetzung) „301- und andere permanente Weiterleitungen verursachen keinen PageRank-Verlust“ (Quelle). Das reine Browser-interne Upgrade ist eine Benutzererfahrungs- und Sicherheits Schicht darüber. Sie brauchen beides, das verschiedene Aufgaben erfüllt:

• 301 (serverseitig): für Crawler, Indexierung und Link-Equity.
• Internes 307-artiges Upgrade (browserseitig, von HSTS): für zurückkehrende Menschen und SSL-Stripping-Schutz – die genaue Statusdarstellung variiert je nach Client/Tool.

Jeder Leitfaden, der Ihnen sagt, HSTS „übernehme die Weiterleitung, sodass Sie Ihre 301 weglassen können“, ist falsch auf eine Weise, die Sie leise Geld kosten wird.

HSTS-Preload: die nahezu permanente Version

max-age schützt wiederkehrende Besucher, hat aber ein Bootstrap-Problem: Ein Erstbesucher, der Ihren Header noch nie erhalten hat, ist bei dieser ersten Anfrage weiterhin exponiert. Preload löst das, indem es Ihre Domain direkt in die Quelle des Browsers einbettet, sodass der Browser weiß, dass Sie nur HTTPS verwenden, bevor er jemals eine Verbindung hergestellt hat.

Sie melden sich bei hstspreload.org an. Die Anforderungen sind exakt:

1. “Serve a valid certificate.” (Übersetzung) „Stellen Sie ein gültiges Zertifikat bereit.“
2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.” (Übersetzung) „Leiten Sie auf demselben Host von HTTP zu HTTPS weiter, wenn Port 80 aktiv ist.“
3. “Serve all subdomains over HTTPS” (Übersetzung) „Stellen Sie alle Subdomains über HTTPS bereit.“ – einschließlich insbesondere der www-Subdomain, falls ein DNS-Eintrag existiert.
4. In der HTTPS-Antwort der Basisdomain: ein HSTS-Header, bei dem “the max-age must be at least 31536000 seconds (1 year),” (Übersetzung) „max-age muss mindestens 31536000 Sekunden (1 Jahr) betragen.“ “the includeSubDomains directive must be specified,” (Übersetzung) „Die Direktive includeSubDomains muss angegeben sein.“ und “the preload directive must be specified.” (Übersetzung) „Die Direktive preload muss angegeben sein.“ (hstspreload.org)

Deshalb ist das obige Zwei-Jahres-Beispiel (max-age=63072000; includeSubDomains; preload) die Form, die Leute einreichen. Hierbei handelt es sich um die exakten Einreichungsanforderungen von hstspreload.org; behandeln Sie diese als aktuellen Stand, nicht als permanente Konstante, und überprüfen Sie die Live-Seite erneut, bevor Sie einreichen.

Es hilft, vier verschiedene Zustände auseinanderzuhalten, da sie ständig verwechselt werden:

Die Entfernung durchläuft dieselben vier Zustände in umgekehrter Reihenfolge und genauso langsam: Das Entfernen der preload-Direktive aus Ihrem Header macht Sie berechtigt für das Entfernungsformular, dann ist die Einreichung ausstehend, und die Domain bleibt für jeden Nutzer durchgesetzt, der einen Browser-Build verwendet, der sie weiterhin ausliefert – bis dieser Build ausläuft.

Nun der Teil, der Preload in eine Einfach-Tür verwandelt. Von der Einreichungsseite selbst: “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (Übersetzung) „Eine Aufnahme in die Preload-Liste lässt sich nur schwer rückgängig machen. Eine Domain kann zwar entfernt werden, doch bis die Änderung per Chrome-Update bei den Nutzern ankommt, vergehen Monate; für andere Browser gibt es keine Zusicherung.“ (hstspreload.org). Und ihr eigener Rat: “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (Übersetzung) „Beantragen Sie die Aufnahme nur, wenn Sie sicher sind, dass Sie HTTPS langfristig für Ihre gesamte Website und alle Subdomains unterstützen können.“

Praktisch übersetzt: Preload ist eine wirklich großartige Sicherheitsmaßnahme, aber wenn Sie jemals etwas – eine Legacy-Subdomain, eine übernommene Marke, ein internes Tool – wieder über einfaches HTTP ausliefern müssen, sind Sie darauf angewiesen, auf Browser-Release-Zyklen zu warten, die jeden Nutzer erreichen. Kinstas Leitfaden beschreibt die operative Realität deutlich: es kann ein schwieriger und zeitaufwändiger Prozess sein, Ihre Domain entfernen zu lassen. Behandeln Sie Preload als permanent.

Warum HSTS darauf ausgelegt ist, zu schmerzen, wenn etwas schiefgeht

HSTS’ Strenge ist kein Fehler – sie ist die gesamte Sicherheitsgarantie. web.dev beschreibt den Kompromiss: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (Übersetzung) „Clients, die Ihre Website als bekannten HSTS-Host gespeichert haben, werden wahrscheinlich mit einem harten Fehler abbrechen, falls Ihre Website jemals einen Fehler in der TLS-Konfiguration aufweist, etwa ein abgelaufenes Zertifikat. HSTS ist ausdrücklich so konzipiert, dass Netzwerkangreifer Clients nicht zum Zugriff ohne HTTPS verleiten können.“ (web.dev).

Die Schlussfolgerung, die Google zieht, ist der Satz, den ich jedem auf die Haut tätowieren würde, der kurz davor steht, dies zu aktivieren: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (Übersetzung) „Aktivieren Sie HSTS erst, wenn Sie sicher sind, dass Ihr Website-Betrieb robust genug ist, um niemals HTTPS mit Zertifikatsvalidierungsfehlern auszuliefern.“ (web.dev).

„Hard-Fail“ bedeutet genau das: kein „Trotzdem fortfahren“-Link, kein Durchklicken. Auf einer normalen HTTPS-Seite führt ein abgelaufenes Zertifikat zu einer beängstigenden Zwischenseite, die ein entschlossener Benutzer umgehen kann. Auf einem HSTS-Host verweigert der Browser die Verbindung rundweg. Der Fehlermodus einer verpassten Zertifikatsverlängerung ändert also seine Kategorie – von „Verkehrseinbrüche, weil Leute abgeschreckt werden“ zu „die Website ist für jeden wiederkehrenden Besucher unerreichbar“.

Szenarien für echte Aussperrungen

Die Arten, wie HSTS in der Praxis zubeißt, lassen sich fast immer auf includeSubDomains oder Preload zurückführen, die Ihrer tatsächlichen HTTPS-Abdeckung vorausgeeilt sind:

• Die vergessene Subdomain. Sie setzen includeSubDomains auf example.com, aber legacy.example.com (eine alte App, eine Statusseite, ein Hersteller-Tool) spricht nur HTTP oder hat ein Zertifikat, das sie nicht abdeckt. Jeder Browser, der den Header gesehen hat, weigert sich nun, diese Subdomain zu laden. Auf diesem Server hat sich nichts geändert – die Richtlinie hat nach unten gegriffen und sie kaputt gemacht.
• Die Wildcard-Zertifikatslücke. Ein *.example.com-Wildcard deckt foo.example.com ab, aber nicht foo.bar.example.com (ein Wildcard ist eine DNS-Ebene tief). Wenn eine tiefere Subdomain auf HTTP oder ein nicht passendes Zertifikat angewiesen ist, sperrt includeSubDomains sie aus.
• Das abgelaufene Zertifikat auf einem HSTS-Host. Die Erneuerungsautomatisierung schlägt fehl, das Zertifikat verfällt, und statt einer umgehbaren Warnung erhalten Sie eine Website, die für alle down ist, deren Browser sich Ihre Richtlinie merkt – bis Sie ein gültiges Zertifikat zurückbekommen und diese sich erneut verbinden und eine frische sichere Antwort erhalten. Es gibt keine schnellere Überschreibung.
• Preload-Reue. Sie haben Preload aktiviert, dann erzwingt ein Geschäftsbedarf einen reinen HTTP-Dienst unter der Domain. Das Zurückrollen sind zwei getrennte, nicht sofort wirksame Aufgaben, nicht eine: Das Ausliefern von max-age=0 über HTTPS löscht nur die gelernte Richtlinie für Clients, die sich erneut verbinden, bevor ihre alte max-age ohnehin abgelaufen wäre, während das Entfernen der Domain aus der Preload-Liste eine eigene Einreichung ist, die dennoch Browser-Release-Zyklen – Monate – braucht, um die Nutzer zu erreichen, unabhängig von allem, was Sie auf Ihrem Server ändern.
• Lokale Dev-/Staging-Kollisionen. Das Preloaden von example.com mit includeSubDomains kann dazu führen, dass dev.example.com oder ein localhost-artiger interner Host unter derselben Apex-Domain HTTP verweigert und lokale Arbeitsabläufe auf überraschende Weise stört.

Keiner dieser Punkte ist ein Grund, HSTS zu vermeiden. Sie sind Gründe, es stufenweise einzuführen: zuerst kurze max-age, includeSubDomains erst nach der Prüfung jeder Subdomain hinzufügen und preload für den Moment reservieren, in dem Sie sicher sind.

HSTS ist kein Ranking-Faktor (und berührt keine Kanonisierung)

Um das SEO-Framing klarzustellen: HSTS ist kein Ranking-Signal. HTTPS selbst ist ein bewusst winziges – Google nannte es ein “very lightweight signal”, das weniger als 1 % der Suchanfragen betrifft – und HSTS ist eine Ebene über HTTPS, kein separates Ranking-Eingabeelement. Es steuert auch nicht direkt Kanonisierung oder Indexierung. Googles eigene Dokumentation ist jedoch spezifischer als ein pauschales “spielt keine Rolle”: Google bevorzugt HTTPS als kanonisch gegenüber einer äquivalenten HTTP-Seite, außer wenn ein ungültiges Zertifikat vorliegt, unsichere Seitenabhängigkeiten bestehen, eine HTTPS-Seite zu HTTP weiterleitet oder ein HTTP-rel="canonical"-Tag vorhanden ist (Google: Konsolidierung doppelter URLs). HSTS kann nichts davon beheben oder überschreiben. Es ist eine browser-seitige Richtlinie ohne Einfluss auf Googles Kanonisierungslogik – ein schlechtes Zertifikat oder eine defekte Weiterleitungskette kann Google trotzdem in Richtung einer HTTP-Kanonisierung drängen, unabhängig davon, was Ihr HSTS-Header aussagt. Die Kanonisierung wird durch Ihre 301-Weiterleitungen, Ihr Zertifikat, Ihr rel="canonical" und Ihre internen Links bestimmt – HSTS verdient seinen Platz aus Gründen der Sicherheit, des Nutzervertrauens und der Schließung der SSL-Stripping-Lücke – tun Sie es aus diesen Gründen, halten Sie Ihre 301-Weiterleitungen und Ihr Zertifikat wirklich solide, und Sie werden HSTS selbst in keinem Ranking-Bericht sehen, egal wie.

Wenn Sie den umfassenderen HTTP→HTTPS-Umzug durchführen, ist HSTS das Letzte, was Sie aktivieren, nicht das Erste – es gehört nach der Migration, sobald sich alles beruhigt hat, als Teil der breiteren Site-Migration-Disziplin.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• HSTS = der Strict-Transport-Security-Antwortheader. Er weist Browser an, für Ihre Domain immer HTTPS zu verwenden, und schließt das “Problem der ersten Anfrage”, das eine 301-Weiterleitung allein offen lässt – die anfängliche HTTP-Anfrage eines neuen Besuchers ist unsicher, bis die Weiterleitung greift, was das SSL-Stripping-Fenster darstellt.
• Drei Direktiven: max-age (erforderlich, Sekunden; wird bei jeder Antwort zurückgesetzt; das Entfernen des Headers löscht keine gelernte Richtlinie – Sie müssen stattdessen max-age=0 über HTTPS ausliefern), includeSubDomains (gilt für alle Subdomains) und preload (ein Flag, um sich für die Browser-Preload-Liste zu entscheiden – Token vorhanden, berechtigt, eingereicht und tatsächlich gelistet sind vier getrennte Zustände).
• Der Kern der internen Aktualisierung: Wenn ein Browser HSTS durchsetzt, schreibt er die URI intern auf HTTPS um, bevor eine Anfrage einen Server erreicht – RFC 6797 schreibt keinen spezifischen Statuscode für diese Umschreibung vor, obwohl Tools sie oft als 307 anzeigen – sodass kein Server sie sieht und Crawler sie nie sehen. Ihre serverseitigen 301-Weiterleitungen sind weiterhin obligatorisch für Suchmaschinen und Link-Equity. HSTS kommt zu Ihren 301-Weiterleitungen hinzu, niemals an ihrer Stelle.
• Preload kodiert Ihre Domain fest im Browser über hstspreload.org (erfordert max-age ≥ 31536000, includeSubDomains und preload). Es ist nahezu irreversibel – die Entfernung ist eine separate Einreichung, die Monate braucht, um Nutzer zu erreichen, Browser für Browser.
• Konzipiert für hartes Scheitern: Ein HSTS-Host mit defektem/abgelaufenem Zertifikat verweigert das Laden, ohne Durchklick-Option. Google: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (Übersetzung) „Aktivieren Sie HSTS erst, wenn Sie sicher sind, dass Ihr Website-Betrieb robust genug ist, um niemals HTTPS mit Zertifikatsvalidierungsfehlern bereitzustellen.“
• Lockout-Szenarien konzentrieren sich auf includeSubDomains und Preload, die Ihre HTTPS-Abdeckung überholen: vergessene HTTP-Subdomains, Wildcard-Zertifikat-Tiefenlücken, abgelaufene Zertifikate, Preload-Reue und Staging-Kollisionen.
• Kein Ranking-Signal – und kann die Kanonisierung nicht überschreiben. Google bevorzugt HTTPS als kanonisch, außer wenn ein Zertifikat ungültig ist, Abhängigkeiten unsicher sind, eine HTTPS-Seite zu HTTP weiterleitet oder das kanonische Tag auf HTTP zeigt – und HSTS hat keine Macht, etwas davon zu beheben oder zu überschreiben. Lassen Sie Ihre 301-Weiterleitungen, Zertifikate und kanonischen Tags die SEO-Arbeit erledigen.

Offizielle Dokumentation

Primärquellen-Dokumentation von Browser- und Standardisierungs-Teams.

Google / web.dev

• HTTPS auf Ihren Servern aktivieren (web.dev) – der HSTS-Abschnitt: der Header, SSL-Stripping, die Hard-Fail-Warnung und „Aktivieren Sie HSTS erst, wenn Sie sicher sind.“
• Site-Umzüge mit URL-Änderungen – warum der serverseitige 301 weiterhin Pflicht ist (Redirects verlieren kein PageRank).
• Page Experience verstehen – wo HTTPS (und damit HSTS) in Googles Framing steht.

Standards & Browser-Referenzen

• MDN – Strict-Transport-Security – vollständige Header-Syntax, die drei Direktiven und wie der Browser das Schema hochstuft.
• RFC 6797 – HTTP Strict Transport Security (HSTS) – die ursprüngliche Spezifikation.
• HSTS-Preload-Liste – Einreichung (hstspreload.org) – die genauen Preload-Anforderungen und die Hinweise zur Entfernung, gepflegt vom Chromium-Projekt.

Zitate aus der Quelle

Öffentliche Aussagen von Google/web.dev und dem Chromium-Preload-Dienst. Jeder Link springt zu (oder zeigt auf) die zitierte Passage auf der Quellseite.

web.dev (Google) – was HSTS tut und die Warnungen

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (Übersetzung) „Nutzen Sie HTTP Strict Transport Security (HSTS), um die Kosten des 301-Redirects zu vermeiden.“ Zum Zitat springen
• “First, use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirect.” (Übersetzung) „Verwenden Sie zuerst Strict Transport Security, um Clients mitzuteilen, dass sie sich immer über HTTPS mit Ihrem Server verbinden sollten, auch wenn sie einer http://-Referenz folgen. Dies vereitelt Angriffe wie SSL-Stripping und vermeidet die Round-Trip-Kosten des 301-Redirects.“ Zum Zitat springen
• “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (Übersetzung) „Clients, die Ihre Website als bekannten HSTS-Host gelistet haben, werden wahrscheinlich hart fehlschlagen, wenn Ihre Website jemals einen Fehler in ihrer TLS-Konfiguration hat (z. B. ein abgelaufenes Zertifikat). HSTS ist ausdrücklich so konzipiert, dass Netzwerkangreifer Clients nicht dazu verleiten können, auf die Website ohne HTTPS zuzugreifen.“ Zum Zitat springen
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (Übersetzung) „Aktivieren Sie HSTS erst, wenn Sie sicher sind, dass Ihr Website-Betrieb robust genug ist, um niemals HTTPS mit Zertifikatsvalidierungsfehlern bereitzustellen.“ Zum Zitat springen

Chromium-Preload-Dienst – hstspreload.org

• “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (Übersetzung) „Beachten Sie, dass die Aufnahme in die Preload-Liste nicht einfach rückgängig gemacht werden kann. Domains können entfernt werden, aber es dauert Monate, bis eine Änderung Benutzer mit einem Chrome-Update erreicht, und wir können keine Garantien für andere Browser geben.“ Quelle
• “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.” (Übersetzung) „Beantragen Sie die Aufnahme nicht, es sei denn, Sie sind sicher, dass Sie HTTPS für Ihre gesamte Website und alle ihre Subdomains langfristig unterstützen können.“ Quelle

MDN – das Header-Verhalten

• “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.” (Übersetzung) „Bevor der Browser eine http-URL lädt, prüft er den Domainnamen gegen seine HSTS-Hosts-Liste. Wenn der Domainname ohne Beachtung der Groß-/Kleinschreibung mit einem HSTS-Host übereinstimmt oder eine Subdomain eines Hosts ist, der includeSubDomains angegeben hat, ersetzt der Browser das URL-Schema durch https.“ Quelle

Sollte ich HSTS aktivieren – und wie weit?

Gehen Sie es von oben nach unten durch. Jedes „Nein“ ist ein Stoppschild, kein Vielleicht. Eine Unterscheidung, bevor Sie beginnen: Die genauen max-age-Werte unten (ein paar Minuten für einen Canary, ein Jahr für einen Ruhezustand) sind Patricks operative Staging-Empfehlungen, keine Protokollanforderungen – die einzige harte numerische Anforderung ist das Preload-Minimum von hstspreload.org (max-age ≥ 31536000), das an diesem Schritt ausdrücklich erwähnt wird. Passen Sie die Staging-Dauern an Ihre eigene Risikotoleranz und Ihren Deployment-Rhythmus an.

1. Ist Ihre gesamte Website bereits über HTTPS mit einem gültigen Zertifikat erreichbar und ist die Migration abgeschlossen?

• Nein → Fassen Sie HSTS noch nicht an. Schließen Sie zuerst die HTTPS-Migration ab: Leiten Sie jede URL per 301 weiter, beheben Sie Mixed Content, prüfen Sie in der Search Console. HSTS ist der letzte Schalter, nicht der erste.
• Ja → weiter.

2. Ist Ihre Zertifikatsverlängerung automatisiert und überwacht (damit ein Ablauf Sie nicht überraschen kann)?

• Nein → Beheben Sie das zuerst. Auf einem HSTS-Host ist ein abgelaufenes Zertifikat ein harter Ausfall, keine Warnung. Richten Sie Auto-Verlängerung + Ablaufwarnung ein, dann weiter.
• Ja → weiter. Aktivieren Sie eine kurze max-age (z. B. ein paar Minuten bis einen Tag) ohne includeSubDomains und bestätigen Sie, dass nichts bricht.

3. Haben Sie jede Subdomain geprüft – einschließlich www, Legacy-Apps, Statusseiten und Vendor-Hosts – und bestätigt, dass jede gültiges HTTPS ausliefert?

• Nein → Lassen Sie includeSubDomains aus. Wenn Sie es jetzt hinzufügen, würde es nach unten greifen und jede HTTP-only- oder Zertifikatsfehlanpassungs-Subdomain brechen.
• Ja → Erhöhen Sie max-age auf etwa ein Jahr und fügen Sie includeSubDomains hinzu. Das ist ein sicherer, starker Ruhezustand für die meisten Websites.

4. Möchten Sie auch die Lücke beim allerersten Besuch schließen, und sind Sie sicher, dass Sie unter dieser Domain nie wieder etwas über reines HTTP ausliefern müssen?

• Nein / unsicher → Stoppen Sie hier. max-age=31536000; includeSubDomains (ohne Preload) ist eine ausgezeichnete Haltung. Der marginale Gewinn von Preload ist seine Irreversibilität nicht wert, wenn Sie unsicher sind.
• Ja, sicher → Fügen Sie das preload-Flag hinzu und reichen Sie es bei hstspreload.org ein. Behandeln Sie es als dauerhaft – die Entfernung dauert Monate, bis sie die Nutzer erreicht.

Separater, immer gültiger Zweig: Kann ich meine 301-Weiterleitungen weglassen, wenn ich HSTS aktiviere?

• Nie. Crawler sehen das reine Browser-interne Upgrade von HSTS nicht. Behalten Sie Ihre serverseitigen 301-Weiterleitungen, egal wie tief Sie in diesem Baum gehen.

HSTS-Rollout-Checkliste

Arbeiten Sie von oben nach unten – jede Stufe ist die Voraussetzung für die nächste. Die gestaffelten Dauern hier sind operative Empfehlungen, keine Protokollanforderungen – die einzige harte Zahl ist das Preload-Minimum von max-age ≥ 31536000 in Stufe 3.

Bevor Sie etwas aktivieren

• Die gesamte Website (Apex + www + alle Subdomains) liefert HTTPS mit einem gültigen Zertifikat aus.
• HTTP→HTTPS 301-Weiterleitungen sind serverseitig eingerichtet, eins zu eins.
• Die automatische Zertifikatsverlängerung ist konfiguriert und es gibt eine Ablaufüberwachung/-warnung.
• Die HTTP→HTTPS-Migration ist abgeschlossen (Search Console sauber, kein Ranking-Absturz).

Stufe 1 – Sicherheit nachweisen

• Fügen Sie Strict-Transport-Security mit einer kurzen max-age (Minuten bis einen Tag) hinzu.
• Noch kein includeSubDomains und noch kein preload.
• Bestätigen Sie, dass die Website in allen Browsern normal lädt und nichts kaputtgegangen ist.

Stufe 2 – Verbindlichkeit

• Erhöhen Sie max-age auf mindestens 31536000 (ein Jahr).
• Prüfen Sie jede Subdomain (einschließlich www, Legacy, Status, Vendor) auf gültiges HTTPS.
• Erst nach bestandener Prüfung fügen Sie includeSubDomains hinzu.
• Testen Sie erneut, dass jede Subdomain über HTTPS lädt.

Stufe 3 – Preload (optional, nahezu dauerhaft)

• Sie sind sicher, dass Sie unter dieser Domain nie wieder HTTP benötigen.
• Der Header ist max-age=31536000 (oder mehr) ; includeSubDomains; preload.
• HTTP auf Port 80 leitet auf HTTPS auf demselben Host weiter.
• Reichen Sie bei hstspreload.org ein und bestätigen Sie den Status.

Immer wahr – nicht überspringen

• Serverseitige 301er bleiben bestehen (Crawler sehen niemals das reine Browser-Upgrade).
• Sie haben einen dokumentierten Rollback-Plan: max-age=0, über HTTPS ausgeliefert, löscht eine gelernte (nicht vorinstallierte) Richtlinie für Clients, die sich erneut verbinden, bevor sie ohnehin abgelaufen wäre. Vorinstallierte Domains benötigen stattdessen den separaten, langsameren Entfernungsprozess.

Die mentalen Modelle

1. HSTS ist eine Schicht, kein Ersatz. Serverseitiger 301 = für Crawler und Link-Equity. Browser-seitiges internes Upgrade (durch HSTS, oft als 307 angezeigt, obwohl die RFC diesen genauen Code nicht vorschreibt) = für wiederkehrende Menschen und SSL-Stripping-Schutz. Unterschiedliche Zielgruppen, unterschiedliche Aufgaben. Sie brauchen immer beides; HSTS subtrahiert niemals einen 301.

2. HSTS schließt eine Lücke, die der 301 nicht kann. Ein 301 schützt die zweite Anfrage und alle weiteren. Die erste Anfrage – bevor die Weiterleitung greift – ist immer noch HTTP. HSTS (für wiederkehrende Besucher) und Preload (für Erstbesucher) sind die einzigen Dinge, die dieses spezifische Fenster schließen.

3. Schrittweise erhöhen, niemals springen. max-age kurz → lang. Nackter Header → includeSubDomains (nach einem Subdomain-Audit) → preload (nur wenn sicher). Jede Stufe ist umkehrbar, außer der letzten. Überspringen Sie keine Stufen, um Zeit zu sparen.

4. Strenge ist das Feature, und sie wirkt in beide Richtungen. Derselbe harte Fehlschlag, der einen Angreifer stoppt, stoppt auch Sie, wenn ein Zertifikat bricht. Die Voraussetzung ist also nicht „Wollen Sie Sicherheit?“ – das will jeder –, sondern „Ist Ihr Zertifikatsbetrieb robust genug, um niemals zu versagen?“

5. Preload ist eine Einbahnstraße. Nicht-vorinstalliertes HSTS kann für einen Client gelockert werden, wenn er das nächste Mal eine sichere Anfrage stellt und max-age=0 erhält – nicht schneller, und nur für Clients, die sich erneut verbinden. Preload geht einen Schritt weiter: Die Entfernung ist eine separate Einreichung, die Monate dauert, bis sie die Nutzer erreicht, Browser-Release für Browser-Release. Legen Sie es in die Kategorie „Entscheidungen, die wir nicht leicht zurücknehmen können“ und behandeln Sie es entsprechend.

6. HSTS ist orthogonal zu Rankings – kann aber auch kein schlechtes Canonical-Signal retten. Es ist kein Ranking-Signal und steuert weder Canonicalisierung noch Indexierung direkt. Bewerten Sie es nach Sicherheit und Vertrauen, nicht nach SEO-Vorteil – den gibt es nicht. Aber es ist auch kein Sicherheitsnetz: Die HTTPS-Canonical-Präferenz von Google weicht weiterhin zurück bei einem schlechten Zertifikat, unsicheren Abhängigkeiten, einer HTTPS→HTTP-Weiterleitung oder einem HTTP-Canonical-Tag, und HSTS hat keine Macht, das zu überschreiben.

HSTS – Spickzettel

Die Header-Direktiven

Häufige Header-Werte (die Staging-Zahlen unten sind operative Vorschläge, keine Protokollanforderungen – das harte Minimum ist die Preload-Zeile)

Weiterleitungen: welche, wer sieht sie

Schnelle Fakten

• Preload erfordert max-age ≥ 31536000 + includeSubDomains + preload – verifiziert gegen die aktuellen veröffentlichten Anforderungen von hstspreload.org.
• Die Entfernung von Preload ist eine separate Einreichung, die Monate dauert, bis sie Browser für Browser bei den Nutzern ankommt – als dauerhaft behandeln.
• Auf einem HSTS-Host bedeutet ein defektes Zertifikat harter Fehlschlag, kein Durchklicken.
• HSTS ist kein Ranking-Signal und ersetzt nicht Ihre 301er.

HSTS-Header setzen

Fügen Sie den Header nur im HTTPS-Serverblock hinzu und beginnen Sie mit einer kurzen max-age, bis Sie bestätigt haben, dass nichts bricht. Fügen Sie ; preload nur hinzu, wenn Sie bei hstspreload.org einreichen möchten – es ist nahezu irreversibel.

Apache (.htaccess)

<IfModule mod_headers.c>
  # Start short (300s) to prove it's safe; raise to 31536000 once confident.
  Header always set Strict-Transport-Security "max-age=300"
  # Full posture once every subdomain is verified HTTPS:
  # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  # Only add ; preload when submitting to hstspreload.org:
  # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Nginx

# On the HTTPS (listen 443) server block:
add_header Strict-Transport-Security "max-age=300" always;
# Full posture once subdomains are verified:
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Preload shape (near-irreversible):
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Prüfen, ob HSTS gesetzt ist (und auslesen)

macOS / Linux

# Print only the Strict-Transport-Security response header
curl -sI https://example.com/ | grep -i strict-transport-security
# → strict-transport-security: max-age=31536000; includeSubDomains

Windows (PowerShell)

# Same check in PowerShell
(Invoke-WebRequest -Uri "https://example.com/" -Method Head).Headers["Strict-Transport-Security"]

HSTS-Eintrag in Chrome prüfen und löschen (DevTools / net-internals)

Wenn Sie testen und ein Browser eine HSTS-Richtlinie „gelernt“ hat, die Sie löschen müssen:

1. Open a new tab and visit:  chrome://net-internals/#hsts
2. Under "Query HSTS/PKP domain", enter your host to see the stored policy.
3. Under "Delete domain security policies", enter the host and Delete.
   (This clears the *learned* policy — it does NOT remove a *preloaded* domain,
   which lives in the browser binary and can't be cleared this way.)

Verwenden Sie dies, um zu bestätigen, dass Ihr Header tatsächlich gespeichert wird, und um einen Test-Host zurückzusetzen – nicht als Fix für die Produktion, wo die Antwort darin besteht, aktiv max-age=0 über HTTPS auszuliefern (das bloße Entfernen des Headers löscht keine Richtlinie, die ein Client bereits gelernt hat; sie wirkt erst, wenn dieser Client sich erneut verbindet und die max-age=0-Antwort erhält).

HSTS-Fehler, die wehtun

1. Ihre 301er weglassen, weil „HSTS das übernimmt.“ Der Klassiker. Der HSTS-Redirect ist ein reines Browser-internes Upgrade, das Crawler nie sehen. Entfernen Sie Ihre serverseitigen 301er und Suchmaschinen verlieren das Signal, das Ihren Wechsel konsolidiert. Behalten Sie immer beides.

2. includeSubDomains aktivieren, bevor Subdomains auditiert werden. Der häufigste Weg, eine Subdomain offline zu nehmen. Wenn irgendeine Subdomain – eine Legacy-App, eine Statusseite, ein Vendor-Host, www selbst – nicht auf gültigem HTTPS läuft, greift die Richtlinie hinunter und bricht sie für jeden Browser, der den Header gesehen hat.

3. Am ersten Tag direkt auf ein einjähriges max-age (oder Preload) springen. Kein Sicherheitsnetz. Kurz starten (max-age=300), bestätigen, dass nichts bricht, dann hochschrauben. Ein langes max-age, das auf einer falsch konfigurierten Website gesetzt wird, ist ein selbstverschuldeter Ausfall, der ein Jahr lang in Browsern hängen bleibt.

4. Preloading vor HTTPS ist wirklich wasserdicht. Preload ist nahezu unumkehrbar – die Entfernung dauert Monate. Googles eigene Aussage: aktivieren Sie HSTS erst, wenn Sie sicher sind, dass Ihr Website-Betrieb robust genug ist. Preload vervielfacht dieses Risiko.

5. Ein abgelaufenes Zertifikat als geringfügiges Problem behandeln. Auf einer Nicht-HSTS-Website ist ein abgelaufenes Zertifikat eine umgehbare Warnung. Auf einem HSTS-Host ist es ein harter Ausfall ohne Durchklick-Option. Wenn Sie HSTS aktivieren, werden Zertifikatserneuerungsautomatisierung und Ablaufwarnungen von netten Extras zu Notwendigkeiten.

6. Den Header in der HTTP-Antwort setzen. Browser ignorieren HSTS, das über HTTP ausgeliefert wird (bewusst – ein Angreifer könnte es einschleusen oder entfernen). Es muss in der HTTPS-Antwort gesendet werden, um zu zählen.

7. Die Tiefenbegrenzung des Wildcard-Zertifikats vergessen. Ein *.example.com-Wildcard deckt foo.bar.example.com nicht ab. Aktivieren Sie includeSubDomains und jede tiefere Subdomain, die auf dieses Zertifikat angewiesen ist, wird ausgesperrt.

Incident-Playbook: Ein HSTS-Host ist ausgesperrt

1. Bestätigen Sie den Fehler aus einem sauberen Netzwerk und mit mehr als einem Browser. Notieren Sie die betroffenen Hostnamen und den genauen Zertifikatsfehler. Eine gespeicherte HSTS-Richtlinie kann dazu führen, dass sich das Symptom zwischen wiederkehrenden und erstmaligen Besuchern unterscheidet.
2. Stellen Sie zuerst gültiges HTTPS wieder her. Wenn das Zertifikat abgelaufen, nicht passend oder ohne Zwischenzertifikat ist, erneuern oder ersetzen Sie es und stellen Sie die vollständige Kette bereit. Ein HSTS-Browser bietet keinen sicheren HTTP-Umgehungsweg an.
3. Kartieren Sie den Richtlinienumfang. Prüfen Sie den Live-Strict-Transport-Security-Header und bestimmen Sie, ob includeSubDomains oder Preload den Ausfall über den Hostnamen hinaus ausdehnt, der ihn gesendet hat.
4. Erfassen Sie alle betroffenen Subdomains. Stellen Sie für einen vergessenen HTTP-only-Host ein gültiges Zertifikat und einen HTTPS-Endpunkt davor, bevor Sie entscheiden, ob Sie den Dienst behalten, migrieren oder umleiten.
5. Korrigieren Sie die Richtlinie erst, nachdem der Zugriff wiederhergestellt ist. Wenn der Umfang unsicher ist, reduzieren oder entfernen Sie den Header in HTTPS-Antworten. Das löscht nicht sofort eine bereits von Browsern zwischengespeicherte Richtlinie, und die Preload-Entfernung ist ein separater, langsamer Prozess.
6. Verifizieren Sie die Wiederherstellung. Testen Sie die Apex-Domain, www und jede betroffene Subdomain auf eine gültige Kette, korrekten Hostnamen, HTTP→HTTPS-Weiterleitung mit einem Hop und den beabsichtigten HSTS- Header. Behalten Sie die Zertifikatsablauf-Überwachung im selben Inventar bei.

Reißen Sie die HTTP-Weiterleitung nicht ab und weisen Sie Benutzer nicht an, die Warnung zu umgehen. Die dauerhafte Lösung ist ein gültiger HTTPS-Endpunkt überall dort, wo die aktive HSTS-Richtlinie reicht.

Eine Live-HSTS-Richtlinie prüfen

Act as a security-minded technical SEO. Review this Strict-Transport-Security
header, the HTTP redirect response, and the supplied subdomain inventory.

For the header, parse max-age, includeSubDomains, and preload. Explain the effective
scope, identify subdomains whose HTTPS or certificate coverage is unproven, and
separate browser-side HSTS behavior from the server-side 301 search engines need. Use
GET requests (HEAD can behave differently on some servers/clients), and record which
client or tool produced each observation and its version, since internal-redirect
representation is client/tool-specific rather than a fixed protocol value.

Recommend the next rollout stage: keep a short max-age canary, lengthen max-age,
add includeSubDomains, or consider preload. Do not recommend preload unless the
evidence shows a valid certificate, same-host HTTP→HTTPS redirects, HTTPS on every
subdomain, max-age of at least 31536000, includeSubDomains, and the preload token.

Return: observed configuration, risks, blocking evidence, next action, rollback
constraint, and exact validation checks.

HSTS-Aussperrung triagieren

Given the affected hostnames, browser error, certificate details, DNS/CDN layout,
and live response headers, identify whether this is an expired certificate, hostname
mismatch, incomplete chain, includeSubDomains spillover, or preload issue. Prioritize
restoring valid HTTPS. Explain why removing a header does not immediately erase a
cached browser policy, then provide recovery and verification steps.

HSTS-Inspektionswerkzeuge

• HTTP Header Checker – den Live- Strict-Transport-Security-Header prüfen und bestätigen, dass er in HTTPS-Antworten erscheint.
• curl -I – die HTTP-Weiterleitung mit dem HTTPS-Header vergleichen, ohne sich auf den gespeicherten HSTS-Zustand eines Browsers zu verlassen.
• Browser-DevTools – die endgültigen Antwortheader und den Zertifikatsfehler bestätigen, den ein echter Client sieht.
• HSTS-Preload-Status – die Einreichungsanforderungen prüfen und ob die Domain bereits im Preload-Prozess vertreten ist.

Verwenden Sie mindestens zwei Ansichten: Die Befehlszeilenausgabe zeigt die Serverantwort, während ein Browser auch clientseitige Durchsetzung und harte Zertifikatsfehler offenlegt. Bevorzugen Sie GET gegenüber HEAD beim Vergleich von Werkzeugen – einige Server und Clients stellen die beiden unterschiedlich dar – und notieren Sie den genauen Client/das genaue Werkzeug/die genaue Version hinter jeder Messung.

Gestaffelte HSTS-Rollout-Tests

Test 0: Die Zustandsmatrix (vor dem Staging von Änderungen ausführen)

Der HSTS-Status ist keine einzelne Tatsache – es sind mehrere unabhängige Zustände, die widersprüchlich sein können. Erfassen Sie jeden Zustand getrennt pro Hostname:

Halten Sie für jede Beobachtung Client, Tool und Version fest – die Darstellung interner Weiterleitungen und die Durchsetzung von HSTS variieren zwischen Browsern, Crawlern und Befehlszeilen-Tools, und eine veraltete Messung von einem Client kann wie ein Widerspruch aussehen, der in Wirklichkeit keiner ist.

Test 1: Kurzer max-age-Canary

• Zweck: Nachweisen, dass der Header nur von gesunden HTTPS-Antworten ausgegeben wird, bevor Clients auf eine lange Richtlinie festgelegt werden.
• Methode: Überprüfen Sie repräsentative Vorlagen und Hosts mit dem HTTP Header Checker und curl -I; vergleichen Sie den bereitgestellten Wert mit der genehmigten Canary-Konfiguration.
• Erwartetes Ergebnis: HTTPS-Antworten tragen die beabsichtigte kurze max-age; HTTP gibt weiterhin eine serverseitige permanente Weiterleitung auf HTTPS zurück.
• Fehlerauslöser: Fehlende oder doppelte Header, eine unerwartet lange Dauer, Zertifikatsfehler oder jede Weiterleitungsschleife.
• Nächster Schritt: Beheben Sie den Header oder den HTTPS-Endpunkt und behalten Sie den Rollout in der Canary-Phase.

Test 2: includeSubDomains-Bereitschaft

• Zweck: Verhindern, dass eine Elternrichtlinie einen vergessenen Hostnamen aussperrt.
• Methode: Testen Sie jeden DNS-Hostnamen im gepflegten Subdomain-Inventar auf eine gültige HTTPS-Antwort, korrekten Zertifikatsnamen und vollständige Kette.
• Erwartetes Ergebnis: Jede in Frage kommende Subdomain funktioniert über HTTPS, einschließlich Legacy-, Anbieter-, Entwicklungs- und tieferer Hosts.
• Fehlerauslöser: Jeder reine HTTP-Dienst, abgelaufenes oder falsches Zertifikat oder ein im Inventar fehlender Hostname.
• Nächster Schritt: Beheben oder verschieben Sie den Host, bevor Sie includeSubDomains hinzufügen.

Test 3: Preload-Bereitschaft

• Zweck: Überprüfen, ob die nahezu permanente Richtlinie die dokumentierten Einreichungsanforderungen erfüllt.
• Methode: Bestätigen Sie ein gültiges Zertifikat, HTTP→HTTPS-Weiterleitungen auf demselben Host, HTTPS auf allen Subdomains und einen Apex-Header mit max-age von mindestens 31536000, includeSubDomains und preload.
• Erwartetes Ergebnis: Jede Anforderung ist erfüllt und die Organisation akzeptiert den langsamen Entfernungsweg.
• Fehlerauslöser: Jede fehlgeschlagene technische Anforderung oder ein ungelöster Bedarf für eine reine HTTP-Subdomain.
• Nächster Schritt: Nicht einreichen; bei der reversiblen gestuften Richtlinie bleiben.

Ressourcen, die Ihre Zeit wert sind

Mein Vortrag

• Bei HTTPS ist Vorsicht besser als Nachsicht — SMX East 2016 (SlideShare) — mein Deep-Dive zu TLS, häufigen HTTPS-Implementierungsfehlern und den Migrationsfallen, die HSTS sowohl schließt als auch verstärken kann. (Der übliche Haftungsausschluss gilt: Es ist mein Verständnis dieser Systeme, und die darin enthaltenen Akzeptanzstatistiken stammen aus dem Jahr 2016.)

Meine weiterführenden Artikel

• Der Anfängerleitfaden für technisches SEO – wo HTTPS und HSTS in das größere Bild passen.

Aus der Branche

• Aktivieren Sie HTTPS auf Ihren Servern (web.dev) – Googles eigene HSTS-Anleitung: der Header, SSL-Stripping und die Hard-Fail-Warnung.
• MDN – Strict-Transport-Security – die maßgebliche Header-Referenz: Syntax, Direktiven und Schema-Upgrade-Verhalten.
• HSTS-Preload-Listeneinreichung (hstspreload.org) – die Preload-Anforderungen des Chromium-Projekts und die Hinweise zur nahezu Unumkehrbarkeit.
• RFC 6797 – HTTP Strict Transport Security – die ursprüngliche Spezifikation, für den Fall, dass Sie den genauen Wortlaut einer Direktive benötigen.
• HSTS – Was es ist und wie man es verwendet (Kinsta) – ein praktischer Implementierungsleitfaden, der die interne Weiterleitung auf Browserebene, die Preload-Liste und die Risiken der Bindung abdeckt.
• SSL Labs Server Test (Qualys) – bewerten Sie Ihre TLS-Konfiguration und bestätigen Sie, dass HSTS korrekt ausgeliefert wird.

Statistiken und harte Fakten, die es wert sind, zitiert zu werden

• Preload erfordert max-age ≥ 31536000 (1 Jahr), includeSubDomains und preload. Die genaue, nicht verhandelbare Einreichungshürde für die im Browser integrierte Liste. Quelle
• Die Entfernung aus der Preload-Liste dauert Monate, bis sie die Nutzer erreicht. Vom Einreichungsdienst: “inclusion in the preload list cannot easily be undone… it takes months for a change to reach users with a Chrome update.” (Übersetzung) „Die Aufnahme in die Preload-Liste kann nicht einfach rückgängig gemacht werden… es dauert Monate, bis eine Änderung die Nutzer mit einem Chrome-Update erreicht.“ Dies ist die Zahl, die Preload zu einer Einbahnstraße macht. Quelle
• HSTS-Hosts schlagen bei jedem TLS-Fehler hart fehl. web.dev: Clients, die Ihre Website als HSTS-Host kennen, “are likely to hard-fail if your site ever has an error in its TLS configuration.” (Übersetzung) „werden wahrscheinlich hart fehlschlagen, wenn Ihre Website jemals einen Fehler in ihrer TLS-Konfiguration hat.“ Kein Durchklicken – ein abgelaufenes Zertifikat wird zum Ausfall. Quelle
• HTTPS selbst ist “a very lightweight signal—affecting fewer than 1% of global queries.” (Übersetzung) „ein sehr leichtgewichtiges Signal – das weniger als 1 % der weltweiten Suchanfragen betrifft.“ Googles eigene Einordnung – und HSTS ist eine Schicht über HTTPS, kein separates Ranking-Signal, daher ist sein SEO-Gewicht praktisch null. Setzen Sie die Erwartungen entsprechend. Quelle

Testen Sie sich selbst: HSTS

Fünf kurze Fragen zu HSTS. Wählen Sie für jede eine Antwort und überprüfen Sie dann.

Änderungsprotokoll