Сохранять или убирать www в вашем доменном имени
Начинаете ли вы с www, когда вводите название сайта в адресной строке? Знаете ли наверняка, есть ли у Википедии, Amazon, Facebook и Twitter www? Не страшно, если не знаете, — многие пользователи даже не задумываются об этом.
Поскольку популярные браузеры, такие как Google Chrome и Safari, теперь скрывают часть URL-адреса с префиксом www, очень легко потерять его в названиях популярных сайтов. Если вам интересно, все вышеупомянутые интернет-гиганты, кроме Twitter, начинаются с www. Но если набирать facebook.com вместо www.facebook.com, вы точно так же получите свою ленту новостей.
Тот факт, что отсутствие www не помешает вам получить доступ к большинству сайтов, может заставить вас думать, что префикс www устарел и можно вообще не включать его в URL своего сайта. Но если это так, то зачем он Википедии, Amazon и Facebook?
В этой статье мы рассмотрим плюсы и минусы включения префикса www в название вашего сайта. Мы также поделимся некоторыми техническими советами, которые помогут в оптимизации сайта независимо от того, выберете ли вы вариант с www или без.
В чем смысл www?
Прежде чем мы углубимся в обсуждение всех преимуществ и недостатков использования или пропуска www, давайте сначала разберемся, откуда берется этот префикс. Чтобы запустить сайт, вам необходимы две вещи: сервер, на котором будут храниться все файлы вашего ресурса, и легкозапоминающееся название, известное как доменное имя. Последнее позволит пользователям получить доступ к вашему сайту через адресную строку браузера, пока DNS делает всю тяжелую работу.
Зачем вам добавлять www к зарегистрированному доменному имени? Исторически такие префиксы использовались как средство различия между серверами внутри вашей сети. На заре интернета не было хостинг-провайдеров и виртуальных выделенных серверов. Каждая компания раньше управляла собственной сетью серверов, и каждый сервер внутри сети считался хостом и выполнял одну функцию, такую как хранение файлов для обмена данными в интернете или работа электронной почты. В зависимости от функции, которую предоставлял хост, он получал определенное имя хоста.
| СЕРВИС, ПРЕДОСТАВЛЯЕМЫЙ ХОСТОМ | ИМЯ ХОСТА | ПОЛНОЕ ДОМЕННОЕ ИМЯ |
|---|---|---|
| Хранит файлы для обмена в интернете | www | www.example.com |
| Используется для обмена данными в сети | ftp | ftp.example.com |
| Обеспечивает доставку электронной почты по сети | mail.example.com |
В сочетании с зарегистрированным доменом компании каждое имя хоста формировало определенное доменное имя (FQDN) — интернет-эквивалент обычного почтового адреса с индексом, названием улицы, города и т.д. Ввод FQDN в адресную строку браузера позволял пользователям получить доступ к необходимому серверу в сети компании.
Но в современном интернете все работает по-другому. Один сервер с одним IP-адресом может использоваться как в качестве веб-сервера, так и в качестве почтового сервера. Кроме того, распространена практика указывать на один и тот же IP-адрес как корневой домен (название сайта без www), так и имя хоста с www. Это позволяет пользователям получать доступ к сайту независимо от того, добавляют ли они www к URL-адресу. Однако для работы над SEO все равно нужно будет выбрать, какой из двух вариантов доменного имени вы предпочитаете.
Как правильно с точки зрения SEO
Что же лучше — доменное имя с www или без? На самом деле с точки зрения SEO не имеет значения, какой вариант вы выберете, и это подтвердил Джон Мюллер в Twitter. Это вопрос брендинга и технических возможностей — мы рассмотрим оба момента далее.
Если вы сделаете свой сайт доступным как через www, так и без www, важно сообщить поисковым системам, какой из вариантов доменного имени предпочтителен. В противном случае поисковики будут рассматривать версии с www и без www как отдельные сайты, они оба проиндексируются — и вам придется решать проблему дублирования контента.
Существует несколько способов указания предпочитаемого (канонического) доменного имени для Google. Наиболее распространенное решение — настроить 301 редирект на стороне сервера. Тогда каждый раз, когда сервер получает запрос на неканонический домен, он автоматически перенаправляет пользователей на канонический. Если ваша предпочтительная версия — www.example.com и пользователи вводят example.com/page01, они в конечном итоге увидят в адресной строке браузера www.example.com/page01.
Если по какой-то причине у вас нет технических средств для настройки 301 редиректа, вы можете добавить тег <link> с атрибутом rel=”canonical” в HTML-код всех страниц с нежелательной версией. Только учтите, что этот метод не так надежен, как редирект 301. Google рассматривает канонические ссылки как рекомендации, а не инструкции, и в результате обе версии сайта могут быть проиндексированы.
Если добавление тегов rel=”canonical” для вас в любом случае лучше, вот как это можно реализовать. Для названия сайта www.example.com добавьте в HTML-код https://example.com/page01 следующую строку:
<link href="https://www.example.org/page01" rel="canonical">
В WordPress 2.9 и выше теги rel=”canonical” будут добавляться на все страницы сайта автоматически, поэтому вам даже не придется ничего делать самостоятельно. Теги будут указывать на версии сайта с www или без www в зависимости от того, какой вы указали в качестве адреса WordPress (URL) в общих настройках WordPress.
С точки зрения пользователя разница в том, что при использовании тега rel=”canonical” вместо 301 редиректа URL в адресной строке браузера и истории не меняется. Таким образом, пользователь, пытающийся получить доступ к example.com, увидит именно этот URL в адресной строке, даже если www.example.com является вашей канонической версией.
Решив, какое доменное имя использовать, и указав предпочитаемую версию как каноническую с помощью любого из описанных методов, важно последовательно использовать выбранный вами вариант URL. Если вы решили оставить www, убедитесь, что все URL-адреса в файле Sitemap и внутренние ссылки содержат этот префикс. По возможности постарайтесь сделать так, чтобы ваши обратные ссылки также включали www — хотя предполагается, что и редирект 301, и атрибут rel=”canonical” пропускают ссылочный вес, некоторая его часть может быть утеряна по пути. В свою очередь, поисковые системы оценят такую последовательность и вознаградят вас улучшенными позициями.
Не забывайте мониторить корректность работы сайта
После того как вы настроили 301 редирект или указали предпочтительные страницы с помощью тегов rel=”canonical”, не забудьте время от времени проверять, все ли работает должным образом.
Что может пойти не так? Допустим, вы внесли на свои страницы теги rel=”canonical”, а затем установили новую тему WordPress, которая автоматически добавила этот тег на все страницы. В итоге у вас появятся повторяющиеся теги rel=”canonical”, которые запутают поисковики, но вы даже не узнаете о проблеме, пока это не повлияет на эффективность вашей SEO.
Чтобы избежать подобных ситуаций, вы можете систематически проводить аудит сайта. Инструмент анализа сайта SE Ranking обнаружит, если на страницах есть дублирующиеся теги rel=”canonical”, несколько страниц указывают на один и тот же канонический URL или на определенных страницах отсутствует rel=”canonical”.
В разделе технического аудита сайта вы можете увидеть, правильно ли настроено зеркало сайта — 301 редирект с www на без www (или наоборот).
Вы можете настроить инструмент SE Ranking так, чтобы автоматически регулярно проверять свой сайт, например, каждую неделю или месяц. Так вы вовремя узнаете, если что-то пойдет не так. Для начала вы можете запустить 14-дневную бесплатную пробную версию — и система автоматически проведет аудит сайта, как только вы добавите свой проект.
Выбор предпочтительного домена
Давайте, наконец, выясним, какая версия доменного имени подойдет вам как каноническая.
На первый взгляд, URL без www выглядит аккуратнее и привлекательнее и пользователи при вводе доменного имени обычно пропускают часть с www. Так почему бы не пропустить его при выборе канонического имени хоста вашего сайта? В конце концов, если вы используете один из распространенных доменов верхнего уровня (com, net или org), люди будут понимать, что это веб-адрес, даже если он не содержит www.
Действительно, имеет смысл выбрать вариант без www ради брендинга. Но перед этим следует учесть некоторые технические ограничения — именно из-за них многие интернет-гиганты сохраняют префикс www.
Когда нужен www?
Допустим, вы решили перейти на версию без www и сопоставили корневой домен и имя хоста с тем же IP-адресом, который вы получили от своего хостинг-провайдера. Это делается с использованием А-записи, и запись DNS выглядит так:
example.com. IN A 192.0.2.0 www.example.com. IN A 192.0.2.0
Затем вы указали example.com как свой канонический домен. Пока все выглядит хорошо. А теперь давайте предположим, что ваш сайт резко вырос в популярности и его посещают тысячи или даже миллионы людей каждый день. Один сервер не может выдержать такую повышенную нагрузку — именно по этой причине на крупных сайтах, таких как Wikipedia, Amazon и Facebook, нет привязки домена к одному IP-адресу. Вместо этого они полагаются на сети доставки содержимого (CDN), чтобы быстро и безопасно предоставлять контент миллионам своих пользователей.
Обработка большого количества трафика
Согласно спецификациям DNS, корневые домены всегда должны указывать на IP-адрес. Но чтобы использовать CDN, вам необходимо указать на своем сайте домен CDN, а не IP-адрес. Теоретически вы можете сопоставить свой домен как с IP-адресом, используя запись типа A, так и с доменом CDN с помощью записи CNAME. Но есть еще одно правило DNS, говорящее о том, что запись CNAME не может сосуществовать с другими типами ресурсных записей. То есть при добавлении обеих A-запись, указывающая на IP-адрес, будет проигнорирована.
Если вас немного сбили с толку все технические термины, упомянутые выше, краткая версия такова: из-за специфики работы DNS-запросов вы не можете указать имя хоста без www на домен CDN. Это приведет к неожиданным ошибкам и будет препятствовать нормальной работе вашего сайта.
Если же вы выберете имя хоста с www в качестве предпочтительной версии, у вас не возникнет проблем с соблюдением правил DNS. Вам просто нужно создать запись CNAME для имени хоста c www, сопоставив ее с выбранной вами CDN. Также добавьте запись A для вашего корневого домена, указывающую на IP-адрес сайта.
www.yourdomain.com. CNAME somecdn.com. yourdomain.com. A 192.0.2.1
Также стоит упомянуть, что некоторые провайдеры DNS (Cloudflare, DNS Made Easy, DNSSimple и другие) ввели обходные пути для преодоления ограничений DNS. Но использование обходных путей ограничит ваш выбор провайдеров DNS и вы при этом можете усложнить жизнь пользователей из-за перенаправления на удаленный узел CDN.
Укрощение файлов cookie
Помимо ограничений DNS, выбор корневого домена в качестве канонического создает проблему с файлами cookie. Дело в том, что в современных браузерах файлы cookie основного домена автоматически передаются в поддомены. Если вы установите файлы cookie для example.com, они также будут отправляться на static.example.com, email.example.com и т.д. Давайте разберемся, почему это плохо.
Первая причина — это неудобно для пользователей. Более крупные сайты часто предпочитают хранить свой статический контент (изображения, видео, файлы JavaScript и CSS) на поддомене, чтобы освободить главный сервер для динамических запросов. Но если сайт работает как корневой домен, файлы cookie по-прежнему будут отправляться с example.com на static.example.com, замедляя доступ к статическому контенту и снижая производительность сайта. Единственный способ предотвратить такую трату пропускной способности — это хранить статический контент на совершенно другом домене. Так делает Twitter, размещая свой статический контент на a0.twimg.com.
Вторая причина — риски для безопасности. Когда вы авторизуетесь в CMS сайта, создается файл cookie. Затем, когда вы посещаете mail.example.com или cdn.example.com, файл cookie отправляется на эти поддомены и может быть прочитан администраторами сервера. Это создает угрозу безопасности, поскольку администраторы могут скопировать файл cookie и использовать его для авторизации в вашей корпоративной CMS. Чтобы снизить риск, вы можете прибегнуть к ограничению IP-адресов, разрешив доступ только IP-адресам вашей корпоративной сети.
Подытожим: если вы хотите оптимизировать скорость своего сайта, размещая статический контент отдельно, но вам не очень хочется покупать для этой цели совершенно новый домен, подумайте о сохранении префикса www в предпочитаемом доменном имени. Тогда вам не придется беспокоиться о том, что третьи лица будут читать файлы cookie вашего сайта.
С или без www
Наличие префикса www в доменном имени может показаться несущественным и незначительным, но оно играет большую роль. Это повлияет на брендинг и масштабируемость вашего сайта, поэтому убедитесь, что вы делаете правильный выбор, исходя из ваших приоритетов и планов на будущее. Как только вы примете решение, отметьте предпочитаемую версию как каноническую и придерживайтесь своего выбора. Переключить доменное имя, убрав с адреса префикс www, технически возможно, но это не принесет никакой пользы для SEO вашего сайта.
А на чьей вы стороне? Поделитесь с нами в комментариях, почему вы предпочитаете использовать домен с www или без.
