I årevis har det rast en liten pedanterikrig i adressefeltene våre. I det ene hjørnet er merker som Google, Instagramog Facebook . Denne gruppen har valgt å omdirigere example.com til www.example.com. I motsatt hjørne: GitHub, DuckDuckGoog Discord. Denne gruppen har valgt å gjøre omvendt og omdirigere www.example.com til example.com.
Hører "WWW" hjemme i en URL? Noen utviklere har sterke meninger om emnet. Vi vil utforske argumenter for og imot det etter litt historie.
Hva er det med Ws?
De tre W-ene står for "Verdensveven", en oppfinnelse fra slutten av 1980-tallet som introduserte verden for nettlesere og nettsteder. Praksisen med å bruke "WWW" stammer fra en tradisjon med å navngi underdomener etter typen tjeneste de tilbyr:
- en webserver på www.example.com
- en FTP-server på ftp.example.com
- en IRC-server på irc.example.com
WWW-mindre domeneproblem 1: Lekker informasjonskapsler til underdomener
Kritikere av «WWW-løse» domener har påpekt at i visse situasjoner, underdomenen.example.com kunne lese informasjonskapsler satt av example.com. Dette kan være uønsket hvis du for eksempel er en webhotellleverandør som lar klienter operere underdomener på domenet ditt. Selv om bekymringen er gyldig, var oppførselen spesifikk for Internet Explorer.
RFC 6265 standardiserer hvordan nettlesere behandler informasjonskapsler og kaller denne oppførselen eksplisitt som feil.
En annen potensiell kilde til lekkasjer er Domain verdi av eventuelle informasjonskapsler satt av example.com. Dersom Domain verdien er eksplisitt satt til example.com, vil informasjonskapslene også bli eksponert for underdomenene.
| Verdi for informasjonskapsler | Utsatt for example.com | Utsatt for underdomenen.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
Avslutningsvis, så lenge du ikke eksplisitt angir en Domain verdi og brukerne dine ikke bruker Internet Explorer, bør det ikke forekomme informasjonskapsellekkasjer.
WWW-mindre domeneproblem 2: DNS-hodepine
Noen ganger kan et "WWW-mindre" domene komplisere oppsettet av Domain Name System (DNS).
Når en bruker skriver example.com i nettleserens adresselinje, må nettleseren kjenne IP-adressen (Internet Protocol) til webserveren de prøver å besøke. Nettleseren ber om denne IP-adressen fra domenets navneservere – vanligvis indirekte gjennom DNS-serverne til brukerens Internett-leverandør (ISP). Hvis navneserverne dine er konfigurert til å svare med en En rekord som inneholder IP-adressen, vil et "WWW-less" domene fungere fint.
I noen tilfeller vil du kanskje heller bruke en Kanonisk navn (CNAME) rekord for nettstedet ditt. En slik rekord kan erklære det www.example.com er et alias av eksempel123.somecdnprovider.com, som forteller brukerens nettleser å i stedet slå opp IP-adressen til eksempel123.somecdnprovider.com og send HTTP-forespørselen dit.
Legg merke til at eksemplet ovenfor brukte et WWW-underdomene. Det er ikke mulig å definere en CNAME-post for example.com. Som pr RFC 1912, CNAME-poster kan ikke eksistere side om side med andre poster. Hvis du prøvde å definere en CNAME-post for example.com, navneserveren (NS) poster for example.com som inneholder IP-adressene til domenets navneservere, vil ikke få eksistere. Som et resultat vil ikke nettlesere kunne finne ut hvor navnetjenerne dine er.
Noen DNS-leverandører lar deg omgå denne begrensningen. Cloudflare kaller løsningen deres CNAME-utjevning. Med denne teknikken konfigurerer domeneadministratorer en CNAME-post, men deres navneservere vil avsløre en A-post.
For eksempel hvis administratoren konfigurerer en CNAME-post for example.com peker på eksempel123.somecdnprovider.com, og en A-rekord for eksempel123.somecdnprovider.com finnes peker på 1.2.3.4, så ville Cloudflare avsløre en A-rekord for example.com peker på 1.2.3.4.
Som konklusjon, mens bekymringen er gyldig for domeneeiere som ønsker å bruke CNAME-poster, tilbyr enkelte DNS-leverandører nå en passende løsning.
WWW-løse fordeler
Mesteparten av argumenter mot WWW er praktiske eller kosmetiske. «No-WWW»-forkjempere har hevdet at det er lettere å si og skrive example.com enn www.example.com (noe som kan være mindre forvirrende for mindre teknologikyndige brukere).
Motstandere av WWW-underdomenet har også påpekt at å droppe det kommer med en ydmyk ytelsesfordel. Nettstedseiere kan barbere 4 byte av hver HTTP-forespørsel ved å gjøre det. Selv om disse besparelsene kan øke for nettsteder med høy trafikk som Facebook, er båndbredde generelt ikke en knapp ressurs.
WWW fordeler
Et praktisk argument for WWW er i situasjoner med nyere toppdomener. For eksempel, www.example.miami er umiddelbart gjenkjennelig som en nettadresse når eksempel.miami er det ikke. Dette er mindre bekymringsfullt for nettsteder som har gjenkjennelige toppnivådomener som . Med.
Innvirkning på søkemotorrangeringen din
Den nåværende konsensus er at valget ditt ikke påvirker søkemotorytelsen. Hvis du ønsker å migrere fra den ene til den andre, vil du konfigurere permanente omdirigeringer (HTTP 301) i stedet for midlertidige (HTTP 302). Permanente omdirigeringer sikrer at SEO-verdien til de gamle URL-ene dine overføres til de nye.
Tips for å støtte begge
Nettsteder velger vanligvis enten example.com or www.example.com som deres offisielle nettsted og konfigurer HTTP 301-omdirigeringer for den andre. I teorien er det mulig å støtte begge deler www.example.com og example.com. I praksis kan kostnadene oppveie fordelene.
Fra et teknisk perspektiv vil du bekrefte at teknologistabelen din kan håndtere det. Ditt innholdsstyringssystem (CMS) eller statisk genererte nettsted vil måtte sende ut interne lenker som relative URL-er for å bevare den besøkendes foretrukne vertsnavn. Analyseverktøyene dine kan logge trafikk til begge vertsnavnene separat med mindre du kan konfigurere vertsnavnene som aliaser.
Til slutt må du ta et ekstra skritt for å sikre søkemotorytelsen din. Google vil vurdere «WWW»- og «ikke-WWW»-versjonene av en nettadresse som duplisert innhold. For å deduplisere innhold i søkeindeksen, vil Google vise hvilken av de to de tror brukeren vil foretrekke – på godt og vondt.
For å beholde kontrollen over hvordan du vises i Google, anbefaler vi å sette inn kanoniske lenkekoder. Bestem først hvilket vertsnavn som skal være det offisielle (kanoniske).
For eksempel hvis du velger www.example.com, må du sette inn følgende kodebit i merke på https://example.com/my-article:
Denne kodebiten indikerer for Google at varianten «WWW-mindre» representerer det samme innholdet. Generelt vil Google foretrekke versjonen du har merket som kanonisk i søkeresultatene, som vil være "WWW"-varianten i dette eksemplet.
konklusjonen
Til tross for intens kampanje på begge sider, forblir begge tilnærmingene gyldige så lenge du er klar over fordelene og begrensningene. For å dekke alle basene dine, sørg for å sette opp permanente omdirigeringer fra den ene til den andre, så er du klar.
