HTTPS как фактор ранжирования — маленький и давний бонус 2014 года, не более того. Реальная боль в другом: mixed content после переезда на https, незакрытые дубли http/https в индексе и HSTS preload, который невозможно быстро откатить, если понадобится. Разбираю, что проверить, и почему «просто поставить SSL» не равно «сделать переход правильно».
Про HTTPS каждый клиент слышал одно: «это важно для SEO, у меня зелёный замочек есть, значит всё в порядке». Замочек — это необходимое условие, а не достаточное. Ранжирование он двигает слабо. А вот испортить переезд на https можно так, что сайт будет терять трафик месяцами, и никто не поймёт почему.
Что HTTPS даёт в ранжировании на самом деле
Google объявил HTTPS сигналом ранжирования ещё в 2014 году и сразу честно назвал его «лёгким» — lightweight signal. С тех пор формулировка не менялась: эффект на позиции минимален по сравнению с контентом, структурой и ссылками. Если у тебя https есть, а у конкурента нет — это не даст тебе первое место само по себе.
Зато есть эффект, который реально двигает трафик, просто не через ранжирование, а через поведение пользователя. С 2018 Chrome маркирует http-страницы с формами как «Не защищено» прямо в адресной строке. Яндекс.Браузер подхватил похожую логику. Пользователь видит это предупреждение рядом со своим кликом в выдаче и просто не идёт дальше — особенно на коммерческих запросах, где придётся вводить телефон или оплату.
В 2022 переносил сайт услуг с http на https — через две недели CTR по тем же самым позициям в выдаче вырос почти на треть, при этом позиции не сдвинулись ни на пункт. Единственное изменение — зелёный замочек вместо «не защищено» рядом со сниппетом.
Частые ошибки при переходе http → https
Переносить сайт на https «и забыть» — тупо хуёвая идея, если не проверить три вещи ниже. Любая из них режет эффект от переезда почти в ноль.
- Mixed content. Страница отдаётся по https, а картинки, скрипты или шрифты внутри неё грузятся по старым http-ссылкам. Браузер блокирует часть ресурсов или помечает соединение как «частично защищённое» — внешне сайт выглядит рабочим, а по факту что-то не загрузилось или замочек не горит зелёным.
- Дубли в индексе. Обе версии — http и https — остаются доступны и индексируются, если не настроен 301-редирект и canonical. Google видит два одинаковых сайта и сам решает, какую версию показывать. Не всегда угадывает правильно.
- Цепочки редиректов. http → https → www → non-www (или в другом порядке) в три-четыре прыжка вместо одного. Каждый лишний редирект — это задержка и потеря части сигналов. Разбирал механику цепочек подробнее в статье про переезд сайта и 301-редиректы.
- Старые http-ссылки в служебных файлах. robots.txt и sitemap.xml со ссылками на http-версию страниц, которых формально уже не существует.
HSTS — что это и где подстава
Заголовок Strict-Transport-Security говорит браузеру: больше никогда не ходи на этот домен по http, даже если пользователь вручную вбил http:// в адресной строке. Указывается через max-age — сколько секунд браузер должен это запоминать после первого визита.
Preload list — следующий уровень. Chrome, Firefox и Safari включают список доменов прямо в код браузера, и для них https применяется ещё до первого DNS-запроса, без необходимости сначала зайти на сайт и получить заголовок. Звучит как усиленная защита, и это правда. Но это долгосрочное обязательство, а не галочка в панели хостинга.
Полтора года назад подключил HSTS preload клиенту с max-age в два года — на тот момент это казалось правильным шагом для галочки безопасности. Через несколько месяцев понадобилось на сутки поднять старый поддомен без валидного сертификата для теста интеграции с партнёром. Физически не вышло: браузер жёстко редиректил на https, сертификата там не было, страница просто не открывалась ни у кого. Снять домен из preload-списка можно, но это не история «исправил за 10 минут» — заявка на удаление идёт через форму Chromium, а изменение доезжает до браузеров пользователей только со следующим релизом, через недели.
Как проверить, что переход сделан нормально
Пройди по пяти пунктам, не только по «замочек зелёный, значит всё ок»:
- SSL Labs тест (ssllabs.com/ssltest) — рейтинг ниже A означает устаревшие протоколы или слабые шифры. TLS 1.0 и 1.1 давно пора выключать, они всё ещё включены на удивительном количестве сайтов.
- securityheaders.com — быстрая проверка заголовков, включая сам HSTS и его параметры.
- GSC → Индексирование → Страницы — ищи старые http-URL со статусом «Дубликат, Google выбрал другую каноническую страницу». Если таких десятки — переезд не закрыт до конца.
- curl -I https://сайт/ — ручная проверка заголовков без браузера, занимает 10 секунд, но показывает редиректы и Strict-Transport-Security буквально как есть.
- Консоль браузера, вкладка Issues — на 5-10 ключевых страницах сайта, ищи mixed content вручную. Автоматические сканеры его пропускают чаще, чем кажется.
| Что настроено | Что делает | Риск при ошибке |
|---|---|---|
| 301 http → https | Склеивает обе версии в один сигнал для поиска | Без него — дубли в индексе, сигналы ранжирования распределяются между версиями |
| Canonical на https | Явно говорит, какая версия «та самая» | Отсутствие — Google сам решает, не всегда угадывает правильную версию |
| HSTS без preload | Браузер запоминает «ходить только по https» после первого визита | Минимальный, легко откатить уменьшением max-age |
| HSTS с preload | Жёстко вшито в браузер ещё до первого визита на сайт | Откат — недели или месяцы, не включай, пока не уверен на 100% |
| Mixed content | — | Браузер блокирует ресурсы или часть разметки, вёрстка может незаметно сломаться |
Ты вообще проверял свой сайт в SSL Labs хоть раз за последний год, или просто поставил сертификат при запуске и забыл, что это настройка, а не разовое действие?