De ani de zile, în barele noastre de adrese răzvrătește un mic război al pedanterii. Într-un colț sunt mărci ca Google, Instagram, și Facebook. Acest grup a ales să redirecționeze example.com la www.example.com. În colțul opus: GitHub, DuckDuckGo, și Discordie. Acest grup a ales să facă invers și să redirecționeze www.example.com la example.com.
„WWW” aparține unei adrese URL? Unii dezvoltatori au opinii puternice asupra subiectului. Vom explora argumentele pro și contra după un pic de istorie.
Ce-i cu W-urile?
Cele trei W reprezintă "World wide web", o invenție de la sfârșitul anilor 1980 care a introdus lumea în browsere și site-uri web. Practica utilizării „WWW” provine dintr-o tradiție de denumire a subdomeniilor după tipul de serviciu pe care îl oferă:
- un server web la www.example.com
- un server FTP la ftp.example.com
- un server IRC la irc.example.com
Preocuparea domeniului fără WWW 1: Scurgerea cookie-urilor către subdomenii
Criticii domeniilor „fără WWW” au subliniat că, în anumite situații, subdomeniu.example.com ar putea citi cookie-urile setate de example.com. Acest lucru poate fi nedorit dacă, de exemplu, sunteți un furnizor de găzduire web care permite clienților să opereze subdomenii pe domeniul dvs. Deși îngrijorarea este valabilă, comportamentul a fost specific Internet Explorer.
RFC 6265 standardizează modul în care browserele tratează cookie-urile și declară în mod explicit acest comportament ca fiind incorect.
O altă sursă potențială de scurgeri este Domain valoare a oricăror cookie-uri setate de example.com. Dacă Domain valoarea este setată în mod explicit la example.com, cookie-urile vor fi, de asemenea, expuse subdomeniilor sale.
| Valoarea cookie-urilor | Expus la example.com | Expus la subdomeniu.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
În concluzie, atâta timp cât nu setați în mod explicit un Domain valoare și utilizatorii dvs. nu folosesc Internet Explorer, nu ar trebui să apară scurgeri de cookie-uri.
Preocuparea domeniului fără WWW 2: dureri de cap DNS
Uneori, un domeniu „fără WWW” poate complica configurarea sistemului de nume de domeniu (DNS).
Când un utilizator tasta example.com în bara de adrese a browserului, acesta trebuie să cunoască adresa IP (Internet Protocol) a serverului web pe care încearcă să îl viziteze. Browserul solicită această adresă IP de la serverele de nume ale domeniului dvs. – de obicei indirect prin serverele DNS ale furnizorului de servicii de internet (ISP) al utilizatorului. Dacă serverele dumneavoastră de nume sunt configurate să răspundă cu un O înregistrare care conține adresa IP, un domeniu „fără WWW” va funcționa bine.
În unele cazuri, este posibil să doriți să utilizați a Nume Canonical (CNAME) înregistrare pentru site-ul dvs. O astfel de înregistrare poate declara că www.example.com este un alias al exemplu123.somecdnprovider.com, care îi spune browserului utilizatorului să caute adresa IP a exemplu123.somecdnprovider.com și trimiteți cererea HTTP acolo.
Observați că exemplul de mai sus a folosit un subdomeniu WWW. Nu este posibil să definiți o înregistrare CNAME pentru example.com. Conform RFC 1912, înregistrările CNAME nu pot coexista cu alte înregistrări. Dacă ați încercat să definiți o înregistrare CNAME pentru example.com, serverul de nume (NS) înregistrează pentru example.com care conțin adresele IP ale serverelor de nume ale domeniului nu ar fi permis să existe. Drept urmare, browserele nu ar putea să-și dea seama unde sunt serverele dvs. de nume.
Unii furnizori de DNS vă vor permite să rezolvați această limitare. Cloudflare numește soluția lor Aplatizarea CNAME. Cu această tehnică, administratorii de domeniu configurează o înregistrare CNAME, dar serverele lor de nume vor expune o înregistrare A.
De exemplu, dacă administratorul configurează o înregistrare CNAME pentru example.com arătând spre exemplu123.somecdnprovider.com, și un record A pentru exemplu123.somecdnprovider.com există arătând spre 1.2.3.4, apoi Cloudflare ar expune o înregistrare A pentru example.com arătând spre 1.2.3.4.
În concluzie, deși preocuparea este valabilă pentru proprietarii de domenii care doresc să utilizeze înregistrările CNAME, anumiți furnizori de DNS oferă acum o soluție adecvată.
Beneficii fără WWW
Cele mai multe dintre argumente împotriva WWW sunt practice sau cosmetice. Avocații „nu-WWW” au susținut că este mai ușor de spus și de tastat example.com decât www.example.com (ceea ce poate fi mai puțin confuz pentru utilizatorii mai puțin cunoscători de tehnologie).
Oponenții subdomeniului WWW au subliniat, de asemenea, că renunțarea acestuia vine cu un avantaj umil de performanță. Proprietarii de site-uri web ar putea reduce cu 4 octeți fiecare solicitare HTTP făcând acest lucru. În timp ce aceste economii s-ar putea adăuga pentru site-urile web cu trafic ridicat, cum ar fi Facebook, lățimea de bandă, în general, nu este o resursă limitată.
Beneficii WWW
Un argument practic în favoarea WWW este în situațiile cu domenii mai noi de nivel superior. De exemplu, www.example.miami este imediat recunoscută ca adresă web când exemplu.miami nu este. Aceasta este mai puțin o preocupare pentru site-urile care au domenii de nivel superior recunoscute, cum ar fi .com.
Impactul asupra clasamentului motorului dvs. de căutare
Consensul actual este că alegerea dvs. nu influențează performanța motorului dvs. de căutare. Dacă doriți să migrați de la unul la altul, veți dori să configurați redirecționări permanente (HTTP 301) în loc de cele temporare (HTTP 302). Redirecționările permanente asigură că valoarea SEO a vechilor dvs. URL-uri se transferă la cele noi.
Sfaturi pentru a le susține pe ambele
Site-urile aleg de obicei oricare dintre ele example.com or www.example.com ca site-ul lor oficial și configurați redirecționări HTTP 301 pentru celălalt. În teorie, este posibil să le susținem pe ambele www.example.com și example.com. În practică, costurile pot depăși beneficiile.
Din punct de vedere tehnic, veți dori să verificați dacă stack-ul dvs. de tehnologie se poate descurca. Sistemul dvs. de management al conținutului (CMS) sau site-ul generat static ar trebui să scoată link-uri interne ca adrese URL relative pentru a păstra numele de gazdă preferat al vizitatorului. Instrumentele dvs. de analiză pot înregistra traficul către ambele nume de gazdă separat, cu excepția cazului în care puteți configura numele de gazdă ca alias.
În cele din urmă, va trebui să faceți un pas suplimentar pentru a vă proteja performanța motorului de căutare. Google va considera că versiunile „WWW” și „non-WWW” ale unei adrese URL sunt conținutul duplicat. Pentru a deduplica conținutul din indexul său de căutare, Google va afișa oricare dintre cele două consideră că utilizatorul îl va prefera - în bine sau în rău.
Pentru a păstra controlul asupra modului în care apar în Google, recomandă inserarea etichetelor de link canonice. Mai întâi, decideți ce nume de gazdă va fi cel oficial (canonic).
De exemplu, dacă alegeți www.example.com, va trebui să inserați următorul fragment în fișierul etichetați https://example.com/my-article:
Acest fragment indică Google că varianta „fără WWW” reprezintă același conținut. În general, Google va prefera versiunea pe care ați marcat-o ca canonică în rezultatele căutării, care ar fi varianta „WWW” în acest exemplu.
Concluzie
În ciuda campaniilor intense de ambele părți, ambele abordări rămân valabile atâta timp cât ești conștient de beneficiile și limitările. Pentru a vă acoperi toate bazele, asigurați-vă că ați configurat redirecționări permanente de la una la alta și sunteți gata.
