SSL-сертификат и SEO: как HTTPS влияет на ранжирование

HTTPS как фактор ранжирования: что известно точно

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

Связка «SSL и SEO» работает через четыре механизма:

• Браузерное предупреждение. Chrome с 2018 года помечает все страницы по HTTP как «Не защищено». Пользователь видит это до того, как прочитает заголовок, и уходит. Рост отказов и падение CTR в выдаче поисковик считывает как ухудшение качества страницы.
• Смешанный контент. Если часть ресурсов на HTTPS-странице грузится по HTTP, браузер их блокирует. Страница визуально ломается, а поисковый робот видит не тот документ, который индексировал раньше.
• Скорость. HTTP/2 и HTTP/3 на практике работают только поверх TLS. То есть без HTTPS вы остаётесь на HTTP/1.1 с ограничением параллельных соединений и без сжатия заголовков. Это уже прямой технический сигнал по Core Web Vitals.
• Дубли и каннибализация. http://example.com, https://example.com, https://www.example.com — для поисковика три разных адреса. Без корректного 301-редиректа и canonical вес размазывается между копиями, и ни одна из них не выходит в топ.

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

Что именно проверяет робот поисковой системы

Поисковый робот не «понимает» сертификат как пользователь — он фиксирует факты:

1. Отвечает ли URL по HTTPS с валидным сертификатом, доверенным цепочкой удостоверяющих центров.
2. Совпадает ли имя в сертификате (CN или SAN) с запрошенным хостом. Сертификат на example.com без www в SAN не подойдёт для www.example.com.
3. Не истёк ли срок действия на момент обхода.
4. Есть ли 301-редирект с HTTP-версии на HTTPS-версию, и работает ли он за один шаг.
5. Нет ли смешанного контента в отрендеренном DOM.
6. Какой адрес указан в canonical, sitemap.xml, hreflang — https-версия или http.

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

Смешанный контент: причина, по которой HTTPS «не до конца»

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

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

• Активный — скрипты, iframe, CSS, шрифты, XHR-запросы. Блокируется браузером безусловно ещё с 2019 года. Следствие: пропадает аналитика, ломается вёрстка, не работают формы.
• Пассивный — изображения, аудио, видео. Браузер пытается автоматически апгрейдить URL до HTTPS, а если ресурс по HTTPS недоступен — блокирует его.

Сообщение в консоли выглядит так:

Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script 'http://example.com/js/app.js'. This request has been blocked.

Здесь важно всё: адрес страницы (она по HTTPS), адрес ресурса (он по HTTP) и вердикт — has been blocked. Именно последняя часть объясняет, почему «картинки пропали, а в коде всё есть».

Как найти смешанный контент без браузера

Самый быстрый способ — выгрузить HTML и поискать в нём абсолютные http-ссылки:

curl -sSL https://example.com/ \
  | grep -oE 'http://[^"'"'"' )]+' \
  | sort | uniq -c | sort -rn | head -20

Построчно:

• curl -sSL — тихий режим, вывод в stdout, -L следует редиректам, чтобы анализировать финальную страницу, а не промежуточный ответ.
• grep -oE 'http://[^"'"'"' )]+' — извлекает только совпадения (-o) по расширенному регулярному выражению (-E): URL, начинающийся с http://, до первой кавычки, пробела или скобки.
• sort | uniq -c — группирует одинаковые находки и считает повторы.
• sort -rn | head -20 — показывает самые частые ресурсы сверху.

Если вывод пуст — смешанного контента в сыром HTML нет. Если строки есть, вы получите точный список ресурсов с частотой: например, 12 http://fonts.googleapis.com/... означает, что шрифт подключён по HTTP на двенадцати местах шаблона.

Дальше два варианта решения:

1. Заменить http:// на https:// в шаблоне — работает, если ресурс отдаётся по HTTPS.
2. Использовать протокол-относительные URL (//example.com/img.png) или относительные пути — тогда схема наследуется от страницы.
3. Добавить заголовок Content-Security-Policy: upgrade-insecure-requests — он заставляет браузер сам апгрейдить все HTTP-запросы страницы. Это костыль, но полезный как временная мера на большом legacy-сайте.

Проверить, отдаётся ли сам ресурс по HTTPS, можно обычным запросом:

curl -sSI https://fonts.googleapis.com/css?family=Roboto | head -n 3

Первая строка HTTP/2 200 означает, что ресурс доступен по HTTPS и можно смело менять протокол в шаблоне. HTTP/1.1 404 или ошибка соединения — ресурс по HTTPS недоступен, его нужно либо зеркалировать, либо заменить.

Как проверить сертификат и цепочку вручную

Разовая проверка через браузер показывает только «замок есть» или «замка нет». Для аудита нужен openssl.

Даты, имена и издатель

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Разбор:

• -connect example.com:443 — адрес и порт для TLS-соединения.
• -servername example.com — включает SNI. Без него виртуальные хосты отдадут дефолтный сертификат, и вы получите ложную картину.
• </dev/null — сразу закрывает stdin, иначе команда будет ждать ввода.
• 2>/dev/null — прячет диагностику TLS-хендшейка, оставляя только сертификат.
• openssl x509 -noout ... — парсит X.509 и печатает нужные поля без самого тела сертификата.

Что смотреть в выводе:

subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Apr  1 12:00:00 2026 GMT
notAfter=Jun 30 11:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

• subject — основное имя. Если тут CN = example.com, а сайт открывается как www.example.com, спасает только запись в SAN.
• issuer — кто выдал. Let's Encrypt в порядке, неизвестный издатель означает, что мобильные браузеры могут не иметь его корневого сертификата.
• notAfter — дата окончания. Если до неё меньше 21 дня, автоматическое продление уже должно было сработать.
• subjectAltName — полный список доменов, покрытых сертификатом. Проверьте, что в нём есть и apex-домен, и www, если оба должны работать.

Если дата истечения уже прошла или близка, действуйте по чек-листу в статье «SSL-сертификат истёк: что делать».

Полнота цепочки

Отдельная типичная проблема — сервер отдаёт листовой сертификат без промежуточного. Десктопные браузеры часто «дотягивают» цепочку сами, а мобильные и API-клиенты — нет: пользователь видит предупреждение, а робот фиксирует ошибку.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *[0-9]+ i:|Verify return code'

• -showcerts — печатает все сертификаты, которые отдал сервер, а не только листовой.
• grep вытаскивает строки s: (subject, чей сертификат) и i: (issuer, кем выдан) — так видна вся цепочка звеньями: issuer одного звена должен совпадать с subject следующего.
• Verify return code показывает итоговую валидацию.

Норма — Verify return code: 0 (ok) и два-три звена цепочки. Если звено одно и код 21 (unable to verify the first certificate), в конфиге веб-сервера указан только cert.pem; нужно переключить на fullchain.pem — это частая причина ошибки, которую мы разбирали в материале про ERR_SSL_PROTOCOL_ERROR.

Заголовки ответа

curl -sSI https://example.com | head -n 20

Обратите внимание на:

• HTTP/2 200 — протокол прикладного уровня. HTTP/1.1 поверх HTTPS означает, что HTTP/2 у вас выключен: настраивается одной директивой в nginx или Apache.
• strict-transport-security: max-age=31536000 — HSTS. Заголовок говорит браузеру обращаться к домену только по HTTPS и в течение года не пытаться открыть HTTP-версию. Это убирает лишний редирект для повторных посетителей.
• alt-svc: h3=":443" — сайт доступен по HTTP/3 (QUIC). Приятный бонус к скорости на плохих мобильных сетях.

Таблица: симптом → причина → решение

Редиректы и канонизация: чтобы HTTPS не создал дубли

Самая дорогая ошибка при переходе на HTTPS — оставить обе версии живыми. Классическая цепочка на плохо настроенном сайте:

http://www.example.com  →  301  →  https://www.example.com  →  301  →  https://example.com

Три адреса, два лишних редиректа. Каждый переход — дополнительный раундтрип и потерянный краулинговый бюджет. Правило простое: один хоп до финального URL.

curl -sS -o /dev/null -w '%{num_redirects} %{url_effective}\n' -L http://www.example.com/

• -o /dev/null — выбрасывает тело ответа, нам нужны только метаданные.
• -w '%{num_redirects} %{url_effective}' — печатает количество переходов и финальный адрес.
• -L — включает следование редиректам.

Норма: 1 https://example.com/. Значение 2 и больше — цепочка, которую нужно свернуть на стороне веб-сервера. Подробный разбор, как это сделать без потерь, — в статье «301-редиректы и SEO: как не потерять вес».

Отдельно проверьте, что canonical на страницах указывает на https-версию, а не остался с прошлой жизни:

curl -sSL https://example.com/ | grep -i '<link rel="canonical"'

Если тут окажется http://example.com/, вы сами сообщаете поисковику, что предпочитаете незащищённую версию. Проверьте sitemap.xml — там должны быть только https-адреса.

Скорость: HTTPS не обязан замедлять сайт

Расхожий миф — «SSL замедляет загрузку». На современном стеке всё наоборот.

Практический вывод: HTTPS даёт доступ к HTTP/2 и HTTP/3, которые ускоряют загрузку больше, чем TLS-хендшейк её замедляет. Убедиться, что у вас включён современный протокол, можно через curl (см. выше) или внешней проверкой TTFB — она покажет, как быстро страница отвечает с точки зрения внешнего наблюдателя, а не localhost.

Что реально стоит включить на сервере:

• TLS 1.2 и 1.3, выключить TLS 1.0/1.1 и SSLv3;
• ssl_session_cache shared:SSL:10m — переиспользование параметров сессии для повторных посетителей;
• OCSP stapling — сервер сам прикладывает подтверждение статуса сертификата, избавляя браузер от отдельного запроса к удостоверяющему центру;
• HTTP/2 или HTTP/3.

HSTS и security-заголовки: что дополняет HTTPS

Сам по себе редирект http → https уязвим: первый запрос пользователя всё ещё идёт по открытому HTTP, и его можно перехватить до того, как сработает 301. HSTS закрывает эту дыру.

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

• max-age — сколько секунд браузер обязан использовать только HTTPS для этого домена.
• includeSubDomains — правило распространяется на поддомены.
• preload — заявка на включение в предзагрузочный список браузеров. Включайте осознанно: попадание в список означает, что домен обязан работать по HTTPS всегда, откат занимает месяцы.

Смежные заголовки, которые влияют на безопасность и на то, как поисковик и браузер оценивают качество страницы: Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy. Их состояние удобно проверять на https://uptimechecker.ru/security-headers-check — сервис покажет, что отдаёт ваш сервер, и укажет на отсутствующие заголовки.

Чек-лист аудита: SSL и SEO на вашем сайте

Пройдите по пунктам — это займёт не больше получаса:

1. Откройте сайт по http:// — должен произойти мгновенный переход на https:// за один редирект.
2. Проверьте обе формы: apex и www. Обе должны вести на один финальный адрес.
3. Посмотрите консоль браузера на главной и на трёх внутренних страницах — ищите Mixed Content.
4. Проверьте дату истечения сертификата и убедитесь, что автопродление настроено и работает.
5. Проверьте Verify return code и количество звеньев цепочки через openssl.
6. Убедитесь, что canonical на страницах указывает на https-адрес.
7. Проверьте sitemap.xml и robots.txt: никаких http-адресов.
8. Проверьте в поисковой консоли, что HTTP-версии исключены из индекса, а HTTPS отображается как канонический.
9. Проверьте HSTS и остальные security-заголовки.
10. Поставьте внешний мониторинг на сертификат: не полагайтесь на то, что «certbot как-нибудь сам».

Пункты 4 и 10 — самые частые источники аварий. Продление сертификата ломается тихо, за 1–2 месяца до истечения, и обнаруживается в момент, когда сайт уже показывает предупреждение. Внешняя проверка на https://uptimechecker.ru/ssl-check покажет издателя, срок действия, покрытие доменов и валидность цепочки извне; сервис https://uptimechecker.ru/ssl-expiry отслеживает именно дату окончания.

Как перенести сайт на HTTPS без потери позиций

Если вы только собираетесь переезжать, порядок действий важен:

1. Выпустите сертификат на все имена, которые будут обслуживаться: apex, www, при необходимости поддомены.
2. Настройте HTTPS-виртуальные хосты и убедитесь, что все внутренние ссылки и ресурсы не содержат жёстко прописанных http-адресов.
3. Сразу настройте 301 со всех http-вариантов на единый https-URL — за один шаг, без промежуточных хостов.
4. Включите HSTS после того, как убедитесь, что HTTPS работает на всех страницах.
5. Обновите canonical, sitemap.xml, robots.txt и внутреннюю перелинковку.
6. Обновите внешние ссылки, которые вы контролируете: профили, каталоги, партнёрские сайты.
7. Наблюдайте: резкий рост ошибок 4xx/5xx или падение трафика из поиска в первые дни — сигнал, что где-то осталась http-версия или цепочка редиректов.

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

Проверьте свой сайт за минуту

Начните с аудита сертификата на https://uptimechecker.ru/ssl-check: это покажет срок действия, издателя, покрытие доменов и целостность цепочки. Рядом стоит проверить цепочку редиректов на https://uptimechecker.ru/redirect-check и скорость ответа на https://uptimechecker.ru/speed-check — эти три проверки вместе дают полную картину того, как ваш HTTPS выглядит со стороны поискового робота и обычного посетителя.