Czy WWW nadal należy do adresów URL? Inteligencja danych PlatoBlockchain. Wyszukiwanie pionowe. AI.

Czy WWW nadal należy do adresów URL?

Od lat w naszych paskach adresowych toczy się mała pedanterska wojna. W jednym rogu są marki takie jak Google, Instagram, Facebook. Ta grupa wybrała przekierowanie example.com do www.example.com. W przeciwległym rogu: GitHub, DuckDuckGo, Discord. Ta grupa zdecydowała się na odwrócenie i przekierowanie www.example.com do example.com.

Czy „WWW” należy do adresu URL? Niektórzy programiści mają zdecydowane opinie na ten temat. Przyjrzymy się argumentom za i przeciw po odrobinie historii.

O co chodzi z Ws?

Trzy W oznaczają „Światowa sieć”, wynalazek z końca lat 1980., który wprowadził świat do przeglądarek i stron internetowych. Praktyka używania „WWW” wywodzi się z tradycji nazywania subdomen według rodzaju świadczonych przez nie usług:

  • serwer WWW pod adresem www.example.com
  • serwer FTP pod adresem ftp.example.com
  • serwer IRC pod adresem irc.example.com

Problem z domenami bez WWW 1: Przeciekanie plików cookie do subdomen

Krytycy domen „bez WWW” zwracają uwagę, że w pewnych sytuacjach subdomena.example.com będzie w stanie odczytać pliki cookie ustawione przez example.com. Może to być niepożądane, jeśli na przykład jesteś dostawcą usług hostingowych, który umożliwia klientom obsługę subdomen w Twojej domenie. Chociaż obawa jest uzasadniona, zachowanie było specyficzne dla programu Internet Explorer.

RFC 6265 ujednolica sposób, w jaki przeglądarki traktują pliki cookie i wyraźnie określa to zachowanie jako nieprawidłowe.

Innym potencjalnym źródłem wycieków jest tzw Domain wartość jakichkolwiek plików cookie ustawionych przez example.com, Jeśli Domain wartość jest jawnie ustawiona na example.com, pliki cookie będą również widoczne dla jego subdomen.

Wartość plików cookie Wystawiony na example.com Wystawiony na subdomena.example.com
secret=data
secret=data; Domain=example.com

Podsumowując, o ile nie ustawisz jawnie a Domain wartość, a Twoi użytkownicy nie korzystają z przeglądarki Internet Explorer, nie powinno dojść do wycieku plików cookie.

Problem z domenami bez WWW 2: Problemy z DNS

Czasami domena „bez WWW” może skomplikować konfigurację systemu nazw domen (DNS).

Gdy użytkownik wpisze example.com w pasku adresu przeglądarki, przeglądarka musi znać adres protokołu internetowego (IP) serwera WWW, który próbuje odwiedzić. Przeglądarka żąda tego adresu IP od serwerów nazw Twojej domeny – zwykle pośrednio przez serwery DNS dostawcy usług internetowych (ISP) użytkownika. Jeśli twoje serwery nazw są skonfigurowane tak, aby odpowiadały za pomocą an Nagranie zawierające adres IP, domena „bez WWW” będzie działać poprawnie.

W niektórych przypadkach możesz zamiast tego użyć a Nazwa kanoniczna (CNAME) rekord dla Twojej witryny. Taki zapis może to stwierdzić www.example.com jest aliasem example123.jakiścdnprovider.com, który mówi przeglądarce użytkownika, aby zamiast tego wyszukała adres IP example123.jakiścdnprovider.com i wyślij tam żądanie HTTP.

Zauważ, że w powyższym przykładzie użyto subdomeny WWW. Nie można zdefiniować rekordu CNAME dla example.com. Jak na RFC 1912, rekordy CNAME nie mogą współistnieć z innymi rekordami. Jeśli próbowałeś zdefiniować rekord CNAME dla example.com, rekordy serwera nazw (NS) dla example.com zawierające adresy IP serwerów nazw domeny nie mogłyby istnieć. W rezultacie przeglądarki nie będą w stanie dowiedzieć się, gdzie znajdują się twoje serwery nazw.

Niektórzy dostawcy DNS umożliwiają obejście tego ograniczenia. Cloudflare nazywa swoje rozwiązanie Spłaszczanie CNAME. Dzięki tej technice administratorzy domeny konfigurują rekord CNAME, ale ich serwery nazw ujawnią rekord A.

Na przykład, jeśli administrator skonfiguruje rekord CNAME dla example.com wskazując example123.jakiścdnprovider.comi rekord A dla example123.jakiścdnprovider.com istnieje wskazując na 1.2.3.4, wtedy Cloudflare ujawni rekord A dla example.com wskazując 1.2.3.4.

Podsumowując, chociaż obawy dotyczą właścicieli domen, którzy chcą korzystać z rekordów CNAME, niektórzy dostawcy DNS oferują teraz odpowiednie obejście.

Korzyści bez WWW

Większość z argumenty przeciw WWW są praktyczne lub kosmetyczne. Zwolennicy „No-WWW” twierdzą, że łatwiej jest powiedzieć i napisać example.com niż www.example.com (co może być mniej mylące dla mniej obeznanych z technologią użytkowników).

Przeciwnicy subdomeny WWW wskazywali również, że rezygnacja z niej wiąże się z niewielką przewagą wydajności. Właściciele witryn mogliby w ten sposób zgolić 4 bajty z każdego żądania HTTP. Chociaż te oszczędności mogą się sumować w przypadku witryn o dużym natężeniu ruchu, takich jak Facebook, przepustowość generalnie nie jest zasobem deficytowym.

korzyści WWW

Jednym z praktycznych argumentów przemawiających za WWW jest sytuacja z nowszymi domenami najwyższego poziomu. Na przykład, www.przyklad.miami jest natychmiast rozpoznawalny jako adres internetowy, gdy przykład.miami nie jest. Jest to mniejszy problem w przypadku witryn, które mają rozpoznawalne domeny najwyższego poziomu, takie jak .com.

Wpływ na pozycję w wyszukiwarkach

Obecny konsensus jest taki, że Twój wybór nie wpływa na wydajność Twojej wyszukiwarki. Jeśli chcesz przeprowadzić migrację z jednego do drugiego, skonfiguruj stałe przekierowania (HTTP 301) zamiast tymczasowych (HTTP 302). Stałe przekierowania zapewniają, że wartość SEO Twoich starych adresów URL zostanie przeniesiona na nowe.

Wskazówki dotyczące obsługi obu

Witryny zazwyczaj wybierają jedną z tych opcji example.com or www.example.com jako ich oficjalnej stronie internetowej i skonfigurować przekierowania HTTP 301 dla drugiej strony. Teoretycznie możliwe jest wspieranie obu www.example.com i example.com. W praktyce koszty mogą przewyższać korzyści.

Z technicznego punktu widzenia będziesz chciał sprawdzić, czy Twój stos technologiczny sobie z tym poradzi. Twój system zarządzania treścią (CMS) lub witryna generowana statycznie musiałaby wyświetlać linki wewnętrzne jako względne adresy URL, aby zachować preferowaną nazwę hosta użytkownika. Twoje narzędzia analityczne mogą oddzielnie rejestrować ruch do obu nazw hostów, chyba że możesz skonfigurować nazwy hostów jako aliasy.

Na koniec musisz zrobić dodatkowy krok, aby zabezpieczyć wydajność swojej wyszukiwarki. Google uzna, że ​​wersje adresu URL „WWW” i „non-WWW” są duplikaty. Aby zdeduplikować treść w swoim indeksie wyszukiwania, Google wyświetli to, co według niego preferuje użytkownik – lepsze lub gorsze.

Aby zachować kontrolę nad tym, jak wyglądasz w Google, zaleca się wstawianie kanonicznych tagów linków. Najpierw zdecyduj, która nazwa hosta będzie oficjalną (kanoniczną).

Na przykład, jeśli wybierzesz www.example.com, będziesz musiał wstawić następujący fragment kodu w pliku  tag na https://example.com/my-article:

Ten fragment wskazuje Google, że wariant „bez WWW” reprezentuje tę samą treść. Ogólnie rzecz biorąc, Google będzie preferować wersję oznaczoną przez Ciebie jako kanoniczną w wynikach wyszukiwania, czyli w tym przykładzie wariant „WWW”.

Wnioski

Pomimo intensywnych kampanii po obu stronach, oba podejścia zachowują ważność tak długo, jak długo jesteś świadomy korzyści i ograniczeń. Aby objąć wszystkie swoje bazy, skonfiguruj stałe przekierowania z jednej do drugiej i gotowe.

Znak czasu:

Więcej z Sztuczki CSS