Seit Jahren tobt in unseren Adressleisten ein kleiner Pedantenkrieg. In der einen Ecke stehen Marken wie Google, Instagram und Facebook. Diese Gruppe leitet example.com auf www.example.com um. In der gegenüberliegenden Ecke: GitHub, DuckDuckGo und Discord. Diese Gruppe hat sich entschieden, das Gegenteil zu tun und www.example.com auf example.com umzuleiten.
Gehört "WWW" zu einer URL? Manche Entwickler haben hierzu starke Meinungen. Wir werden die Argumente dafür und dagegen nach einem kurzen historischen Abriss untersuchen.
Was hat es mit dem WWW auf sich?
Die drei Ws stehen für "World Wide Web", eine Erfindung aus den späten 1980er Jahren, die der Welt Browser und Websites brachte. Die Praxis, "WWW" zu verwenden, stammt aus einer Tradition, Subdomains nach der Art des Dienstes zu benennen, den sie bereitstellen.
- ein Webserver unter www.example.com
- ein FTP-Server unter ftp.example.com
- ein IRC-Server unter irc.example.com
Problem bei Domains ohne WWW 1: Cookies werden an Subdomains weitergegeben
Kritiker von "WWW-losen" Domains haben darauf hingewiesen, dass unter bestimmten Umständen subdomain.example.com Cookies lesen könnte, die von example.com gesetzt wurden. Dies kann unerwünscht sein, wenn Sie zum Beispiel ein Webhosting-Anbieter sind, der es Kunden erlaubt, Subdomains auf Ihrer Domain zu betreiben. Obwohl die Sorge berechtigt ist, war dieses Verhalten spezifisch für den Internet Explorer.
RFC 6265 standardisiert, wie Browser mit Cookies umgehen, und nennt dieses Verhalten ausdrücklich als falsch.
Eine weitere potenzielle Quelle für Lecks ist der Domain-Wert von allen Cookies, die von example.com gesetzt werden. Wenn der Domain-Wert explizit auf example.com gesetzt wird, werden die Cookies auch an seine Subdomains weitergegeben.
| Cookie-Wert | Weitergegeben an example.com | Weitergegeben an subdomain.example.com |
|---|---|---|
secret=data | ✅ | ❌ |
secret=data; Domain=example.com | ✅ | ✅ |
Zusammenfassend lässt sich sagen, dass, solange Sie keinen expliziten Domain-Wert setzen und Ihre Benutzer keinen Internet Explorer verwenden, keine Cookie-Leaks auftreten sollten.
Problem bei Domains ohne WWW 2: DNS-Kopfschmerzen
Manchmal kann eine "WWW-lose" Domain Ihre Domain Name System (DNS)-Konfiguration verkomplizieren.
Wenn ein Benutzer example.com in die Adressleiste seines Browsers eingibt, muss der Browser die Internet Protocol (IP)-Adresse des Webservers erfahren, den er besuchen möchte. Der Browser fordert diese IP-Adresse von den Nameservern Ihrer Domain an – normalerweise indirekt über die DNS-Server des Internet Service Providers (ISP) des Benutzers. Wenn Ihre Nameserver so konfiguriert sind, dass sie mit einem A-Record, der die IP-Adresse enthält, antworten, funktioniert eine "WWW-lose" Domain einwandfrei.
In einigen Fällen möchten Sie stattdessen einen Canonical Name (CNAME)-Record für Ihre Website verwenden. Ein solcher Record kann deklarieren, dass www.example.com ein Alias von example123.somecdnprovider.com ist, was dem Browser des Benutzers mitteilt, stattdessen die IP-Adresse von example123.somecdnprovider.com nachzuschlagen und die HTTP-Anfrage dorthin zu senden.
Beachten Sie, dass das obige Beispiel eine WWW-Subdomain verwendet hat. Es ist nicht möglich, einen CNAME-Record für example.com zu definieren. Gemäß RFC 1912 können CNAME-Records nicht mit anderen Records koexistieren. Wenn Sie versuchen würden, einen CNAME-Record für example.com zu definieren, dürfte kein MX (Mail Exchanger)-Record für example.com existieren. Infolgedessen wäre es nicht möglich, E-Mails an @example.com zu empfangen.
Einige DNS-Anbieter erlauben es Ihnen jedoch, diese Einschränkung zu umgehen. Cloudflare nennt seine Lösung CNAME-Flattening. Mit dieser Technik konfigurieren Domain-Administratoren einen CNAME-Record, aber ihre Nameserver exponieren einen A-Record.
Wenn der Administrator beispielsweise einen CNAME-Record für example.com konfiguriert, der auf example123.somecdnprovider.com zeigt, und ein A-Record für example123.somecdnprovider.com existiert, der auf 1.2.3.4 zeigt, dann würde Cloudflare einen A-Record für example.com exponieren, der auf 1.2.3.4 zeigt.
Zusammenfassend lässt sich sagen, dass die Bedenken zwar für Domain-Besitzer, die CNAME-Records verwenden möchten, berechtigt sind, aber bestimmte DNS-Anbieter inzwischen eine geeignete Lösung anbieten.
Vorteile von Domains ohne WWW
Die meisten Argumente gegen WWW sind praktischer oder kosmetischer Natur. "No-WWW"-Befürworter argumentieren, dass es einfacher ist, example.com zu sagen und zu tippen als www.example.com (was für weniger technisch versierte Benutzer weniger verwirrend sein mag).
Gegner der WWW-Subdomain haben auch darauf hingewiesen, dass das Weglassen einen bescheidenen Leistungsvorteil mit sich bringt. Website-Betreiber könnten dadurch 4 Bytes pro HTTP-Anfrage einsparen. Während diese Einsparungen für stark frequentierte Websites wie Facebook ins Gewicht fallen könnten, ist Bandbreite im Allgemeinen keine knappe Ressource.
Vorteile von WWW
Ein praktisches Argument für WWW liegt in Situationen mit neueren Top-Level-Domains (TLDs). Zum Beispiel ist www.example.miami sofort als Webadresse erkennbar, während example.miami es nicht ist. Dies ist für Websites mit erkennbaren TLDs wie .com weniger relevant.
Auswirkungen auf Ihr Suchmaschinenranking
Der aktuelle Konsens ist, dass Ihre Wahl keinen Einfluss auf Ihre Suchmaschinenleistung hat. Wenn Sie von einer zur anderen migrieren möchten, sollten Sie permanente Weiterleitungen (HTTP 301) statt temporärer (HTTP 302) konfigurieren. Permanente Weiterleitungen stellen sicher, dass der SEO-Wert Ihrer alten URLs auf die neuen übertragen wird.
Tipps zur Unterstützung beider
Websites wählen in der Regel entweder example.com oder www.example.com als ihre offizielle Website und konfigurieren HTTP 301-Weiterleitungen für die andere. Theoretisch ist es möglich, sowohl www.example.com als auch example.com zu unterstützen. In der Praxis könnten die Kosten den Nutzen übersteigen.
Aus technischer Sicht sollten Sie überprüfen, ob Ihr Tech-Stack dies verarbeiten kann. Ihr Content-Management-System (CMS) oder Ihre statisch generierte Website müsste interne Links als relative URLs ausgeben, um den bevorzugten Hostnamen des Besuchers beizubehalten. Ihre Analyse-Tools protokollieren möglicherweise den Traffic zu beiden Hostnamen getrennt, es sei denn, Sie können die Hostnamen als Aliase konfigurieren.
Schließlich müssen Sie einen zusätzlichen Schritt unternehmen, um Ihre Suchmaschinenleistung zu sichern. Google betrachtet die "WWW"- und die "Non-WWW"-Versionen einer URL als doppelten Inhalt. Um doppelten Inhalt in seinem Suchindex zu eliminieren, wird Google diejenige der beiden anzeigen, die seiner Meinung nach vom Benutzer bevorzugt wird – im Guten wie im Schlechten.
Um die Kontrolle darüber zu behalten, wie Sie bei Google erscheinen, empfiehlt es sich, kanonische Link-Tags einzufügen. Entscheiden Sie sich zunächst, welcher Hostname der offizielle (kanonische) sein soll.
Wenn Sie zum Beispiel www.example.com wählen, müssen Sie den folgenden Ausschnitt in das <head>-Tag auf https://example.com/my-article einfügen:
<link href="https://www.example.com/my-article" rel="canonical">Dieser Ausschnitt weist Google darauf hin, dass die "WWW-lose" Variante denselben Inhalt darstellt. Im Allgemeinen wird Google die Version, die Sie als kanonisch markiert haben, in den Suchergebnissen bevorzugen, was in diesem Beispiel die "WWW"-Variante wäre.
Fazit
Trotz intensiver Kampagnen auf beiden Seiten bleiben beide Ansätze gültig, solange Sie sich der Vorteile und Einschränkungen bewusst sind. Um alle Eventualitäten abzudecken, richten Sie einfach permanente Weiterleitungen von einer zur anderen ein, und Sie sind bestens gerüstet.
Der Autor wählte den Open Internet/Free Speech Fund, um im Rahmen des Write for DOnations-Programms eine Spende zu erhalten.
Ich fand diesen Teil etwas verwirrend
In diesem Fall würde der CNAME-Record vom Nameserver für example.com bedient, während die NS-Records vom .com-Nameserver bedient würden, glaube ich?
Vielleicht wäre ein klareres Beispiel, wenn der Nameserver von example.com einen CNAME-Record für die Root und auch MX-Records bedienen würde, was gegen die DNS-Spezifikation verstoßen würde.
Das stimmt, Benjamin. Danke für den Vorschlag!
Eigentlich können Sie sowieso keine CNAME-Records für die Basisdomain haben, da die Basisdomain immer einen SOA-Record hat. Selbst ohne MX-Records ist es also nie möglich, einen CNAME für die Basisdomain zu setzen.
Das stimmt zwar immer noch, aber Sie können die neuen DNS-Recordtypen SVCB und HTTPS verwenden, um Ihre Root effektiv zu "aliasen". Dies hängt natürlich von der Browserunterstützung ab, aber glücklicherweise scheint sich das schnell durchzusetzen. Zum jetzigen Zeitpunkt wurde der Entwurf genehmigt und wartet nur noch auf eine RFC-Nummer.
Sie können auch den HTTPS-DNS-Record verwenden, um zu bewerben, dass Ihr Webserver HTTP/3 und HSTS verwendet, so dass Clients nicht die erste Anfrage über HTTP/2 stellen und nach dem Header
Alt-Svcsuchen müssen.Ich denke genauso, es gibt einige Vorteile, aber die Idee ist vor ein paar Jahren gestorben, aber für Subdomains denke ich, sind Lokalisierungen wie en, de die besten.
Toller Artikel, danke.
Hat sich Paul, der sich für WWW eingesetzt hat, nicht Jahre später dafür entschuldigt, es in den Standard gezwungen zu haben? (Ich kann mich sehr irren!)
Offensichtlich kümmert sich die Öffentlichkeit (die Hauptnutzer des Internets) nicht um WWW oder versteht es nicht, während sie ein wenig mehr Verständnis für Subdomain.XZY.com hat, wenn auch nicht viel mehr.
Eine kleine Einwendung: Ist "eine Erfindung aus den späten 1980er Jahren" nicht etwas früh, da der erste Webserver und die ersten Browser 1991 veröffentlicht wurden?
Ich schätze, es hängt davon ab, wann man eine Technologie als erfunden betrachtet. Es stimmt, dass die breite Öffentlichkeit das Web erst 1991 erlebte. Der Artikel verwendet Berners-Lees ersten Vorschlag als Referenzpunkt, der aus dem Jahr 1989 stammt.
Das "www" hilft zu zeigen, dass es sich tatsächlich um eine URL handelt. Ich vermute, dass Großeltern oder weniger technisch versierte Benutzer verwirrt über .co, .biz, .hotdog, .etc URLs sind und das Beibehalten des www nicht-.com-Domains klarer macht.
Ich habe mich rein aus ästhetischen Gründen dagegen entschieden.