SSL и HTTPS для SEO: настройка, миграция, проверка

Сайт на HTTPS — это не просто замок в адресной строке. HTTPS для сайта — базовое требование современного веба: Google учитывает его в ранжировании с августа 2014 года, HTTP/2 физически работает только поверх TLS, Chrome помечает HTTP-страницы как «небезопасные». Отсутствие SSL-сертификата в 2026 году — это красный флаг для пользователя и минус в сумме ранжирующих сигналов.

В гайде разбираем, как работает SSL/TLS, какие бывают сертификаты (DV, OV, EV, Wildcard, SAN), где бесплатно получить сертификат через Let's Encrypt, как настроить 301-редирект и починить mixed content, когда нужен HSTS и как его правильно включить. В конце — чек-лист миграции на 10 пунктов и FAQ по типичным проблемам.

Почему HTTPS важен для SEO

HTTPS — фактор ранжирования Google с августа 2014 года, когда компания официально объявила о включении протокола в алгоритм. Вес фактора небольшой: слабый контент на HTTPS не обойдёт сильный на HTTP. Но при прочих равных — HTTPS-страница получает преимущество, и с каждым годом это преимущество только растёт: Chrome уже помечает HTTP как «небезопасный», Firefox предупреждает при вводе пароля, браузеры постепенно отказывают HTTP-страницам в новых возможностях.

Технические причины — не менее важные, чем ранжирование. Core Web Vitals измеряются только по HTTPS: метрики LCP и INP Chrome не соберёт с HTTP-страницы. Протокол HTTP/2, который даёт ощутимый прирост скорости за счёт мультиплексирования, работает только поверх TLS. Service Workers, Web Push, геолокация и ещё десяток современных API доступны только HTTPS-сайтам.

Доверие пользователя — третий фактор. Форма оплаты или логина без замка в адресной строке заставляет задуматься даже технически неграмотного пользователя. Отказ от HTTPS в 2026 году — это сознательное ограничение сайта, не связанное с SEO напрямую, но влияющее на поведенческие сигналы.

Как работает SSL/TLS

SSL (Secure Sockets Layer) — устаревшее название протокола, актуальная версия называется TLS (Transport Layer Security). В индустрии термины используются как синонимы, и «SSL-сертификат» обычно означает именно TLS.

Когда пользователь открывает https://example.com, браузер и сервер выполняют TLS-handshake — серию обменов для согласования шифрования и проверки подлинности. Сервер передаёт сертификат, в котором указано: имя домена, срок действия, удостоверяющий центр (Certificate Authority, CA), открытый ключ. Браузер проверяет подпись центра по цепочке до корневого сертификата, который уже встроен в операционную систему.

Цепочка сертификатов — источник большинства проблем. Сервер должен отдавать не только свой сертификат, но и промежуточные сертификаты CA до корневого. Если промежуточный пропущен, часть клиентов (особенно мобильные и старые Android) не смогут проверить подпись — сайт откроется с предупреждением. Валидатор SSL Labs подсвечивает эту ошибку первой.

Типы SSL-сертификатов

Пять типов сертификатов, которые встречаются в реальной работе.

DV — самый распространённый тип. Для 95% сайтов его достаточно: браузер показывает замок, данные шифруются, поисковики довольны. Разница с OV/EV — только в том, что в сертификате указано юридическое лицо владельца. Визуальное преимущество EV (зелёная строка с названием компании) Google и крупные браузеры убрали в 2019 году — теперь DV, OV и EV выглядят для пользователя одинаково.

Wildcard покрывает все поддомены одного домена: blog.example.com, shop.example.com, api.example.com — один сертификат. Удобно при частом создании поддоменов. SAN — явный список доменов, подходит для группы из 2–5 сайтов одного владельца.

Где получить сертификат

Три варианта — в порядке частоты использования.

Let's Encrypt (бесплатно)

Некоммерческий центр сертификации, выпускающий DV-сертификаты автоматически. Используется на миллионах сайтов, признан всеми браузерами. Установка — одной командой через утилиту certbot:

certbot --nginx -d example.com -d www.example.com

certbot сам обратится к Let's Encrypt, пройдёт HTTP-01 challenge (подтверждение контроля над доменом), выпустит сертификат, пропишет пути в конфиг Nginx и перезагрузит веб-сервер. Для Apache — аналогично с флагом --apache. Срок действия сертификата — 90 дней, обновление — автоматическое (см. раздел про миграцию).

Платные CA

DigiCert, Sectigo, GlobalSign, GeoTrust — центры, выпускающие платные DV, OV и EV. Для DV разницы с Let's Encrypt практически нет: оплата даёт гарантии и техподдержку, шифрование при этом то же. OV и EV — когда нужно юридическое подтверждение организации (банки, госсектор, крупный e-commerce).

Self-signed (только для разработки)

Самоподписанный сертификат, выпускается локально через OpenSSL за 30 секунд. Используется только в dev-окружении: браузер покажет страницу с предупреждением «не доверенный сертификат», и обойти её пользователь не станет. На продакшне — недопустимо.

Миграция с HTTP на HTTPS: 8 шагов

Сценарий: сайт работает на http://example.com, нужно перевести на https://example.com без потери позиций. Ниже — сводный чек-лист, за ним — подробный разбор каждого шага.

Разбор шагов

1. Выпустите сертификат. Let's Encrypt через certbot — для 95% сайтов; платный OV/EV — если нужны юридические гарантии.

2. Установите сертификат на сервере. Пример конфига Nginx:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # ... остальные директивы
}

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

Для Apache редирект настраивается в .htaccess:

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

3. Настройте 301-редирект HTTP → HTTPS. Только код 301 (постоянный), не 302. Без промежуточных цепочек — http://example.com/page сразу на https://example.com/page. Подробности — в статье «301 или 302 редирект: когда какой использовать».

4. Обновите внутренние ссылки и ресурсы. Пройдите по шаблонам, CSS, JS, контенту БД: замените все http://example.com/... на https://example.com/.... Относительные ссылки (/page) не трогаются — они уже работают. Внешние ресурсы (CDN, шрифты Google) — тоже на HTTPS.

5. Обновите canonical, sitemap.xml, robots.txt. Все абсолютные URL — с https://. Sitemap: в robots.txt — с HTTPS. В sitemap.xml все <loc> — с HTTPS. Canonical в HTML — с HTTPS. Подробности по sitemap — в гайде.

6. Уведомите Google Search Console и Яндекс.Вебмастер. HTTPS — отдельный ресурс в GSC, добавьте его как новый. Загрузите новый sitemap.xml. В Я.Вебмастере — подтвердите HTTPS-версию и укажите её как главное зеркало.

7. Настройте HSTS. После подтверждения, что HTTPS работает стабильно хотя бы неделю — добавьте заголовок Strict-Transport-Security (см. раздел ниже).

8. Настройте автопродление сертификата. Для Let's Encrypt — cron-задача, проверяющая срок действия раз в 12 часов:

0 */12 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

Без этого шага через 90 дней сертификат истечёт, и сайт станет недоступен. После миграции обязательно проверьте 301-редиректы и цепочки — типичная ошибка, когда http://www.example.com редиректится сначала на https://www.example.com, а потом на https://example.com (цепочка из двух шагов вместо одного прямого).

Mixed content: находим и чиним

Mixed content — страница загружается по HTTPS, но подгружает ресурсы (картинки, скрипты, стили, iframe) по HTTP. Браузер делит такие ресурсы на два типа:

• Active mixed content — JS, CSS, iframe, XHR. Браузер блокирует их, сайт ломается визуально и функционально.
• Passive mixed content — изображения, видео, аудио. Браузер загружает, но показывает предупреждение: замок становится жёлтым или серым.

Главная причина mixed content после миграции — захардкоженные абсолютные HTTP-URL в контенте. Статья в блоге, написанная 3 года назад, содержит <img src="http://example.com/old-image.jpg"> — после миграции этот URL становится проблемой.

Решения — от простого к сложному. Первое: массовая замена в БД через SQL — UPDATE posts SET content = REPLACE(content, 'http://example.com', 'https://example.com'). Второе: относительные URL без протокола (//example.com/image.jpg) — браузер подставит текущий протокол страницы. Третье: HTTP-заголовок Content-Security-Policy: upgrade-insecure-requests — браузер автоматически заменяет HTTP на HTTPS для всех ресурсов страницы. Это не отменяет починку в исходниках, но закрывает проблему быстро.

Найти все страницы с mixed content вручную невозможно — для этого нужен краулер, обходящий сайт и разбирающий ресурсы каждой страницы.

HSTS и preload list

HSTS (HTTP Strict Transport Security) — HTTP-заголовок, который говорит браузеру: «с этого домена ходи только по HTTPS, даже если пользователь набрал http:// или кликнул на старую ссылку». Заголовок отправляется в ответе HTTPS-страницы:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

max-age=63072000 — срок в секундах (2 года). includeSubDomains — правило распространяется на все поддомены. preload — флаг для включения в preload-список.

Preload list — список доменов, встроенных в Chrome, Firefox, Safari и Edge. Домены из списка браузер считает HSTS-защищёнными с первой секунды, даже до первого визита пользователя. Полная защита от downgrade-атак, но у этой защиты есть обратная сторона: удалить домен из preload-списка сложно, процедура занимает недели или месяцы. Включать только после полной уверенности, что все поддомены работают по HTTPS, сертификаты стабильны, и возврат на HTTP не планируется.

Правильный порядок включения HSTS: сначала max-age=300 (5 минут) на неделю для проверки, затем max-age=31536000 (год), и только потом — preload и подача в список.

Как проверить SSL

Три инструмента, покрывающих 90% задач.

Первый — SSL Labs. Канонический тест: цепочка сертификатов, протоколы (TLS 1.2, 1.3), шифры, уязвимости (POODLE, BEAST, Heartbleed), HSTS. Выставляет оценку от A+ до F — для продакшена нужен минимум A. Работает бесплатно, одна проверка занимает 1–2 минуты.

Второй — curl в консоли, для быстрой проверки цепочки:

curl -vI https://example.com 2>&1 | grep -iE 'subject|issuer|expire|SSL'

Покажет срок действия, издателя, имя домена в сертификате. Полезно, когда нужен быстрый ответ без веб-интерфейса.

Третий — проверка SSL в SEO Crawler. Работает по всему сайту: обходит страницы, проверяет срок действия сертификата, цепочку, наличие HSTS и mixed content. Полезен после миграции — показывает, на каких страницах остались HTTP-ресурсы.

Рекомендация по настройке Let's Encrypt — в официальной документации проекта.

Часто задаваемые вопросы