HTTPS стал стандартом де-факто: безопасность, доверие пользователей, плюс бонус к позициям в поиске. На практике переход на HTTPS для WordPress обычно упирается в три вещи: выпуск сертификата (часто Let's Encrypt), корректные редиректы и устранение mixed content (смешанного контента). В этой инструкции я разберу весь путь на примере виртуального хостинга, чтобы вы сделали всё чисто и без сюрпризов.
План перехода на HTTPS для WordPress
- Подготовка: DNS, доступ к панели/SSH, резервная копия.
- Выпуск и установка сертификата Let's Encrypt на виртуальном хостинге.
- Принудительный редирект HTTP → HTTPS и базовые заголовки безопасности.
- Переключение URL сайта в WordPress и фиксация в
wp-config.php. - Поиск и устранение mixed content: безопасный search-replace, правки тем/плагинов, внешних ресурсов.
- Очистка кэшей, повторная проверка, мониторинг автообновления сертификата.
Подготовка: что проверить заранее
Перед стартом:
- Убедитесь, что домен указывает на ваш виртуальный хостинг (актуальные A/AAAA-записи), TTL не слишком велик.
- Проверьте доступ: панель управления хостингом и SSH (если доступен). На многих тарифах доступен WP-CLI — он заметно упрощает замену ссылок.
- Сделайте резервную копию: файлы сайта и дамп базы. Это важно для отката, если что-то пойдёт не по плану.
Совет: если у вас включены CDN/прокси (например, вы используете внешний обратный прокси перед хостингом), лучше сперва настроить HTTPS на источнике (виртуальном хостинге), а уже потом включать строгие политики на CDN.
Let's Encrypt на виртуальном хостинге
На большинстве виртуальных хостингов сертификат Let's Encrypt выпускается в пару кликов и обновляется автоматически. Главное условие — домен должен открываться с вашего хостинга, чтобы валидация по HTTP-01 прошла успешно.
Типичные шаги выпуска
- В панели хостинга найдите раздел управления SSL для нужного домена.
- Выберите бесплатный сертификат Let's Encrypt, добавьте нужные имена (корневой домен и поддомен
www, если он используется). - Запустите выпуск. Дождитесь статуса «установлен» и проверьте, что цепочка сертификата корректна.
Если на сайте уже есть жёсткий редирект на HTTPS, валидация по HTTP-01 обычно всё равно проходит (клиенты следуют редиректу), но при нестандартных правилах переписи она может ломаться. На время выпуска/обновления убедитесь, что путь
/.well-known/acme-challenge/не блокируется вашими правилами.
Исключение для ACME в .htaccess
Если используете Apache и правила переписывания, добавьте исключение для ACME до правил редиректа:
# .htaccess (Apache)
# Исключаем ACME-челлендж из переписывания
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/.well-known/acme-challenge/
RewriteRule ^ - [L]
# Далее — ваши редиректы/правила
Исключение для ACME в Nginx
# Фрагмент server{} для Nginx
location ^~ /.well-known/acme-challenge/ {
default_type text/plain;
root /var/www/example.com/public; # путь к корню сайта
}
Редирект HTTP → HTTPS и базовые заголовки
После установки сертификата включаем принудительный переход на HTTPS. Сделайте это на уровне веб-сервера, это быстрее и понятнее для поисковиков.
Apache (.htaccess)
<IfModule mod_rewrite.c>
RewriteEngine On
# пропускаем ACME (см. выше), статические файлы можно не трогать
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Nginx
# В HTTP-сервере делаем 301 на HTTPS
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
Для защиты от даунгрейда и ускорения последующих заходов включите HSTS. Начните с малого max-age, чтобы был запас на откат.
HSTS
# Apache
Header always set Strict-Transport-Security "max-age=300; includeSubDomains"
# Nginx
add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
Через пару недель без проблем поднимите
max-ageдо 6–12 месяцев. Не включайтеpreload, пока не убедитесь, что полностью готовы (иначе сложнее откатывать). Подробнее см. подробный разбор Certbot и HSTS.
Переключаем WordPress на HTTPS
Через админку
В панели администратора WordPress откройте «Настройки → Общие» и поменяйте:
- Адрес WordPress (URL) — на
https://example.com - Адрес сайта (URL) — на
https://example.com
После сохранения вас разлогинит — войдите снова, уже по HTTPS.
Фиксация в wp-config.php
Чтобы настройки не «съехали» и админка всегда работала по HTTPS, добавьте в wp-config.php:
// Принудительно HTTPS для админки и авторизации
define('FORCE_SSL_ADMIN', true);
// Фиксируем домен (чтобы настройки не переопределялись)
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
// Если сайт за обратным прокси/CDN, помогаем WordPress распознавать HTTPS
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Не забудьте подставить свой домен. Если у вас мультиязычность/мультисайт, правила могут отличаться — планируйте миграцию отдельно для каждой сети/сайта.
Mixed content: как найти и исправить
Mixed content — это когда страница загружается по HTTPS, но на ней есть ресурсы по http://. Браузеры блокируют опасные типы (скрипты, XHR), а картинки/шрифты часто помечают как «несекьюрные», ломая зелёный замок. Источники проблемы:
- Абсолютные ссылки в контенте (посты, страницы, виджеты).
- Жёстко прописанные URL в темах/плагинах.
- Внешние ресурсы (шрифты, картинки, SDK), доступные только по HTTP.
- Кэш- и минификатор-плагины, зафиксировавшие старые ссылки.
Диагностика
- Откройте сайт в браузере, включите инструменты разработчика → «Console» и перезагрузите страницу — увидите предупреждения о смешанном контенте.
- Проверьте исходный код страницы (View Source) и статические бандлы из кэша/минификатора.
- На хостинге по SSH: найдите «http://» в теме/плагинах/заготовках.
# Ищем жёсткие http-ссылки в каталоге wp-content
grep -R --line-number --fixed-strings "http://" wp-content
Безопасный search-replace через WP-CLI
Лучший способ массово заменить URL в базе — WP-CLI. Он понимает сериализованные данные, не ломает сложные поля и работает быстро.
# Проверяем текущие адреса
wp option get home
wp option get siteurl
# Готовим замену домена http -> https (пример для example.com)
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --report-changed-only
# Иногда полезно добить явные шаблоны в контенте
wp search-replace 'src="http://"' 'src="https://"' --include-columns=post_content --report-changed-only
wp search-replace 'href="http://"' 'href="https://"' --include-columns=post_content --report-changed-only
# Чистим кэш WordPress
wp cache flush
wp transient delete --all
На некоторых виртуальных хостингах WP-CLI уже установлен. Если нет — проверьте, можно ли запустить его из домашнего каталога пользователя. Без SSH используйте точечные правки и безопасные инструменты замены, затем деплой.
SQL: точечная альтернатива (с оговорками)
Если WP-CLI недоступен, допустимы целевые UPDATE-запросы для контента (но не для сериализованных опций). Примеры:
-- Меняем ссылки в содержимом постов и страниц
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com')
WHERE post_content LIKE '%http://example.com%';
-- Никогда не трогаем GUID! Он технический и может оставаться http
-- UPDATE wp_posts SET guid = REPLACE(...) -- так делать не нужно
Дальше вручную проверьте виджеты и меню в админке: они часто содержат ссылки с протоколом.
Темы и плагины: убираем жёсткие http
- Вместо конкатенации протокола используйте API WordPress:
home_url(),site_url(),wp_enqueue_script(),wp_enqueue_style()— WordPress сам подставит нужную схему, если корректно определён HTTPS. - Если в теме встречаются
http://к вашему домену — замените наhttps://или на относительные/протокол-независимые ссылки//example.com/...(но последние сложнее отлаживать с CSP, поэтому лучше явноhttps://). - Внешние ресурсы подключайте строго по HTTPS. Если источник не поддерживает HTTPS, придётся отказаться от него или захостить файл у себя. При желании используйте платные SSL-сертификаты для нужных поддоменов.
Временная страховка: CSP upgrade-insecure-requests
Чтобы временно «перевести» оставшиеся http-ресурсы на https, можно включить заголовок Content-Security-Policy с директивой upgrade-insecure-requests. Это не панацея (если внешний ресурс не имеет HTTPS, он всё равно не загрузится), но помогает быстро обелить замок в браузере, пока вы добиваете хвосты.
# Apache
Header always set Content-Security-Policy "upgrade-insecure-requests"
# Nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;
Как только устранили все источники смешанного контента, можно оставить директиву (она не мешает), либо перейти к строгой политике CSP с белыми списками — это уже отдельный этап.
CDN/прокси, правильное распознавание HTTPS
Если трафик приходит через CDN/обратный прокси, WordPress может не увидеть, что соединение защищённое, и генерировать ссылки на HTTP. Мы уже добавили в wp-config.php обработку заголовка X-Forwarded-Proto. Дополнительно проверьте, что веб-сервер прокидывает этот заголовок в PHP и что PHP-FPM не обрезает заголовки.
Для Nginx проксирования к PHP добавьте:
# В блоке location ~ \.php$ или аналогичном
fastcgi_param HTTPS on;
fastcgi_param HTTP_X_FORWARDED_PROTO $scheme;
Либо на уровне обратного прокси установите X-Forwarded-Proto: https для защищённых соединений.
Кэш, минификация и сборки
- Очистите кэш плагинов (кэш страниц, минификаторы CSS/JS, оптимизаторы изображений).
- Если используете внешние кэширующие слои — очистите их тоже.
- Пересоберите минифицированные бандлы, чтобы ссылки внутри них стали https.
Проверяем редиректы и заголовки
Проверьте, что редирект одинарный (сразу 301 на HTTPS) и что заголовки HSTS/CSP отдаются верно.
# Ожидаем 301 с http на https
curl -I http://example.com
# Ожидаем 200 и наличие HSTS/CSP
curl -I https://example.com
В ответах ищем:
HTTP/1.1 301 Moved Permanentlyна HTTP-запросе и Location: на HTTPS.Strict-Transport-Securityи при желанииContent-Security-Policyна HTTPS-ответе.
Автопродление Let's Encrypt: на что обратить внимание
- Сертификат обычно обновляется автоматически за 30 дней до истечения. Проверьте дату истечения в панели хостинга.
- Путь
/.well-known/acme-challenge/должен быть доступен без авторизации и нестандартных ответов. - Фаервол/защита на стороне сайта не должна блокировать валидационные запросы. Если используете агрессивные WAF/бот-фильтры, белый список для ACME-пути обязателен.
Чек-лист «ничего не забыть»
- Сделана резервная копия файлов и БД.
- Сертификат выпущен и установлен (домен и www-вариант, если нужен).
- HTTP → HTTPS редирект настроен, HSTS включён с небольшим
max-age. - В WordPress переключены home и siteurl, добавлен
FORCE_SSL_ADMINвwp-config.php. - Сделан безопасный search-replace (WP-CLI), кэши/транзиенты очищены.
- Устранён mixed content: темы, плагины, виджеты, внешние ресурсы.
- Проверены curl-ответы и консоль браузера, нет лишних редиректов.
- Включено автопродление сертификата и проверен доступ к ACME-пути.
Частые ошибки и как их лечить
1) Бесконечные редиректы
Чаще всего — конфликт между редиректом на уровне веб-сервера и плагином редиректов или неправильное определение HTTPS за прокси. Включите обработку HTTP_X_FORWARDED_PROTO (см. выше), отключите плагин редиректов на время диагностики, оставив редирект только на веб-сервере.
2) Картинки грузятся по HTTP в контенте
Сделайте wp search-replace домена, затем проверьте редактор записей — мог остаться HTML в блоках/виджетах. Исправьте вручную. Пересоздайте минифицированные бандлы и очистите кэш.
3) Шрифты/скрипты с внешнего домена не работают
Проверьте, что внешний домен доступен по HTTPS и не блокируется политикой CORS/CSP. Если HTTPS нет — замените источник или захостите файл у себя.
4) Не открывается админка после включения HSTS
Вероятно, сертификат временно невалиден или редирект сломался. Снизьте max-age заранее (мы ставили 300), исправьте причину и только потом снова повышайте срок.
5) Сломались вебхуки/интеграции
Проверьте, не «зашиты» ли http:// в URL интеграций (CRM, платёжные шлюзы, уведомления). Обновите на https:// и проверьте логи.
Финальные штрихи: SEO и сервисные URL
- Обновите карту сайта, если она кэшируется внешне. Проверьте, что в ней https‑ссылки.
- Проверьте robots.txt — обычно не нужен апдейт, но иногда встречаются абсолютные ссылки.
- Проверьте каноникал‑теги: они должны указывать на
https://. - Если меняли домен параллельно с HTTPS, настройте канонические редиректы и ориентируйтесь на чек‑лист миграции домена.
Готово. После выполнения этих шагов WordPress будет стабильно работать на HTTPS, замок в браузере станет «чистым», а обновление сертификата — автоматическим. Главное — аккуратно пройти этап с mixed content и не забыть про кэши. Если вы только выбираете площадку, посмотрите наши тарифы на виртуальный хостинг или начните с главной, чтобы купить хостинг.
