I årevis har en lille pedanteri-krig raset i vores adresselinjer. I det ene hjørne er mærker som Google, Instagramog Facebook. Denne gruppe har valgt at omdirigere example.com til www.example.com. I det modsatte hjørne: GitHub, DuckDuckGoog Discord. Denne gruppe har valgt at gøre det omvendte og omdirigere www.example.com til example.com.
Hører "WWW" hjemme i en URL? Nogle udviklere har stærke meninger om emnet. Vi vil undersøge argumenter for og imod det efter lidt historie.
Hvad er der med W'erne?
De tre W'er står for "Internettet", en opfindelse fra slutningen af 1980'erne, der introducerede verden til browsere og websteder. Praksis med at bruge "WWW" stammer fra en tradition for at navngive underdomæner efter den type service, de leverer:
- en webserver kl www.example.com
- en FTP-server kl ftp.example.com
- en IRC-server kl irc.example.com
WWW-mindre domæneproblem 1: Lækker cookies til underdomæner
Kritikere af "WWW-løse" domæner har påpeget, at i visse situationer, underdomæne.example.com ville være i stand til at læse cookies sat af example.com. Dette kan være uønsket, hvis du for eksempel er en webhostingudbyder, der lader klienter drive underdomæner på dit domæne. Selvom bekymringen er gyldig, var adfærden specifik for Internet Explorer.
RFC 6265 standardiserer, hvordan browsere behandler cookies og kalder eksplicit denne adfærd som forkert.
En anden potentiel kilde til lækager er Domain værdi af eventuelle cookies sat af example.com. Hvis Domain værdi er eksplicit sat til example.com, vil cookies også blive eksponeret for dets underdomæner.
| Cookie værdi | Udsat for example.com | Udsat for underdomæne.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
Som konklusion, så længe du ikke udtrykkeligt angiver en Domain værdi og dine brugere ikke bruger Internet Explorer, bør der ikke forekomme cookie-lækager.
WWW-mindre domæneproblem 2: DNS-hovedpine
Nogle gange kan et "WWW-mindre" domæne komplicere din opsætning af Domain Name System (DNS).
Når en bruger skriver example.com i browserens adresselinje skal browseren kende IP-adressen (Internet Protocol) på den webserver, de forsøger at besøge. Browseren anmoder om denne IP-adresse fra dit domænes navneservere – normalt indirekte via DNS-serverne hos brugerens internetudbyder (ISP). Hvis dine navneservere er konfigureret til at svare med en En rekord der indeholder IP-adressen, vil et "WWW-less" domæne fungere fint.
I nogle tilfælde vil du måske i stedet bruge en Kanonisk navn (CNAME) rekord for din hjemmeside. En sådan optegnelse kan erklære det www.example.com er et alias af eksempel123.somecdnprovider.com, som fortæller brugerens browser i stedet at slå IP-adressen op på eksempel123.somecdnprovider.com og send HTTP-anmodningen dertil.
Bemærk, at eksemplet ovenfor brugte et WWW-underdomæne. Det er ikke muligt at definere en CNAME-post for example.com. Som pr RFC 1912, CNAME-poster kan ikke eksistere side om side med andre poster. Hvis du forsøgte at definere en CNAME-post for example.com, navneserveren (NS) registrerer for example.com indeholdende IP-adresserne på domænets navneservere ville ikke få lov til at eksistere. Som et resultat ville browsere ikke være i stand til at finde ud af, hvor dine navneservere er.
Nogle DNS-udbydere vil tillade dig at omgå denne begrænsning. Cloudflare kalder deres løsning CNAME-udfladning. Med denne teknik konfigurerer domæneadministratorer en CNAME-post, men deres navneservere vil afsløre en A-post.
For eksempel, hvis administratoren konfigurerer en CNAME-post for example.com peger på eksempel123.somecdnprovider.com, og en A-rekord for eksempel123.somecdnprovider.com eksisterer peger på 1.2.3.4, så ville Cloudflare afsløre en A-rekord for example.com peger på 1.2.3.4.
Som konklusion, mens bekymringen er gyldig for domæneejere, der ønsker at bruge CNAME-poster, tilbyder visse DNS-udbydere nu en passende løsning.
WWW-løse fordele
Det meste af argumenter imod WWW er praktiske eller kosmetiske. "No-WWW"-fortalere har hævdet, at det er lettere at sige og skrive example.com end www.example.com (hvilket kan være mindre forvirrende for mindre teknologikyndige brugere).
Modstandere af WWW-underdomænet har også påpeget, at at droppe det kommer med en ydmyg ydeevnefordel. Webstedsejere kunne barbere 4 bytes af hver HTTP-anmodning ved at gøre det. Selvom disse besparelser kan lægge op til websteder med høj trafik som Facebook, er båndbredde generelt ikke en knap ressource.
WWW fordele
Et praktisk argument for WWW er i situationer med nyere topdomæner. For eksempel, www.eksempel.miami er umiddelbart genkendelig som en webadresse når eksempel.miami er det ikke. Dette er mindre bekymrende for websteder, der har genkendelige topdomæner som f.eks .com .
Indvirkning på din søgemaskine placering
Den nuværende konsensus er, at dit valg ikke påvirker din søgemaskines ydeevne. Hvis du ønsker at migrere fra den ene til den anden, vil du konfigurere permanente omdirigeringer (HTTP 301) i stedet for midlertidige (HTTP 302). Permanente omdirigeringer sikrer, at SEO-værdien af dine gamle URL'er overføres til de nye.
Tips til at støtte begge dele
Websteder vælger typisk enten example.com or www.example.com som deres officielle hjemmeside og konfigurer HTTP 301-omdirigeringer for den anden. I teorien er det muligt at understøtte begge dele www.example.com , example.com. I praksis kan omkostningerne opveje fordelene.
Fra et teknisk perspektiv vil du gerne bekræfte, at din teknologistack kan håndtere det. Dit indholdsstyringssystem (CMS) eller statisk genererede websted skal udsende interne links som relative URL'er for at bevare den besøgendes foretrukne værtsnavn. Dine analyseværktøjer kan logge trafik til begge værtsnavne separat, medmindre du kan konfigurere værtsnavnene som aliaser.
Til sidst skal du tage et ekstra skridt for at beskytte din søgemaskines ydeevne. Google vil betragte "WWW"- og "ikke-WWW"-versionerne af en URL for at være duplikat indhold. For at deduplikere indhold i sit søgeindeks vil Google vise den af de to, som den tror, brugeren vil foretrække – på godt og ondt.
For at bevare kontrollen over, hvordan du vises i Google, anbefaler det, at du indsætter kanoniske link-tags. Beslut først, hvilket værtsnavn der skal være det officielle (kanoniske).
For eksempel, hvis du vælger www.example.com, bliver du nødt til at indsætte følgende uddrag i tag på https://example.com/my-article:
Dette uddrag angiver over for Google, at varianten "WWW-mindre" repræsenterer det samme indhold. Generelt vil Google foretrække den version, du har markeret som kanonisk i søgeresultaterne, hvilket ville være "WWW"-varianten i dette eksempel.
Konklusion
På trods af intens kampagne på begge sider forbliver begge tilgange gyldige, så længe du er klar over fordelene og begrænsningerne. For at dække alle dine baser skal du sørge for at oprette permanente omdirigeringer fra den ene til den anden, og du er klar.
