Al jaren woedt er een kleine pedanterieoorlog in onze adresbalken. In een hoek staan merken als Kopen Google Reviews, Instagram en Facebook. Deze groep heeft ervoor gekozen om door te verwijzen example.com naar www.example.com. In de tegenoverliggende hoek: GitHub, DuckDuckGo en Discord. Deze groep heeft ervoor gekozen om het omgekeerde te doen en om te leiden www.example.com naar example.com.
Hoort "WWW" thuis in een URL? Sommige ontwikkelaars hebben uitgesproken meningen over het onderwerp. We zullen argumenten voor en tegen onderzoeken na een beetje geschiedenis.
Wat is er met de W's?
De drie W's staan voor "Wereld wijde web", een uitvinding uit de late jaren 1980 die de wereld kennis liet maken met browsers en websites. De praktijk van het gebruik van "WWW" komt voort uit een traditie van het benoemen van subdomeinen naar het type service dat ze bieden:
- een webserver op www.example.com
- een FTP-server op ftp.voorbeeld.com
- een IRC-server op irc.voorbeeld.com
WWW-loos domein zorg 1: Cookies lekken naar subdomeinen
Critici van "WWW-loze" domeinen hebben erop gewezen dat in bepaalde situaties subdomein.voorbeeld.com cookies geplaatst door zou kunnen lezen example.com. Dit kan ongewenst zijn als u bijvoorbeeld een webhostingprovider bent die klanten subdomeinen op uw domein laat beheren. Hoewel de bezorgdheid terecht is, was het gedrag specifiek voor Internet Explorer.
RFC 6265 standaardiseert hoe browsers cookies behandelen en noemt dit gedrag expliciet als onjuist.
Een andere mogelijke bron van lekken is de Domain waarde van eventuele cookies ingesteld door example.com. Indien de Domain waarde is expliciet ingesteld op example.com, worden de cookies ook blootgesteld aan de subdomeinen.
| Cookiewaarde | Blootgesteld example.com | Blootgesteld subdomein.voorbeeld.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
Concluderend, zolang je niet expliciet een Domain waarde en uw gebruikers geen Internet Explorer gebruiken, zouden er geen cookie-lekken moeten optreden.
WWW-loos domeinprobleem 2: DNS-hoofdpijn
Soms kan een "WWW-loos" domein de configuratie van uw Domain Name System (DNS) bemoeilijken.
Wanneer een gebruiker typt example.com in de adresbalk van hun browser moet de browser het IP-adres (Internet Protocol) weten van de webserver die ze proberen te bezoeken. De browser vraagt dit IP-adres op bij de nameservers van uw domein – meestal indirect via de DNS-servers van de internetprovider (ISP) van de gebruiker. Als uw naamservers zijn geconfigureerd om te reageren met een Een opname met het IP-adres, zal een "WWW-loos" domein prima werken.
In sommige gevallen wilt u misschien in plaats daarvan een gebruiken Canonieke naam (CNAME) opnemen voor uw website. Zo'n record kan dat verklaren www.example.com is een alias van voorbeeld123.somecdnprovider.com, die de browser van de gebruiker vertelt om in plaats daarvan het IP-adres van op te zoeken voorbeeld123.somecdnprovider.com en stuur het HTTP-verzoek daarheen.
Merk op dat in het bovenstaande voorbeeld een WWW-subdomein werd gebruikt. Het is niet mogelijk om een CNAME-record te definiëren voor example.com. Vanaf RFC 1912, kunnen CNAME-records niet naast andere records bestaan. Als u probeerde een CNAME-record te definiëren voor example.com, registreert de naamserver (NS) voor example.com die de IP-adressen van de nameservers van het domein bevatten, mogen niet bestaan. Als gevolg hiervan zouden browsers niet kunnen achterhalen waar uw naamservers zijn.
Bij sommige DNS-providers kunt u deze beperking omzeilen. Cloudflare noemt hun oplossing CNAME-afvlakking. Met deze techniek configureren domeinbeheerders een CNAME-record, maar hun nameservers zullen een A-record vrijgeven.
Als de beheerder bijvoorbeeld een CNAME-record configureert voor example.com verwijst naar voorbeeld123.somecdnprovider.com, en een A-record voor voorbeeld123.somecdnprovider.com bestaat wijzend naar 1.2.3.4, dan zou Cloudflare een A-record blootleggen voor example.com verwijst naar 1.2.3.4.
Concluderend, terwijl de zorg geldt voor domeineigenaren die CNAME-records willen gebruiken, bieden bepaalde DNS-providers nu een geschikte oplossing.
WWW-loze voordelen
De meeste argumenten tegen WWW zijn praktisch of cosmetisch. Voorstanders van "Geen-WWW" hebben betoogd dat het gemakkelijker is om te zeggen en te typen example.com neem contact www.example.com (wat misschien minder verwarrend is voor minder technisch onderlegde gebruikers).
Tegenstanders van het WWW-subdomein hebben er ook op gewezen dat het laten vallen ervan een bescheiden prestatievoordeel met zich meebrengt. Website-eigenaren kunnen hierdoor 4 bytes van elk HTTP-verzoek afscheren. Hoewel deze besparingen kunnen oplopen voor drukbezochte websites zoals Facebook, is bandbreedte over het algemeen geen schaarse hulpbron.
WWW-voordelen
Een praktisch argument ten gunste van WWW is in situaties met nieuwere top-level domeinen. Bijvoorbeeld, www.voorbeeld.miami is direct herkenbaar als een webadres wanneer voorbeeld.miami niet. Dit is minder een probleem voor sites met herkenbare topniveaudomeinen zoals .com.
Impact op uw positie in zoekmachines
De huidige consensus is dat uw keuze geen invloed heeft op de prestaties van uw zoekmachine. Als u van de ene naar de andere wilt migreren, moet u permanente omleidingen (HTTP 301) configureren in plaats van tijdelijke omleidingen (HTTP 302). Permanente omleidingen zorgen ervoor dat de SEO-waarde van uw oude URL's wordt overgedragen naar de nieuwe.
Tips om beide te ondersteunen
Sites kiezen meestal een van beide example.com or www.example.com als hun officiële website en configureer HTTP 301-omleidingen voor de andere. In theorie is het mogelijk om beide te ondersteunen www.example.com en example.com. In de praktijk kunnen de kosten de baten overtreffen.
Vanuit technisch oogpunt wilt u controleren of uw technische stack het aankan. Uw contentmanagementsysteem (CMS) of statisch gegenereerde site zou interne links als relatieve URL's moeten uitvoeren om de voorkeurshostnaam van de bezoeker te behouden. Uw analysetools registreren mogelijk verkeer naar beide hostnamen afzonderlijk, tenzij u de hostnamen als aliassen kunt configureren.
Ten slotte moet u een extra stap nemen om de prestaties van uw zoekmachine te waarborgen. Google beschouwt de "WWW"- en "niet-WWW"-versies van een URL als zijnde dubbele inhoud. Om inhoud in zijn zoekindex te dedupliceren, zal Google de van de twee weergeven waarvan het denkt dat de gebruiker er de voorkeur aan geeft - in voor- en tegenspoed.
Om de controle te behouden over hoe u in Google verschijnt, raadt het aan om canonieke linktags in te voegen. Bepaal eerst welke hostnaam de officiële (canonieke) naam zal zijn.
Als je bijvoorbeeld kiest www.example.com, moet u het volgende fragment invoegen in de tag op https://example.com/my-article:
Dit fragment geeft aan Google aan dat de "WWW-loze" variant dezelfde inhoud vertegenwoordigt. Over het algemeen geeft Google de voorkeur aan de versie die u als canoniek heeft gemarkeerd in de zoekresultaten, wat in dit voorbeeld de 'WWW'-variant zou zijn.
Conclusie
Ondanks intense campagnes aan beide kanten, blijven beide benaderingen geldig zolang u zich bewust bent van de voordelen en beperkingen. Om al uw bases te dekken, moet u ervoor zorgen dat u permanente omleidingen van de ene naar de andere instelling instelt en u bent helemaal klaar.
