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

Первое и главное — доверие в момент заявки. Браузеры давно перестали быть нейтральными: адрес без https подписывается как незащищённый, а при фокусе на поле с телефоном или почтой в некоторых браузерах всплывает отдельное предупреждение. Человек, который до этого спокойно читал про услугу, в этот момент останавливается. Особенно чувствительны ниши, где форма собирает что-то личное: юридические услуги, медицина, бухгалтерия, любые личные кабинеты.

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

Сертификаты различаются не силой шифрования, а глубиной проверки владельца. DV (Domain Validation) подтверждает только права на домен, выпускается автоматически за минуты и шифрует данные ровно так же, как дорогие варианты. Для сайта услуг, лендинга, корпоративного сайта и небольшого магазина этого достаточно. Бесплатный вариант такого класса — Let’s Encrypt: он выдаётся на 90 дней, поэтому автопродление настраивается сразу при установке, иначе через три месяца сайт встретит посетителей ошибкой безопасности.

OV (Organization Validation) требует подтверждения существования компании документами — его берут, когда важно показать проверенное юрлицо. EV — расширенная проверка, вариант для крупных сервисов с собственной оплатой. Wildcard имеет смысл, если у вас есть поддомены: один сертификат закрывает и основной домен, и все дочерние адреса.

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

Это ключевая ошибка переезда. Сертификат установили, https заработал, а старые адреса продолжают открываться. Для поисковой системы http-версия и https-версия — два разных сайта с полностью одинаковым содержимым. Она вынуждена выбирать, какой из них показывать, и делает это по собственным сигналам, зачастую оставляя в выдаче старые адреса. Внешние ссылки и накопленная история при этом размазываются между двумя зеркалами.

Лечится это постоянным 301-редиректом: каждый http-адрес должен вести на свой https-аналог, страница в страницу. Не общий редирект на главную — иначе десятки продвигаемых страниц схлопнутся в одну, и вы гарантированно потеряете позиции по всем внутренним запросам. И не 302: временный редирект говорит поиску, что старый адрес ещё вернётся, и склейка не происходит.

Проверить результат просто. Откройте несколько внутренних адресов вручную, набрав их с http, — вы должны оказаться ровно на тех же страницах с https. Заодно проверьте пару адресов с www и без — вариантов зеркал должно остаться ровно одно.

Ситуация, которая ставит в тупик чаще всего: сертификат установлен, страница открывается по https, но браузер всё равно не показывает замок или показывает его перечёркнутым. Причина — смешанный контент: сама страница отдана по защищённому протоколу, а часть её содержимого подгружается по старому http. Достаточно одной картинки, одного файла стилей или одного подключённого скрипта.

Чаще всего остатки http прячутся в четырёх местах: абсолютные пути к изображениям, записанные прямо в текстах статей и карточек товаров; подключения шрифтов и библиотек в шаблоне; настройки самой CMS, где прописан базовый адрес сайта; коды сторонних сервисов, добавленные когда-то вручную. Разбирать это надо до включения редиректов — иначе браузер начнёт блокировать часть ресурсов, и сайт может визуально развалиться в самый неподходящий момент.

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

Переезд не заканчивается на сервере. В Яндекс.Вебмастере https-версию нужно добавить как отдельный сайт, подтвердить права и указать смену главного зеркала — до этого момента панель продолжит показывать статистику по старому адресу, а робот будет обходить старые страницы. В Google Search Console добавляется новый ресурс и загружается обновлённая карта сайта. Sitemap.xml и robots.txt правятся обязательно: карта должна содержать только новые адреса, а в robots.txt должна стоять ссылка на неё же.

Дальше — всё, что ссылается на сайт снаружи. Адрес в счётчике Яндекс.Метрики, ссылки в объявлениях и быстрых ссылках Яндекс.Директа, карточка организации в Яндекс Бизнесе, профили на отраслевых площадках, подписи в почте, QR-коды в офлайн-материалах. Реклама здесь приоритетна: объявление, ведущее на старый адрес, отработает через редирект, но лишний переход — это лишняя задержка на мобильном, а иногда и потеря utm-меток при неаккуратной настройке.

Последний шаг — переобход. Ключевые коммерческие страницы отправляются в Вебмастере на принудительную переиндексацию, чтобы поиск быстрее увидел новые адреса. Дальше остаётся наблюдать отчёты — что именно смотреть, разбираем в материале про ежемесячную проверку Яндекс.Вебмастера.

Небольшие колебания в первые недели после смены протокола — ожидаемая часть процесса: поисковые системы переиндексируют адреса не одномоментно, и по части запросов страница временно показывается хуже. Паниковать на этом этапе не нужно, а вот проверить пять вещей стоит сразу. Отдают ли http-адреса код 301 и ведут ли они постранично. Указано ли новое главное зеркало в Вебмастере. Нет ли на страницах смешанного контента. Не остались ли в карте сайта старые адреса. Не поменялись ли попутно сами URL страниц — иногда при переезде заодно правят структуру, и тогда причина просадки вообще не в протоколе.

Чего делать точно не стоит — откатываться обратно на http. Вторая смена протокола за короткий срок означает второй переезд для поиска и удваивает период неопределённости. Так же вредно менять структуру сайта, шаблоны и тексты в те же недели: если что-то поедет, вы не поймёте, что именно стало причиной. Переезд на HTTPS должен быть единственным изменением в этом окне.

Отдельный сигнал тревоги — если через месяц в выдаче всё ещё встречаются http-адреса. Это значит, что склейка не произошла, и надо возвращаться к первому пункту: почти всегда виноват редирект — он либо не постранично, либо отдаёт 302, либо не срабатывает на части разделов.

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

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

Четвёртая ситуация — сайт, который уже переезжал и делал это наполовину. Такое встречается регулярно: сертификат когда-то поставили, редиректы настроили частично, а в базе остались тысячи внутренних ссылок со старым протоколом. Внешне всё в порядке, но поиск годами держит в индексе смесь адресов. Здесь работа начинается не с сертификата, а с ревизии: какие адреса реально отдаются, что показано в отчёте страниц в поиске и в каком состоянии карта сайта.