Как настроить переадресацию с HTTP на HTTPS и WWW в 2026

Переадресация с HTTP на HTTPS и на канонический WWW-домен в 2026 году — это уже не «галочка для SEO», а базовая гигиена сайта. Я почти на каждом проекте настраиваю это в самом начале: и на WordPress, и на Bitrix, и на Laravel, потому что криво сделанный редирект очень быстро превращается в дубли, петли, mixed content и странные падения в аналитике.

На моей практике чаще всего проблема не в самом SSL, а в том, что кто-то поставил сертификат, включил редирект через плагин или панель хостинга и забыл про www/non-www, прокси, CDN, Cloudflare и заголовки. А потом клиент пишет: «Почему Google видит две версии сайта?» или «Почему после обновления PHP 8.2 слетела авторизация?». Честно говоря, в 2026 году такое уже должно делаться один раз и правильно.

Зачем нужна единая каноническая версия сайта

Если коротко: поисковик должен видеть один адрес сайта, а не четыре. Условно говоря, у вас может быть http://site.ru, http://www.site.ru, https://site.ru и https://www.site.ru. Для человека это «вроде одно и то же», а для бота — четыре разных URL. И если вы не склеили это редиректом, начинаются дубли страниц, размывание ссылочного веса и путаница в индексации.

Я обычно делаю так: выбираю одну главную версию — чаще всего https://www.site.ru или https://site.ru, в зависимости от проекта и исторического поведения домена. Если домен уже много лет жил с www, а в индекс попала именно эта версия, ломать привычную схему без причины не стоит. Если хотите глубже понять базу, у меня есть отдельная статья про SSL-сертификаты и про переход на HTTPS — там хорошо разобраны базовые моменты.

Однозначно стоит сделать редирект с HTTP на HTTPS не только ради SEO. Это про безопасность, корректные куки, работу сервисов аналитики, платежей и форм. Сейчас браузеры уже открыто помечают незащищённый HTTP как небезопасный. А если сайт собирает данные пользователей, шифрование — это не опция, а нормальный стандарт.

Какой порядок настройки правильный в 2026

На деле самый безопасный порядок такой: сначала проверяете, что SSL-сертификат уже работает на нужном домене, потом настраиваете редирект на канонический HTTPS+WWW, и только после этого обновляете внутренние ссылки, sitemap, canonical, robots и интеграции. Если перепутать порядок, можно словить 301-цепочку или, что хуже, временную петлю.

У меня был клиент на Bitrix с PHP 8.1 и MySQL 8.0, где ребята сначала включили редирект в Nginx, потом поставили плагин для HTTPS в админке, а поверх ещё Cloudflare. Итог — три слоя логики, запросы ходили по кругу, а в логах было 14–18 редиректов на один URL. Сайт открывался, но PageSpeed и crawl budget были убиты напрочь. Это плохая идея.

Правильная схема выглядит так:

1. Сайт должен открываться по HTTPS без ошибок сертификата.
2. Выбираете одну главную версию: с www или без.
3. Настраиваете единый 301-редирект со всех альтернативных вариантов.
4. Проверяете внутренние ссылки, canonical, sitemap и robots.
5. Тестируете ответ сервера через curl, DevTools и онлайн-проверку.

Если хотите сделать это в комплексе, я бы ещё посмотрел на настройку HTTPS-редиректов и HSTS. HSTS — вещь полезная, но включать её надо аккуратно, особенно если у вас есть поддомены, старые интеграции или не до конца понятная инфраструктура.

Настройка редиректа в Nginx

Если у вас обычный VPS или выделенный сервер, чаще всего редирект настраивается именно в Nginx. Я этот вариант люблю больше всего: он быстрый, прозрачный и не зависит от CMS. На сайтах с высокой нагрузкой — это особенно важно. Для WordPress, Bitrix и Laravel на PHP 8.2/8.3 Nginx обычно даёт самый предсказуемый результат.

Вот рабочий пример для редиректа с HTTP на HTTPS и на www. Допустим, канонический домен у нас www.site.ru.

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

    return 301 https://www.site.ru$request_uri;
}

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

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

    return 301 https://www.site.ru$request_uri;
}

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

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

    root /var/www/site/public;
    index index.php index.html;

    # остальная конфигурация сайта
}

Тут логика простая: любой HTTP-запрос сразу улетает на HTTPS с www. Если кто-то заходит на https://site.ru, он тоже получает один редирект на https://www.site.ru. Всё. Без лишних условий и магии.

Но есть нюанс. Если сайт стоит за обратным прокси, CDN или Cloudflare, нужно смотреть на заголовки X-Forwarded-Proto и на то, как ваш upstream понимает HTTPS. У одного клиента на Laravel был случай: Nginx редиректил правильно, а приложение считало, что запрос пришёл по HTTP, и генерировало абсолютные ссылки без https. В итоге формы работали, но в письмах и шаблонах были старые адреса. Пришлось править trusted proxies и конфиг приложения.

Если тема серверной настройки вам близка, советую ещё почитать про обратный прокси Nginx и HTTP/2 и HTTP/3. Редиректы, прокси и транспортный уровень часто связаны сильнее, чем кажется на первый взгляд.

.htaccess для Apache: когда это нужно

Если сайт крутится на Apache, а доступа к виртуальному хосту нет, тогда остаётся .htaccess. Я не фанат такого подхода, потому что он медленнее и проще сломать структуру, но в shared-хостинге это часто единственный вариант. Для небольших сайтов на WordPress это нормальная история.

Ниже пример для редиректа на HTTPS и WWW. Допустим, главным адресом должен быть https://www.site.ru.

RewriteEngine On

# Редирект с HTTP на HTTPS и на WWW
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^site\.ru$ [NC]
RewriteRule ^ https://www.site.ru%{REQUEST_URI} [L,R=301]

Если у вас наоборот главным должен быть вариант без www, меняете правило на такой вариант:

RewriteEngine On

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

Но тут есть тонкость: если хостинг уже сам делает HTTPS-принудительно на уровне панели, а вы ещё добавили правило в .htaccess, можно получить дублирование логики. Я на WordPress однажды видел конфигурацию, где и плагин Really Simple SSL, и .htaccess, и редирект в панели хостинга работали одновременно. Сайт вроде открывался, но в логах было видно лишнее обращение к серверу на каждый запрос. На слабом shared-хостинге это чувствуется даже по Time to First Byte.

Для WordPress я обычно предпочитаю сначала смотреть на серверный уровень, потом уже на CMS. Если проект большой или вы только планируете перенос, полезно будет глянуть и материал про ускорение WordPress, и про сравнение Bitrix и WordPress. Там хорошо видно, почему одна и та же задача по редиректам решается по-разному в зависимости от стека.

Настройка через CMS: WordPress, Bitrix, Laravel

Иногда клиент просит: «Сделайте вообще без сервера, только через CMS». Я обычно отвечаю: можно, но это не лучший вариант. Редирект на уровне приложения — норм как временное решение или для совсем простых схем. Но если у вас есть доступ к Nginx или Apache, лучше делать именно там. Это и быстрее, и надёжнее.

WordPress часто решают через плагины типа Really Simple SSL или Redirection. Но для принудительного перехода с HTTP на HTTPS+WWW этот способ я использую только если нет прав на сервер. Плагины — это дополнительная точка отказа. И да, они иногда конфликтуют с кэшем, CDN и security-плагинами.

Bitrix обычно требует аккуратного обращения с настройками в .settings.php, конфигурацией веб-сервера и логикой URL в компонентах. У меня был проект на Битрикс с PHP 8.3, где редирект сделали в init.php через LocalRedirect(). Работало, но в некоторых случаях редирект срабатывал уже после инициализации части ядра. Итог — лишняя нагрузка и странные ошибки в административной части. Для Битрикс я почти всегда советую серверный редирект и только потом проверку доменных настроек в самом ядре.

Laravel позволяет красиво обрабатывать редиректы через middleware или trusted proxies. Но, честно говоря, если задача только в www/https, не надо тащить это в код приложения. Вот пример на PHP, если всё же нужно быстро проверить логику или сделать fallback:

<?php

$host = $_SERVER['HTTP_HOST'] ?? '';
$uri  = $_SERVER['REQUEST_URI'] ?? '/';
$isHttps = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off')
    || (isset($_SERVER['SERVER_PORT']) && (int)$_SERVER['SERVER_PORT'] === 443);

if (!$isHttps || $host === 'site.ru') {
    header('Location: https://www.site.ru' . $uri, true, 301);
    exit;
}

Но я повторю: это скорее запасной путь. Если есть возможность, задачу надо закрывать на уровне веб-сервера. Именно так сайт ведёт себя стабильнее, особенно если у вас ещё настроены OPcache, Redis и кэширование страниц.

SEO-последствия и проверка индексации

Редирект сам по себе не решает SEO-задачу до конца. После настройки нужно убедиться, что поисковики видят именно ту версию, которую вы выбрали. Я обычно проверяю canonical, sitemap.xml, robots.txt и внутренние ссылки. Если этого не сделать, можно получить кашу из URL, и тогда даже идеальный 301 не спасёт.

С точки зрения SEO редирект 301 передаёт сигнал о постоянном переезде. Это нормальная история, но всё равно нужно обновить карту сайта и убрать ссылки на старые варианты. Если у вас в sitemap остались HTTP-адреса, Google будет тратить crawl budget на лишнюю работу. А если на страницах стоят canonical на неканонический домен, вы сами себе мешаете.

Я часто советую после настройки открыть старые URL и посмотреть HTTP-ответ через curl -I. Вот что должно быть в идеале: один ответ 301 и финальный 200 на выбранном домене. Никаких 302, 307 и длинных цепочек.

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

Если хотите системно подойти к проверке, загляните в SEO-аудит сайта и в статью про XML sitemap для SEO. Там есть полезные моменты, которые я сам использую на проектах после миграций и смены доменной схемы.

И ещё один момент. После редиректа обязательно проверьте Google Search Console и Яндекс.Вебмастер. В 2026 году ошибки с доменной версией очень быстро отражаются в отчетах. Если индексируется старый вариант, значит где-то остались ссылки, canonical или sitemap на прежний адрес. Тут уже не надо гадать, надо лезть в детали.

HSTS, CDN и прокси: где чаще всего «льются» ошибки

Вот здесь начинаются самые неприятные истории. На маленьком сайте всё может работать идеально, а потом вы подключаете Cloudflare, CDN, WAF или обратный прокси — и редирект начинает вести себя странно. Причина обычно в том, что сервер видит один протокол, а приложение думает, что другой.

Если у вас CDN, сначала проверьте режим SSL на стороне CDN. Например, в некоторых конфигурациях Cloudflare включён Full SSL, но origin-сервер не настроен корректно. Тогда вы получаете либо бесконечный редирект, либо mixed content. Для таких случаев у меня есть отдельный материал про SSL без ошибок mixed content — он очень помогает не наступить на грабли.

HSTS тоже нужно использовать с головой. Да, это полезная защита: браузер запоминает, что сайт должен открываться только по HTTPS. Но если вы включите HSTS слишком рано, а потом обнаружите, что какой-то поддомен или внешний сервис ещё живёт на HTTP, будет больно. Однозначно стоит сначала проверить всю инфраструктуру: почту, поддомены, API, стейджинг и старые интеграции.

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

Частые ошибки и как их исправить

Самая частая ошибка — редирект настроен только на главную страницу, а вложенные URL работают как попало. Вторая по популярности — сайт отправляет пользователя на www, а потом CMS снова перекидывает его обратно без www. Третья — после редиректа ломаются картинки, стили или скрипты, потому что часть ассетов осталась на HTTP.

Ещё одна классика — перенос сайта на HTTPS без пересборки абсолютных ссылок в базе. Это особенно заметно на старых WordPress и на некоторых Bitrix-проектах, где в контенте сохранены полные URL. Тогда на страницах появляются mixed content-ошибки, а браузер блокирует шрифты, стили и iframe. Если нужна отдельная инструкция по этой теме, посмотрите материал про mixed content.

Я обычно делаю чек-лист в таком порядке:

• проверяю HTTP → HTTPS на всех вариантах домена;
• смотрю, есть ли цепочки редиректов;
• проверяю canonical в шаблонах;
• ищу старые HTTP-ссылки в базе данных;
• перепроверяю sitemap и robots.txt;
• тестирую формы, авторизацию и оплату;
• смотрю логи сервера на 301/302/4xx.

Если где-то всплывает ошибка 500 после правок, не паникуйте. Иногда проблема вообще не в редиректе, а в конфигурации сервера или в PHP-обработчике. У меня такое было после обновления PHP с 8.1 на 8.3: один устаревший модуль начал падать раньше, чем срабатывало правило rewrite. В таких случаях помогает нормальный чек-лист по ошибкам сайта и анализ логов.

Пошаговый алгоритм для проекта в 2026

Если собрать всё в один рабочий алгоритм, я бы делал так. Сначала определяю главную версию домена. Для проектов с историей это может быть www, для новых — часто без www. Потом убеждаюсь, что SSL уже выпущен и корректно отрабатывает на обеих версиях. После этого настраиваю единый 301-редирект на сервере.

Следом иду в CMS и обновляю внутренние URL, canonical, sitemap, Open Graph и, если нужно, hreflang. Для мультиязычных проектов это особенно критично, потому что лишние редиректы ломают связки языковых версий. Если у вас сложная структура, советую ещё посмотреть статью про многоязычный сайт и про hreflang.

Дальше я обычно проверяю производительность. И вот здесь многие удивляются: «Зачем редирект проверять в PageSpeed?». А затем, что лишняя цепочка редиректов может легко съесть 100–300 мс, а иногда и больше, особенно если сервер далеко, SSL настраивали криво, а CDN работает через дополнительный слой. На мобильном это ощущается сильнее. Для глубокого разбора скорости у меня есть отдельные статьи про Core Web Vitals и PageSpeed Insights.

На практике нормальный редирект в 2026 году — это не просто «чтобы открывалось». Это часть общей архитектуры сайта. Он должен быть быстрым, однозначным и предсказуемым. Если хотите, чтобы сайт был живым, безопасным и не терял позиции после технических изменений, редирект надо проектировать так же серьёзно, как кэширование, обновления CMS или защиту от взлома.

Если вам нужно настроить это на боевом проекте, я обычно смотрю всю схему целиком: сервер, CMS, CDN, сертификат, аналитика, Search Console и логи. Именно поэтому услуги по поддержке Bitrix, поддержке WordPress и доработке сайта часто включают не только правки кода, но и аккуратную техническую настройку окружения.