Настройка SSL на сайте после установки: редиректы, HSTS и смешанный контент

Редирект с http на https: как настроить правильно

Задача редиректа — не дать ни одному запросу остаться на незащищённом протоколе, включая заходы по старым ссылкам из поиска, закладок и внешних сайтов. Редирект должен быть постоянным (код 301, а не временный 302) — это сигнал поисковикам передать вес страницы на новый адрес, а не просто перебросить посетителя. В nginx это отдельный серверный блок на 80 порту:

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}

Важная деталь — сразу определиться с каноническим адресом: с www или без. Если оставить оба варианта равноправными, поисковики будут видеть два независимых сайта с одинаковым содержимым, что размывает SEO-вес. Правильная схема в одно действие: с http приводить сразу на канонический https-адрес, без промежуточного редиректа http→https→www→https без www — каждое лишнее звено цепочки редиректов замедляет загрузку страницы на десятки-сотни миллисекунд и путает часть краулеров.

HSTS: заголовок, который лучше включать не сразу

HSTS (HTTP Strict Transport Security) — это заголовок ответа сервера, который говорит браузеру: «на этот домен больше никогда не заходи по http, даже если пользователь явно наберёт http:// в адресной строке». После первого визита браузер сам, без запроса на сервер, переписывает все последующие обращения к домену на https. Настраивается директивой в конфиге сервера:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

max-age задаётся в секундах (в примере — год), includeSubDomains распространяет правило на все поддомены. Здесь есть риск, о котором редко предупреждают: если у сайта есть поддомен, который по какой-то причине пока не работает на https (тестовый стенд, старый сервис), правило includeSubDomains сделает его недоступным для всех, кто уже получил HSTS-заголовок — браузер просто откажется открывать его по http, а https там не настроен. Именно поэтому HSTS стоит включать только после того, как редирект и https проверены на всех поддоменах и сайт отработал стабильно без ошибок протокола минимум пару недель. Отдельно — параметр preload: он добавляет домен в зашитый в браузеры список, что делает откат на http практически невозможным (список обновляется браузерами редко и с задержкой), включать его стоит только при полной уверенности в конфигурации навсегда.

Смешанный контент: что это и почему браузер всё равно ругается

Смешанный контент возникает, когда https-страница подгружает часть ресурсов — картинки, скрипты, стили, шрифты — по обычному http-адресу. Браузер в этом случае не показывает уже привычную «безопасную» индикацию, а часть смешанного контента (в первую очередь скрипты и iframe) блокирует полностью, из-за чего элементы страницы визуально ломаются. Причина почти всегда одна: ссылки на ресурсы прописаны в базе данных или коде сайта абсолютным адресом с http:// ещё с тех времён, когда сайт работал без сертификата, и переход на https эти ссылки не тронул. Найти проблему быстрее всего через консоль разработчика в браузере (вкладка Console показывает предупреждения вида «Mixed Content: the page was loaded over HTTPS, but requested an insecure resource») или через вкладку Security, где явно перечислены источники нешифрованных ресурсов.

Как исправить смешанный контент на практике

Для сайтов на CMS вроде WordPress или 1С-Битрикс, где контент хранится в базе данных, точечно менять каждую ссылку в коде страниц бессмысленно — правка делается массовым поиском и заменой в базе данных: все вхождения http://example.ru меняются на https://example.ru одним запросом или через специализированный плагин для WordPress. Для ссылок на внешние ресурсы (шрифты, виджеты, CDN сторонних сервисов) правильный вариант — заменить на протокол-независимую ссылку (//fonts.example.com/font.css без указания http или https) либо явно на https, если внешний сервис его поддерживает — почти все современные CDN и шрифтовые сервисы работают по https уже по умолчанию. Отдельно стоит проверить статические файлы шаблона (CSS, JS), где абсолютные http-ссылки на картинки или шрифты иногда зашиты прямо в код темы, а не в базе данных — эти места поиск-замена по базе не находит.

Что обновить в Яндекс.Вебмастере и Google Search Console

С точки зрения поисковых систем смена протокола — это по факту переезд сайта на новый адрес, даже если содержимое не изменилось ни на символ. В Google Search Console https-версия сайта требует отдельного добавления как нового ресурса — старые данные о позициях и трафике с http-версии не переносятся автоматически, а идут отдельным разделом. В Яндекс.Вебмастере похожий принцип: нужно подтвердить права на https-версию домена и через раздел «Переезд сайта» указать, что теперь основной является она — без этого шага Яндекс может ещё долго считать канонической старую http-версию. Обе платформы стоит связать сразу после настройки редиректа, не откладывая: чем раньше поисковик узнает о переезде, тем быстрее переиндексирует сайт по новому протоколу без потери позиций. Подробный процесс проверки индексации сайта — отдельная тема, которая пригодится сразу после смены протокола.

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

Пройти минимальный чек-лист: curl -IL http://example.ru должен показать один 301-редирект сразу на канонический https-адрес, без цепочки из нескольких прыжков; консоль разработчика на всех ключевых страницах (главная, карточка товара, страница с формой) не должна показывать предупреждений о смешанном контенте; заголовок ответа должен содержать Strict-Transport-Security, если HSTS уже включён; а онлайн-чекер конфигурации SSL должен показывать оценку не ниже B — более низкие оценки обычно означают устаревшие протоколы или отсутствие полной цепочки сертификатов. Эти же проверки стоит закладывать в регулярный технический аудит сайта, а не проводить один раз сразу после установки сертификата.

FAQ