English
DeutschEine Domain, vier Einstiege: unter welcher Adresse eine Seite wirklich antwortet
Inhalt
Eine Domain ist für ihren Inhaber eine Sache und für das Netz vier. Mit www und ohne, verschlüsselt und nicht: Jede Kombination ist eine eigene Adresse, die ein Server beantworten, verweigern oder weiterreichen kann. Nichts zwingt sie zur Übereinstimmung.
Ob sie übereinstimmen, entscheidet darüber, wie Suchmaschinen die Seite zählen, wie viele Umläufe ein Besucher zahlt, bevor Inhalt erscheint, und ob ein Zertifikat das abdeckt, was tatsächlich eingetippt wird.
Vier Adressen, eine Seite
Für einen Browser haben http://example.com und https://www.example.com nichts gemeinsam außer dem Inhaber. Anderes Schema, anderer Hostname, andere Herkunft. Cookies der einen Adresse werden nicht an die andere gesendet, und Inhalt unter beiden ist Inhalt, den es zweimal gibt.
Suchmaschinen lösen das auf, indem sie eine kanonische Adresse wählen, aber diese Wahl ist geraten, solange die Seite nichts dazu sagt. Wer unter allen vier Adressen dieselben Seiten ausliefert, verteilt seine eingehenden Verweise darauf: Einige zeigen auf die nackte Domain, einige auf www, und keine der beiden Fassungen sammelt das ganze Signal.
Die Lösung besteht nicht darin, die richtige zu finden, sondern darin, irgendeine zu wählen und die anderen drei dorthin zu führen.
Was zusammenlaufen heißt
Zusammenlaufen heißt: Jeder Einstieg endet auf derselben Adresse, und er endet dort dauerhaft. Drei Einzelheiten entscheiden, ob das gelingt.
Zuerst das Schema: Die unverschlüsselten Einstiege müssen auf https weiterleiten, und zwar mit einer 301 statt einer 302, damit Browser und Suchmaschinen die verschlüsselte Fassung als die Adresse behandeln.
Danach die Hostform: Welche von www und nackter Domain auch gewählt wird, die andere leitet dorthin. Die Wahl ist Geschmackssache mit einer technischen Folge, nämlich dass Cookies einer nackten Domain an jede Subdomain gehen, Cookies eines www-Hosts dagegen nicht.
Und das Zertifikat muss beide Namen tragen. Eine Weiterleitung von einem Host, den das Zertifikat nicht abdeckt, scheitert, bevor sie überhaupt gelesen wird: Zuerst bricht der Handshake, und statt einer Weiterleitung erscheint eine Warnseite.
Achtundvierzig Einstiege, gemessen
Zwölf bekannte Domains wurden am 2. September 2026 verfolgt, jede über alle vier Einstiege, Station für Station, ohne dass ein Client die Schritte zusammenfassen durfte.
Neun der zwölf liefen zusammen: Alle vier Einstiege endeten auf einer Adresse. Sechs davon wählten die www-Form, drei die nackte Domain. Diese Verteilung lohnt sich zu merken, wenn das nächste Mal jemand behauptet, eine der beiden sei der Standard.
Von der unverschlüsselten nackten Domain aus gezählt – also von dem, was eingetippt wird, wenn nichts weiter eingetippt wird – antwortete eine Domain sofort, sieben brauchten einen Sprung, vier brauchten zwei. Zwei Sprünge sind der ehrliche Preis dafür, das mit getrennten Regeln richtig zu machen: einer für das Schema, einer für die Hostform. Beides in einer Regel zusammenzuziehen ist möglich und spart einen Umlauf.
Eine Domain wechselte unterwegs zusätzlich den Pfad und endete auf einem Unterverzeichnis statt auf der Startseite. Das ist eine bewusste Entscheidung, und es lohnt sich zu wissen, dass ein Weiterleitungslauf sie als Sprung zählt wie jeden anderen.
Die drei, die nicht zusammenliefen
Zwei der zwölf antworteten unter beiden Hostformen. Die nackte Domain lieferte Inhalt aus, die www-Fassung ebenso, jede blieb, wo sie war. Beides sind große, fachkundige Projekte, was den Punkt besser trägt als ein kleines Beispiel: Das ist kein Anfängerfehler, sondern eine Konfiguration, die niemand noch einmal angesehen hat.
Der Preis ist leise. Beide Fassungen funktionieren, niemand meldet einen Fehler, und die Teilung zeigt sich allein als zwei Einträge in einem Suchindex oder als ein Verweisprofil, das sich auf zwei Hosts verteilt.
Der dritte Fall war deutlicher: Eine Domain antwortete auf http und blieb dort. Keine Weiterleitung auf https, in keiner der beiden Hostformen. Jeder Besucher, der das Schema nicht eintippt, bekommt die unverschlüsselte Fassung, und ein Browser, der die Seite noch nie gesehen hat, hat keinen Anlass, es zuerst mit der verschlüsselten zu versuchen.
Der Sprung, den HSTS spart
Sobald die Kette stimmt, wird der erste Sprung trotzdem bei jedem Besuch bezahlt, der unverschlüsselt beginnt. Der Header Strict-Transport-Security nimmt ihn allen ab, die schon einmal da waren: Der Browser merkt sich für die angegebene Dauer, dass dieser Host nur über https anzusprechen ist, und lässt die unverschlüsselte Anfrage ganz aus.
Zwei Warnungen gehören dazu. Der gemerkte Wert lässt sich schwer zurücknehmen, deshalb gehört in den ersten Versuch eine kurze Dauer. Und der Header zählt nur, wenn er über https ankommt, muss also auf der Endadresse stehen und nicht auf der Weiterleitung dorthin.
Alle vier auf einmal lesen
Das von Hand zu prüfen heißt acht bis sechzehn Aufrufe mit curl -I, dazu die Disziplin, die Shell den Weiterleitungen nicht stillschweigend folgen zu lassen.
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" http://example.com/Der Redirect-Ketten- und Canonical-Host-Tracer in der Toolbox erledigt diese Prüfungen in einem Durchgang. Er verfolgt die eingegebene Adresse Sprung für Sprung und erfasst jeweils Statuscode, Location-Header und Dauer. Anschließend ruft er alle vier Varianten ab und meldet, ob sie auf derselben Adresse enden. Ketten mit mehr als einem Sprung, temporäre Codes anstelle dauerhafter Codes und Weiterleitungen von https zurück auf http werden ausdrücklich als Befunde hervorgehoben, sodass sie nicht von Hand aus der Liste herausgesucht werden müssen.
Fragen und Antworten
Wie sieht eine Apache-Regel aus, die Schema und Hostform in einem einzigen Sprung korrigiert?
Zwei Bedingungen, mit ODER verknüpft, und ein Ziel, das beides zugleich richtig setzt. Für die www-Form als Endadresse:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
Jeder Einstieg, der nicht schon die Endadresse ist, landet damit nach genau einem Sprung am Ziel, auch die unverschlüsselte nackte Domain. Der Pfad wandert über die Klammergruppe mit, den Abfrageteil hängt Apache von selbst wieder an.
Eine Falle liegt in der ersten Bedingung. Sitzt vor dem Server ein Load Balancer oder CDN, der TLS beendet und intern über http weiterreicht, meldet %{HTTPS} immer off, und die Regel leitet jede Anfrage erneut um, also in eine Schleife. Dann muss die Bedingung den Header prüfen, den der vorgeschaltete Dienst setzt, meist X-Forwarded-Proto. Und die Regel ersetzt nicht das Zertifikat: Die nackte Domain muss darin stehen, sonst scheitert der Handshake, bevor die Regel überhaupt greift.
Gehören includeSubDomains und preload schon in den ersten HSTS-Header?
Besser nicht. includeSubDomains zwingt jede Subdomain auf https, auch solche, die noch gar kein gültiges Zertifikat haben, und die Aufnahme in die Preload-Liste der Browser setzt eine Dauer von mindestens einem Jahr voraus und lässt sich nur langsam rückgängig machen. Beide gehören deshalb in eine spätere Stufe, wenn alle Subdomains über https erreichbar sind.
Reicht ein canonical-Tag, statt die anderen drei Adressen umzuleiten?
Für Suchmaschinen ist es ein Hinweis, für Besucher gar nichts. Wer die nackte Domain über http aufruft, bleibt auf der unverschlüsselten Fassung, und Anmeldungen und Einwilligungen, die in Cookies oder im Browserspeicher liegen, bleiben an die Adresse gebunden, unter der sie entstanden sind. Auch als Hinweis ist es schwächer als eine 301: Suchmaschinen dürfen es übergehen, und eingehende Verweise zeigen weiter auf beide Hosts.
Sinnvoll ist das canonical-Tag zusätzlich zur Weiterleitung, auf der Endadresse und auf sie selbst verweisend. Dann stimmen beide Signale überein, und Kopien mit angehängten Parametern werden ebenfalls richtig zugeordnet.
Passend dazu
