Когда вы вводите название веб-сайта в адресную строку браузера, вы когда-нибудь начинали с www? Можете ли вы сказать, являются ли Википедия, Amazon, Facebook и Twitter www или нет? Не волнуйтесь, если вы не можете, потому что вы не одиноки.
Поскольку популярные веб-браузеры, такие как Google Chrome и Safari, теперь скрывают часть www в URL-адресе, легко потерять префикс www в названиях популярных веб-сайтов. Если вам интересно, все вышеупомянутые интернет-гиганты, кроме Twitter, - это www. Но если вы наберете facebook.com вместо www.facebook.com, вы все равно загрузите свою новостную ленту через несколько секунд.
Тот факт, что пропуск части www не будет препятствовать вашему доступу к большинству веб-сайтов, может заставить вас думать, что www устарел, и вы можете вообще не удосужиться включить его в URL-адрес своего веб-сайта. Но если бы это было так, то почему Википедия, Amazon и Facebook придерживались этого традиционного формата?
В этом посте мы рассмотрим плюсы и минусы того, чтобы сделать www частью названия вашего сайта. Кроме того, я также поделюсь некоторыми советами по технической настройке, которые помогут вам сохранить ваш сайт оптимизированным для SEO, независимо от того, выберете ли вы www или нет.
Какой смысл в www?
Прежде чем мы углубимся в обсуждение всех преимуществ и недостатков сохранения или пропуска части www, давайте сначала разберемся, откуда она берется. Чтобы запустить веб-сайт, вам в основном нужны две вещи: сервер, на котором будут храниться все файлы вашего веб-сайта, а также легко запоминающееся имя, также известное как доменное имя. Последний позволит пользователям получить доступ к вашему веб-сайту, набрав (www.) example.com вместо IP-адреса сервера в адресную строку, а DNS делает всю тяжелую работу.
Итак, зачем вам добавлять префикс www к своему зарегистрированному доменному имени? Исторически сложилось так, что такие префиксы использовались как средство различения серверов в вашей сети. На заре Интернета не было хостинг-провайдеров и виртуальных частных серверов. Каждая компания использовала для управления своей собственной сетью серверов, каждый сервер в сети считался хостом и выполнял одну функцию, такую как хранение файлов для обмена в Интернете или обмена почтой. Таким образом, что касается вида услуги, предоставленной хостом, он получил определенное имя хоста.
В сочетании с зарегистрированным доменом компании каждое имя хоста образует полное доменное имя (FQDN) — интернет-эквивалент полного адреса объекта с почтовым индексом, названием улицы, названием города и т. д. Ввод FQDN в адресную строку браузера позволял пользователям получить доступ к необходимому серверу в сети компании.
В современном интернет-ландшафте все уже не работает таким образом. Один сервер с одним IP-адресом может использоваться как в качестве веб-сервера, так и в качестве почтового сервера. Кроме того, общепринятой практикой является указание как корневого домена (именно так с технической точки зрения называются веб-сайты, не относящиеся к www), так и имени хоста www на один и тот же IP-адрес. Это позволит пользователям получить доступ к вашему веб-сайту независимо от того, добавляют ли они www в URL-адрес веб-сайта. Однако по причинам SEO вам все равно нужно будет выбрать, какой из двух вариантов доменного имени вы предпочитаете.
Исправление с точки зрения SEO
Конечно, вы хотите решить, использовать ли www или не www с учетом SEO. Но с точки зрения SEO на самом деле не имеет значения, какой вариант вы выберете, что было подтверждено Джоном Мюллером в Твиттере. Предпочтение одного перед другим на самом деле является вопросом брендинга и технических возможностей — мы остановимся на обеих вещах более подробно позже.
Если вы делаете свой веб-сайт доступным как через www, так и без www, для SEO важно сообщить Google, какой из вариантов доменного имени является вашим предпочтительным. В противном случае Google будет рассматривать версии с www и без www как отдельные веб-сайты, они оба будут проиндексированы, и вам придется иметь дело с проблемой дублирования контента.
Когда дело доходит до указания предпочитаемого доменного имени (также называемого каноническим), у вас есть несколько способов под рукой. Наиболее распространенным решением будет настройка перенаправлений 301 на стороне сервера. Таким образом, каждый раз, когда сервер получает запрос к неканоническому домену, он автоматически перенаправляет пользователей на канонический эквивалент. Таким образом, если ваша предпочтительная версия www.example.com и пользователь вводит example.com/page01, он или она в конечном итоге увидит www.example.com/page01 в адресной строке браузера.
Если по каким-то причинам у вас нет технических средств для настройки 301 редиректа, вы можете добавить тег rel=canonical <link> в 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.
С точки зрения пользователя, разница между использованием тегов 301 redirect и rel=canonical заключается в том, что в последнем случае URL-адрес в адресной строке браузера и истории не меняется. Таким образом, пользователь, пытающийся получить доступ к example.com, увидит именно этот URL-адрес в адресной строке, даже если www.example.com является вашим каноническим вариантом. Однако, поскольку популярные веб-браузеры теперь пропускают www, я сомневаюсь, что пользователи даже заметят, что что-то изменилось.
Теперь, когда вы решите, использовать ли www или не www, и пометить предпочитаемую версию как каноническую с помощью любого из двух методов, также важно последовательно использовать выбранный вами вариант URL. Итак, если вы решили сохранить www, убедитесь, что все ваши URL-адреса Sitemap и внутренние ссылки имеют www. Более того, по возможности постарайтесь сделать так, чтобы ваши обратные ссылки также включали www - хотя и 301 редирект, и rel = canonicals должны передавать ссылочный сок, некоторые из них могут потеряться по пути. В свою очередь, Google оценит вашу последовательность и вознаградит вас лучшим рейтингом.
Нет подхода «установил и забыл»
После того, как вы настроили 301 редирект или пометили предпочтительные страницы тегами rel = canonical, не забывайте время от времени проверять, правильно ли все работает. Если вам интересно, почему они этого не сделают, вот пример из реальной жизни.
Допустим, вы пометили свои веб-страницы тегами rel = canonical, а затем добавили новую тему WordPress, которая автоматически включала один и тот же тег на всех страницах, о которых вы не знали. Таким образом, у вас будут повторяющиеся теги rel = canonical, которые Google считает запутанными, но вы даже не узнаете, что возникла проблема, пока она не повлияет на вашу эффективность SEO.
Чтобы избежать подобных ситуаций, можно систематически проводить аудит сайта. Например, инструмент аудита веб-сайтов SE Ranking сообщит вам, есть ли на некоторых страницах вашего веб-сайта повторяющиеся теги rel = canonical, если несколько страниц указывают на один и тот же канонический URL-адрес или если на некоторых страницах отсутствует тег rel = canonical.
Вы можете настроить SE Ranking для регулярного проведения аудита веб-сайта, например, каждую неделю или месяц, чтобы вы могли вовремя определить, пойдет ли что-то не так. Чтобы проверить, все ли правильно настроено на вашем веб-сайте, вы можете начать 14-дневную бесплатную пробную версию, и система автоматически проверит ваш веб-сайт, как только вы добавите свой проект на платформу.
Выбор предпочитаемого домена
Теперь, когда вы знаете, насколько важно четко указать Google, какую версию доменного имени вы предпочитаете, давайте, наконец, выясним, какая из двух будет служить вам лучше в качестве канонической. На первый взгляд, URL-адрес без www выглядит аккуратнее и привлекательнее. Он также скатывается с языка намного легче. Как однажды заметил английский автор Дуглас Адамс, произнесение аббревиатуры www занимает в три раза больше времени, чем просто произнесение «World Wide Web». Поэтому неудивительно, что вещатели обычно опускают часть www при упоминании веб-сайта в эфире. На самом деле это то, что делает большинство людей, когда произносят имя веб-сайта вслух.
При вводе доменного имени в адресную строку пользователи, которые не помнят первые дни Интернета, обычно также пропускают часть www. Так почему бы не пропустить его при выборе канонической версии названия вашего сайта? В конце концов, на дворе 2020 год, и люди все равно поймут, что это веб-адрес, даже если www не является частью URL-адреса и до тех пор, пока вы используете один из распространенных доменов верхнего уровня, таких как com, net или org.
Действительно имеет смысл выбрать non-www ради брендинга. Но прежде чем сделать это, необходимо учитывать некоторые технические ограничения. Эти ограничения являются причиной того, что интернет-гиганты придерживаются www.
Когда www является необходимостью?
Допустим, вы решили отказаться от www и сопоставили корневой домен и имя хоста с тем же IP-адресом, который вы получили от своего хостинг-провайдера. Это делается с помощью записи A-типа, а запись DNS выглядит следующим образом.
example.com. IN A 192.0.2.0
www.example.com. IN A 192.0.2.0
Затем вы отметили example.com как свой канонический домен. Пока все выглядит неплохо.
Теперь давайте предположим, что однажды ваш сайт значительно вырастет и начнет получать тысячи или даже миллионы посетителей каждый день. Один сервер не может выдержать такую повышенную нагрузку, и именно по этой причине крупные веб-сайты, такие как Википедия, Amazon и Facebook, не имеют своих доменов, сопоставленных с одним IP-адресом. Вместо этого они полагаются на сети доставки контента (CDN) для быстрой и безопасной доставки контента миллионам своих пользователей. Таким образом, вы, естественно, захотите также использовать CDN. И здесь возникают технические ограничения.
Обработка большого трафика
Согласно спецификациям DNS, корневые домены всегда должны указывать на IP-адрес. Но чтобы использовать CDN, вам нужно указать свой веб-сайт на домен CDN, а не на IP-адрес. Теоретически вы можете сопоставить свой домен как с IP-адресом с помощью записи типа A, так и с доменом CDN с помощью записи CNAME. Но здесь появляется еще одно правило DNS, говорящее о том, что запись CNAME не может сосуществовать с другими типами записей ресурсов. Таким образом, если вы добавите оба, запись A-типа, указывающая на IP-адрес, будет проигнорирована, нарушив первое правило.
Если вы были немного ошеломлены всеми техническими терминами, упомянутыми выше, вот краткая версия. Из-за того, как работают DNS-запросы, вы не можете указать имя узла без www на домен CDN. Это приведет к неожиданным ошибкам и не позволит вашему сайту функционировать должным образом.
В то же время, если вы выберете имя хоста www в качестве предпочтительной версии, у вас не возникнет проблем с соблюдением правил DNS. Вы просто создадите запись CNAME для имени хоста 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, не являющийся www - они размещают свой статический контент на a0.twimg.com.
Вторая причина – риски безопасности. Когда вы входите в CMS вашего веб-сайта, выдается файл cookie. Затем, когда вы посещаете mail.example.com или cdn.example.com, файл cookie отправляется на эти поддомены и может быть прочитан администраторами сервера. Это представляет угрозу безопасности, поскольку администраторы могут скопировать файл cookie и использовать его для входа в вашу корпоративную CMS. Чтобы снизить риск, вы можете прибегнуть к ограничению IP-адресов, разрешая доступ только к IP-адресам вашей корпоративной сети.
Итак, если вы хотите оптимизировать скорость своего веб-сайта, размещая статический контент отдельно, но вы не совсем хотите покупать совершенно новый домен для этой цели, подумайте о том, чтобы сохранить префикс www в предпочитаемом вами доменном имени. Таким образом, вам также не придется беспокоиться о том, что третьи лица прочитают файлы cookie вашего веб-сайта.
На www или не на www
Префикс www в доменном имени может показаться маленьким и незначительным, но он может иметь большое значение. Это влияет на ваш брендинг и масштабируемость вашего веб-сайта, поэтому выбирайте с умом, исходя из ваших приоритетов и планов на будущее. И как только вы примете решение, отметьте предпочитаемую версию как каноническую и придерживайтесь ее. Переключение с www на отсутствие www технически возможно, но это не принесет пользы SEO вашего сайта.
