WordPress не работает после установки SSL: как найти причину и исправить HTTPS

Сайт WordPress работал нормально. Вы установили SSL-сертификат, включили HTTPS или изменили адрес сайта с http:// на https:// — и после этого началось:

• сайт не открывается;
• браузер сообщает о бесконечных перенаправлениях;
• /wp-admin/ перестал пускать;
• главная открывается, а стили или картинки пропали;
• сертификат вроде установлен, но HTTPS работает неправильно;
• часть страниц загружается по HTTPS, часть пытается уйти обратно на HTTP;
• после включения CDN или reverse proxy появился redirect loop.

В такой ситуации не надо сразу ставить SSL-плагин, менять .htaccess, править WordPress URL и добавлять три редиректа одновременно.

Сначала нужно определить, на каком уровне сломался переход на HTTPS.

В нормальной схеме запрос проходит примерно так:

Браузер
   ↓
HTTPS / SSL-сертификат
   ↓
Nginx / Apache / хостинг / CDN
   ↓
WordPress
   ↓
Тема / плагины / база данных / ресурсы

Ошибка на каждом уровне выглядит по-разному.

WordPress официально поддерживает HTTPS, но SSL должен уже корректно работать на веб-сервере. Само наличие сертификата ещё не означает, что WordPress правильно определяет HTTPS, использует правильные URL и не конфликтует с proxy или редиректами.

Что сделать сразу, если WordPress сломался после SSL

Самое главное правило:

Не меняйте сразу несколько уровней конфигурации.

Не надо одновременно:

менять WordPress Address
+
править .htaccess
+
включать редирект в панели хостинга
+
включать SSL-плагин
+
менять CDN

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

Сначала сохраните:

• резервную копию базы данных;
• текущий wp-config.php;
• текущий .htaccess, если используется Apache;
• конфигурацию Nginx, если у вас есть к ней доступ.

После этого отвечаем на один вопрос:

HTTPS сам по себе работает
или
WordPress ломается уже поверх рабочего HTTPS?

Шаг 1. Проверяем сам HTTPS

С компьютера или сервера выполните:

curl -I https://example.com/

Замените example.com своим доменом.

Если всё нормально, вы увидите HTTP-ответ, например:

HTTP/2 200

или перенаправление:

HTTP/2 301
location: https://www.example.com/

Сам код 301 ещё не означает проблему. Важно увидеть, куда именно вас отправляют.

Для более подробной проверки TLS:

curl -Iv https://example.com/

Здесь можно увидеть:

• удалось ли установить TLS-соединение;
• для какого домена выдан сертификат;
• проходит ли его проверка;
• какой HTTP-ответ приходит дальше.

Если HTTPS вообще не устанавливает соединение

Например:

SSL certificate problem

или браузер показывает ошибку сертификата ещё до загрузки WordPress.

Тогда пока не трогаем WordPress.

Схема выглядит так:

Браузер
   ↓
TLS/SSL ✕
   ↓
WordPress ещё даже не начал нормально работать

Проверять нужно:

• сертификат действительно выдан для нужного домена;
• есть ли в нём www, если сайт используется с www;
• не истёк ли срок действия;
• правильно ли настроен HTTPS virtual host;
• используется ли нужный сертификат;
• корректна ли цепочка сертификатов;
• тот ли сервер отвечает на 443-м порту.

WordPress указывает, что SSL должен быть предварительно настроен на сервере и secure virtual host должен быть рабочим до включения HTTPS-зависимых настроек WordPress.

Дополнительная проверка сертификата через OpenSSL

Если есть OpenSSL:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts </dev/null

Параметр:

-servername example.com

важен для серверов с несколькими сайтами: он передаёт имя домена при TLS-соединении.

Для краткой информации о сертификате можно использовать:

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

Получите примерно:

subject=...
issuer=...
notBefore=...
notAfter=...

Если сертификат неправильный или просрочен — сначала исправляем это.

Шаг 2. Определяем свой симптом

Теперь выберите, что происходит именно у вас.

После SSL WordPress сломался
          ↓
┌───────────────────────────────┬──────────────────────────────┐
│ HTTPS вообще не открывается   │ HTTPS открывается            │
│                               │                              │
│ → сертификат                  │ → идём дальше                │
│ → 443 / virtual host          │                              │
├───────────────────────────────┼──────────────────────────────┤
│ Бесконечный редирект          │ Страница без CSS / картинок  │
│                               │                              │
│ → WordPress URL               │ → Mixed Content              │
│ → server redirect             │ → старые HTTP URL            │
│ → proxy / CDN                 │ → CDN / тема / база          │
├───────────────────────────────┼──────────────────────────────┤
│ wp-admin не открывается       │ Браузер пишет «не защищено»  │
│                               │                              │
│ → URL                         │ → сертификат                 │
│ → cookies                     │ → Mixed Content              │
│ → FORCE_SSL_ADMIN             │ → HTTP-ресурсы               │
└───────────────────────────────┴──────────────────────────────┘

Начинать нужно именно со своей ветки.

Шаг 3. Проверяем URL самого WordPress

У WordPress есть два важных адреса.

Первый — URL, по которому посетители открывают сайт.

В коде это связано с:

home

и:

home_url()

Второй — URL, где доступны файлы самого WordPress:

siteurl

и:

site_url()

В обычной установке они часто одинаковы:

https://example.com
https://example.com

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

Поэтому совет:

«Просто сделайте оба значения одинаковыми»

нельзя применять вслепую.

Проверяем URL через WP-CLI

Если WP-CLI доступен:

wp option get home

и:

wp option get siteurl

Для обычного сайта после полноценного перехода на HTTPS ожидается что-то вроде:

https://example.com

Если видите:

home:
https://example.com

siteurl:
http://example.com

у сайта уже есть потенциальный конфликт схем.

WordPress считает сайт полностью использующим HTTPS, когда и home URL, и site URL используют HTTPS.

Проверяем wp-config.php

Значения в базе могут быть переопределены константами.

Проверьте:

grep -nE "WP_HOME|WP_SITEURL|FORCE_SSL_ADMIN" wp-config.php

Например:

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

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

А если задано:

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

поля адресов в панели WordPress могут быть недоступны для редактирования — WordPress использует значения из wp-config.php.

Если после смены URL сайт перестал открываться

Классическая ситуация:

Настройки → Общие
↓
http://example.com
меняем на
https://example.com
↓
Сохранить
↓
сайт больше не открывается

Не паникуйте.

Если есть доступ по SSH или FTP, можно временно явно задать правильные URL в wp-config.php.

Например, для стандартной установки в корне:

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

Размещают такие настройки до строки загрузки WordPress, а не в случайном месте файла.

Но снова: если WordPress установлен в подкаталоге, WP_SITEURL может быть другим. Подставляйте фактическую структуру вашего сайта, а не копируйте пример.

WordPress уходит в бесконечный редирект после SSL

Теперь одна из самых неприятных ситуаций.

Браузер сообщает:

ERR_TOO_MANY_REDIRECTS

или:

Too many redirects

Это означает, что браузер получает перенаправление, выполняет его — и снова получает перенаправление. Цикл повторяется.

Сначала не очищаем всё и не меняем конфиги наугад.

Посмотрим саму цепочку.

Проверяем цепочку редиректов

curl -IL --max-redirs 10 http://example.com/

И отдельно:

curl -IL --max-redirs 10 https://example.com/

Нормальная схема может выглядеть примерно так:

http://example.com
↓ 301
https://example.com
↓ 200

То есть один переход.

Плохая схема:

http://example.com
↓
https://example.com
↓
http://example.com
↓
https://example.com
↓
...

Или:

https://example.com
↓
https://www.example.com
↓
https://example.com
↓
https://www.example.com
↓
...

Теперь мы уже знаем не просто:

WordPress делает много редиректов.

А видим между какими адресами происходит цикл.

Откуда может взяться redirect loop

После SSL перенаправление могут одновременно делать:

WordPress
+
плагин
+
.htaccess
+
Nginx
+
панель хостинга
+
reverse proxy
+
CDN

Каждый по отдельности может быть настроен правильно.

Вместе они способны устроить цикл.

Например:

Nginx:
HTTP → HTTPS

WordPress:
считает запрос HTTP

WordPress:
пытается отправить на HTTPS

proxy:
снова передаёт запрос WordPress как HTTP

WordPress:
снова считает запрос HTTP

↓
цикл

WordPress за reverse proxy или CDN

Это отдельная и очень важная ветка.

Архитектура может выглядеть так:

Браузер
   ↓ HTTPS
CDN / reverse proxy
   ↓ HTTP
WordPress

Для посетителя соединение HTTPS.

Но backend видит:

HTTP

WordPress проверяет, используется ли SSL, через is_ssl(). В обычной ситуации функция ориентируется на HTTPS или порт 443. За некоторыми reverse proxy этого недостаточно.

Тогда получается:

пользователь уже на HTTPS
↓
WordPress думает, что запрос HTTP
↓
WordPress отправляет на HTTPS
↓
proxy снова приходит к WordPress по HTTP
↓
WordPress снова отправляет на HTTPS
↓
ERR_TOO_MANY_REDIRECTS

Проверяем X-Forwarded-Proto

Нормально настроенный proxy обычно сообщает backend исходную схему через заголовок:

X-Forwarded-Proto: https

Для Nginx reverse proxy это может выглядеть так:

proxy_set_header X-Forwarded-Proto $scheme;

В wp-config.php обработка доверенного HTTP_X_FORWARDED_PROTO может выглядеть так:

if (
    isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false
) {
    $_SERVER['HTTPS'] = 'on';
}

Но этот код не надо вставлять просто потому, что вы увидели его в статье.

Сначала должно быть подтверждено, что:

• сайт действительно находится за reverse proxy;
• proxy сам формирует или перезаписывает X-Forwarded-Proto;
• backend получает этот заголовок от доверенного proxy.

Иначе вы лечите проблему, которой у вас нет.

Бесконечный редирект без reverse proxy

Если CDN/proxy нет, проверяем другие уровни.

Сначала:

wp option get home
wp option get siteurl

Затем:

grep -nE "WP_HOME|WP_SITEURL|FORCE_SSL_ADMIN" wp-config.php

После этого смотрим серверные редиректы.

Проверяем Apache .htaccess

Сохраните копию:

cp .htaccess .htaccess.backup

И посмотрите правила:

cat .htaccess

Особенно ищем:

RewriteCond
RewriteRule
HTTPS
https://

Например, если HTTPS уже принудительно включается на уровне панели хостинга или proxy, а ещё один набор правил пытается делать это в .htaccess, нужно понять, нет ли конфликта.

Но не удаляйте весь .htaccess только потому, что увидели RewriteRule.

Стандартные правила WordPress тоже используют rewrite.

Проверяем Nginx

Посмотреть активную конфигурацию:

sudo nginx -T 2>/dev/null

Быстрый поиск перенаправлений:

sudo nginx -T 2>/dev/null \
  | grep -nEi "return 30[1278]|rewrite|https|X-Forwarded-Proto"

Ищем, где именно выполняется:

return 301 https://...

или другой redirect.

Важно понять:

кто отвечает за HTTP → HTTPS?

Желательно иметь одну понятную точку, а не четыре слоя, каждый из которых пытается исправить предыдущий.

Проверяем SSL- и redirect-плагины

Посмотреть активные плагины:

wp plugin list --status=active

Обратите внимание на плагины, связанные с:

• SSL;
• HTTPS;
• redirects;
• security;
• cache;
• CDN.

Не отключайте сразу всё.

Если подозрение падает на конкретный плагин:

wp plugin deactivate <plugin-slug>

После отключения повторите:

curl -IL --max-redirs 10 https://example.com/

Если цикл исчез — область поиска локализована.

ERR_TOO_MANY_REDIRECTS только в wp-admin

Допустим:

https://example.com/

работает.

А:

https://example.com/wp-admin/

зацикливается.

Проверяем:

WP_HOME
WP_SITEURL
FORCE_SSL_ADMIN
proxy HTTPS detection
cookies
SSL/security plugin

Проверяем FORCE_SSL_ADMIN

В wp-config.php может быть:

define( 'FORCE_SSL_ADMIN', true );

Это штатная константа WordPress, принуждающая login и admin работать через SSL. Но HTTPS на сервере уже должен быть корректно настроен до её включения.

То есть:

FORCE_SSL_ADMIN = true

сам по себе не является ошибкой.

Вопрос:

WordPress действительно понимает, что текущий запрос уже HTTPS?

Очистите cookies после смены HTTP → HTTPS

После изменения схемы могут измениться условия использования authentication cookies.

Поэтому если:

• фронтенд работает;
• URL выглядят правильно;
• а login/admin ведёт себя странно,

удалите cookies только для своего домена и попробуйте войти снова.

Mixed Content после перехода на HTTPS

Теперь другая картина.

Страница открывается:

https://example.com

но что-то внутри неё всё ещё запрашивается как:

http://example.com/image.jpg

или:

http://example.com/style.css

Получается:

HTTPS-страница
   ↓
HTTP-ресурс
   ↓
Mixed Content

Из-за этого браузер может блокировать часть ресурсов или предупреждать о небезопасном содержимом.

Как увидеть Mixed Content

Откройте страницу в Chrome/Edge.

Нажмите:

F12

Откройте:

Console

Ищите сообщения:

Mixed Content

Теперь у вас есть конкретный URL ресурса, а не абстрактное:

После SSL поломался дизайн.

Откуда берутся старые HTTP URL

Обычно из:

• старых записей в базе WordPress;
• содержимого страниц;
• виджетов;
• настроек темы;
• page builder;
• custom CSS;
• настроек плагина;
• CDN;
• вручную прописанных URL;
• старого home/siteurl;
• HTML в шаблоне.

WordPress Core умеет помогать с обычной миграцией HTTP → HTTPS, но это не гарантирует автоматическое исправление любого URL, вручную записанного темой, плагином или сторонним сервисом.

После HTTPS пропали картинки

Открываем DevTools → Network.

Обновляем страницу.

Находим не загрузившуюся картинку.

Смотрим URL.

Если:

http://example.com/wp-content/uploads/...

проблема очевидна.

Если:

https://example.com/wp-content/uploads/...

но ответ:

404

это уже не Mixed Content.

Тогда проверяем:

• существует ли файл;
• правильный ли путь;
• CDN;
• rewrite;
• права;
• URL uploads.

То есть очень важно не сваливать все проблемы после SSL в одну категорию.

После HTTPS пропали CSS и сайт выглядит «голым»

Симптом:

текст есть
картинки частично есть
оформления почти нет

Первым делом:

F12 → Console

и:

F12 → Network → CSS

Посмотрите, какой CSS не загрузился.

Если адрес:

http://example.com/wp-content/themes/...

— ищем старый HTTP URL.

Если:

https://example.com/...

но 404/403 — это уже другой тип проблемы.

Так вы перестаёте гадать:

SSL сломал CSS.

и получаете конкретику:

style.css запрашивается с неправильной схемой.

Ищем HTTP URL в базе через WP-CLI

Сначала ничего не заменяем.

Можно посмотреть, сколько старых URL осталось, через wp search-replace в режиме:

--dry-run

Например:

wp search-replace \
  'http://example.com' \
  'https://example.com' \
  --all-tables-with-prefix \
  --skip-columns=guid \
  --dry-run

Эта команда не сохраняет изменения, а показывает, что было бы заменено.

wp search-replace умеет корректно работать с сериализованными PHP-данными и поддерживает --dry-run, поэтому он намного безопаснее, чем слепой глобальный REPLACE() через SQL по всей базе.

Перед настоящей заменой — backup

Если dry-run показывает ожидаемые изменения, сначала сделайте резервную копию базы.

Через WP-CLI:

wp db export before-https-replace.sql

Убедитесь, что файл появился.

Только после этого можно выполнить настоящую замену:

wp search-replace \
  'http://example.com' \
  'https://example.com' \
  --all-tables-with-prefix \
  --skip-columns=guid

Не копируйте эту команду бездумно, если:

• используется Multisite;
• домены отличаются;
• WordPress расположен в нестандартном каталоге;
• несколько сайтов живут в одной базе;
• часть таблиц относится к другим приложениям.

Сначала --dry-run.

Почему не стоит делать обычный SQL REPLACE по всей базе

В WordPress плагины, темы и виджеты могут хранить сериализованные данные.

В таких данных хранится не только строка, но и её длина.

Если заменить:

http://

на:

https://

неправильным способом, длина меняется.

Сериализованная структура может перестать корректно разбираться.

Ищем URL, прописанные прямо в файлах

Если база уже чистая, а Mixed Content остался, проверьте wp-content.

Например:

grep -RIn \
  --exclude-dir=node_modules \
  --exclude-dir=vendor \
  "http://example.com" \
  wp-content/

Можно найти:

theme.css
functions.php
custom.js
plugin settings file

или другой файл.

Теперь уже правим конкретное место.

Не выполняйте глобальную замену:

http:// → https://

по всем файлам подряд.

В коде могут присутствовать внешние URL и другие значения, которые нельзя менять автоматически.

Внешний HTTP-ресурс

Например, нашли:

<script src="http://third-party.example/script.js"></script>

Не надо просто заменить:

http

на:

https

и надеяться.

Сначала проверьте:

https://third-party.example/script.js

действительно существует и имеет рабочий сертификат.

Если внешний сервис HTTPS не поддерживает, лучше:

• заменить сервис;
• убрать ресурс;
• найти современный HTTPS endpoint.

WordPress Site Health и HTTPS

В современных версиях WordPress стоит проверить:

Инструменты
→ Здоровье сайта

WordPress умеет определять, использует ли сайт HTTPS и поддерживает ли окружение безопасное переключение.

Если Site Health говорит, что HTTPS не распознаётся, хотя браузер уже открывает сайт через HTTPS, это важная подсказка.

Особенно для:

CDN
reverse proxy
load balancer

После SSL не открывается wp-admin

Разбираем отдельно.

Проверьте сначала:

curl -IL --max-redirs 10 https://example.com/wp-login.php

Если увидели цикл — смотрим URL и HTTPS detection.

Если login page открывается нормально, но после ввода пароля снова возвращает на login — проверяем:

1. cookies;
2. WP_HOME;
3. WP_SITEURL;
4. значения home и siteurl;
5. FORCE_SSL_ADMIN;
6. proxy/CDN;
7. плагины security/cache.

Если wp-admin недоступен — не обязательно нужен браузер

Через WP-CLI всё ещё можно посмотреть:

wp option get home
wp option get siteurl

Плагины:

wp plugin list --status=active

И при необходимости отключить конкретный подозрительный плагин:

wp plugin deactivate <plugin-slug>

Это позволяет диагностировать сайт даже тогда, когда Dashboard уже не открывается.

Проверяем кеш

Допустим, вы исправили:

HTTP URL

на:

HTTPS URL

но браузер всё равно показывает старую версию.

Не начинайте снова править базу.

Проверьте кеш по уровням:

браузер
↓
WordPress cache plugin
↓
server cache
↓
reverse proxy
↓
CDN

После исправления HTTPS старый кеш может продолжать отдавать HTML со ссылками на http://.

Как понять, кто продолжает отдавать старый HTML

Получите страницу напрямую:

curl -sS https://example.com/ > page.html

И проверьте:

grep -n "http://example.com" page.html

Если старый URL находится уже в HTML от сервера — дело не только в браузере.

Если сервер отдаёт чистый HTTPS, а браузер показывает старую версию — подозрение на локальный браузерный кеш становится сильнее.

Проверяем HTTP → HTTPS после исправления

Когда сайт уже работает, выполните:

curl -I http://example.com/

Ожидаем redirect на HTTPS.

Например:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Теперь:

curl -I https://example.com/

Ожидаем нормальный ответ:

HTTP/2 200

Или другой ожидаемый код страницы.

Хорошая схема:

HTTP
↓
один понятный redirect
↓
HTTPS
↓
200

А не:

HTTP
↓
HTTPS
↓
www
↓
без www
↓
HTTPS
↓
ещё redirect
↓
200

Проверяем всю цепочку одной командой

curl -IL --max-redirs 10 http://example.com/

В идеальном случае цепочка короткая и понятная.

Если видите пять-шесть переходов — стоит выяснить, кто их создаёт.

Проверяем WordPress после исправления

Через WP-CLI:

wp option get home
wp option get siteurl

Ожидаемые значения для стандартной установки:

https://example.com
https://example.com

Если в wp-config.php используются:

WP_HOME
WP_SITEURL

проверяем и их.

Проверяем страницу глазами браузера

Открываем:

https://example.com/

И смотрим:

F12 → Console

Не должно оставаться Mixed Content.

Затем:

Network

Обновляем страницу.

Особенно смотрим:

Doc
CSS
JS
Img
Fetch/XHR

Убедитесь, что ресурсы вашего сайта больше не уходят на старый http://.

Проверяем wp-admin

Открываем:

https://example.com/wp-admin/

Проверяем:

• login;
• Dashboard;
• загрузку CSS;
• медиа;
• редактирование страницы;
• сохранение.

После перехода на HTTPS недостаточно увидеть только рабочую главную.

Проверяем типичный пользовательский сценарий

Если это WooCommerce:

товар
↓
корзина
↓
checkout

Если обычный WordPress:

главная
↓
статья
↓
форма
↓
wp-admin

Если есть API:

/wp-json/

Переход на HTTPS не должен ломать реальные пользовательские действия.

Диагностическая схема целиком

WordPress сломался после SSL
              ↓
       HTTPS открывается?
        ↓             ↓
       НЕТ           ДА
        ↓             ↓
сертификат / 443    Что именно сломалось?
virtual host           ↓
             ┌─────────┴──────────┐
             ↓                    ↓
      Redirect loop          CSS / картинки
             ↓                    ↓
      curl -IL              DevTools Console
             ↓                    ↓
     WordPress URLs          Mixed Content?
             ↓                    ↓
    server redirect          HTTP URL
             ↓                    ↓
     proxy / CDN             база / тема /
             ↓               плагин / CDN
     X-Forwarded-Proto            ↓
             ↓                search-replace
       is_ssl() корректен?        ↓
             └─────────┬──────────┘
                       ↓
                    исправили
                       ↓
                 очистили кеш
                       ↓
             проверили HTTP → HTTPS
                       ↓
                   wp-admin
                       ↓
                 Console / Network
                       ↓
                 повторный тест

Что не стоит делать после установки SSL

1. Ставить несколько SSL-плагинов одновременно

Это не увеличивает надёжность.

Это увеличивает количество мест, которые могут делать редирект.

2. Одновременно включать HTTPS во всех местах

Например:

хостинг
+
CDN
+
Nginx
+
.htaccess
+
WordPress plugin

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

3. Менять home и siteurl вслепую

Они часто совпадают.

Но не всегда.

Особенно если WordPress находится в отдельной директории.

4. Делать глобальный SQL REPLACE по базе

Можно повредить сериализованные данные.

Используйте инструмент, который их понимает, и сначала --dry-run.

5. Включать FORCE_SSL_ADMIN до рабочего SSL

Сначала должен быть рабочий SSL и secure host.

6. Считать любой сломанный CSS Mixed Content

Сначала посмотрите Network.

Если CSS идёт по HTTPS, но получает 404, SSL здесь может быть вообще ни при чём.

7. Исправлять redirect loop очисткой кеша и больше ничем

Очистка cookies или кеша может убрать старое состояние.

Но если:

HTTP ↔ HTTPS

реально зациклены на сервере, очищать кеш можно хоть десять раз.

Короткий алгоритм: WordPress сломался после SSL

Если оставить из всей статьи только одну инструкцию:

1. Проверить:
   curl -Iv https://example.com/

2. Если TLS не работает:
   чинить сертификат / HTTPS virtual host.

3. Если TLS работает:
   curl -IL --max-redirs 10 https://example.com/

4. Если redirect loop:
   проверить:
   home
   siteurl
   WP_HOME
   WP_SITEURL
   FORCE_SSL_ADMIN
   server redirect
   proxy/CDN

5. Если дизайн сломан:
   F12 → Console / Network
   искать Mixed Content и HTTP URL.

6. Если старые URL в базе:
   wp search-replace ... --dry-run

7. Сделать backup.

8. Только после проверки выполнить search-replace.

9. Очистить кеш на всех используемых уровнях.

10. Проверить:
    HTTP → HTTPS
    главную
    wp-admin
    CSS/JS/images
    реальные пользовательские сценарии.

Быстрый набор команд

Проверить HTTPS

curl -Iv https://example.com/

Проверить redirects

curl -IL --max-redirs 10 http://example.com/

curl -IL --max-redirs 10 https://example.com/

Проверить WordPress URLs

wp option get home

wp option get siteurl

Проверить переопределения

grep -nE "WP_HOME|WP_SITEURL|FORCE_SSL_ADMIN" wp-config.php

Посмотреть плагины

wp plugin list --status=active

Проверить старые HTTP URL без изменения базы

wp search-replace \
  'http://example.com' \
  'https://example.com' \
  --all-tables-with-prefix \
  --skip-columns=guid \
  --dry-run

Backup базы

wp db export before-https-replace.sql

Найти URL в файлах

grep -RIn \
  --exclude-dir=node_modules \
  --exclude-dir=vendor \
  "http://example.com" \
  wp-content/

Если WordPress после SSL всё равно не работает

Не продолжайте хаотично менять настройки.

Соберите:

1. результат:
   curl -Iv https://example.com/

2. цепочку:
   curl -IL --max-redirs 10 https://example.com/

3. значения:
   home
   siteurl
   WP_HOME
   WP_SITEURL

4. информацию:
   используется ли CDN / reverse proxy

5. ошибки:
   Browser Console / Network

6. если есть:
   правила .htaccess или Nginx,
   связанные с HTTPS.

После этого проблема обычно превращается из:

«Я установил SSL, и WordPress умер»

в гораздо более конкретную:

«Сертификат рабочий, но WordPress за reverse proxy не определяет HTTPS и зацикливает /wp-admin/».

или:

«Сам сайт работает по HTTPS, но в настройках темы осталось 37 старых HTTP URL, из-за которых браузер блокирует CSS и изображения».

А конкретную проблему уже можно нормально исправлять.