Как проверить, правильно ли установлен SSL-сертификат на WordPress-сайте

|

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

С чего начать проверку на WordPress-сайте

Сначала откройте сайт в обычном окне браузера и посмотрите, что именно он сообщает. Формулировка ошибки уже подсказывает направление поиска:

  • «Соединение не является приватным» или похожее предупреждение — часто проблема в сертификате, его сроке действия, домене или цепочке доверия.
  • Замок есть, но часть страницы грузится по HTTP — это уже mixed content, и сертификат здесь может быть установлен правильно.
  • Редирект на HTTPS не срабатывает — сайт открывается по HTTP или ходит по кругу между версиями HTTP и HTTPS.

Если у вас есть доступ к панели хостинга, начните с проверки там: у многих провайдеров видно, какой сертификат установлен, на какие домены он выписан и когда истекает срок действия. Это полезно, но не заменяет проверку самого сайта и WordPress.

Проверка сертификата в браузере

Самый быстрый способ понять, установлен ли сертификат на нужный домен, — открыть подробности соединения в браузере. В Chrome, Edge и Firefox путь отличается, но смысл один: посмотреть сведения о сертификате.

Проверьте такие вещи:

  • Имя домена в сертификате должно совпадать с адресом сайта. Если сайт открывается как www.example.ru, а сертификат выписан только на example.ru, браузер может ругаться.
  • Срок действия не должен быть истёкшим.
  • Издатель должен быть доверенным центром сертификации.
  • Цепочка сертификатов должна быть полной, без ошибок в промежуточных сертификатах.

Если в браузере видно, что сертификат выдан на другой домен, это не проблема WordPress. Обычно причина на стороне хостинга, панели управления, CDN или настройки виртуального хоста.

Что проверить на стороне WordPress

Даже при корректном сертификате WordPress может продолжать работать как будто HTTPS не настроен. Для сайта это означает не только предупреждения, но и лишние редиректы, дубли URL и mixed content.

Адрес сайта в настройках WordPress

Откройте Настройки → Общие и проверьте два поля: Адрес WordPress (URL) и Адрес сайта (URL). Оба значения должны использовать https://, если сайт уже переведён на HTTPS.

Если здесь остался http://, WordPress может генерировать ссылки на старый протокол, даже если сертификат установлен правильно. После изменения адресов проверьте вход в админку, главную страницу и несколько внутренних страниц.

Плагины, тема и жёстко прописанные ссылки

Частая причина mixed content на WordPress-сайте — ссылки на изображения, скрипты, шрифты или iframe, которые были добавлены вручную в контенте, виджетах или настройках темы. Это особенно заметно после переезда с HTTP на HTTPS.

Проверьте:

  • контент записей и страниц, где могли остаться абсолютные ссылки вида http://example.ru/wp-content/uploads/...;
  • настройки темы, где могут быть прописаны логотип, фавикон, шрифты, иконки, карты или внешние скрипты;
  • плагины кэша, оптимизации, аналитики и вставки кода — они часто подмешивают ресурсы отдельно от WordPress.

Если сайт большой, ручной поиск не всегда удобен. Тогда проще проверить базу данных или использовать инструменты поиска и замены, но делать это нужно аккуратно: сначала резервная копия, потом замена только старых http://-ссылок на нужный домен.

Как быстро найти ошибки в цепочке сертификата и домене

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

Практически полезны такие проверки:

  • SSL Labs Server Test — показывает цепочку сертификатов, поддерживаемые протоколы, ошибки конфигурации и общую оценку HTTPS-настройки.
  • Проверка через командную строку — если есть доступ к терминалу, можно увидеть, какой сертификат реально отдаёт сервер.
  • Панель хостинга — помогает понять, установлен ли сертификат именно на нужный домен и поддомен.

Если нужен быстрый ручной тест через терминал, можно использовать openssl. Команда ниже показывает сертификат, который сервер отдаёт для конкретного домена:

openssl s_client -connect example.ru:443 -servername example.ru

В выводе смотрят на несколько вещей: совпадает ли subject или subjectAltName с доменом, есть ли промежуточные сертификаты и нет ли ошибок проверки цепочки. Если сайт работает через www, проверять нужно именно этот хост, а не только корневой домен.

Если сертификат выдан на один вариант домена, а сайт открывается на другом, исправление обычно делается на стороне хостинга или в редиректах. WordPress здесь не сможет «починить» сам сертификат.

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

Корректный SSL-сертификат не гарантирует, что сайт всегда будет открываться по HTTPS. Нужно отдельно проверить редирект с HTTP-версии адреса на HTTPS-версию.

Откройте в браузере обе версии:

  • http://example.ru
  • https://example.ru

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

Проверить ответ сервера можно и через командную строку:

curl -I http://example.ru

В ответе ищите код 301 или 308 и заголовок Location: https://example.ru/. Если вместо этого вы видите другой адрес, цепочку редиректов или ошибку, нужно смотреть настройки сервера, CDN, плагина редиректов или конфигурацию WordPress.

Как понять, что проблема не в сертификате, а в mixed content

Это один из самых частых сценариев после установки SSL на WordPress. Браузер уже показывает замок, но часть страницы всё равно может быть помечена как небезопасная или не загружаться корректно.

Типичные источники mixed content на WordPress-сайте:

  • изображения и медиафайлы, вставленные по старым HTTP-ссылкам;
  • скрипты аналитики, чатов, карт и виджетов;
  • CSS-файлы и шрифты, подключённые темой или плагином по HTTP;
  • встроенные элементы в контенте, особенно если сайт долго работал на старом домене или переезжал между поддоменами.

Проверять нужно не только главную страницу, но и внутренние шаблоны: записи, страницы, архивы, корзину, личный кабинет и формы. На WooCommerce-сайте mixed content часто всплывает именно на страницах оформления заказа, где подключаются сторонние скрипты оплаты и трекинга.

Если ошибка только в отдельных элементах, сертификат обычно установлен правильно, а исправлять нужно ссылки в WordPress, настройках темы или плагинов.

Когда проблема на стороне хостинга, CDN или DNS

Иногда владелец сайта проверяет WordPress, а причина находится совсем в другом месте. Это нормально: HTTPS зависит не только от CMS.

Обратите внимание на такие признаки:

  • сертификат в браузере не совпадает с доменом, хотя в панели хостинга он установлен;
  • на основном домене всё работает, а на www или поддомене — нет;
  • после подключения CDN сертификат меняется или появляется ошибка на уровне прокси;
  • сайт открывается по HTTPS только на части серверов, если используется балансировка или несколько окружений.

В таких случаях нужно проверить DNS-записи, привязку домена в панели хостинга, настройки CDN и то, какой именно сервер отвечает на 443 порт. WordPress может быть настроен правильно, но браузер увидит ошибку, если запрос попадает не туда.

Минимальный чек-лист проверки

Если нужно быстро понять, корректно ли установлен SSL-сертификат на WordPress-сайте, пройдите по этому порядку:

  1. Откройте сайт в браузере и посмотрите текст предупреждения.
  2. Проверьте домен в сведениях о сертификате.
  3. Убедитесь, что срок действия сертификата не истёк.
  4. Сравните http:// и https:// версии сайта и проверьте редирект.
  5. Посмотрите настройки Адрес WordPress и Адрес сайта в Настройки → Общие.
  6. Проверьте mixed content в консоли браузера.
  7. Если ошибка остаётся, протестируйте цепочку сертификата через SSL Labs или openssl.

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

SSL-сертификат на WordPress-сайте считается установленным правильно не тогда, когда «замок появился», а когда сертификат выдан на нужный домен, цепочка доверия полная, HTTP стабильно редиректится на HTTPS, а сам WordPress не отдаёт смешанный контент. Если всё это проверено, сайт можно считать настроенным корректно.

⭐⭐⭐⭐⭐