{"id":13574,"date":"2026-10-16T13:00:00","date_gmt":"2026-10-16T11:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13574"},"modified":"2026-10-09T23:17:34","modified_gmt":"2026-10-09T21:17:34","slug":"eine-domain-vier-einstiege-unter-welcher-adresse-eine-seite-wirklich","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/tutorials-de-digital-marketing-de\/eine-domain-vier-einstiege-unter-welcher-adresse-eine-seite-wirklich\/","title":{"rendered":"Eine Domain, vier Einstiege: unter welcher Adresse eine Seite wirklich antwortet"},"content":{"rendered":"

Eine Domain ist f\u00fcr ihren Inhaber eine Sache und f\u00fcr das Netz vier. Mit www und ohne, verschl\u00fcsselt und nicht: Jede Kombination ist eine eigene Adresse, die ein Server beantworten, verweigern oder weiterreichen kann. Nichts zwingt sie zur \u00dcbereinstimmung.<\/p>\n

Ob sie \u00fcbereinstimmen, entscheidet dar\u00fcber, wie Suchmaschinen die Seite z\u00e4hlen, wie viele Uml\u00e4ufe ein Besucher zahlt, bevor Inhalt erscheint, und ob ein Zertifikat das abdeckt, was tats\u00e4chlich eingetippt wird.<\/p>\n

\n\"Vier
Vier Schreibweisen derselben Domain – und die Zahl der Spr\u00fcnge, die jede kostet, bevor Inhalt kommt.<\/figcaption><\/figure>\n

Vier Adressen, eine Seite<\/h2>\n

F\u00fcr einen Browser haben http:\/\/example.com<\/code> und https:\/\/www.example.com<\/code> nichts gemeinsam au\u00dfer 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.<\/p>\n

Suchmaschinen l\u00f6sen das auf, indem sie eine kanonische Adresse w\u00e4hlen, 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.<\/p>\n

Die L\u00f6sung besteht nicht darin, die richtige zu finden, sondern darin, irgendeine zu w\u00e4hlen und die anderen drei dorthin zu f\u00fchren.<\/p>\n

Was zusammenlaufen hei\u00dft<\/h2>\n

Zusammenlaufen hei\u00dft: Jeder Einstieg endet auf derselben Adresse, und er endet dort dauerhaft. Drei Einzelheiten entscheiden, ob das gelingt.<\/p>\n

Zuerst das Schema<\/strong>: Die unverschl\u00fcsselten Einstiege m\u00fcssen auf https weiterleiten, und zwar mit einer 301 statt einer 302, damit Browser und Suchmaschinen die verschl\u00fcsselte Fassung als die Adresse behandeln.<\/p>\n

Danach die Hostform<\/strong>: Welche von www und nackter Domain auch gew\u00e4hlt wird, die andere leitet dorthin. Die Wahl ist Geschmackssache mit einer technischen Folge, n\u00e4mlich dass Cookies einer nackten Domain an jede Subdomain gehen, Cookies eines www-Hosts dagegen nicht.<\/p>\n

Und das Zertifikat<\/strong> muss beide Namen tragen. Eine Weiterleitung von einem Host, den das Zertifikat nicht abdeckt, scheitert, bevor sie \u00fcberhaupt gelesen wird: Zuerst bricht der Handshake, und statt einer Weiterleitung erscheint eine Warnseite.<\/p>\n

Achtundvierzig Einstiege, gemessen<\/h2>\n

Zw\u00f6lf bekannte Domains wurden am 2. September 2026 verfolgt, jede \u00fcber alle vier Einstiege, Station f\u00fcr Station, ohne dass ein Client die Schritte zusammenfassen durfte.<\/p>\n

Neun der zw\u00f6lf liefen zusammen: Alle vier Einstiege endeten auf einer Adresse. Sechs davon w\u00e4hlten die www-Form, drei die nackte Domain. Diese Verteilung lohnt sich zu merken, wenn das n\u00e4chste Mal jemand behauptet, eine der beiden sei der Standard.<\/p>\n

Von der unverschl\u00fcsselten nackten Domain aus gez\u00e4hlt – also von dem, was eingetippt wird, wenn nichts weiter eingetippt wird – antwortete eine Domain sofort, sieben brauchten einen Sprung, vier brauchten zwei. Zwei Spr\u00fcnge sind der ehrliche Preis daf\u00fcr, das mit getrennten Regeln richtig zu machen: einer f\u00fcr das Schema, einer f\u00fcr die Hostform. Beides in einer Regel zusammenzuziehen ist m\u00f6glich und spart einen Umlauf.<\/p>\n

Eine Domain wechselte unterwegs zus\u00e4tzlich 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\u00e4hlt wie jeden anderen.<\/p>\n

\n\"Mehrere
\n<\/figure>\n

Die drei, die nicht zusammenliefen<\/h2>\n

Zwei der zw\u00f6lf antworteten unter beiden Hostformen. Die nackte Domain lieferte Inhalt aus, die www-Fassung ebenso, jede blieb, wo sie war. Beides sind gro\u00dfe, fachkundige Projekte, was den Punkt besser tr\u00e4gt als ein kleines Beispiel: Das ist kein Anf\u00e4ngerfehler, sondern eine Konfiguration, die niemand noch einmal angesehen hat.<\/p>\n

Der Preis ist leise. Beide Fassungen funktionieren, niemand meldet einen Fehler, und die Teilung zeigt sich allein als zwei Eintr\u00e4ge in einem Suchindex oder als ein Verweisprofil, das sich auf zwei Hosts verteilt.<\/p>\n

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\u00fcsselte Fassung, und ein Browser, der die Seite noch nie gesehen hat, hat keinen Anlass, es zuerst mit der verschl\u00fcsselten zu versuchen.<\/p>\n

Der Sprung, den HSTS spart<\/h2>\n

Sobald die Kette stimmt, wird der erste Sprung trotzdem bei jedem Besuch bezahlt, der unverschl\u00fcsselt beginnt. Der Header Strict-Transport-Security<\/code> nimmt ihn allen ab, die schon einmal da waren: Der Browser merkt sich f\u00fcr die angegebene Dauer, dass dieser Host nur \u00fcber https anzusprechen ist, und l\u00e4sst die unverschl\u00fcsselte Anfrage ganz aus.<\/p>\n

Zwei Warnungen geh\u00f6ren dazu. Der gemerkte Wert l\u00e4sst sich schwer zur\u00fccknehmen, deshalb geh\u00f6rt in den ersten Versuch eine kurze Dauer. Und der Header z\u00e4hlt nur, wenn er \u00fcber https ankommt, muss also auf der Endadresse stehen und nicht auf der Weiterleitung dorthin.<\/p>\n

Alle vier auf einmal lesen<\/h2>\n

Das von Hand zu pr\u00fcfen hei\u00dft acht bis sechzehn Aufrufe mit curl -I<\/code>, dazu die Disziplin, die Shell den Weiterleitungen nicht stillschweigend folgen zu lassen.<\/p>\n

curl -sI -o \/dev\/null -w \"%{http_code} %{redirect_url}\\n\" http:\/\/example.com\/<\/code><\/pre>\n
Der Redirect-Ketten- und Canonical-Host-Tracer<\/a> in der Toolbox erledigt diese Pr\u00fcfungen in einem Durchgang. Er verfolgt die eingegebene Adresse Sprung f\u00fcr Sprung und erfasst jeweils Statuscode, Location<\/code>-Header und Dauer. Anschlie\u00dfend ruft er alle vier Varianten ab und meldet, ob sie auf derselben Adresse enden. Ketten mit mehr als einem Sprung, tempor\u00e4re Codes anstelle dauerhafter Codes und Weiterleitungen von https zur\u00fcck auf http werden ausdr\u00fccklich als Befunde hervorgehoben, sodass sie nicht von Hand aus der Liste herausgesucht werden m\u00fcssen.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Wie sieht eine Apache-Regel aus, die Schema und Hostform in einem einzigen Sprung korrigiert?<\/h3>\n
Zwei Bedingungen, mit ODER verkn\u00fcpft, und ein Ziel, das beides zugleich richtig setzt. F\u00fcr die www-Form als Endadresse:<\/p>\n
RewriteEngine On<\/code><\/p>\n
RewriteCond %{HTTPS} off [OR]<\/code><\/p>\n
RewriteCond %{HTTP_HOST} !^www\\.example\\.com$ [NC]<\/code><\/p>\n
RewriteRule ^(.*)$ https:\/\/www.example.com\/$1 [L,R=301]<\/code><\/p>\n
Jeder Einstieg, der nicht schon die Endadresse ist, landet damit nach genau einem Sprung am Ziel, auch die unverschl\u00fcsselte nackte Domain. Der Pfad wandert \u00fcber die Klammergruppe mit, den Abfrageteil h\u00e4ngt Apache von selbst wieder an.<\/p>\n
Eine Falle liegt in der ersten Bedingung. Sitzt vor dem Server ein Load Balancer oder CDN, der TLS beendet und intern \u00fcber 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\u00fcfen, 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 \u00fcberhaupt greift.<\/p>\n
Geh\u00f6ren includeSubDomains und preload schon in den ersten HSTS-Header?<\/h3>\n
Besser nicht. includeSubDomains zwingt jede Subdomain auf https, auch solche, die noch gar kein g\u00fcltiges Zertifikat haben, und die Aufnahme in die Preload-Liste der Browser setzt eine Dauer von mindestens einem Jahr voraus und l\u00e4sst sich nur langsam r\u00fcckg\u00e4ngig machen. Beide geh\u00f6ren deshalb in eine sp\u00e4tere Stufe, wenn alle Subdomains \u00fcber https erreichbar sind.<\/p>\n
Reicht ein canonical-Tag, statt die anderen drei Adressen umzuleiten?<\/h3>\n
F\u00fcr Suchmaschinen ist es ein Hinweis, f\u00fcr Besucher gar nichts. Wer die nackte Domain \u00fcber http aufruft, bleibt auf der unverschl\u00fcsselten 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\u00e4cher als eine 301: Suchmaschinen d\u00fcrfen es \u00fcbergehen, und eingehende Verweise zeigen weiter auf beide Hosts.<\/p>\n
Sinnvoll ist das canonical-Tag zus\u00e4tzlich zur Weiterleitung, auf der Endadresse und auf sie selbst verweisend. Dann stimmen beide Signale \u00fcberein, und Kopien mit angeh\u00e4ngten Parametern werden ebenfalls richtig zugeordnet.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n