Какой код использовать для перевода сайта на HTTPS?

Только 301 (Moved Permanently). Код 302 сообщает поисковику, что переезд временный, и вес страницы остаётся на старом адресе. При постоянном перенаправлении 301 передаёт почти весь ссылочный вес на новую версию.

Можно ли настроить редирект без правки .htaccess?

Да, если хостинг или панель управления предлагает переключатель «Принудительный HTTPS» — например, в ISPmanager, cPanel или на облачных платформах. Панель просто записывает нужные строки в конфигурацию сервера за вас.

Сколько времени занимает передача веса после редиректа?

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

Что делать, если после настройки браузер показывает цикл перенаправления?

Цикл возникает, если на сервере есть встречный редирект с https на http, а также при проксировании трафика на внешний сервис с собственным правилом. Проверяют конфигурацию nginx, настройки CDN и правила в .htaccess — обычно проблема в одной строке с обратным условием.

Нужно ли переписывать внутренние ссылки вручную?

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

Что произойдёт, если оставить http-версию доступной без редиректа?

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

Постоянное перенаправление сайта на защищённый протокол

Схема постоянного перенаправления 301 на защищённый протокол

Коротко: Редирект с http на https — это постоянное перенаправление (код 301) со старого незащищённого адреса на новый защищённый. На Apache настраивается тремя строками в .htaccess, на nginx — отдельным блоком server, в IIS — правилом в модуле URL Rewrite. Ошибки в правилах дают цикл перенаправления или открытые страницы без шифрования.

Переезд на защищённый протокол давно перестал быть опцией. Браузеры помечают http-сайты плашкой «Не защищено», платёжные системы без TLS не работают в принципе, а поисковые системы отдают предпочтение страницам с сертификатом. Но одного SSL-сертификата мало: если старая версия сайта продолжает открываться, вы получаете две копии одного контента по разным адресам. Именно поэтому редирект с http на https — обязательная часть переезда, а не «доработка на потом».

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

Причины перехода на HTTPS

Причины перехода делятся на три группы: технические, коммерческие и репутационные. Техническая — TLS-шифрование защищает трафик между браузером и сервером, включая cookie сессии и данные форм. Коммерческая — большинство платёжных шлюзов и внешних API работают только по защищённому каналу. Репутационная — Chrome и Яндекс Браузер выводят предупреждение в адресной строке, а Яндекс Метрика и Вебмастер по умолчанию подсвечивают http-сайты как уязвимые.

Отдельно стоит поисковая составляющая. Google ещё в 2014 году заявил HTTPS как один из факторов ранжирования — слабый, но реальный. Яндекс учитывает его косвенно через поведенческие: пользователи чаще закрывают сайты с предупреждением «Не защищено», что напрямую влияет на поведенческие метрики.

Аспект	HTTP	HTTPS
Шифрование данных	Нет	TLS 1.2 / 1.3
Метка в браузере	«Не защищено»	Замок, имя домена
Платёжные формы	Не работают	Работают штатно
Влияние на ранжирование	Нейтрально у Google	Слабый плюс
Cookies с флагом Secure	Не передаются	Передаются

Если вы только разбираетесь в терминах и вообще в тематике продвижения, рекомендуем начать с материала Расскажем новичкам, что скрывает seo и как расшифровывается код — там объясняется база, на которую дальше опирается вся техническая часть.

Настройка 301 редиректа

Редирект на https нужен только один — постоянный, с кодом 301. Временный (302, 307) говорит поисковику: «страница скоро вернётся на прежний адрес». Вес со ссылок и поведенческих факторов такой переезд не передаёт и часто приводит к тому, что http-версия остаётся в индексе на месяцы. Правило простое: переезд на постоянный протокол — только 301.

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

IIS редирект http на https

На IIS (Windows Server) перенаправление настраивается через модуль URL Rewrite. Если модуль не установлен, его нужно добавить через Web Platform Installer. Дальше в web.config появляется блок rewrite с правилом, которое проверяет схему запроса и перенаправляет на https. Типовое правило выглядит так: условие HTTPS = off, action type Redirect, redirectType Permanent. Важно указать redirectType="Permanent" — иначе IIS по умолчанию отдаёт код 302.

Настройка на Apache и nginx

На Apache правило прописывается в .htaccess — об этом подробно в следующем разделе. На nginx перенаправление делается отдельным серверным блоком, где в директиве listen указан порт 80, а единственная директива — return 301 https://$host$request_uri;. Второй блок listen 443 обслуживает основной сайт. Такой подход предпочтительнее условных if-конструкций внутри основного server — они работают медленнее и чаще вызывают циклы.

Вы пришли к нам по SEO

Мы сделаем так, что и ваши клиенты придут к вам. SEO от 30 000 рублей в месяц.

Напишите Анатолию →

Работа с .htaccess файлом

Правильный htaccess редирект с http на https — это три строки, поставленные до основных правил перезаписи WordPress, Bitrix или другой CMS. Порядок важен: если правило окажется ниже, CMS может успеть переписать URL и редирект сработает уже на несуществующую страницу.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Разберём конструкцию. Условие %{HTTPS} off проверяет, что текущий запрос пришёл по незащищённому каналу. Если да — правило применяется. Директива R=301 указывает код ответа, флаг L останавливает дальнейшую обработку правил. %{HTTP_HOST} подставляет имя домена, поэтому правило работает и для основного адреса, и для www-версии.

Обратите внимание на подводный камень: если сайт стоит за обратным прокси или CDN (Cloudflare, Selectel, VK Cloud), сервер видит подключение не от пользователя, а от балансировщика, и %{HTTPS} всегда возвращает off. В таком случае корректнее проверять заголовок %{HTTP:X-Forwarded-Proto}. Именно из-за этой детали htaccess редирект на https с виду работает верно, но в итоге уводит пользователя в бесконечный цикл.

Для тех, кто хочет настроить редирект с http на https htaccess «на минималках», часто хватает варианта с явным указанием хоста:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://www.example.ru%{REQUEST_URI} [R=301,L]

Плюс — исключается зависимость от HTTP_HOST. Минус — правило придётся дублировать для каждого поддомена и алиасов. Универсальный вариант из предыдущего абзаца всё же предпочтительнее.

Проверка редиректа инструментами

После настройки правило нужно проверить не одним способом. Потому что браузер кеширует 301 надолго — иногда сложно отличить рабочий редирект от закешированного.

curl -I http://ваш-сайт — самый быстрый способ. В ответе должны быть HTTP/1.1 301 Moved Permanently и заголовок Location: https://...
Отчёты о скриншотах в Chrome DevTools — вкладка Network, колонка Status показывает цепочку кодов. Если редиректов больше одного, значит есть лишний хоп.
Сервисы вроде redirect-checker или httpstatus.io — показывают всю цепочку редиректов от старого адреса до финального URL и предупреждают о циклах.
Яндекс Вебмастер и Google Search Console — раздел «Диагностика» со временем покажет, если поиск увидел противоречие в переадресации.

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

По данным Google Search Central (2026), при корректно настроенном 301-редиректе новые адреса попадают в индекс в среднем за 2–4 недели, при ошибках в правилах индексация затягивается на 2–3 месяца.

Ошибки при перенаправлении

Есть три классических ошибки, которые мы встречаем в чужих проектах. Первая — использование 302 вместо 301. Из-за этого поисковая система считает переезд временным и продолжает отдавать старый адрес. Вторая — забытый редирект с https на http в компонентах CMS или внутренних скриптах. Получается встречное направление, и браузер уходит в бесконечный цикл ERR_TOO_MANY_REDIRECTS.

Третья ошибка касается CDN и прокси. Если редирект с https на http через htaccess стоит неправильно — например, с условием RewriteCond %{HTTP:X-Forwarded-Proto} !https без учёта реальной схемы, — правило может срабатывать даже на уже защищённых запросах. В логах это выглядит как постоянный редирект, а на экране — как ошибка загрузки страницы.

Ещё две проблемы помельче: забытый sitemap.xml с http-адресами и жёстко прописанные http-ссылки в шаблонах писем, меню и микроразметке. Их лучше править на новых страницах сразу, чтобы не плодить лишние хопы редиректа на каждом заходе.

Если в вашей нише много ключевых фраз и статей, при переезде имеет смысл параллельно пересобрать семантику — например, через Работа с пересекатором ключевых фраз.

Коротко о главном

Редирект с http на https — базовый технический шаг при переезде на защищённый протокол. Работает он только тогда, когда настроен код 301, а не 302, и правила стоят выше остальных перезаписей URL. На Apache всё укладывается в три строки в .htaccess, на nginx — в отдельный серверный блок, на IIS — в правило URL Rewrite. Прокси и CDN требуют проверки заголовка X-Forwarded-Proto, иначе редирект зациклится. Проверяйте результат через curl и DevTools, не забывайте про sitemap и внутренние ссылки — тогда переезд проходит без просадки позиций.