Кратко: перевод WordPress на HTTPS — это четыре обязательных шага: сменить адреса сайта в базе (siteurl и home), заменить все http:// на https:// в контенте и настройках, настроить 301-редиректы с http на https и убрать смешанный контент — случаи, когда на https-странице подгружаются http-картинки, скрипты или стили. Пока в коде страницы остаётся хоть один http-ресурс, браузер показывает «не защищено» и зачёркивает замок, даже если сертификат установлен верно. Правильный порядок: свежий бэкап → выпуск сертификата на хостинге → смена адресов → массовая замена http на https через WP-CLI → редиректы на уровне сервера → поиск и правка mixed content → проверка canonical, sitemap, robots и Search Console. Главные грабли — сериализованные данные, которые нельзя менять обычным SQL-запросом, и жёстко прописанный http:// в теме или плагинах. Ниже — готовые команды WP-CLI, конфиги .htaccess и nginx, PHP- и JS-сниппеты, таблицы и чек-лист проверки.
Зачем переходить на HTTPS и что такое смешанный контент
HTTPS шифрует обмен между браузером и сервером: логины, данные форм, cookie сессий и содержимое страниц нельзя перехватить или подменить в открытом канале. Сегодня это не «фича для продвинутых», а базовое требование: браузеры помечают http-сайты как «не защищено», часть возможностей API попросту не работает без безопасного контекста, а поисковые системы давно используют HTTPS как один из сигналов качества. Если вы уже купили и настроили SSL-сертификат для сайта, следующий логичный шаг — полностью перевести сайт на https.
Но одного сертификата мало. Смешанный контент (mixed content) — это когда сама страница открывается по https, а часть её ресурсов подключается по http: старые картинки в постах, стили темы, скрипты плагинов, шрифты, iframe с видео. Браузер блокирует такие ресурсы или помечает страницу как небезопасную. Внешне это выглядит как «сломанный дизайн» и зачёркнутый замок в адресной строке, а по факту — потеря доверия и просадка конверсии. Именно поэтому миграция на HTTPS — это всегда два направления работы: переключить URL-адреса и вычистить смешанный контент.
Хорошая новость: в WordPress задача решаема почти полностью из командной строки, без ручного перещёлкивания тысяч ссылок. Главное — соблюдать порядок и не пропустить бэкап, о чём подробно рассказывает материал про резервное копирование WordPress.
Подготовка: бэкап, сертификат и проверка хостинга
Перед любыми правками сделайте полный снимок: файлы и базу данных. Замена адресов необратима, если ошибиться в строке, а откатить всё вручную сложнее, чем восстановить из бэкапа за пару минут. Проверьте заранее, что хостинг поддерживает бесплатный сертификат Let’s Encrypt или позволяет загрузить платный. Если сомневаетесь в тарифе и возможностях, стоит свериться со сравнением: как подобрать подходящий хостинг для сайта по параметрам и тарифам.
Убедитесь, что домен указывает на нужный сервер и что сертификат выпущен именно на ваше доменное имя — с www или без, а лучше сразу на оба варианта. Если сайт переезжает заодно на новый сервер, порядок чуть длиннее: сначала перенос файлов и базы, потом HTTPS. Как это делается шаг за шагом, описано в пошаговой инструкции про перенос сайта WordPress на другой хостинг. Доменные тонкости — в статье про выбор и регистрацию домена для сайта.
Пока сертификат ещё не активен, не включайте принудительный редирект — иначе получите цикл перенаправлений и недоступный сайт. Сначала убедитесь, что https-версия открывается и отдаёт корректный сертификат, и только потом переключайте адреса.
Меняем адреса сайта: siteurl и home
WordPress хранит два ключевых адреса: siteurl (где лежат файлы движка) и home (адрес главной страницы). Оба лежат в таблице options. Их можно менять двумя способами — временно через wp-config.php или напрямую в базе. Первый удобнее на время миграции: пока константы прописаны в конфиге, сайт будет использовать их, игнорируя значения в базе, и админка не «отвалится» после первой же правки.
<?php
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
define('FORCE_SSL_ADMIN', true);После того как убедитесь, что сайт открывается по https и админка работает, значения можно перенести в базу и убрать константы из конфига. Сделать это правильно лучше через WP-CLI, а не через phpMyAdmin — так вы не поймаете опечатку в имени таблицы. Основные команды собраны в гайде по WP-CLI для новичков.
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
wp option get siteurlОтдельно стоит держать в голове, что адреса хранятся в разных местах, и заменить их все разом одной кнопкой нельзя. Ниже — карта, которая помогает не пропустить ничего.
| Где хранится адрес | Что именно | Как менять |
|---|---|---|
| wp_options | siteurl, home | wp option update или WP-CLI search-replace |
| Контент записей и страниц | Ссылки и картинки внутри текста | Массовая замена в базе |
| Настройки темы и плагинов | Логотип, фоны, слайдеры, меню | Сериализованные значения, менять только инструментом |
| Файлы темы и плагинов | Хардкод http:// в шаблонах | Ручная правка кода |
Массовая замена http на https в базе
Вручную пройтись по всем записям невозможно, поэтому используется массовая замена. Ключевой инструмент — команда WP-CLI search-replace: она корректно обрабатывает сериализованные массивы, в отличие от прямого SQL-запроса. Всегда сначала прогоняйте прогон в режиме --dry-run, чтобы увидеть, сколько совпадений будет изменено.
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --dry-run
wp search-replace 'http://example.com' 'https://example.com' --all-tables --preciseФлаг --all-tables заставляет заменить значения во всех таблицах, а не только в стандартных. Для старых инсталляций поддержите и вариант с www, и без, чтобы не осталось «полуссылок». Если WP-CLI недоступен, минимальный SQL-запрос для самых важных полей выглядит так — но помните, что он не починит сериализованные данные.
UPDATE wp_options SET option_value = replace(option_value, 'http://example.com', 'https://example.com') WHERE option_name IN ('home','siteurl');Не трогайте поле guid у записей. Оно является внутренним идентификатором и не используется для вывода ссылок, поэтому менять его не нужно и даже вредно. Если после замены что-то в админке ведёт себя странно, включите отладку по инструкции WP_DEBUG и отладка WordPress и посмотрите логи.
301-редиректы: .htaccess и nginx
После смены адресов старые http-ссылки, индексы поисковиков и закладки пользователей должны попадать на новые https-адреса. Делается это постоянным редиректом 301 — он передаёт вес страницы и сообщает поисковикам, что адрес изменился навсегда. На сервере с Apache правило добавляется в начало .htaccess, до стандартных правил WordPress.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>На nginx того же эффекта добиваются на уровне сервера отдельным блоком, который слушает 80-й порт и сразу возвращает https. Это надёжнее, чем правила в теме.
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}Иногда редирект настраивают плагином или из темы через хук. Такой способ годится как временное решение, но работает позже серверных правил и создаёт лишнюю нагрузку. Если решите пойти этим путём, добавьте сниппет в дочернюю тему, чтобы правки не потерялись при обновлении.
add_action('template_redirect', function () {
if (!is_ssl()) {
wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301);
exit;
}
});Сравнение способов помогает выбрать подходящий для вашего окружения.
| Способ | Уровень | Плюсы | Минусы |
|---|---|---|---|
| Плагин | WordPress | Просто включить, без правки файлов | Зависимость, лишняя нагрузка |
| .htaccess | Apache | Работает до загрузки PHP, быстро | Нужен доступ к файлу, ошибка ломает сайт |
| nginx | Сервер | Самый быстрый и надёжный вариант | Требует правки конфига сервера |
| template_redirect | Тема / PHP | Гибкие условия и исключения | Срабатывает позже, тратит ресурсы |
Смешанный контент: как найти и починить
Когда редиректы настроены, наступает самый кропотливый этап — поиск ресурсов, которые всё ещё грузятся по http. Чаще всего это изображения внутри старых постов, скрипты и стили, подключённые жёстко, шрифты, встроенные видео и кнопки виджетов. Откройте консоль браузера: вкладка Console покажет предупреждения вида «Mixed Content», а во вкладке Network отфильтруйте запросы по http. Быстро просканировать текущую страницу можно коротким сниппетом в консоли.
document.querySelectorAll('[src],[href]').forEach(function (el) {
var url = el.getAttribute('src') || el.getAttribute('href');
if (url && url.indexOf('http://') === 0) {
console.warn('Mixed content:', url);
}
});Найденные адреса в контенте исправляются той же массовой заменой. Но бывает и так, что правильная строка в базе уже https, а на странице ресурс всё равно грузится по http — это значит, что адрес формируется в коде. Тогда помогает фильтр, который принудительно правит ссылку на выводе. Такой сниппет удобно держать в дочерней теме, а не в основной.
add_filter('the_content', function ($content) {
return str_replace('http://example.com', 'https://example.com', $content);
});Понимать, откуда приходит смешанный контент, помогает таблица ниже. Проверьте подключение стилей и скриптов — правильный способ описан в статье про подключение CSS и JS в WordPress.
| Источник | Пример | Решение |
|---|---|---|
| Картинки в постах | <img src=»http://…»> | Массовая замена http на https |
| Скрипты и стили темы | Хардкод в header.php | Правка кода или фильтр |
| Шрифты и иконки | @import по http | Замена в CSS на // или https |
| Встроенные видео и iframe | Старый embed-код | Обновить код вставки |
Попутно стоит заняться скоростью: миграция — хороший повод проверить оптимизацию изображений в WordPress и минификацию и объединение CSS и JS.
Сложные случаи: сериализация, хардкод, темы и плагины
Самая частая ошибка новичка — «починить» ссылки прямым SQL-запросом по всей таблице. В WordPress многие настройки хранятся в виде сериализованных массивов, где длина строки зашита в её формате. Если заменить http на https обычным replace, длина не совпадёт, строка «сломается», и настройки превратятся в мусор. Именно поэтому используют WP-CLI search-replace, который корректно пересчитывает сериализацию.
Второй случай — жёстко прописанный адрес в коде. Ищите строку http:// по файлам темы и плагинов: в шаблонах, настройках по умолчанию, редиректах внутри плагинов. Для поиска по коду удобно использовать grep или редактор проекта, а не перебирать файлы вручную. Дочерняя тема даёт безопасное место для правок — об этом подробно в материале про дочернюю тему WordPress.
Третий случай — кэш. После замены адресов очистите кэш плагина, кэш браузера и, если он есть, кэш на уровне сервера или CDN. Иначе на странице может оставаться старая http-версия ресурсов, и вы будете искать несуществующую проблему. Общие принципы описаны в гайде по кэшированию WordPress.
И не забудьте про почту и формы: после смены адреса письма WordPress должны формировать корректные ссылки. Если письма «ломаются» или не доходят, разберитесь с настройкой по статье про настройку SMTP и wp_mail.
Дополнительная защита: HSTS и принудительный SSL
Когда сайт стабильно работает по https, стоит закрепить это на уровне политики безопасности. Заголовок HSTS (Strict-Transport-Security) заставляет браузер впредь обращаться к сайту только по https, даже если пользователь вручную введёт http. Добавить его можно на сервере или через хук.
add_action('send_headers', function () {
header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
});Настройка FORCE_SSL_ADMIN в wp-config.php (см. выше) заставляет админку работать только по https, а сам сайт удобно держать под общим принудительным SSL. В связке с базовыми правилами это заметно снижает риск утечек. Основные настройки защиты собраны в материале про безопасность WordPress для новичков, а порядок обновлений — в статье про безопасное обновление WordPress.
Учтите важный нюанс: включайте HSTS и редиректы только после того, как убедились, что весь сайт и все поддомены отдают валидный сертификат. Иначе браузеры начнут блокировать доступ, и откатить это у части пользователей будет уже невозможно — политика кэшируется на их стороне.
Проверка после миграции: редиректы, SEO и аналитика
Проверка — обязательная часть миграции. Пройдите чек-лист: главная, внутренние страницы, карточки товаров, формы, поиск по сайту. Посмотрите в консоли браузера, что не осталось предупреждений Mixed Content, а замок в адресной строке отображается без предупреждений. Проверьте, что http-адрес отдаёт 301 на https, а не 200 и не цикл.
curl -I http://example.comДальше — задача сохранить позиции в поиске. Убедитесь, что canonical-ссылки ведут на https-адреса, карта сайта обновлена и доступна по новому протоколу, а robots.txt не закрывает важные разделы. Про sitemap читайте в статье про XML-карту сайта для Яндекса и Google, про запреты — в материале robots.txt и noindex в WordPress, а про структуру ссылок — про ЧПУ и настройку permalinks.
Не забудьте обновить адрес сайта в панелях вебмастера: Яндекс.Вебмастер и Google Search Console переключаются на https-версию, там же стоит проверить, что загрузка карты сайта и обход проходят без ошибок. Если аналитика настроена, счётчики продолжат собирать данные, но проверьте, что скрипт подключается по https и не блокируется. Верификация домена в сервисах, привязанная к http, может потребовать повторного подтверждения.
Частые вопросы о миграции WordPress на HTTPS
Можно ли просто заменить http на https в базе через SQL?
Для полей home и siteurl обычный запрос подойдёт, но для всей базы — нет. Многие настройки хранятся в сериализованном виде, где длина строки зашита в формате данных, и простая замена ломает структуру. Используйте WP-CLI search-replace с флагом —all-tables: он корректно пересчитывает сериализацию. Перед запуском всегда делайте прогон с —dry-run и свежий бэкап базы.
Что такое смешанный контент и как его найти?
Смешанный контент — это ресурсы, которые подключаются по http на странице, открытой по https: картинки, скрипты, стили, шрифты, iframe. Из-за них браузер помечает сайт как небезопасный или блокирует ресурсы. Найти их можно в консоли браузера: вкладка Console покажет предупреждения Mixed Content, а вкладка Network позволит отфильтровать http-запросы. Для быстрой проверки страницы подойдёт короткий JavaScript-сниппет, который перебирает атрибуты src и href.
Нужно ли менять поле guid у записей при переходе на HTTPS?
Нет, менять guid не нужно и не рекомендуется. Это внутренний идентификатор записи, который не используется для формирования ссылок на сайте. Он служит лишь для распознавания записей в RSS, поэтому смена протокола на него не влияет. Меняйте только реальные адреса: siteurl, home, ссылки в контенте и настройках.
Почему после перехода браузер пишет «не защищено»?
Если сертификат установлен и сайт открывается по https, но браузер предупреждает, значит, на странице остался смешанный контент. Даже один http-ресурс отменяет «зелёный замок». Проверьте консоль и сеть на предмет http-запросов, почините картинки и скрипты, очистите кэш плагина, браузера и CDN. Часто виновники — старые изображения внутри постов и жёстко подключённые шрифты.
Потеряю ли я позиции в SEO после перехода на HTTPS?
При правильной настройке — нет, а со временем позиции обычно растут. Критично настроить постоянные 301-редиректы с http на https, чтобы передать вес страниц, и сохранить те же URL-структуры. Проверьте canonical, обновите карту сайта и robots, переключите сайт в панелях вебмастера на https-версию. Временные колебания возможны, но это нормальный этап переиндексации.
Как настроить 301-редирект с http на https?
Надёжнее всего — на уровне сервера: на nginx отдельный блок с listen 80 и return 301, на Apache — правило RewriteCond и RewriteRule в начале .htaccess. Плагин или хук template_redirect тоже работают, но срабатывают позже и тратят ресурсы. Включайте редирект только после того, как убедились, что https-версия и сертификат работают корректно, иначе рискуете получить цикл перенаправлений.
Вывод
Миграция WordPress на HTTPS сводится к понятной последовательности: бэкап, сертификат, смена адресов siteurl и home, массовая замена http на https через WP-CLI, 301-редиректы на уровне сервера, вычистка смешанного контента и финальная проверка редиректов, canonical, sitemap и панелей вебмастера. Если пройти эти шаги по порядку, сайт переедет без потери позиций и без «сломанного» дизайна.
Главное — не экономить на двух вещах: на бэкапе перед началом и на корректном инструменте замены. Сериализованные данные и хардкод в коде — те два места, где чаще всего ломаются даже опытные разработчики. А смешанный контент, который легко не заметить, стоит проверять вручную в консоли браузера, а не «на глаз».
Если не хочется разбираться с базой, серверными конфигами и поиском mixed content самостоятельно, эту работу можно поручить команде. Мы переводим сайты на HTTPS, настраиваем редиректы, чистим смешанный контент и проверяем SEO после миграции. Посмотрите услуги разработки и поддержки сайтов, изучите портфолио выполненных проектов и почитайте блог о сайтах и продвижении. Опишите задачу через форму контактов — подскажем, что нужно именно вашему сайту и как переехать без риска.
