Когда сайт доступен по адресу www.site.ru, но не открывается по site.ru, проблема обычно выглядит странно: домен один и тот же, контент один и тот же, а результат разный. Для владельца сайта это не мелочь. Часть клиентов вводит адрес с www, часть без www, часть переходит из поиска, рекламы, письма или старой закладки. Если один вариант не работает, пользователь видит ошибку и может решить, что сайт полностью недоступен.
Ниже разберем, почему так происходит, как быстро отделить DNS-проблему от ошибки SSL или настройки хостинга, и что лучше проверять после исправления.
Почему адрес с www и без www может работать по-разному
site.ru и www.site.ru технически являются разными именами. Они могут вести на один сервер, но для этого их нужно отдельно настроить в DNS, на хостинге, в SSL-сертификате и в правилах редиректа. Браузер не обязан автоматически понимать, что эти адреса должны быть одинаковыми.
Обычно владелец выбирает основной вариант: например, сайт должен открываться без www, а адрес с www должен делать постоянный редирект на него. Можно выбрать и обратную схему. Важно не то, какой вариант выбран, а то, чтобы оба адреса предсказуемо открывались и не показывали ошибку.
Что чаще всего ломается
Нет DNS-записи для одного из вариантов
Самая понятная причина: в DNS настроили запись для www.site.ru, но забыли запись для site.ru, или наоборот. Тогда один адрес может возвращать IP-адрес сервера, а второй не находится вообще.
Пример: после переноса на новый хостинг вебмастер обновил CNAME для www, потому что так было в инструкции конструктора сайта. Корневой домен site.ru остался на старом IP или без A-записи. В результате www.site.ru открывается, а site.ru показывает ошибку DNS.
SSL-сертификат выпущен только на один адрес
Даже если DNS настроен верно, браузер проверяет сертификат. Сертификат должен покрывать тот адрес, который открыл пользователь. Если сертификат выпущен только для www.site.ru, а посетитель зашел на site.ru, браузер может показать предупреждение о небезопасном соединении.
Это часто проявляется после ручной установки сертификата, смены панели хостинга или подключения CDN. Для надежной схемы сертификат должен включать оба имени: основной домен и вариант с www.
Редирект настроен неправильно
Редирект нужен, чтобы привести пользователей к одному каноническому адресу. Но ошибка в правилах может привести к циклу, двойному переходу на http, возврату на старый домен или неожиданной странице хостинга.
Пример: пользователь открывает http://www.site.ru, сервер отправляет его на https://site.ru, а другое правило снова возвращает на https://www.site.ru. Браузер останавливает цепочку и показывает ошибку слишком большого количества перенаправлений.
Хостинг или веб-сервер не знает второй домен
DNS может вести оба адреса на правильный IP, но веб-сервер должен принять запрос для каждого имени. Если в панели хостинга добавлен только site.ru, а www.site.ru не указан как алиас, сервер может отдать стандартную страницу, 403, 404 или чужой виртуальный хост.
Такое бывает после переноса сайта, смены тарифа, ручной настройки Nginx/Apache или подключения нового домена в панели управления.
CDN или прокси подключены только к одному варианту
Если сайт работает через CDN, оба варианта адреса должны быть согласованы с настройками CDN, DNS и сертификатов. Иногда www уже идет через CDN, а корневой домен остается на старом сервере. Внешне это выглядит как частичная недоступность: один адрес быстрый и рабочий, второй отвечает ошибкой или старой версией сайта.
Как проверить проблему вручную
Начните с простой проверки в браузере. Откройте четыре варианта адреса:
http://site.ru;https://site.ru;http://www.site.ru;https://www.site.ru.
Запишите, что происходит в каждом случае: открывается ли сайт, есть ли предупреждение SSL, появляется ли ошибка DNS, идет ли редирект и на какой конечный адрес он приводит.
Дальше проверьте DNS. Можно использовать онлайн-инструмент проверки DNS или консольные команды вроде nslookup site.ru и nslookup www.site.ru. Важно понять, возвращают ли оба имени ожидаемые записи. Если один адрес не имеет записи или ведет на старый IP, сначала исправляют DNS.
После DNS проверьте SSL. Откройте проблемный адрес через https и посмотрите, на какое имя выдан сертификат. Для сайта с двумя вариантами адреса сертификат должен покрывать оба имени. Если сертификат корректный только для одного варианта, нужно перевыпустить или расширить его.
Затем проверьте цепочку редиректов. Она должна быть короткой и понятной: например, http://www.site.ru -> https://site.ru. Если цепочка прыгает между адресами или возвращает пользователя на http, проблема в правилах сервера, CMS, CDN или панели хостинга.
Практические сценарии: что считать исправлением
После переноса на новый хостинг работает только www
В панели нового хостинга добавили www.site.ru, потому что именно такой адрес был в старой инструкции. Корневой домен остался на старом DNS или не был добавлен как алиас. Исправление: добавить оба варианта домена в панели хостинга, настроить A/AAAA или CNAME-записи и выпустить SSL на оба имени. После изменения оба адреса должны отвечать снаружи и приводить к одному выбранному HTTPS-адресу.
После выпуска SSL без www появился браузерный риск
Сайт открывается по https://site.ru, но https://www.site.ru показывает предупреждение. Это не ошибка контента, а несовпадение имени в сертификате. Исправление: перевыпустить сертификат так, чтобы он включал site.ru и www.site.ru, затем проверить редирект. Результат считается стабильным, когда TLS-проверка проходит для обоих имен до перехода на основной адрес.
После настройки редиректа сайт ушел в цикл
Администратор добавил правило в .htaccess, а CMS уже делала собственный редирект на другой вариант адреса. В итоге браузер получает несколько противоположных команд. Исправление: выбрать один канонический адрес, оставить одно главное правило редиректа и убрать конфликтующие настройки. Контрольная проверка должна показать короткий переход без возврата между www и адресом без www.
Какой следующий шаг выбрать
- Один вариант не открывается прямо сейчас. Запустите проверку сайта для проблемного адреса. Web-Puls отдельно сравнит домен с
wwwи безwww, DNS/IP, SSL, ответы сервера, редиректы и конечный канонический host. - Оба варианта открываются, но ведут себя по-разному. Зафиксируйте конечные URL и выберите один основной HTTPS-адрес. Второй вариант должен приводить к нему постоянным редиректом без цикла.
- После исправления нужно убедиться, что сбой не вернется. Добавьте оба адреса в мониторинг, особенно после переноса, смены DNS, CDN или перевыпуска сертификата.
- Проверка подтвердила проблему, но непонятно, где менять настройки. Передайте результат на оценку разовой диагностики. В форме уже выбран нужный формат и указана тема; добавьте оба URL, время ошибки и последние изменения.
Как правильно настроить основной адрес
Сначала выберите канонический вариант: с www или без. Для SEO и удобства важно, чтобы все внутренние ссылки, карта сайта, настройки CMS и редиректы использовали один основной адрес.
Затем настройте DNS для обоих имен. Корневой домен чаще указывает на IP через A/AAAA-запись, а www может быть CNAME или отдельной A-записью, в зависимости от хостинга и CDN. Не копируйте настройки вслепую: проверьте требования вашей платформы.
После этого настройте SSL-сертификат. Он должен быть действительным, не просроченным и подходить к обоим вариантам адреса. Если используется автоматическое продление, убедитесь, что проверка домена проходит для каждого имени.
Финальный шаг - редирект. Все второстепенные варианты должны приводить к одному рабочему HTTPS-адресу. Проверять нужно не только главную страницу, но и внутренние URL: старая ссылка из рекламы или письма тоже должна открываться без ошибки.
Почему ручной проверки недостаточно
Проблема с www и без www часто появляется после работ, которые кажутся рутинными: перенос сайта, обновление DNS, выпуск SSL, изменение CDN, настройка редиректов. В момент проверки все может открываться у администратора, но часть пользователей уже получает ошибку из-за кэша DNS, другого региона, IPv6 или старой закладки.
Поэтому полезно проверять оба варианта адреса автоматически. В Web-Puls можно настроить мониторинг доступности сайта и отдельно контролировать важные URL: основной домен, вариант с www, страницу входа, корзину, форму заявки или другой критичный путь. Такой подход помогает быстрее заметить, что один адрес перестал открываться, хотя второй еще отвечает.
Когда стоит обратиться за технической поддержкой
Если проблема сводится к одной DNS-записи, ее можно исправить самостоятельно. Но при связке DNS, SSL, CDN, хостинга и редиректов легко пропустить конфликт. Особенно если сайт уже получает трафик, а ошибка проявляется только у части клиентов.
Если нужно не только увидеть недоступность, но и разобрать причину, используйте форму разовой диагностики. Укажите оба варианта адреса, текст ошибки, время проверки с часовым поясом и что менялось перед сбоем. Пароли, токены и доступ к панели хостинга для первичной оценки передавать не нужно.
Короткий чек-лист
- Выберите основной адрес: с
wwwили без. - Проверьте DNS-записи для обоих вариантов.
- Убедитесь, что хостинг принимает оба имени.
- Проверьте SSL-сертификат для
site.ruиwww.site.ru. - Настройте один понятный редирект на HTTPS и канонический адрес.
- Проверьте главную страницу и несколько внутренних URL.
- Добавьте оба варианта в мониторинг, чтобы не искать проблему по жалобам клиентов.
Вывод
Сайт с www и сайт без www выглядят как один проект, но для DNS, SSL и веб-сервера это разные адреса. Если один из них не настроен, часть пользователей увидит ошибку, даже когда владелец считает, что сайт работает. Надежная схема проста: оба адреса должны резолвиться, иметь корректный сертификат, приниматься хостингом и приводить к одному основному HTTPS-варианту. После настройки стоит включить автоматическую проверку, чтобы следующая ошибка стала видна сразу, а не после обращения клиента.
Практический маршрут: сравните проблемный адрес с его www/без www вариантом, после исправления поставьте оба адреса на контроль, а если причина остается неясной — передайте результат на оценку диагностики.