Как настроить переадресацию с www на без www

Адрес сайта может открываться в двух вариантах: www.example.ru и example.ru. Для посетителя разница кажется незначительной, однако поисковые системы и браузеры воспринимают такие URL как разные входы на один ресурс. Если сервер не настроен правильно, появляются дубли страниц, расхождения в статистике и путаница с основным доменом.

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

Настройка выполняется на нескольких уровнях: в DNS, на веб-сервере, в CMS и в инструментах аналитики. Самым важным элементом обычно становится постоянный редирект 301. Он должен сохранять путь и параметры URL, чтобы адрес /catalog/item переходил именно в /catalog/item, а не на главную страницу.

Зачем выбирать единый вариант домена

Версии с www и без него технически могут вести на один и тот же сайт, но поисковая система способна рассматривать их как разные адреса. Тогда ссылки, поведенческие сигналы и история страниц распределяются между двумя вариантами. Это снижает прозрачность структуры и усложняет анализ органического трафика.

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

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

Обычно выбирают вариант без www, потому что он короче и удобнее для ручного ввода. Однако это не универсальное правило. Крупные проекты могут оставить www, особенно если планируют использовать отдельные поддомены для статических файлов, API или сервисных разделов. Важна не сама форма, а последовательность.

Подготовка DNS и сертификата

До настройки редиректа необходимо убедиться, что оба имени разрешаются через DNS. Для домена без префикса обычно создают A-запись с IP-адресом сервера или соответствующую ALIAS/ANAME-запись, если такую возможность предоставляет DNS-провайдер. Для www используют A-запись или CNAME на основной домен.

Одна только DNS-запись не выполняет переадресацию. Она лишь сообщает, на какой сервер направлять запрос. Сам переход задаётся конфигурацией веб-сервера, поэтому домен www должен быть добавлен в панель хостинга или в виртуальный хост, даже если его единственная задача — отправлять посетителей на основной адрес.

Отдельно проверьте SSL-сертификат. При обращении к https://www.example.ru браузер сначала устанавливает защищённое соединение и только потом получает ответ 301. Значит, сертификат обязан включать имя www.example.ru. Для варианта без префикса требуется его собственное покрытие. Часто используют сертификат с двумя именами или wildcard-сертификат.

Такая проверка важна и для доменных материалов, где рассматриваются разные варианты использования имени сайта. Полезным дополнительным контекстом может быть публикация о доменах, но техническое решение всё равно следует сверять с настройками конкретного DNS-провайдера и хостинга.

Настройка переадресации на сервере

На Apache редирект часто задают в файле .htaccess, расположенном в корневой папке сайта. Для перехода с www на адрес без префикса подойдут такие правила:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.example\.ru$ [NC]
RewriteRule ^(.*)$ https://example.ru/$1 [R=301,L]

Вместо example.ru нужно указать реальное имя домена. Флаг NC делает сравнение регистра независимым, R=301 задаёт постоянный редирект, а $1 сохраняет путь страницы. Если пользователь откроет www.example.ru/news/article, он должен попасть на https://example.ru/news/article, а не потерять адресную часть.

На Nginx обычно создают отдельный серверный блок для имени с www:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.ru;

    return 301 https://example.ru$request_uri;
}

Для HTTPS в рабочей конфигурации также указывают сертификат и ключ, если это требуется выбранной схемой. Часто HTTP и HTTPS разделяют на отдельные блоки, чтобы сначала принудительно включить шифрование, а затем убрать www. Важно не создать цепочку из нескольких переходов: идеальный результат — один ответ 301 непосредственно на окончательный URL.

Если сайт работает на CMS, часть настроек может находиться в административной панели. Основной адрес в параметрах системы должен совпадать с выбранной версией домена. При этом серверный редирект всё равно нужен: CMS-код запускается уже после обращения к серверу и не заменяет корректную обработку всех вариантов протокола и имени.

Настройка CMS, ссылок и SEO-сигналов

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

Проверьте тег rel="canonical" на страницах. Он должен указывать на URL без www, если именно этот вариант выбран основным. В карте сайта XML также должны присутствовать только канонические адреса. Файл robots.txt, ссылки в меню и настройки языковых версий следует привести к тому же формату.

Не стоит ограничиваться заменой домена в главной странице. Редирект должен работать для всех разделов, вложенных каталогов, файлов и параметров, если они нужны сайту. При этом рекламные метки вроде utm_source должны сохраняться. Потеря параметров во время перехода затруднит оценку рекламных кампаний и источников посещений.

Для публичного сайта важно согласовать техническое решение с его содержательной частью. Например, при оформлении раздела «О нас» структура адресов должна оставаться стабильной; рекомендации из материала про описание страницы «О нас» можно применять уже после выбора основной версии домена.

Проверка результата и типичные ошибки

Проверить настройку можно через браузер, команду curl или специализированный HTTP-инструмент. Команда для заголовков выглядит так:

curl -I https://www.example.ru/page

В ответе ожидаются статус 301 и заголовок Location: https://example.ru/page. Затем отдельно проверьте HTTP-вариант, HTTPS-вариант, главную страницу, вложенный URL, адрес с завершающим слешем и ссылку с параметрами. Во всех случаях конечным должен быть один согласованный формат.

Распространённая ошибка — временный редирект 302 вместо постоянного 301. Код 302 подходит для краткосрочных экспериментов, но для окончательного выбора домена он менее уместен. Другая проблема — редирект только главной страницы: внутренние URL при этом могут отдавать дубли или открываться на неправильном хосте.

Следите за цепочками переходов. Если запрос сначала идёт с HTTP на HTTPS, затем с www на без www, а после этого ещё меняется слеш, сервер выполняет несколько ответов подряд. Лучше объединить правила так, чтобы любой альтернативный адрес сразу переходил на окончательный HTTPS-URL. Это ускоряет загрузку и сокращает вероятность ошибок.

Скорость имеет значение и для восприятия пользователем: лишний сетевой запрос добавляет задержку до загрузки контента. В этом контексте полезно учитывать влияние скорости загрузки, особенно если сайт посещают с мобильных устройств или медленных соединений.

Не следует путать перенаправление домена с парковкой домена. Парковка может показывать техническую заглушку или связывать несколько имён с одним проектом, но не заменяет корректный HTTP-ответ. Разницу между этими подходами помогает прояснить материал о парковке домена.

Настройте DNS для обоих вариантов имени, выпустите сертификат с нужными доменами, добавьте постоянный редирект на сервере и приведите CMS, карту сайта, canonical-ссылки и внутреннюю навигацию к единому формату. После этого проверьте все сочетания протокола, поддомена и вложенного пути, а затем контролируйте индексацию и отчёты аналитики. Такой порядок позволит безопасно закрепить основной адрес без потери страниц и посетителей.