Роками в наших адресних рядках точиться маленька педантична війна. В одному кутку бренди, як Google, Instagram та Facebook. Ця група вибрала переспрямування example.com до www.example.com. У протилежному кутку: GitHub, DuckDuckGo та Discord. Ця група вирішила зробити зворотне та перенаправити www.example.com до example.com.
Чи належить «WWW» до URL-адреси? Деякі розробники дотримуються твердої думки з цього приводу. Після невеликої історії ми розглянемо аргументи «за» і «проти».
Що з Ws?
Три W означають "Всесвітня мережа", винахід кінця 1980-х років, який познайомив світ із браузерами та веб-сайтами. Практика використання «WWW» походить від традиції імен субдоменів за типом послуг, які вони надають:
- веб-сервер на www.example.com
- FTP-сервер на ftp.example.com
- сервер IRC за адресою irc.example.com
Проблема без домену WWW 1: витік файлів cookie на субдомени
Критики доменів без WWW зазначають, що в певних ситуаціях subdomain.example.com зможе читати файли cookie, встановлені example.com. Це може бути небажаним, якщо, наприклад, ви є постачальником веб-хостингу, який дозволяє клієнтам керувати субдоменами у вашому домені. Хоча занепокоєння дійсне, поведінка була специфічною для Internet Explorer.
RFC 6265 стандартизує те, як браузери обробляють файли cookie, і явно називає таку поведінку неправильною.
Іншим потенційним джерелом витоків є Domain значення будь-яких файлів cookie, встановлених example.com, Якщо Domain явно встановлено значення example.com, файли cookie також будуть доступні для його субдоменів.
| Цінність файлів cookie | Піддається example.com | Піддається subdomain.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
На завершення, якщо ви явно не встановите a Domain і ваші користувачі не використовують Internet Explorer, витоку файлів cookie не повинно статися.
Проблема 2 без домену WWW: головний біль DNS
Іноді домен без WWW може ускладнити налаштування системи доменних імен (DNS).
Коли користувач вводить текст example.com в адресний рядок свого веб-переглядача, браузеру потрібно знати адресу Інтернет-протоколу (IP) веб-сервера, який вони намагаються відвідати. Браузер запитує цю IP-адресу у серверів імен вашого домену – зазвичай опосередковано через DNS-сервери постачальника послуг Інтернету (ISP) користувача. Якщо ваші сервери імен налаштовані на відповідь за допомогою Запис містить IP-адресу, домен без WWW працюватиме нормально.
У деяких випадках ви можете замість цього використовувати a Канонічна назва (CNAME) запис для вашого сайту. Про це може свідчити такий запис www.example.com є псевдонімом example123.somecdnprovider.com, який повідомляє веб-переглядачу користувача замість цього шукати IP-адресу example123.somecdnprovider.com і надішліть HTTP-запит туди.
Зверніть увагу, що в прикладі вище використовувався субдомен WWW. Неможливо визначити запис CNAME для example.com. Згідно RFC 1912, записи CNAME не можуть співіснувати з іншими записами. Якщо ви спробували визначити запис CNAME для example.com, записи сервера імен (NS) для example.com що містить IP-адреси серверів імен домену, не буде дозволено існувати. У результаті браузери не зможуть визначити, де знаходяться ваші сервери імен.
Деякі постачальники DNS дозволять вам обійти це обмеження. Cloudflare називає своє рішення Зведення CNAME. За допомогою цієї методики адміністратори домену налаштовують запис CNAME, але їхні сервери імен відображатимуть запис A.
Наприклад, якщо адміністратор налаштує запис CNAME для example.com вказує на example123.somecdnprovider.comі запис A для example123.somecdnprovider.com існує вказуючи на 1.2.3.4, тоді Cloudflare відкриє запис A для example.com вказує на 1.2.3.4.
Підсумовуючи, хоча занепокоєння дійсне для власників доменів, які бажають використовувати записи CNAME, деякі постачальники DNS тепер пропонують відповідний обхідний шлях.
Переваги без WWW
Більшість з аргументи проти WWW є практичними або косметичними. Прихильники “No-WWW” стверджують, що легше говорити та друкувати example.com ніж www.example.com (що може бути менш заплутаним для менш обізнаних у техніці користувачів).
Противники субдомену WWW також зазначали, що його видалення приносить скромну перевагу в продуктивності. Таким чином власники веб-сайтів можуть скоротити 4 байти на кожен HTTP-запит. Хоча ця економія може бути корисною для веб-сайтів із високим трафіком, таких як Facebook, пропускна здатність загалом не є дефіцитним ресурсом.
Переваги WWW
Одним з практичних аргументів на користь WWW є ситуація з новими доменами верхнього рівня. Наприклад, www.example.miami одразу розпізнається як веб-адреса, коли наприклад.маямі не є. Це не викликає занепокоєння для сайтів, які мають розпізнавані домени верхнього рівня, наприклад .com.
Вплив на ваш рейтинг у пошуковій системі
Поточний консенсус полягає в тому, що ваш вибір не впливає на продуктивність вашої пошукової системи. Якщо ви бажаєте перейти від одного до іншого, вам слід налаштувати постійні переспрямування (HTTP 301) замість тимчасових (HTTP 302). Постійне переспрямування гарантує, що значення SEO ваших старих URL-адрес переноситься на нові.
Поради щодо підтримки обох
Сайти зазвичай вибирають будь-яке з них example.com or www.example.com як їхній офіційний веб-сайт і налаштуйте переспрямування HTTP 301 для іншого. Теоретично можна підтримувати обидва www.example.com та example.com. На практиці витрати можуть перевищувати вигоди.
З технічної точки зору вам потрібно переконатися, що ваш технічний стек може це впоратися. Ваша система керування вмістом (CMS) або статично згенерований сайт мали б виводити внутрішні посилання як відносні URL-адреси, щоб зберегти бажане ім’я хосту відвідувача. Ваші інструменти аналітики можуть реєструвати трафік до обох імен хостів окремо, якщо ви не можете налаштувати імена хостів як псевдоніми.
Нарешті, вам потрібно буде зробити додатковий крок, щоб захистити продуктивність вашої пошукової системи. Google вважатиме версії URL-адреси «WWW» і «не-WWW». дубльований контент. Щоб видалити дублікати вмісту у своєму пошуковому індексі, Google відображатиме той із двох, який, на його думку, віддасть перевагу користувачу – на краще чи на гірше.
Щоб зберегти контроль над тим, як ви відображаєтеся в Google, рекомендуємо вставляти канонічні теги посилань. Спочатку вирішіть, яке ім’я хосту буде офіційним (канонічним).
Наприклад, якщо вибрати www.example.com, вам потрібно буде вставити наступний фрагмент у позначка на https://example.com/my-article:
Цей фрагмент вказує Google, що варіант «без WWW» представляє той самий вміст. Загалом Google віддасть перевагу версії, яку ви позначили як канонічну в результатах пошуку, якою буде варіант «WWW» у цьому прикладі.
Висновок
Незважаючи на інтенсивну кампанію з обох сторін, обидва підходи залишаються дійсними, доки ви усвідомлюєте переваги та обмеження. Щоб охопити всі ваші бази, обов’язково налаштуйте постійні переадресації від однієї до іншої, і все готово.
