Как настроить SSL для www и без www в 2026 году

Настроить SSL для www и без www в 2026 году — это не просто «включить HTTPS» и забыть. На деле тут легко наделать дубли, словить циклические редиректы, потерять часть трафика и получить грязь в аналитике. Я у себя на проектах обычно сразу привожу домен к одной канонической версии и отдельно проверяю, как это переживут Bitrix, WordPress, Laravel и CDN.

Зачем приводить www и без www к одной версии

Если коротко: потому что это плохая идея оставлять и example.ru, и www.example.ru как две равноправные версии. Для пользователя разницы почти нет, а для поисковиков это два разных адреса. И вот тут начинается веселье: дубль страниц, распыление ссылочного веса, лишние редиректы, путаница в cookie и иногда проблемы с OAuth, если сайт завязан на внешние сервисы.

На моей практике один интернет-магазин на WordPress с WooCommerce сидел на двух версиях домена почти два года. В GSC было по 12–15 тысяч URL в индексе, хотя реально страниц было около 4 тысяч. После приведения к одной версии и нормальной склейки через 301 трафик сначала просел на 3–4 дня, потом стабилизировался, а через месяц сайт вернул позиции и даже прибавил по низкочастотке. Честно говоря, в 2026 году такой хаос на домене — это уже признак технического долга, а не «ничего страшного».

Если у вас уже есть материалы по теме, я советую сначала освежить базу: что такое SSL-сертификат и зачем он нужен сайту и настройка HTTPS редиректов и HSTS. Там хорошо разобраны базовые принципы, а здесь я пойду именно в практику: как настроить SSL для www и без www, чтобы не словить сюрпризы.

Как вообще работает SSL для www и без www

SSL-сертификат сам по себе не «привязывается» к одной форме домена в каком-то магическом смысле. В 2026 году почти всегда используют либо Wildcard, либо обычный SAN-сертификат, который покрывает несколько имён: example.ru и www.example.ru. Если есть поддомены, тогда уже смотрят на wildcard вида *.example.ru, но это не всегда лучший выбор.

На деле тут важны три вещи: DNS-записи, сертификат и редирект. DNS должен указывать на правильный сервер. Сертификат должен включать оба имени. А сервер — отдавать 301 с неканонической версии на каноническую. Если хотя бы один элемент сделан криво, получаются предупреждения в браузере, ошибки проверки сертификата или редирект-луп.

Я обычно рекомендую сначала выбрать канонический вариант: либо https://example.ru, либо https://www.example.ru. И уже после этого настраивать всё остальное. Нельзя оставлять «как-нибудь пусть работает». Не работает. Особенно если у вас подключены CDN, CRM, формы обратной связи, сервисы аналитики и рассылки.

Как выбрать каноническую версию домена

Выбор между www и без www — это не вопрос вкуса. Это вопрос архитектуры. Я обычно смотрю на то, как настроены DNS, есть ли CDN, какие сертификаты выпускаются, как работают куки и есть ли уже внешние упоминания в ссылочном профиле. Иногда без www удобнее для бренда. Иногда www лучше с точки зрения совместимости.

Если говорить грубо, для большинства сайтов в 2026 году я ставлю без www, а www редиректю на основной домен. Но если у клиента уже 10 лет живёт www-версия, Mailchimp, Facebook Pixel, подписка на поддоменах и куча старых ссылок — я не геройствую. Оставляю как есть, лишь бы всё было стабильно.

Здесь полезно посмотреть и соседние статьи: как выбрать хостинг для сайта — чтобы сервер не мешал нормальной SSL-настройке, а также как настроить 301 редиректы, потому что в нашем случае редирект — это половина успеха.

Если у вас сайт на Bitrix или WordPress, канонический домен потом лучше зафиксировать и в настройках CMS. Иначе можно получить ситуацию, когда nginx уже редиректит правильно, а сама CMS генерирует внутренние ссылки на старую версию. Это, кстати, одна из самых частых ошибок у клиентов на PHP 8.2 и 8.3 с nginx + PHP-FPM.

Какой SSL-сертификат нужен для обеих версий домена

Чтобы сертификат работал и на www, и без него, у вас должно быть указано оба имени в SAN. Например:

example.ru
www.example.ru

Если сертификат выдаёт Let’s Encrypt, то он спокойно покрывает оба варианта. У меня на большинстве проектов это вообще стандарт: Let’s Encrypt + автообновление. Для сайтов на Linux-серверах с nginx это обычно самый практичный сценарий. На Apache тоже работает, но там уже смотрим на структуру виртуальных хостов и .htaccess.

Если сертификат купленный, проверьте, чтобы в нём были прописаны оба домена. Да, в 2026 году это всё ещё встречается: клиент купил SSL, установил, а потом удивляется, что www показывает предупреждение. Причина банальная — сертификат выпустили только на основной домен. Это не баг браузера, это ошибка выпуска.

У меня был случай с корпоративным сайтом на Laravel 10 под PHP 8.3 и MySQL 8.0. Сертификат установили только на example.ru. Внутренние API-запросы шли через www.example.ru, и фронт периодически ловил mixed content и CORS-ошибки. Пришлось не просто перевыпускать сертификат, а ещё и править конфиг nginx и переменные окружения в .env.

Настройка на nginx: рабочий пример для www и без www

Если у вас nginx, задача решается довольно чисто. Я обычно делаю отдельный серверный блок для HTTP, который сразу уводит весь трафик на HTTPS и на одну каноническую версию. Потом отдельный блок для канонического хоста с сертификатом. И ещё один блок — на неконаническую версию, которая делает 301.

Вот рабочий пример. Допустим, основной домен у нас без www.

server {
    listen 80;
    listen [::]:80;
    server_name example.ru www.example.ru;

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

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

    root /var/www/example.ru/public;
    index index.php index.html;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

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

Это не единственный вариант, но он понятный и надёжный. На практике я часто вижу конфигурации, где редирект сделан только на HTTP, а HTTPS-зона для www вообще забыта. Потом браузер сначала пытается открыть https://www.example.ru, получает сертификат или виртуальный хост не туда, и всё начинает сыпаться. Однозначно стоит проверять обе схемы: и HTTP, и HTTPS, и обе версии домена.

Если сайт за Cloudflare, Selectel, Timeweb Cloud, Hetzner или обычным VPS, логика одна и та же. Но в CDN иногда включается «гибкий SSL» или проксирование, и тогда можно случайно получить бесконечный редирект. Поэтому после настройки я всегда делаю curl -I и проверяю цепочку ответов.

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

В ответе должно быть видно, что неконаническая версия отдаёт 301 на каноническую. Не 302. Не 307. Именно 301, если речь о постоянной склейке доменов.

Настройка на Apache и .htaccess

Если у вас Apache, то можно решить вопрос через конфиг виртуального хоста или через .htaccess. Я честно говоря больше люблю править именно vhost, потому что .htaccess — это лишняя нагрузка и не всегда лучший вариант. Но в shared-hosting он часто остаётся единственным инструментом.

Пример для .htaccess, если канонический домен без www:

RewriteEngine On

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.ru$ [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [L,R=301]

Если наоборот нужен www, просто меняете адрес в правиле. Но я всегда рекомендую после правки протестировать не только главную страницу, но и внутренние URL, картинки, AJAX-эндпоинты и вход в админку. На WordPress это особенно важно, потому что часть ссылок может тянуться из базы, темы или плагина кеширования.

У одного клиента на WordPress 6.5 мы поймали странную ситуацию: главная редиректилась правильно, а страницы записей открывались с двойным редиректом. Причина была в том, что в wp-config.php стоял WP_HOME с одной версией домена, а в базе siteurl — с другой. Пришлось синхронизировать всё и почистить кеш LiteSpeed Cache. После этого PageSpeed на мобильном вырос с 74 до 89, хотя задача была вообще не про скорость. Но такие вещи часто идут пакетом.

Особенности для Bitrix, WordPress и Laravel

На Bitrix всё упирается в правильные настройки домена, кеширования и редиректов на уровне сервера. Если сайт в 1С-Битрикс, я обычно первым делом проверяю, что в настройках сайта указан один основной домен, а в /bitrix/php_interface/dbconn.php и init.php нет самописного хаоса. Ещё отдельно смотрю, не прописан ли где-то старый www в шаблонах, корзине, почте и CRM-интеграциях.

WordPress проще в базовой логике, но там больше шансов на конфликт плагинов. Если вы уже читали как ускорить WordPress, то знаете, что кеши и редиректы на этом движке часто живут своей жизнью. Я обычно после настройки SSL ещё сбрасываю кеш объекта, файловый кеш, CDN-кеш и кеш страницы, иначе пользователь может какое-то время видеть старый canonical или смешанные ссылки.

Laravel, наоборот, обычно чистый. Там всё решается через nginx, переменные окружения и, если нужно, middleware. Но есть нюанс: если приложение генерирует абсолютные URL через APP_URL, то там должен быть уже один канонический адрес. Иначе в письмах, webhook-ах, JSON-ответах и ссылках в админке начнут гулять разные версии домена.

На одной CRM-системе на Laravel 11 и PHP 8.2 я видел ситуацию, когда фронт редиректил на https://example.ru, а API в письмах и webhook-ответах отдавал ссылки на https://www.example.ru. Итог — жалобы пользователей, лишние запросы в поддержку и путаница в логах. После унификации адреса и правки APP_URL проблема исчезла. Грубо говоря, домен должен быть один не только для браузера, но и для всей логики сайта.

Как проверить, что всё работает правильно

После настройки я всегда делаю ручную проверку. Не доверяю только визуальному открытому сайту. В 2026 году это слишком слабый контроль. Нужны curl, браузер, инспектор сертификата, DevTools, а ещё желательно проверить данные в Search Console и Яндекс.Вебмастере.

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

• Открывается ли http://example.ru и уходит ли он на нужный HTTPS;
• Открывается ли http://www.example.ru и получает ли 301;
• Открывается ли https://www.example.ru без предупреждений сертификата;
• Нет ли цепочки из 2–3 редиректов вместо одного;
• Не появляется ли mixed content в консоли браузера;
• Совпадает ли canonical на страницах с выбранной версией домена.

Если хотите проверить ответ сервера более предметно, используйте curl -IL:

curl -IL http://www.example.ru/page/
curl -IL https://www.example.ru/page/
curl -IL http://example.ru/page/
curl -IL https://example.ru/page/

Ещё я советую заглянуть в статьи как настроить SSL без ошибок mixed content и почему сайт не индексируется. Они хорошо дополняют тему, потому что после перехода на HTTPS у людей часто всплывает именно смешанный контент или проблемы с индексацией дублей.

Чаще всего возникающие ошибки и как их не допустить

Самая распространённая ошибка — настроить редирект только для одной схемы. Например, с http://www на https://example.ru, но забыть про https://www. Вторая по популярности — сертификат только на один домен. Третья — у CMS в базе остался старый адрес, и она продолжает генерировать ссылки не туда.

Ещё бывает проблема с HSTS. Если вы уже включили жёсткий режим и потом ошиблись в конфиге, браузер может надолго запомнить неправильное направление. Тогда кажется, что «сайт сломался у всех», хотя на деле вы просто сделали слишком агрессивное принуждение к HTTPS до полной отладки. Я обычно сначала проверяю редиректы, потом mixed content, потом только включаю HSTS.

Отдельная боль — CDN. Если там включён прокси-режим, а на origin-сервере ещё стоит редирект на другой хост, можно получить петлю. Лечится это спокойно, но надо понимать, где именно находится конечная точка TLS-терминации. Иначе будете полдня смотреть на 525, 526 или бесконечный 301.

Не забывайте и про SEO-настройки. Если в sitemap.xml у вас часть URL на www, а часть без www, это уже повод для беспокойства. Лучше сразу привести XML sitemap к одной версии, а потом проверить robots.txt и canonical. Заодно рекомендую посмотреть материал настройка XML sitemap для SEO и настройка robots.txt.

Чек-лист настройки SSL для www и без www в 2026 году

Я обычно работаю по простому чек-листу. Он помогает не забыть мелочи, а в SSL и редиректах мелочи как раз всё и решают.

1. Выбираю канонический домен: www или без www.
2. Проверяю DNS-записи на обе версии домена.
3. Выпускаю сертификат с SAN на оба имени.
4. Настраиваю 301 с неконанической версии на каноническую.
5. Проверяю HTTP и HTTPS отдельно.
6. Правлю настройки CMS: WordPress, Bitrix или Laravel.
7. Обновляю canonical, sitemap, internal links.
8. Проверяю mixed content и консоль браузера.
9. Тестирую curl, PageSpeed, Lighthouse и Search Console.
10. После стабилизации включаю HSTS, если это действительно нужно.

Если проект уже живой, после смены версии домена я советую ещё посмотреть логи 3–7 дней. Иногда старые боты, внешние сервисы и даже CRM продолжают ломиться на старые адреса. В таких случаях полезны мониторинг и логирование. У меня был клиент, у которого после склейки ещё две недели сыпались запросы на старый www из внешнего каталога и платёжного сервиса. Без логов мы бы просто не поняли, откуда это идёт.

Если вам нужна техническая помощь руками, а не советы в вакууме, можно посмотреть услуги на поддержку Bitrix, поддержку WordPress или доработку сайта. На практике настройка SSL часто идёт вместе с правками nginx, CMS и безопасности, поэтому это не та задача, которую стоит растягивать на недели.

Когда лучше не мучиться самому

Если у вас простой лендинг на Apache и один домен — да, можно сделать всё за вечер. Но если сайт живёт на Bitrix, подключён к CRM, использует CDN, почтовые сервисы, webhooks, поддомены и отдельный API, я бы не играл в лотерею. Там одна неверная галочка может привести к падению входа в админку, ошибкам 500, проблемам с оплатой и жалобам пользователей.

Особенно осторожно надо быть, если сайт уже переведён на PHP 8.1, 8.2 или 8.3, а сервер работает под nginx 1.24/1.26 и ещё есть reverse proxy. В таких конфигурациях ошибка в server_name или в обработке X-Forwarded-Proto может сломать генерацию ссылок и редиректы. И тут уже не поможет «перезапустить сервер». Нужна нормальная диагностика.

Я обычно советую привлекать специалиста, если есть хотя бы один из признаков: большой трафик, интернет-магазин, много интеграций, мультиязычность, API, нестандартный хостинг или уже случались падения после обновлений. Это не перестраховка. Это нормальный рабочий подход. И если нужно не только настроить SSL, но и привести в порядок сервер, DNS, кеши и безопасность, я бы начал с аудита и только потом переходил к правкам.

На моей практике нормальная настройка SSL для www и без www занимает от 30 минут до 2–3 часов, если всё чисто. Если же наследие старое, а сайт собирался по частям, можно и на полдня застрять. Но это всё равно лучше, чем потом неделями ловить просадку в SEO и чинить кривые редиректы по одному URL.