www.site.ru и site.ru — это два разных адреса. Не два способа написать один адрес, а именно два разных: разные DNS-записи, разные HTTP-ответы, разные объекты в индексе поисковика. Браузеры скрывают www в адресной строке, пользователи давно перестали его набирать — но с технической точки зрения разница никуда не делась.
Выбор между ними — не вопрос вкуса. Это технический выбор с конкретными последствиями для DNS, SEO и работы куков. Разберём каждый аспект отдельно.
Чем отличаются технически
С точки зрения DNS:
site.ru— это apex-домен (он же корневой, naked, zone apex). В DNS это запись с именем@.www.site.ru— это поддоменwww. В DNS это отдельная запись с именемwww.
Оба могут вести на один и тот же сервер — но это две разные DNS-записи, два разных имени. Браузер делает отдельные DNS-запросы для каждого. HTTP-запросы уходят на разные хосты (поле Host: в заголовке разное). Сервер получает разные запросы и должен явно настроить, как их обрабатывать.
Без дополнительной настройки это означает: два варианта адреса, потенциально с разными ответами, разными сертификатами и независимой индексацией в поисковиках.
Проблема CNAME на apex
Здесь начинается техническая история, которая объясняет, почему www вообще не исчезает.
Что такое CNAME и зачем он нужен. CNAME (Canonical Name) — это DNS-запись, которая говорит: «за ответом на этот вопрос — иди туда». Вместо IP-адреса указывается другое имя. Это стандартный способ подключить CDN или облачный хостинг: вы указываете www CNAME cdn.provider.ru, провайдер сам управляет IP-адресами, а вы об этом не думаете.
Почему это не работает для apex. Стандарт DNS (RFC 1034, 1987 год) запрещает CNAME на записях, где уже есть другие типы. А корневая зона обязана содержать SOA и NS — записи об авторитетном DNS-сервере. CNAME не может с ними сосуществовать. Технически: apex-домен не может быть CNAME.
Это значит, что site.ru нельзя направить на cdn.provider.ru через стандартные механизмы DNS — только через фиксированный IP-адрес (A-запись). Если CDN поменяет IP — вы обнаружите проблему в самый неподходящий момент.
Как это обходят. Крупные DNS-провайдеры реализовали нестандартные расширения:
- Cloudflare — CNAME Flattening: провайдер принимает CNAME-подобную запись, сам раскрывает её до IP и отдаёт клиенту A-запись
- Яндекс 360, некоторые другие — поддерживают ALIAS или ANAME: запись, которая ведёт себя как CNAME, но технически является A-записью
- redirekto.ru — предоставляет статические IP-адреса для A-записей: apex-домен прописывается через A, и это стандартное решение, которое работает везде
Если ваш DNS-провайдер не поддерживает CNAME Flattening/ALIAS, а вам нужен apex-домен на CDN — вы или переходите к провайдеру с нужной поддержкой, или используете www как основной вариант.
SEO: дубли и ссылочный вес
Когда оба варианта — site.ru и www.site.ru — доступны без редиректа, возникает классическая SEO-проблема дублирования контента.
Поисковик видит два разных URL с одинаковым контентом. Оба могут попасть в индекс. Внешние ссылки на сайт распределяются между двумя адресами вместо одного — и ссылочный вес размывается. Поведенческие сигналы тоже делятся.
Практически это выглядит так: часть сайтов ссылается на site.ru, часть — на www.site.ru. Без редиректа оба URL независимы. Вместо одного сильного домена у вас два слабых.
Решение одно: 301 редирект с неосновного варианта на основной. Это не просто техническая формальность — это указание поисковику, что два адреса — это один сайт, и весь накопленный вес нужно консолидировать на одном URL.
Яндекс: главное зеркало
У Яндекса для этой задачи есть отдельный механизм — «Главное зеркало» в Яндекс Вебмастере (Индексирование → Главное зеркало).
301 редирект Яндекс видит и учитывает, но процесс переклейки зеркал — отдельный алгоритм с задержкой. Без явного указания в Вебмастере Яндекс может долго держать оба варианта в индексе или выбрать «неправильный» вариант самостоятельно.
Правильная схема работы с Яндексом при выборе главного зеркала:
- Настроить 301 редирект с неосновного варианта на основной
- Добавить оба домена в Яндекс Вебмастер
- В разделе «Главное зеркало» явно указать нужный вариант
Только после шага 3 Яндекс начнёт процесс «склейки» — объединит ссылочный вес и историю в одну запись. Это занимает от нескольких недель до пары месяцев.
Важная деталь: менять главное зеркало в Вебмастере можно не чаще раза в несколько недель. Частая смена воспринимается подозрительно и может замедлить индексацию.
Google и rel=canonical
Google не требует отдельного инструмента для выбора главного зеркала — он определяет его по сигналам в контенте и инфраструктуре:
- 301 редирект — самый сильный сигнал
rel="canonical"— мета-тег или HTTP-заголовок, указывающий предпочтительный URL- Ссылки на сайте — на какой вариант URL ссылается сам сайт во внутренней перелинковке
- Sitemap — какие URL указаны в карте сайта
Для простого случая www/non-www достаточно настроить 301 редирект. Google переопределит канонический URL в течение нескольких недель.
Если оба варианта доступны (без редиректа), но canonical указан на один из них — Google это уважает, но предпочитает прямое подтверждение через редирект. Canonical без редиректа — это просьба. Редирект — это факт.
Куки и поддомены
Этот аспект важен при разработке, но часто игнорируется при выборе главного зеркала.
Браузер передаёт куки на основе атрибута Domain в заголовке Set-Cookie:
Domain=.example.ru(с точкой) — кука доступна всем поддоменам:www.example.ru,api.example.ru,admin.example.ru- Без атрибута Domain или
Domain=example.ru— поведение зависит от браузера, но обычно кука доступна только тому домену, который её выставил
Практическое следствие: если авторизация работает на example.ru, а пользователь заходит через www.example.ru — куки могут не передаться, и сессия слетит. Это реальный баг, который появляется при неправильной настройке, когда оба варианта доступны без редиректа.
Правильный редирект снимает проблему полностью: пользователь всегда попадает на один и тот же вариант домена, кука выставляется один раз, конфликтов нет.
Как выбрать
Честный ответ: для большинства сайтов разницы нет. Но есть несколько критериев, которые помогают принять решение:
Выбирайте без www, если:
- Сайт новый и истории нет
- Домен короткий и запоминаемый — лаконичность важна
- Используете современный CDN с поддержкой CNAME Flattening или ALIAS
Выбирайте www, если:
- Сайт уже работает и большинство внешних ссылок ведут на
www - У вас сложная архитектура с поддоменами и важна изоляция куков
- DNS-провайдер не поддерживает CNAME Flattening, но нужна гибкость CNAME
Главное правило: если сайт уже работает — выбирайте тот вариант, который чаще встречается в существующих внешних ссылках. Переключение потребует переклейки зеркал в Яндексе и ждать переиндексации в Google. Это не страшно, но занимает время.
Пошаговая настройка редиректа между вариантами — в материале «Редирект apex на www».
Типичные ошибки
Редирект настроен, но только для HTTP. Самая частая ошибка. http://www.site.ru редиректит на http://site.ru, а вот https://www.site.ru — нет. Поисковик видит HTTPS-версию www как отдельный сайт. Убедитесь, что редирект работает для всех четырёх комбинаций: http://www, https://www, http:// и https://.
Редирект есть, но главное зеркало в Яндексе не указано. Яндекс видит редирект, но медленно обрабатывает смену зеркала без явного указания в Вебмастере. Результат — недели задержки и возможная путаница в индексе.
Смена зеркала без истории. Если сайт долго работал на www, а вы переключаете на non-www — все внешние ссылки на www-адреса формально перестают быть каноническими. 301 передаёт вес, но переиндексация займёт время. Делайте это взвешенно.
Canonical и редирект противоречат друг другу. rel=canonical на www.site.ru указывает на www.site.ru, а 301 с www уходит на site.ru. Поисковик получает противоречивые сигналы. Canonical и редирект должны согласованно указывать на один вариант.
Забыли обновить sitemap. После смены главного зеркала URL в sitemap.xml должны соответствовать новому каноническому варианту. Sitemap с www-ссылками при non-www как главном зеркале — технически не ошибка, но создаёт лишние вопросы для краулера.
Хорошая новость: всё это делается один раз. Настроили редирект, указали главное зеркало в Вебмастере, проверили четыре HTTPS/HTTP комбинации — и забыли. Сайт будет корректно индексироваться, ссылочный вес консолидируется, а пользователи всегда попадают туда, куда нужно, независимо от того, как они набрали адрес.