WWW и без WWW открывают разные сайты: как настроить единый домен

Адреса www.example.ru и example.ru технически являются разными хостами. Если DNS, виртуальные хосты или CDN направляют их в разные каталоги, пользователи и поисковые системы видят две версии, разные сертификаты или вообще чужой сайт.

Выберите один основной хост, настройте оба имени на одну инфраструктуру и выполните один постоянный редирект на канонический вариант. До включения HSTS убедитесь, что сертификат и HTTPS работают для обоих имен.

Что проверить в первую очередь

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

• Сравните A, AAAA и CNAME для корневого домена и www у нескольких DNS-резолверов.
• Получите HTTP-заголовки обоих адресов по HTTP и HTTPS без автоматического перехода.
• Проверьте, какой server block/vhost принимает каждый Host и какой document root использует.
• Убедитесь, что сертификат содержит оба имени и отдается правильным SNI-хостом.

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

У подобных сбоев редко бывает одна универсальная причина. На итог одновременно влияют конфигурация приложения, окружение, данные, кеш, права и внешние сервисы. Проверка должна идти от внешнего симптома к конкретному уровню, на котором впервые появляется неверное состояние.

• www остался CNAME на старый хостинг, а корневой домен уже направлен на новый сервер.
• Default virtual host обслуживает один из адресов чужим или системным каталогом.
• Редиректы настроены одновременно в CDN, Nginx и приложении, образуя цепочку или цикл.
• Сертификат выпущен только на каноническое имя, поэтому HTTPS редирект не успевает выполниться.
• Приложение генерирует canonical и абсолютные URL на основе непроверенного Host.

Пошаговая диагностика

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

• Проверьте DNS с учетом IPv4 и IPv6: старый AAAA часто остается незамеченным.
• Сравните IP, сертификат, Server, Location и конечный URL для четырех комбинаций HTTP/HTTPS и www/без www.
• Посмотрите access log с полем Host, чтобы увидеть фактический виртуальный хост.
• Отключите кеш браузера и проверьте через curl, так как 301 и HSTS запоминаются.
• Проверьте настройки CDN, proxy и панели хостинга, если DNS ведет не прямо на сервер.

Как выбрать и закрепить канонический хост

С точки зрения SEO оба варианта допустимы. Важно выбрать один, последовательно использовать его во всех сигналах и не создавать цепочек.

• Основной хост должен совпадать в 301, canonical, sitemap, hreflang и внутренних ссылках.
• Альтернативный хост обязан поддерживать HTTPS, чтобы безопасно выполнить редирект.
• Редирект сохраняет путь и query string, если параметры действительно нужны странице.
• Переход должен происходить за один шаг, например HTTP www сразу на HTTPS без www.
• Приложение принимает только разрешенные Host, чтобы исключить подмену ссылок и кеша.

Как исправить проблему

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

• Исправьте DNS обоих имен и дождитесь обновления TTL, не удаляя рабочую запись раньше времени.
• Добавьте оба server_name в контролируемую конфигурацию и отдельное правило канонизации.
• Выпустите сертификат с SAN для корня и www.
• Оставьте одно место, ответственное за редирект, и уберите конфликтующие правила.
• Обновите canonical, sitemap и внутренние абсолютные ссылки на выбранный адрес.

Безопасный порядок внедрения

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

Как проверить результат

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

• Все четыре входных адреса завершаются на одном каноническом URL за один редирект.
• Оба HTTPS-имени отдают валидный сертификат без предупреждения браузера.
• Путь, безопасные параметры и метод GET сохраняются корректно.
• В sitemap и HTML нет смешения www/без www, а сервер не отдает чужой vhost.

Типичные ошибки при исправлении

• Удалять DNS альтернативного хоста вместо настройки редиректа.
• Включать HSTS includeSubDomains до проверки сертификатов и всех поддоменов.
• Создавать цикл между CDN и Nginx из-за разных представлений о каноническом хосте.
• Использовать JavaScript-редирект вместо серверного 301.

Как предотвратить повторение

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

• Проверяйте корень и www в мониторинге DNS, TLS и HTTP.
• Храните vhost и правила редиректов в системе контроля версий.
• Добавьте тест конечного URL и количества переходов после каждого изменения CDN.
• Ограничьте список разрешенных Host на уровне приложения и proxy.

Что подготовить для разбора

• Краткое описание ожидаемого и фактического поведения без паролей, токенов и персональных данных.
• Точное время и последовательность действий, после которых появляется проблема.
• Версии приложения, окружения и зависимостей, а также перечень последних изменений.
• Фрагменты журналов с контекстом до и после ошибки; секреты в них необходимо скрыть.
• Описание уже выполненных проверок и способ безопасно повторить проблему.

Частые вопросы

Что лучше для SEO: www или без www?

Оба варианта равнозначны при последовательной настройке. Выбирайте удобный и закрепляйте 301, canonical, sitemap и внутренними ссылками.

Нужно ли выпускать SSL на адрес, который сразу редиректит?

Да. TLS устанавливается до HTTP-редиректа, поэтому альтернативное имя тоже должно иметь валидный сертификат.

Когда нужна помощь специалиста

Если www и корневой домен ведут на разные версии или образуют циклы, я могу проверить DNS, IPv6, vhost, CDN и сертификаты, настроить один безопасный редирект и привести SEO-сигналы к выбранному адресу.