Seit etwa 20 Jahren wird diskutiert, ob www im kanonischen Hostnamen (CNAME) Ihrer Website verwendet werden soll. Also, was zu verwenden oder nicht?
Obwohl viele Menschen die Begriffe "Domainname" und "Hostname" synonym verwenden, gibt es einen Unterschied zwischen ihnen, und dies ist nicht nur eine Frage der Semantik. Ich werde diese Beschreibung etwas vereinfachen, um mich auf den Punkt zu konzentrieren.
Für Sie als IT-Administrator ist Ihre Domain Ihr Netzwerk. Es ist sinnvoll, der Domain einen Namen zu geben. Das DNS-System ist dafür angepasst, sodass Sie einen Domainnamen registrieren, z. B.
example.com . Jetzt haben Sie unter dieser Domain Ihre eigenen Hosts. Jeder Computer mit einer Netzwerkverbindung wird als Host betrachtet. Die WWW-Dokumentenservicemaschine erhält natürlich den Hostnamen
www in Ihrer Domain, sodass der vollqualifizierte Domainname (FQDN)
www.example.com . Sie werden dasselbe für die übrigen Hosts in Ihrem Netzwerk tun, unabhängig davon, ob Sie einen Webserver haben oder nicht. Sie bereinigen also Ihr Netzwerk.
Um zum Webserver in der Domain
example.com , sollten Sie zum Host mit dem Namen
www.example.com . Übrigens gab es in jenen Tagen, als Dinosaurier das Web durchstreiften, keine virtuellen Hosts. Jeder Webserver bediente nur eine Website (mindestens eine IP-Adresse). Der Hostname spielte keine Rolle, wenn er auf die richtige IP-Adresse zeigte.
"Bare Domain Name", d.h. Ein Domainname ohne 'www', als
example.com in Bezug auf DNS, wird als Ursprung bezeichnet. Als das World Wide Web Mitte der neunziger Jahre immer beliebter wurde, begannen einige Administratoren, dieselbe IP-Adresse wie der WWW-Host als Ursprung anzugeben. Auf diese Weise können Website-Besucher anstelle des vollständig qualifizierten Hostnamens nur
example.com in den Browser eingeben.
Dann kam SEO
Da
example.com und
www.example.com auf unterschiedliche IP-Adressen und seit Januar 1997 auf unterschiedliche Websites mit derselben IP-Adresse verweisen können, sagten uns SEO-Spezialisten, wir sollten einen kanonischen Hostnamen wählen, und der Rest muss dort zeigen (mit HTTP-Statuscode 301).
Es war sinnvoll, einen Namen zu wählen. Aber welches? Für SEO ist das wirklich egal. Die Hauptsache ist, eine zu haben. Aber neben SEO gibt es noch andere Probleme. Lesen Sie weiter.
Wie verstehen die Leute die URL?
Als ich um die Jahrhundertwende bei einer Marketingagentur arbeitete, befürchtete ich, dass die Leute nicht verstehen könnten, dass sie die Adresse des World Wide Web vor sich hatten, wenn wir den Teil „www“ weglassen. Ich meine, wir haben gerade angefangen, "http: //" zu überspringen. Außerdem habe ich mich aus historischen Gründen persönlich dafür entschieden, den vollständigen "richtigen" Hostnamen zu verwenden, d. H.
www.example.com .
Heute halte ich es nicht für wichtig. Die Leute werden verstehen, dass dies eine Webadresse ist, egal ob www da ist oder nicht, wenn sich vor ihnen eine bekannte Top-Level-Domain befindet. Da eine Version immer noch zu einer anderen umleitet, spielt es keine Rolle, dass Ihr kanonischer Hostname
www.example.com lautet, und Sie verwenden
example.com nur aus Gründen der Schönheit für Print-Anzeigen. Wenn Sie über eine von Tausenden neuer .beer-Top-Level-Domains verfügen, ist es aus den gleichen Gründen, die Sie um die Jahrhundertwende im Marketing hatten, sinnvoll, www hinzuzufügen.
Ohne www ist es einfacher und schöner
Ich muss zugeben:
example.com schneller zu tippen, einfacher zu lesen und spart nur Platz. Es ist verständlich, dass die Leute anfingen, www zu löschen - und einfach den Ursprung als kanonischen Hostnamen angeben.
Warum streiten sie sich immer noch darüber?
Warum diskutieren wir immer noch mit 'www' oder nicht? Lassen Sie jeden verwenden, was er will, ist das nicht möglich?
Natürlich kannst du.
Wenn Sie jedoch ein Website-Administrator sind, möchten Sie wahrscheinlich eine fundierte Entscheidung treffen und einige Dinge im Voraus durchdenken. Zum Beispiel Cookies.
Cookies werden an Subdomains weitergegeben
Im Namen des Hosts gesetzte Cookies werden auch für alle Subdomains gesetzt. Wenn die Site auf
example.com ein Cookie setzt, sendet der Browser diese Datei auch, wenn er
www.example.com . Hört sich gut an, es ist die gleiche Seite, oder? Cookies werden jedoch auch an
cdn.example.com ,
email.example.com ,
intranet.example.com ,
thirdpartyservice.example.com usw.
thirdpartyservice.example.com . Bei vielen Diensten von Drittanbietern können Sie Ihre Domain auf diese Weise verwenden.
Das vom Host
www.example.com * gesetzte Cookie-Set * wird * nicht an einen "brüderlichen" Host wie den oben genannten gesendet. Ihr Browser versteht, dass dies keine "Subservices" sind, sondern völlig andere Dienste, die nicht auf Ihre Cookies zugreifen sollten.
Unnötige Cookies beeinträchtigen die Leistung
HTTP und Cookies funktionieren so, dass sie bei jeder Anforderung an den Webserver vom Browser gesendet werden. Dies bedeutet, dass, wenn Ihre Website Cookies für den Ursprung setzt (example.com), diese Datei auch für jede Anfrage gesendet werden muss, die Sie beispielsweise an
email.example.com oder
intranet.example.com . Dies verlangsamt die Verbindung.
Cookies können von Dritten gelesen werden
Wenn die Website mit origin (example.com) identisch ist und das CMS-System verwendet, werden nach der Autorisierung Cookies an Ihren Browser ausgegeben, um die Sitzung offen zu halten. Wenn Sie dann
someinternalservice.example.com besuchen, kann der Administrator dieses Dienstes dieses Cookie lesen, kopieren und verwenden, um sich in Ihrem Namen beim CMS des Unternehmens anzumelden. Gleiches gilt für den E-Mail-Anbieter beim Besuch von
email.example.com oder dem CDN-Anbieter, der Ressourcen wie
static.example.com usw. herunterlädt.
Wenn Sie sich Sorgen über die Sicherheit von mindestens etwas auf
example.com , müssen Sie davor "www" einfügen. Auch wenn dies Sie nicht überzeugt, 'www' zu verwenden, weiß ich nicht, was es überzeugen kann. Weder HTTPS noch 2FA helfen, da dieses Cookie ein magisches Zeichen ist. Andere Sicherheitsmaßnahmen, wie z. B.
IP-Beschränkungen , können jedoch hilfreich sein.
Cookies aus Subdomains können geteilt werden, wenn Sie möchten
Wenn Sie einen Dienst in einer Subdomain haben, z. B.
sso.example.com , können Sie mit RFC 6265 Cookies für den Ursprung festlegen und diese mit
example.com oder
www.example.com . Wenn Sie also die "nackte Domain" als Hostnamen aufgeben, erhalten Sie tatsächlich mehr Flexibilität.
DNS-Einschränkung
Wenn wir von Flexibilität sprechen, müssen wir wieder über DNS sprechen.
In DNS gibt es eine Einschränkung, dass der Ursprung ein A-Eintrag sein muss, dh auf eine feste IP-Adresse verweist.
Wenn Ihre Site groß wird und Sie sie auf ein Hosting verschieben oder an eine Firewall oder einen DDoS-Schutzdienst weiterleiten möchten, leiten Sie den Hostnamen mithilfe des CNAME-Datensatzes an einen anderen inkonsistenten Hostnamen weiter, den der Anbieter abhängig von Ihrem Datenverkehr und Ihren Anforderungen steuert.
Wenn die Site jedoch auf einer nackten Domain (example.com) gehostet wird, können Sie dies nicht tun. Es ist jedoch kein Problem, den Hostnamen mit 'www' in CNAME anzugeben. Wenn Sie also jetzt oder in Zukunft Skalierbarkeit wünschen, sollten Sie den Hostnamen von Anfang an auf "www" setzen.
Fazit: Wählen Sie www
Dies ist wichtig, ob Sie www verwenden oder nicht. Ich bin damit einverstanden, dass nackte Domains hübscher aussehen, aber dies ist nur eine praktische Frage für die Adressleiste des Browsers. Sie können
www.example.com als kanonischen Hostnamen verwenden und an anderen Stellen einfach die nackte Domain verwenden. Benutzer werden bei Bedarf weiterhin umgeleitet.
Wichtige Argumente sprechen jedoch für die Verwendung des vollständig qualifizierten Hostnamens mit "www": für Leistung, Sicherheit und Flexibilität.
Beenden Sie also ein für alle Mal die Diskussion: Entscheiden Sie sich für 'www'!