Уже много лет в наших адресных строках бушует небольшая война педантизма. В одном углу такие бренды, как Google, Instagramи что его цель. Эта группа выбрала переадресацию 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 |
✅ | ✅ |
В заключение, пока вы явно не установите Domain значение и ваши пользователи не используют Internet Explorer, утечки файлов cookie быть не должно.
Проблема домена без WWW 2: головная боль DNS
Иногда домен «без WWW» может усложнить настройку системы доменных имен (DNS).
Когда пользователь вводит example.com в адресную строку своего браузера, браузер должен знать адрес интернет-протокола (IP) веб-сервера, который он пытается посетить. Браузер запрашивает этот IP-адрес у серверов имен вашего домена — обычно косвенно, через DNS-серверы интернет-провайдера (ISP) пользователя. Если ваши серверы имен настроены на ответ Запись содержащий IP-адрес, домен «без WWW» будет работать нормально.
В некоторых случаях вы можете вместо этого использовать Каноническое имя (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 являются практическими или косметическими. Сторонники отказа от WWW утверждают, что проще сказать и напечатать example.com чем www.example.com (что может быть менее запутанным для менее технически подкованных пользователей).
Противники поддомена WWW также отмечают, что отказ от него дает небольшое преимущество в производительности. Таким образом владельцы веб-сайтов могут сократить каждый HTTP-запрос на 4 байта. Хотя эта экономия может добавиться для веб-сайтов с высокой посещаемостью, таких как 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».
Заключение
Несмотря на интенсивные кампании с обеих сторон, оба подхода остаются в силе до тех пор, пока вы знаете о преимуществах и ограничениях. Чтобы охватить все ваши базы, обязательно настройте постоянные перенаправления с одного на другое, и все готово.
