Чи слід включати "www" у URL-адреси свого веб-сайту? Які плюси і мінуси?

Які плюси і мінуси щодо http://www.example.com/vs http://example.com/?

Наприклад, проблема, про яку я знаю, полягає в тому, що якщо я використовую домен, wwwя не можу встановити файли cookie лише для поточного піддомену (оскільки немає піддомену), а файли cookie, які я встановив, будуть надіслані всім субдоменам.

Майте на увазі, однак, що використання www.example.comдозволяє вам встановлювати файли cookie лише на головному сайті . Використання example.comдозволить вам встановити файли cookie, на *.example.comяких входить static.example.com. Отже, кожен запит на будь-який субдомен буде містити файли cookie, які трохи уповільнюють передачу. Використання www.example.comдозволить вам вирішити, на яку частину ви хочете встановити файли cookie.

Якщо ви збираєтесь скористатися www.example.com, вам слід зробити example.comпостійне перенаправлення на www.example.com.

wwwДомену до південь, в деяких випадках, насправді зовсім інший сервер , ніж батьківський TLD. Хоча більшість пошукових систем досить розумні, щоб зрозуміти це, її все-таки хороша практика розміщувати повторний напрямок.

Я повний зворотній шлях до цього, www.example.comє постійним переадресацією example.com, тому що я віддаю перевагу використанню коротшої канонічної URL-адреси. Для мене також має сенс, що я можу очікувати, що запит HTTP example.comотримає веб-сторінку або переспрямування на те, що субдомен має справу з HTTP-запитами.

Крім того, ви хочете, щоб люди, які посилаються на ваш сайт, використовували канонічну URL-адресу, яку вибирають із панелі інструментів веб-переглядача. Перенаправлення на ту, що НЕ є вашою канонічною URL-адресою, допомагає забезпечити послідовність у цьому плані.

Включаючи wwwсубдомен, схоже, зводиться до двох умов:

1. Файли cookie - чи встановлення файлів cookie *.example.comвикликає у мене горе (несе більше трафіку), оскільки файли cookie надсилатимуться з кожним запитом, незалежно від субдомену. У цьому випадку я б вирішив використовувати те, wwwоскільки воно надає мені можливість встановити файли cookie, *.example.comякщо мені це потрібно (наприклад, автентифіковане файли cookie користувача), або www.example.comзменшити трафік для інших моїх субдоменів.

2. Естетичний - Мене дуже хвилює те, як виглядає домен? Якщо я справді ненавиджу, wwwале переживаю за трафік файлів cookie, я можу полегшити проблему, розмістивши мій статичний вміст у цілому новому домені, такому, static-example.comякий залишатиметься безкоштовним.

Це незначне враження, але те, що стосується комерційних сайтів. Від нетехнічних користувачів очікується, що веб-сайт починається wwwтак, коли вони не бачать, що вони не можуть вважати домен як веб-сайт.

Хоча це може здатися дурним для тих із нас, хто знає, як все працює, я часто стикався з таким ставленням із сім’єю, друзями та нетехнічними колегами, і ці люди, ймовірно, представляють переважну більшість ваших клієнтів.

Крім того, багато програмного забезпечення, таких як електронна пошта, світові процесори, клієнти соціальних мереж & co, автоматично розпізнають доменне ім’я, починаючи з wwwгіперпосилання, і роблять його активним - з голим або non-wwwдоменом, який вам потрібно буде додати http://до програмного забезпечення щоб активізувати його. Можливість натиснути на посилання замість копіювання та вставлення у веб-переглядач може змінити різницю між клієнтом, який відвідує ваш веб-сайт або переходить до вашого конкурента.

Здається, не існує жодних конкретних причин для використання однієї за іншою щодо результатів пошуку чи інших бажаних результатів. Мої особисті переваги - no-wwwчерез довжину.

Найголовніше - переконайтеся, що ви переспрямовуєте на бажаний домен, і не забудьте встановити бажаний домен у Пошуковій консолі Google (Інструменти Google для веб-майстрів).

Не повторюючи дійсних відповідей вище щодо файлів cookie, естетики, нетехнічних користувачів, які очікують на wwwсубдомен тощо.

Ще одна причина, на яку я схильний надавати www.піддоменний підхід для основного сайту - це місцевий розвиток. Я використовую local.для свого локального тестового сервера. Я завжди очікую доступ до сайту через субдомен і, за потреби, легко розрізняти тестовий та активний сайти. Файли cookie можна зберігати окремо від локальних та живих сайтів.

• www.example.com Живий сайт
• local.example.com Локальний тестовий сервер

Використання піддомену для тестового сервера також дозволяє легко протестувати з мобільного пристрою, оскільки субдомен може бути визначений у загальнодоступній DNS, яка вказує на локальний тестовий сервер (локальний IP). Тільки коли мобільний пристрій знаходиться в локальній мережі WiFi, він зможе отримати доступ до локального тестового сервера. (Переконайтеся, що оптимізація мобільного браузера відключена під час локального підключення, інакше сервер віддаленої оптимізації також спробує отримати доступ до вашого локального сервера і вийти з ладу.)

Так, завжди використовувати wwwзамість оголеного домену. Незважаючи на те, що Heroku є дещо спеціалізованим, вид тканини маршрутизації, який вони створили, швидше за все, стане більш поширеним, оскільки люди розгортають веб-сайти в кластерах машин. Голі домени просто набагато менш гнучкі, ніж www, оскільки для них потрібен A замість запису CNAME. Дивіться https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords .

Хоча сьогодні ви можете так не думати, кожен сайт в Інтернеті повинен і, сподіваємось, незабаром весь час буде використовувати SSL. Це тому, що безпека завжди краща, ніж відсутність безпеки, а витрати на SSL вже лише ~ 1% додаткового процесора (див. Http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html ). Ви також повинні отримати свій SSL сертифікат для www.

Мої SEO люди кажуть, що Google не любить голі домени. Симптомом цього є те, що якщо ви спробуєте перенаправити свій myblog.blogspot.comблог example.com/blog, ви отримаєте помилку, згідно з якою блоги не можна розміщувати в голих доменах .