Переход на HTTPS: полный чек-лист

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

Подготовка к переходу на HTTPS

Перед началом любой миграции я всегда делаю полный аудит сайта. Честно говоря, многие разработчики пропускают этот этап и потом расхлёбывают последствия неделями. У меня был случай, когда клиент попросил "быстренько перевести на HTTPS" интернет-магазин с 50 000 товаров. Оказалось, что половина изображений загружалась с внешних CDN по HTTP, а в базе данных было зашито около 2000 абсолютных ссылок на старый протокол.

Первым делом проверяю техническую готовность сервера. На nginx 1.18+ и Apache 2.4+ проблем обычно не возникает, но если сервер древний — могут быть сюрпризы с поддержкой современных версий TLS. Особенно это касается старых версий OpenSSL — ниже 1.0.2 лучше не использовать.

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

Далее составляю карту всех поддоменов и сервисов. API, CDN, почтовые сервисы, системы аналитики — всё должно быть учтено. На одном проекте забыли про поддомен с API для мобильного приложения, и после миграции приложение просто перестало работать на неделю.

Выбор и установка SSL-сертификата

Выбор сертификата зависит от типа проекта. Для большинства сайтов вполне достаточно Domain Validation (DV) сертификата — они выдаются быстро и стоят недорого. Extended Validation (EV) нужен только для крупных интернет-магазинов и банков, где важна дополнительная индикация доверия в браузере.

Я обычно использую Let's Encrypt для проектов где нужен быстрый старт, и коммерческие сертификаты от Comodo или GlobalSign для корпоративных клиентов. Let's Encrypt хорош тем, что бесплатный и автоматически обновляется, но некоторые клиенты хотят видеть "настоящий" платный сертификат в админке.

Установка на nginx выглядит примерно так:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    ssl_certificate /path/to/intermediate.crt;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options DENY always;
    add_header X-Content-Type-Options nosniff always;
}

Обратите внимание на заголовки безопасности — они критически важны. HSTS заставляет браузер всегда использовать HTTPS для вашего домена, даже если пользователь введёт HTTP-ссылку. X-Frame-Options защищает от clickjacking атак.

После установки обязательно проверяю конфигурацию через SSL Labs. Оценка должна быть не ниже A, а лучше A+. Если видите C или B — значит где-то ошибка в настройках шифрования.

Настройка редиректов с HTTP на HTTPS

Редиректы — это самая важная часть миграции с точки зрения SEO. Неправильно настроенные редиректы могут убить позиции сайта за несколько дней. Я всегда использую 301 редирект, который передаёт максимальный вес ссылок на новые URL.

Для nginx настройка выглядит так:

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

Для Apache через .htaccess:

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

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

У одного клиента была ситуация: старый сайт работал на поддомене old.example.com, а новый должен был быть на example.com. При этом нужно было сохранить структуру URL. Пришлось писать сложные правила редиректов:

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

server {
    listen 443 ssl;
    server_name old.example.com;
    # SSL конфиг...
    return 301 https://example.com$request_uri;
}

Важный момент — редиректы должны работать для всех URL, включая изображения, CSS, JS файлы. Часто разработчики забывают про статические файлы, и после миграции сайт "разваливается" визуально.

Обновление ссылок в коде и базе данных

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

Для WordPress я использую плагин Better Search Replace или делаю замену напрямую в базе данных:

UPDATE wp_options SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://example.com', 'https://example.com');

Для Битрикс процесс сложнее из-за особенностей структуры базы данных. Нужно обновить не только контент, но и настройки модулей:

UPDATE b_option SET VALUE = REPLACE(VALUE, 'http://example.com', 'https://example.com');
UPDATE b_iblock_element_property SET VALUE = REPLACE(VALUE, 'http://example.com', 'https://example.com') WHERE VALUE LIKE '%http://example.com%';

Но аккуратно с Битриксом — у него много сериализованных данных в базе, и простая замена может их сломать. Лучше использовать специальные методы API или делать замены через административную панель.

Обязательно проверяю все конфигурационные файлы. В .env файлах Laravel, в wp-config.php WordPress, в dbconn.php и других конфигах могут быть зашиты HTTP-ссылки. Особенно это касается настроек API и внешних сервисов.

Ещё один важный момент — обновление путей в JavaScript и CSS файлах. Часто в коде прописаны абсолютные пути к API или ресурсам. Если пропустить их, то после миграции могут возникнуть ошибки mixed content.

Работа с mixed content ошибками

Mixed content — это когда HTTPS страница загружает ресурсы по HTTP. Браузеры блокируют такой контент, что приводит к поломке функциональности сайта. Это одна из самых частых проблем при переходе на HTTPS.

Я всегда проверяю консоль разработчика в браузере после миграции. Chrome показывает все заблокированные ресурсы с подробным описанием. Firefox тоже хорошо диагностирует такие проблемы.

Типичные источники mixed content:

• Изображения с внешних CDN или фотобанков
• Встраиваемые виджеты (карты, соцсети, платёжные системы)
• Внешние JavaScript библиотеки
• Встроенные видео с YouTube или Vimeo
• Шрифты с Google Fonts или других CDN

У меня был проект интернет-магазина, где после перехода на HTTPS перестала работать корзина. Оказалось, что платёжная система возвращала JavaScript по HTTP, и браузер его блокировал. Пришлось обращаться в техподдержку платёжки и ждать обновления их API.

Для исправления mixed content использую несколько подходов:

1. Обновляю ссылки на protocol-relative (начинающиеся с //):

<img src="//example.com/image.jpg" alt="Изображение">
<script src="//ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>

2. Меняю HTTP на HTTPS там где это возможно:

<link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet">

3. Для ресурсов которые недоступны по HTTPS, настраиваю прокси через свой сервер или ищу альтернативы.

Особая головная боль — это старые виджеты и счётчики. Яндекс.Метрика и Google Analytics давно поддерживают HTTPS, но некоторые мелкие сервисы до сих пор работают только по HTTP. Таких либо убираю, либо заменяю на аналоги.

Обновление настроек CMS и плагинов

После технической части нужно обновить настройки самой CMS. В WordPress это базовый URL в настройках, в Битриксе — настройки сайтов и мультисайтов, в Laravel — переменные окружения.

В WordPress меняю настройки через админку или в wp-config.php:

define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');

В Битриксе обновляю настройки через административную панель: "Настройки" → "Настройки продукта" → "Сайты". Там меняю протокол для всех доменов на HTTPS и проверяю настройки мультисайтов если они есть.

Особое внимание уделяю плагинам и модулям безопасности. Многие из них имеют настройки связанные с протоколом. Wordfence в WordPress, веб-антивирус в Битриксе — все могут потребовать обновления конфигурации.

Проверяю настройки кеширования. Если используется Redis или Memcached, нужно очистить весь кеш после миграции. В Битриксе это можно сделать через админку, в WordPress — через плагины кеширования.

Не забываю про настройки почтовых форм и уведомлений. Часто в шаблонах писем прописаны абсолютные ссылки на сайт. После миграции все ссылки в письмах должны вести на HTTPS версию.

Тестирование после миграции

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

Первым делом проверяю основные страницы в разных браузерах. Chrome, Firefox, Safari, Edge — у каждого свои особенности работы с HTTPS. Особенно внимательно смотрю на мобильные браузеры — там часто всплывают неожиданные проблемы.

Проверяю работу всех форм на сайте. Контактные формы, формы подписки, формы заказа — часто после миграции они перестают отправляться из-за изменения URL в настройках почтовых скриптов.

Тестирую интеграции с внешними сервисами. CRM системы, платёжные шлюзы, системы аналитики — все должны получать данные по новому протоколу. Интеграция с CRM особенно чувствительна к смене протокола.

Обязательно проверяю скорость загрузки сайта. HTTPS может немного замедлить работу из-за дополнительного SSL handshake, но современные серверы и HTTP/2 компенсируют эту задержку. Если сайт стал заметно медленнее — нужно оптимизировать настройки SSL.

Использую инструменты для проверки SSL конфигурации:

• SSL Labs Test — для проверки качества SSL настроек
• SecurityHeaders.com — для проверки заголовков безопасности
• Why No Padlock — для поиска mixed content проблем
• Google PageSpeed Insights — для проверки влияния на скорость

На одном проекте после миграции Core Web Vitals ухудшились на 15%. Оказалось, что SSL сертификат был настроен без поддержки HTTP/2, и браузеры загружали ресурсы последовательно вместо параллельной загрузки.

Обновление SEO настроек

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

Первым делом обновляю все sitemap файлы. XML карты сайта должны содержать только HTTPS URL. В WordPress это обычно происходит автоматически через Yoast SEO или RankMath, но лучше проверить вручную.

Обновляю robots.txt файл. Там должна быть ссылка на HTTPS версию sitemap:

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Добавляю новый HTTPS сайт в Google Search Console и Яндекс.Вебмастер. Важно — не удаляю старый HTTP сайт сразу, а держу оба некоторое время. Это позволяет отслеживать переход индексации с одного протокола на другой.

Отправляю новые sitemap в поисковые системы через Search Console. Обычно Google начинает переиндексацию в течение нескольких дней, Яндекс может быть медленнее.

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

Проверяю настройки канонических URL. Если используются rel="canonical" теги, они должны указывать на HTTPS версии страниц. В противном случае поисковики могут получить противоречивые сигналы.

Мониторинг и отслеживание после миграции

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

Настраиваю мониторинг доступности SSL сертификата. Использую сервисы типа UptimeRobot или Pingdom, которые проверяют не только доступность сайта, но и валидность сертификата. Это критически важно — если сертификат истечёт, сайт станет недоступен.

Отслеживаю логи веб-сервера на предмет ошибок SSL. В nginx это access.log и error.log, в Apache — аналогично. Ищу ошибки типа "SSL handshake failed" или "certificate verify failed" — они могут указывать на проблемы с конфигурацией.

Мониторю показатели в Google Analytics и Яндекс.Метрике. Обычно в первые дни после миграции может быть небольшой провал трафика — это нормально. Поисковики переиндексируют сайт, и трафик восстанавливается в течение 1-2 недель.

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

У одного клиента после перехода на HTTPS трафик упал на 30% и не восстанавливался месяц. Оказалось, что редирект с www версии был настроен неправильно, и поисковики индексировали сайт как дубль. Пришлось исправлять настройки и ждать переиндексации ещё месяц.

Особое внимание уделяю скорости загрузки страниц. Если сайт стал медленнее работать, это может негативно повлиять на позиции. Медленная работа сайта — частая проблема после неправильной настройки HTTPS.

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

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

По моему опыту, успешная миграция на HTTPS при правильном выполнении всех шагов даёт положительный эффект уже через 2-3 недели. Улучшается доверие пользователей, повышаются позиции в поиске, снижается количество предупреждений браузеров о небезопасности сайта. Но только при условии, что все этапы выполнены правильно и нет технических ошибок.

Главное правило которого я придерживаюсь — не торопиться и тщательно проверять каждый этап. Лучше потратить дополнительный день на тестирование, чем потом неделю исправлять проблемы на рабочем сайте. HTTPS миграция — это не та задача, где можно действовать по принципу "авось пронесёт".