Домен с www или без: как выбрать основной адрес сайта

example.com и www.example.com — два разных доменных имени. Они могут вести на один сайт, но без явной настройки поисковик и посетители увидят две версии каждой страницы. Выберите основной вариант, а второй постоянно перенаправляйте на него с сохранением пути.

Технического преимущества у www или адреса без него для обычного сайта нет. Решение зависит от привычки аудитории, бренда и инфраструктуры. Качество настройки важнее самого выбора.

Чем отличаются два варианта

Адрес без www называют корневым или apex-доменом: example.com. www.example.com является поддоменом. Оба могут иметь отдельные DNS-записи, размещаться на разных серверах и получать разные сертификаты.

Исторически www обозначал веб-службу рядом с mail и ftp. Сегодня пользователи привычно воспринимают оба варианта как сайт. Короткий адрес удобен в печати, а поддомен www иногда проще связывать с облачной площадкой через CNAME. Конкретные возможности зависят от DNS-провайдера и хостинга.

Не меняйте существующий основной адрес только ради моды. Если сайт давно работает на www, переход затронет все URL и потребует редиректов. Пользователь почти не заметит разницы, а ошибка конфигурации создаст дубли или недоступность.

Выберите один адрес по практическим ограничениям

Для нового сайта сравните:

• какой вариант уже используется в названии и рекламе;
• поддерживает ли площадка корневой домен по A/AAAA или собственному ALIAS;
• нужен ли CNAME для интеграции с CDN или управляемой платформой;
• какие адреса уже получают внешние ссылки;
• какой вариант указан в почте, документах и приложениях.

Зафиксируйте решение письменно: например, «основной адрес — https://example.com, https://www.example.com перенаправляет на него». Это короткое правило должно совпадать в DNS, веб-сервере, CMS и поисковых файлах.

Оба имени должны находить вашу площадку

Чтобы сервер смог вернуть редирект, запрос сначала должен дойти до него. Поэтому настройте DNS и для основного, и для дополнительного имени. Возможна схема, где корень имеет A/AAAA, а www — CNAME на корень или имя площадки. Используйте вариант из документации хостинга.

Добавьте оба домена к проекту или виртуальному хосту. Если площадка знает только основной адрес, запрос дополнительного имени может попасть на заглушку до выполнения редиректа.

Подключение записей подробно разобрано в статье об A, AAAA и CNAME, а вся последовательность — в уроке о подключении домена к хостингу.

HTTPS требуется до перенаправления

Пользователь может открыть https://www.example.com, даже если основным выбран адрес без www. Браузер сначала проверяет TLS-сертификат для www.example.com, устанавливает защищённое соединение и только после этого получает HTTP-ответ с перенаправлением.

Значит, сертификат должен включать оба имени. Если дополнительный адрес не покрыт, посетитель увидит предупреждение о безопасности вместо редиректа. Проверьте также автоматическое продление сертификата после изменения состава имён.

HTTP-версии обоих адресов направляйте на основной HTTPS. В итоге все четыре входа сходятся в один вариант:

Исходный адрес	Результат
http://example.com/page	основной https с тем же /page
http://www.example.com/page	основной https с тем же /page
дополнительный адрес по HTTPS	основной https с тем же путём
основной адрес по HTTPS	страница отвечает без лишней цепочки

Постоянный редирект должен сохранять путь

Для окончательного выбора используют серверный постоянный редирект, обычно 301 или 308. Оба статуса сообщают о постоянном новом адресе; 308 однозначно сохраняет метод запроса, а историческое поведение 301 может менять POST на GET. Для обычных публичных GET-страниц часто используется 301, но API и формы требуют отдельной проверки.

Не перенаправляйте все старые URL на главную. Запрос /catalog/item должен перейти на /catalog/item основного домена. Иначе посетитель потеряет нужную страницу, а поисковая система может трактовать ответ как нерелевантный или мягкую 404.

Проверьте отсутствие цепочки: дополнительный HTTP-адрес лучше сразу направить на окончательный основной HTTPS, а не проходить несколько промежуточных вариантов.

Canonical и sitemap должны подтверждать выбор

Canonical — ссылка в служебной части HTML, указывающая предпочтительный URL страницы среди одинаковых или очень похожих версий. На основной странице она должна ссылаться на её полный основной HTTPS-адрес. Это сигнал для поисковой системы, но не замена доступному редиректу.

Внутренние ссылки, карта сайта, Open Graph, структурированные данные и RSS также должны использовать основной домен. Если редирект ведёт без www, а canonical и sitemap продолжают указывать www, сигналы противоречат друг другу.

Google Search Central относит постоянный редирект и rel="canonical" к сильным сигналам канонизации, а включение в sitemap — к более слабому. Они работают лучше, когда указывают один вариант.

Проверьте результат как посетитель и как робот

Откройте четыре сочетания HTTP/HTTPS и www/без www для главной и внутренней страницы. Убедитесь, что:

• итоговый URL один и тот же;
• путь и параметры не потеряны;
• сертификат действителен на первом HTTPS-соединении;
• постоянный ответ не образует цикл;
• основной URL возвращает 200;
• HTML содержит self-referencing canonical;
• sitemap и внутренние ссылки используют основной адрес.

После изменения следите за ошибками обхода и трафиком на старый вариант. Редирект оставляют надолго: старые ссылки, закладки и документы могут жить годами.

Если настройка вызвала цикл, временно уберите новое правило редиректа и восстановите последнюю рабочую конфигурацию веб-сервера. DNS обычно возвращать не нужно, если оба имени уже ведут на ту же площадку. Для Nginx принципы конфигурации разобраны в статье о каноническом адресе и редиректах.

Источники

• RFC 9110: HTTP Semantics
• Google Search Central: Canonical URLs
• Google Search Central: Redirects and Google Search