Czy powinienem zawierać „www” w adresach URL mojej witryny? Jakie są zalety i wady?

Jakie są zalety i wady posiadania http://www.example.com/vs http://example.com/?

Na przykład wiem, że problem polega na tym, że jeśli używam domeny bez, wwwnie mogę ustawić pliku cookie tylko dla bieżącej subdomeny (ponieważ nie ma subdomeny), a ustawione przeze mnie pliki cookie zostaną wysłane do wszystkich subdomen.

Pamiętaj jednak, że korzystanie z tej opcji www.example.compozwala ustawić pliki cookie tylko na stronie głównej . Korzystanie example.compozwala jedynie na ustawienie plików cookie, na *.example.comktóre obejmuje static.example.com. Dlatego każde żądanie dowolnej subdomeny będzie zawierać pliki cookie, które nieco spowalniają transfer. Użycie www.example.compozwoli Ci zdecydować, dla której części chcesz ustawić pliki cookie.

Jeśli zamierzasz użyć www.example.com, powinieneś dokonać example.comstałego przekierowania do www.example.com.

W wwwniektórych przypadkach subdomena jest w rzeczywistości zupełnie innym serwerem niż nadrzędna TLD. Podczas gdy większość wyszukiwarek jest wystarczająco inteligentna, aby to rozgryźć, nadal dobrą praktyką jest przekierowanie.

Jestem całkowitym przeciwieństwem tego, www.example.comjest to stałe przekierowanie example.com, ponieważ wolę używać krótszego kanonicznego adresu URL. Ma dla mnie również sens, że mogę oczekiwać, że żądanie HTTP example.comspowoduje wyświetlenie strony internetowej lub przekierowanie do dowolnej subdomeny zajmującej się żądaniami HTTP.

Ponadto chcesz, aby osoby prowadzące do Twojej witryny korzystały z kanonicznego adresu URL, który wybierają z paska narzędzi przeglądarki. Przekierowanie na ten, który NIE jest twoim kanonicznym adresem URL, pomaga zapewnić spójność w tym zakresie.

Uwzględnienie wwwsubdomeny wydaje się sprowadzać do dwóch warunków:

1. Pliki cookie - *.example.comspowodują, że pliki cookie spowodują mój smutek (zwiększą ruch), ponieważ pliki cookie będą wysyłane przy każdym żądaniu, niezależnie od subdomeny. W takim przypadku wybrałbym użycie, wwwponieważ daje mi to możliwość ustawienia plików cookie w *.example.comrazie potrzeby (np. Uwierzytelniony plik cookie użytkownika) lub www.example.comograniczenia ruchu do innych moich subdomen.

2. Estetyczny - czy bardzo zależy mi na wyglądzie domeny? Jeśli naprawdę nienawidzę, wwwale martwię się ruchem związanym z plikami cookie, mógłbym rozwiązać problem, hostując moją statyczną treść w zupełnie nowej domenie, takiej jak ta, static-example.comktóra pozostanie wolna od plików cookie.

Jest to niewielka kwestia, ale istotna w przypadku witryn komercyjnych. Użytkownicy nietechniczni oczekują, że witryna zacznie się od strony internetowej, wwwwięc jeśli nie zauważą, że nie uważają domeny za witrynę internetową.

Choć może to wydawać się głupie dla tych z nas, którzy wiedzą, jak to działa, często spotykam się z tą postawą z rodziną, przyjaciółmi i nietechnicznymi kolegami, a ci ludzie mogą reprezentować zdecydowaną większość Twoich klientów.

Ponadto wiele programów, takich jak poczta e-mail, procesory światowe, klienci sieci społecznościowych i współpracownicy, automatycznie rozpozna nazwę domeny rozpoczynającą się wwwjako hiperłącze i uaktywni ją - w przypadku nagiej non-wwwdomeny lub domeny, którą należy dodać http://do oprogramowania aby był aktywny. Możliwość kliknięcia linku zamiast konieczności kopiowania i wklejania do przeglądarki może mieć znaczenie między klientem odwiedzającym witrynę lub odwiedzającym konkurenta.

Wydaje się, że nie ma żadnych konkretnych powodów, aby stosować jeden na drugim w zakresie wyników wyszukiwania lub innych pożądanych rezultatów. Moje osobiste preferencje no-wwwwynikają z długości.

Najważniejsze jest, aby upewnić się, że przekierowujesz do preferowanej domeny i pamiętaj, aby ustawić preferowaną domenę w Google Search Console (Narzędzia Google dla webmasterów).

Bez powtarzania powyższych poprawnych odpowiedzi dotyczących plików cookie, estetyki, użytkowników nietechnicznych oczekujących wwwpoddomeny itp.

Innym powodem, dla którego preferuję www.podejście do poddomeny dla strony głównej, jest rozwój lokalny. Używam local.do mojego lokalnego serwera testowego. Zawsze oczekuję, że strona będzie dostępna za pośrednictwem subdomeny i w razie potrzeby mogę łatwo rozróżnić witryny testowe od aktywnych. Pliki cookie można przechowywać oddzielnie od witryn lokalnych i na żywo.

• www.example.com Witryna na żywo
• local.example.com Lokalny serwer testowy

Użycie subdomeny dla serwera testowego pozwala również na łatwe testowanie z urządzenia mobilnego, ponieważ subdomenę można zdefiniować w publicznym DNS, który wskazuje na lokalny serwer testowy (lokalny adres IP). Tylko wtedy, gdy urządzenie mobilne znajduje się w lokalnej sieci WiFi, będzie mogło uzyskać dostęp do lokalnego serwera testowego. (Upewnij się, że optymalizacje przeglądarki mobilnej są wyłączone podczas łączenia lokalnego, w przeciwnym razie zdalny serwer optymalizacji również spróbuje uzyskać dostęp do twojego lokalnego serwera i nie powiedzie się.)

Tak, zawsze używaj wwwzamiast czystej domeny. Chociaż Heroku jest w pewnym stopniu wyspecjalizowane, to rodzaj zbudowanej przez siebie struktury routingu prawdopodobnie stanie się bardziej powszechny, gdy ludzie będą wdrażać strony internetowe na klastrach maszyn. Nagie domeny są po prostu mniej elastyczne niż www, ponieważ wymagają rekordu A zamiast rekordu CNAME. Zobacz https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords .

Chociaż dziś możesz tak nie myśleć, każda witryna w Internecie powinna i, mam nadzieję, wkrótce będzie korzystać z SSL przez cały czas. Jest tak, ponieważ bezpieczeństwo jest zawsze lepsze niż brak bezpieczeństwa, a koszty SSL to już tylko ~ 1% dodatkowy procesor (patrz http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html ). Powinieneś również uzyskać certyfikat SSL dla www.

Moi SEO mówią mi, że Google nie lubi nagich domen. Objawem tego jest to, że jeśli spróbujesz przekierować swojego myblog.blogspot.combloga example.com/blog, pojawi się błąd informujący, że blogów nie można hostować w nagich domenach .