Переезд на HTTPS: как перейти на SSL без потери позиций

Сегодня сайт без HTTPS воспринимается как анахронизм: браузеры помечают такие страницы как «Не защищено», пользователи опасаются вводить контактные данные, а поисковые системы давно учитывают наличие защищённого соединения при ранжировании. Если ваш ресурс до сих пор работает по протоколу HTTP, переезд на HTTPS — не вопрос «нужно ли», а вопрос «когда и как сделать это правильно». Главная сложность в том, что для поисковых систем версии сайта на http:// и https:// — это два разных ресурса. Ошибка при переезде способна на недели обрушить позиции и трафик, поэтому к процедуре нужно подойти как к полноценному техническому проекту. В этой статье я разберу, зачем нужен HTTPS, какие бывают SSL-сертификаты, и дам пошаговый алгоритм переезда без потери позиций, проверенный на десятках проектов.

Что такое HTTPS и зачем он нужен сайту

HTTPS (HyperText Transfer Protocol Secure) — это тот же протокол передачи данных, что и HTTP, но с дополнительным слоем шифрования по технологии SSL/TLS. Когда пользователь открывает страницу по HTTPS, весь обмен данными между его браузером и сервером шифруется: логины, пароли, номера карт, содержимое форм. Перехватить и прочитать эти данные «по дороге» становится практически невозможно.

Причин для перехода несколько, и каждая из них самостоятельно достаточна:

• Безопасность. Без шифрования любые данные, которые посетитель отправляет через сайт, можно перехватить в открытой Wi-Fi-сети, через скомпрометированный роутер или промежуточный узел. Для интернет-магазинов, сайтов с личными кабинетами и любых форм с персональными данными это критично.
• Доверие пользователей. Современные браузеры (Chrome, Яндекс.Браузер, Safari) показывают на HTTP-страницах с формами явное предупреждение «Не защищено». Человек, увидевший такую плашку, с большой вероятностью закроет вкладку и уйдёт к конкуренту. Замок в адресной строке — это сигнал надёжности, который влияет на конверсию.
• Фактор ранжирования. И Google, и Яндекс официально подтверждали, что наличие HTTPS учитывается алгоритмами. Это не самый весомый фактор, но при прочих равных защищённый сайт получает преимущество. Кроме того, многие современные веб-технологии (HTTP/2, Service Workers, геолокация, push-уведомления) работают только по HTTPS.
• Соответствие требованиям. Если вы принимаете онлайн-оплату, работа с платёжными системами и стандартом PCI DSS без HTTPS попросту невозможна. Работа с персональными данными по 152-ФЗ также подразумевает защиту канала передачи.

Иными словами, HTTPS сегодня — это гигиенический минимум, а не конкурентное преимущество. Его отсутствие воспринимается как недоработка, которая стоит вам доверия, конверсии и части поискового трафика.

Виды SSL-сертификатов: DV, OV, EV и Let's Encrypt

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

По уровню валидации:

• DV (Domain Validation) — проверка домена. Самый простой и распространённый тип. Удостоверяющий центр проверяет только то, что вы владеете доменом (обычно через DNS-запись или файл на сервере). Выдаётся за минуты. Подходит большинству сайтов: блогам, корпоративным сайтам, информационным порталам, небольшим магазинам.
• OV (Organization Validation) — проверка организации. Помимо домена проверяется реальное существование юридического лица. Выдача занимает несколько дней. Уместен для среднего и крупного бизнеса, где важно показать посетителю, что за сайтом стоит реальная компания.
• EV (Extended Validation) — расширенная проверка. Максимальный уровень проверки организации с предоставлением учредительных документов. Раньше давал «зелёную строку» с названием компании в адресной строке, сейчас браузеры от этого визуального выделения отказались. Актуален для банков, крупных платёжных сервисов, маркетплейсов.

По охвату доменов:

• Single-domain — защищает один домен (например, только example.ru).
• Wildcard — защищает домен и все его поддомены первого уровня (example.ru, shop.example.ru, blog.example.ru). Удобно, если у вас много поддоменов.
• Multi-domain (SAN) — один сертификат на несколько разных доменов.

Let's Encrypt заслуживает отдельного упоминания. Это некоммерческий удостоверяющий центр, который выдаёт бесплатные DV-сертификаты. Они полностью полноценны с точки зрения шифрования и доверия браузеров. Единственная особенность — срок действия 90 дней, но практически все хостинги настраивают автоматическое продление, и вы об этом просто не вспоминаете. Для подавляющего большинства проектов малого и среднего бизнеса бесплатного Let's Encrypt более чем достаточно. Платные DV/OV/EV имеет смысл рассматривать, если вам нужна страховка (финансовая гарантия удостоверяющего центра), расширенная проверка организации или сертификат на несколько доменов с определёнными гарантиями SLA.

Практический совет: не переплачивайте. Если вы не банк и не крупный финтех, начните с Let's Encrypt или базового DV от хостинга — для SEO и доверия пользователей этого хватит. Тип сертификата на позиции в поиске напрямую не влияет: важен сам факт защищённого соединения, а не «престижность» сертификата.

Подготовка к переезду: что сделать заранее

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

1. Зафиксируйте текущие позиции и трафик. Выгрузите данные из Яндекс.Вебмастера, Метрики и сервисов съёма позиций. Это ваша точка отсчёта: по ней вы будете понимать, просели ли позиции после переезда и насколько.
2. Сделайте полную карту URL. Соберите все страницы сайта (через краулер вроде Screaming Frog, через sitemap, через выгрузку из CMS). Вам нужно понимать полный список адресов, которые предстоит редиректить.
3. Соберите внешние ссылки. Проверьте, какие площадки ссылаются на ваш сайт. После переезда эти ссылки будут вести на http-версию и проходить через редирект — важно понимать масштаб.
4. Найдите все упоминания http:// в коде. Внутренние ссылки, пути к картинкам, скриптам, стилям, шрифтам — всё это может быть прописано с абсолютными http-адресами и стать источником смешанного контента.
5. Сделайте резервную копию. Полный бэкап сайта и базы данных перед любыми изменениями обязателен. Если что-то пойдёт не так, вы сможете быстро откатиться.
6. Выберите время. Идеально — период минимального трафика (для большинства бизнесов это ночь или выходные). Это снизит влияние возможных кратковременных сбоев на пользователей.

Чем тщательнее подготовка, тем меньше сюрпризов на самом переезде. Переезд на HTTPS технически близок к другим масштабным миграциям, поэтому полезно изучить общие принципы в материале о том, как организовать смену домена без потери трафика — многие подходы (карта редиректов, контроль зеркал, переиндексация) применимы и здесь.

Шаг 1. Установка SSL-сертификата на сервер

Первый практический шаг — установить сертификат. Способ зависит от вашего хостинга:

• Через панель хостинга. Большинство современных хостеров (особенно с панелями ISPmanager, cPanel) позволяют установить Let's Encrypt в пару кликов: вы выбираете домен, нажимаете «Выпустить сертификат», и панель сама настраивает автопродление. Это самый простой путь.
• Вручную через certbot. На VPS/выделенном сервере используют утилиту certbot, которая выпускает и продлевает сертификаты Let's Encrypt и настраивает веб-сервер (nginx, Apache).
• Покупной сертификат. Если вы приобрели платный сертификат, его файлы (сам сертификат, приватный ключ, цепочку) нужно загрузить в панель или прописать в конфигурации веб-сервера.

После установки обязательно проверьте корректность через любой онлайн-сервис проверки SSL (например, SSL Labs). Убедитесь, что сертификат валиден, цепочка сертификатов полная (нет ошибки «incomplete chain»), и поддерживаются современные протоколы TLS 1.2/1.3. На этом этапе сайт уже должен открываться по https://, при этом http-версия пока остаётся доступной — редирект мы настроим следующим шагом. Откройте сайт по защищённому адресу и убедитесь, что замок отображается, а ошибок сертификата нет.

Шаг 2. Настройка 301-редиректа с HTTP на HTTPS

Это ключевой шаг всего переезда. Нужно настроить серверный 301-редирект (постоянное перенаправление) со всех http-адресов на соответствующие https-адреса. Именно 301 (а не 302) передаёт поисковым системам сигнал, что страница переехала навсегда, и сохраняет накопленный вес страницы.

Важнейшее требование: редирект должен быть постраничным, один к одному. Каждая страница http://example.ru/catalog/tovar должна вести на https://example.ru/catalog/tovar, а не на главную. Массовый редирект всего на главную страницу — грубая ошибка, которая уничтожает поисковый трафик внутренних страниц.

Пример настройки для nginx — добавляется отдельный серверный блок, слушающий 80-й порт, который возвращает 301 на https-версию с сохранением URI. Для Apache редирект прописывается в .htaccess через директивы RewriteCond/RewriteRule, проверяющие отсутствие HTTPS и перенаправляющие на https-схему. Если у вас MODX или другая CMS на Apache, чаще всего работают именно через .htaccess.

На что обратить внимание при настройке редиректа:

• Без цепочек. Редирект должен быть прямым: http → https за один переход. Цепочки вида http → http со слешем → https → https с www — это потеря веса и скорости. О том, как правильно склеивать версии сайта, я подробно рассказывал в гайде про 301-редирект и склейку зеркал.
• Учитывайте www и без www. Если у сайта есть варианты с www и без, все четыре комбинации (http+www, http без www, https+www, https без www) должны в итоге вести на одно главное зеркало одним прямым редиректом.
• Все поддомены. Не забудьте про поддомены: блог, магазин, мобильную версию — каждый из них нужно отдельно перевести на HTTPS и настроить редиректы.
• Проверьте код ответа. После настройки проверьте через инструмент проверки ответа сервера (есть в Яндекс.Вебмастере), что http-страница отдаёт именно 301, а не 302 и не цепочку.

Шаг 3. Обновление внутренних ссылок и canonical

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

Что нужно обновить:

• Внутренние ссылки в контенте и меню. Через поиск по базе данных или файлам найдите все вхождения http://ваш-домен и замените на https:// (или на протоколо-относительный/относительный путь).
• Атрибут canonical. Это критично. Тег rel="canonical" на каждой странице должен указывать на https-версию. Если canonical остался с http://, поисковик будет получать противоречивый сигнал: редирект ведёт на https, а канонический адрес — http. Это одна из самых частых и болезненных ошибок.
• Open Graph и микроразметка. URL в og:url, в Schema.org разметке тоже должны быть обновлены на https.
• Hreflang (если есть). Альтернативные языковые версии должны ссылаться на https-адреса.
• Пути к статике. Картинки, CSS, JS, шрифты — об этом подробнее в разделе про смешанный контент, но проверить их пути нужно именно сейчас.

Лучшая практика — настроить CMS так, чтобы все абсолютные URL формировались с протоколом https. В MODX, например, это решается через системные настройки базового URL сайта и переопределение схемы. Аккуратная работа со ссылочной структурой — часть общей внутренней оптимизации, и переезд на HTTPS — хороший повод заодно навести порядок в перелинковке.

Шаг 4. Правка sitemap.xml и robots.txt

Файлы, которые управляют индексацией, тоже нужно привести в порядок, иначе вы будете подавать поисковику смешанные сигналы.

sitemap.xml:

• Все URL внутри карты сайта должны быть указаны через https://. Если sitemap генерируется автоматически — перегенерируйте его после смены базового URL. Если вручную — обновите адреса.
• Сама карта должна быть доступна по https-адресу.
• Старый sitemap с http-адресами уберите, чтобы не было дублирующих сигналов.

robots.txt:

• Директива Sitemap должна указывать на https-версию карты: Sitemap: https://example.ru/sitemap.xml.
• Директива Host (если вы её используете для Яндекса) должна содержать https-адрес главного зеркала. Хотя в последние годы Яндекс ориентируется в первую очередь на 301-редиректы для определения главного зеркала, корректный Host лишним не будет.
• Убедитесь, что robots.txt сам открывается по https и не закрывает случайно нужные разделы от индексации.

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

Шаг 5. Смешанный контент (mixed content): поиск и устранение

Смешанный контент — это ситуация, когда страница загружается по HTTPS, но внутри неё подгружаются ресурсы по HTTP: картинки, скрипты, стили, шрифты, видео, iframe. Браузер воспринимает это как угрозу: канал больше не считается полностью защищённым. В результате вы видите либо замок с предупреждением, либо вовсе заблокированные ресурсы (часто блокируются именно скрипты и стили, из-за чего «ломается» вёрстка и функциональность).

Различают два вида:

• Пассивный смешанный контент — картинки, видео, аудио, загруженные по http. Браузер обычно подгружает их, но помечает соединение как небезопасное (замок пропадает или становится с предупреждением).
• Активный смешанный контент — скрипты, стили, iframe, AJAX-запросы по http. Браузер чаще всего блокирует их полностью, что может сломать работу сайта.

Как искать смешанный контент:

1. Консоль браузера. Откройте страницу, нажмите F12, перейдите на вкладку Console — браузер выводит предупреждения «Mixed Content» с указанием конкретных ресурсов.
2. Краулер. Screaming Frog и аналоги умеют находить http-ресурсы на https-страницах массово, по всему сайту.
3. Онлайн-сервисы. Специальные сканеры смешанного контента проверяют сайт целиком и выдают список проблемных URL.

Как чинить:

• Перепишите пути ресурсов на https или сделайте их относительными (без указания протокола). Это касается изображений в контенте, фоновых картинок в CSS, подключаемых скриптов и стилей.
• Проверьте сторонние подключения. Виджеты, счётчики, карты, чаты, рекламные коды — убедитесь, что все они поддерживают https. Старые скрипты, доступные только по http, придётся заменить.
• Загружаемые пользователями файлы. Если в базе данных сохранены http-ссылки на загруженные ранее картинки, их нужно массово заменить SQL-запросом.
• Заголовок CSP. Для надёжности можно настроить Content-Security-Policy с директивой upgrade-insecure-requests, которая заставляет браузер автоматически подтягивать ресурсы по https.

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

Шаг 6. Настройка в Яндекс.Вебмастере и Google Search Console

Для российских проектов работа с Яндексом — приоритет. Вот что нужно сделать после технического переезда.

В Яндекс.Вебмастере:

• Добавьте https-версию как отдельный сайт. В Вебмастере http:// и https:// — разные ресурсы. Добавьте новую (https) версию и подтвердите права.
• Укажите главное зеркало. В разделе «Переезд сайта» / настройках индексирования укажите, что главное зеркало теперь https-версия. Яндекс склеит версии на основе вашего 301-редиректа и этой настройки. Процесс склейки занимает время — обычно от нескольких дней до пары недель.
• Загрузите новый sitemap с https-адресами в https-версию сайта.
• Следите за разделом «Диагностика» — там появятся уведомления о проблемах, если что-то настроено некорректно.

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

В Google Search Console:

• Добавьте и подтвердите https-версию (либо используйте подтверждение на уровне домена через DNS, которое покрывает все варианты сразу).
• Загрузите обновлённый sitemap.
• Запросите переобход ключевых страниц через инструмент проверки URL.

В Яндекс.Метрике: убедитесь, что счётчик подключён по https и в настройках указан корректный адрес сайта. Проверьте, что данные продолжают собираться без разрывов. Если счётчик подключался по http и используется протоколо-зависимый код, обновите его. Аналогично проверьте Google Analytics и любые другие системы аналитики, цели и электронную коммерцию.

Шаг 7. Переиндексация и контроль склейки

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

Что делать на этом этапе:

• Ускорьте переобход. В Яндекс.Вебмастере есть инструмент «Переобход страниц» — добавьте туда главные и наиболее важные URL. В Google — «Проверка URL» с запросом индексирования.
• Контролируйте склейку зеркал. Следите, как http-страницы постепенно выпадают из индекса, а https-страницы — появляются. Это нормальный процесс, который занимает недели.
• Проверяйте позиции. Сравнивайте с зафиксированными до переезда значениями. Небольшие колебания в первые недели — норма.
• Не трогайте редиректы. Старые http-страницы с 301-редиректом нельзя удалять или отключать минимум несколько месяцев (а лучше — навсегда оставить редирект). Если убрать его слишком рано, накопленный вес потеряется.

Если после переезда вы видите аномальное падение и страницы массово выпадают из поиска, разберитесь с причинами по чек-листу из статьи о том, почему сайт выпал из индекса — часто корень в неверном редиректе, ошибке в canonical или случайном запрете индексации.

Почему позиции могут просесть и как это минимизировать

Честно скажу владельцам бизнеса: при любом переезде, в том числе на HTTPS, возможна временная просадка позиций и трафика. Обычно она длится от 2 до 4 недель, пока поисковики переиндексируют сайт и склеят зеркала. Это связано с тем, что для алгоритмов это смена адресов всех страниц, и им требуется время на пересчёт.

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

Как минимизировать просадку:

• Делайте всё за один заход. Не растягивайте переезд: установка сертификата, редиректы, обновление ссылок, sitemap, настройка в вебмастерах — желательно в рамках одного дня. Сайт в «полупереехавшем» состоянии — источник противоречивых сигналов.
• Не совмещайте с другими изменениями. Не меняйте одновременно структуру URL, дизайн, контент. Если поменять всё сразу и позиции просядут, вы не поймёте, что именно стало причиной. Переезд на HTTPS должен быть изолированной операцией.
• Обеспечьте чистые прямые редиректы без цепочек — это ускоряет передачу веса.
• Ускоряйте переобход через инструменты вебмастеров.
• Следите за скоростью загрузки. HTTPS добавляет небольшие накладные расходы на установление соединения. Включите HTTP/2 и, по возможности, HSTS — это компенсирует и даже ускорит загрузку.

Если вы планируете переезд на HTTPS одновременно с редизайном — будьте особенно осторожны. Логику сохранения позиций при смене внешнего вида сайта я разбирал в материале про SEO при редизайне сайта: совмещать масштабные изменения можно, но только с детальным контролем каждого фактора.

Частые ошибки при переезде на HTTPS

За годы практики я видел один и тот же набор ошибок, который сводит на нет аккуратную в остальном работу. Проверьте себя по этому списку.

• Редирект-цепочки. http → https → https с www → финальный URL. Каждое лишнее звено теряет вес и замедляет загрузку. Редирект должен быть прямым: один переход к финальному адресу.
• Редирект 302 вместо 301. Временное перенаправление не передаёт вес и не сигнализирует поисковику о постоянном переезде. Только 301.
• Массовый редирект на главную. Когда все http-страницы перенаправляются на https-главную, внутренние страницы теряют трафик полностью. Редирект всегда постраничный.
• Забытый canonical. Тег canonical, оставшийся с http-адресом, противоречит редиректу и путает поисковик. Обновляйте обязательно.
• Не все поддомены. Перевели основной домен, а блог или магазин на поддомене оставили на http. Получаете смешанную картину и предупреждения о незащищённости на части ресурса.
• Забытые картинки и скрипты. Самый частый источник смешанного контента. Абсолютные http-пути к изображениям, стилям, счётчикам остаются в коде или базе и ломают «зелёный замок».
• Старый sitemap с http-адресами. Карта сайта со старыми адресами подаёт поисковику противоречивый сигнал и замедляет переиндексацию.
• Удаление редиректа слишком рано. Отключение 301 через неделю-другую обрывает передачу веса. Редирект должен жить долго.
• Не указано главное зеркало в Яндексе. Без явного указания склейка может затянуться или пойти не в ту сторону.
• Внешние ссылки не учтены. Если на вас ссылаются по http, эти ссылки будут проходить через редирект — это нормально, но крупные площадки желательно попросить обновить ссылки на https напрямую.

Чек-лист переезда на HTTPS

Сведём всё в практический чек-лист, по которому удобно сверяться на каждом этапе. Распечатайте или сохраните его перед началом работ.

Подготовка:

• Зафиксированы текущие позиции и трафик.
• Собрана полная карта URL сайта.
• Сделан полный бэкап сайта и базы данных.
• Выбрано время с минимальным трафиком.

Технические работы:

• SSL-сертификат установлен и проверен (валиден, полная цепочка, TLS 1.2/1.3).
• Настроен постраничный 301-редирект http → https без цепочек.
• Учтены все комбинации www / без www и все поддомены.
• Все внутренние ссылки обновлены на https.
• Тег canonical на всех страницах указывает на https.
• Обновлены og:url, микроразметка, hreflang.
• Найден и устранён весь смешанный контент (картинки, скрипты, стили, виджеты).
• sitemap.xml содержит только https-адреса и доступен по https.
• В robots.txt обновлены директивы Sitemap и Host.
• Включён HTTP/2, по возможности настроен HSTS.

Поисковые системы и аналитика:

• Https-версия добавлена и подтверждена в Яндекс.Вебмастере.
• Указано главное зеркало (https) в Яндексе.
• Https-версия добавлена и подтверждена в Google Search Console.
• Новый sitemap загружен в обе панели.
• Запрошен переобход ключевых страниц.
• Яндекс.Метрика и Google Analytics работают по https, данные собираются.

Контроль после переезда:

• Проверены коды ответа сервера (301, не 302, без цепочек).
• Отслеживается склейка зеркал и переиндексация.
• Мониторятся позиции в сравнении с точкой отсчёта.
• Редиректы оставлены работать на длительный срок.

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

Поддержка после переезда

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

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

Вывод

Переезд на HTTPS — обязательная процедура для любого современного сайта: она повышает безопасность, доверие пользователей и работает как фактор ранжирования. Технически переезд несложен, но требует аккуратности на каждом шаге: установка сертификата, постраничный 301-редирект без цепочек, обновление внутренних ссылок и canonical, правка sitemap и robots, устранение смешанного контента, настройка главного зеркала в Яндекс.Вебмастере и переиндексация. Цена ошибки высока: неверный редирект, забытый canonical или незамеченный смешанный контент способны на недели обрушить позиции — и хорошо, если только на недели.

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