После переезда сайта на HTTPS часто остаётся неприятный хвост: часть внутренних ссылок, картинок и ссылок в контенте продолжает вести на старый http://. На фронтенде это выглядит как смешанный контент, в консоли браузера появляются предупреждения, а в админке кажется, что всё уже давно исправлено. На практике проблема обычно сидит в базе: в постах, виджетах, настройках темы, метаданных и иногда в старых вставках из конструктора.
Если менять домен или протокол без проверки базы, WordPress не всегда сам переписывает старые адреса. Особенно это заметно на сайтах, которые долго жили на HTTP, а потом переехали на HTTPS без полноценной замены URL в контенте.
Как понять, что проблема именно в старых URL
Сначала стоит убедиться, что это не кэш, не CDN и не внешний ресурс. Самый быстрый способ — открыть страницу в браузере и посмотреть консоль разработчика. Если там есть сообщения о mixed content, браузер прямо показывает, какой ресурс грузится по HTTP.
Ещё один практичный признак — в исходном коде страницы находятся ссылки вида http://example.com/wp-content/uploads/... или http://example.com/..., хотя сам сайт уже открывается по HTTPS. Это значит, что адреса зашиты в контенте или в метаданных.
Что проверить до замены
- в
Настройки → Общиеоба адреса сайта уже стоят сhttps://; - редирект с HTTP на HTTPS работает на уровне сервера;
- кэш плагина и CDN очищены;
- ошибка воспроизводится в приватном окне без расширений браузера;
- в исходнике страницы есть старые URL, а не только в визуальном редакторе.
Пошаговое решение: заменить старые HTTP-ссылки на HTTPS
Если сайт уже полностью работает по HTTPS, задача обычно сводится к аккуратной поисково-заменяющей операции по базе. Делать это вручную через редактор записей не стоит: старые ссылки могут быть не только в контенте, но и в мета-полях, настройках темы и данных плагинов.
Самый безопасный путь — сначала сделать резервную копию базы, а потом выполнить замену через инструмент, который понимает сериализованные данные. Для WordPress это критично: простая SQL-замена может сломать массивы и настройки плагинов.
Вариант через WP-CLI
Если у вас есть доступ к консоли, используйте wp search-replace. Он умеет корректно работать с сериализованными данными и обычно подходит лучше всего.
wp search-replace 'http://site.ru' 'https://site.ru' --all-tables --precise --skip-columns=guidЗдесь важно не трогать guid. Для записей WordPress это не поле для массовой правки URL, и его изменение обычно не даёт пользы, а иногда создаёт путаницу при миграциях и импорте.
Вариант через плагин
Если WP-CLI недоступен, можно использовать инструменты поиска и замены в админке. На практике это удобно для небольших сайтов, но всё равно нужно проверять, умеет ли плагин работать с сериализованными данными. Если нет — есть риск повредить настройки.
Для сайтов, где одновременно нужно почистить дубли, мета-теги и старые технические хвосты, иногда удобнее подключить Clearfy Pro. Но даже в этом случае массовую замену URL лучше делать отдельным инструментом и только после бэкапа.
Если нужно исправить только вывод темы
Иногда старый протокол сидит не в базе, а в коде темы: в настройках кастомайзера, в опциях темы или в жёстко прописанных ссылках. Тогда помогает точечная правка через фильтры или через обновление опций.
add_filter('theme_mod_header_logo', function ($value) {
if (is_string($value)) {
return str_replace('http://site.ru', 'https://site.ru', $value);
}
return $value;
});Этот пример показан только как иллюстрация подхода. В реальном проекте лучше сначала найти, где именно хранится значение, и править источник, а не подменять вывод на лету.
Когда лучше не делать замену вручную
Есть несколько сценариев, где «просто заменить http на https» — плохая идея. Например, если на сайте есть внешние интеграции, которые ещё не переведены на HTTPS, или если часть контента намеренно ссылается на сторонний HTTP-ресурс. В таком случае массовая замена может поломать рабочие ссылки.
| Подход | Когда подходит | Риск |
|---|---|---|
| WP-CLI search-replace | Полная замена старого домена на новый протокол | Нужен доступ к консоли и бэкап |
| Плагин поиска и замены | Нет SSH/WP-CLI, сайт небольшой | Важно проверить сериализацию |
| Правка кода темы | Проблема только в одном шаблоне или опции | Можно пропустить другие источники URL |
Проверка результата после внедрения
После замены не ограничивайтесь открытием главной страницы. Нужно проверить несколько уровней: HTML, медиафайлы, административные настройки и кэш.
- Откройте несколько старых записей и посмотрите исходный код страницы.
- Проверьте, что изображения в
wp-content/uploadsотдаются по HTTPS. - Посмотрите консоль браузера на предмет mixed content.
- Очистите кэш плагина, серверный кэш и CDN.
- Если используется поисковый индекс или sitemap, пересоздайте их после замены.
Дополнительно можно быстро проверить базу через поиск по SQL. Это не заменяет полноценную замену, но помогает понять, остались ли старые адреса.
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%http://site.ru%';Если запрос возвращает записи, значит часть контента ещё не переписана. Аналогично стоит проверить wp_postmeta и таблицу опций, если проблема затрагивает не только посты.
Частые ошибки и как их исправить
Меняют только адрес сайта в настройках
Это не решает проблему, если старые URL уже сохранены в записях и метаданных. Нужно именно переписать данные в базе, а не только поменять siteurl и home.
Запускают обычный SQL UPDATE по всей базе
Так можно повредить сериализованные данные. Если в настройках плагина хранится массив, длина строки изменится, а структура сломается. Для таких задач нужен инструмент, который понимает сериализацию.
Забывают про кэш и CDN
После замены сайт может продолжать отдавать старые адреса из кэша. В этом случае кажется, что ничего не изменилось, хотя база уже чистая. Сначала очищайте кэш, потом проверяйте страницу заново.
Трогают поле guid
Это частая ошибка при массовых заменах. Для обычной миграции на HTTPS поле guid обычно не переписывают. Если его менять без причины, можно создать лишние проблемы при импорте и синхронизации.
Практические советы по безопасности и производительности
Перед любой массовой заменой сделайте резервную копию базы и файлов. Это не формальность: если в базе есть сериализованные данные, откат часто проще, чем ручное восстановление отдельных опций.
Если сайт работает через CDN или reverse proxy, проверьте, что WordPress корректно понимает HTTPS на уровне сервера. Иначе часть ссылок может генерироваться как HTTP даже после замены в базе. В таких случаях иногда нужен корректный X-Forwarded-Proto на стороне прокси или настройка сервера, а не очередная правка контента.
Для сайтов, где нужно не только убрать старые URL, но и почистить технический мусор после миграции, полезно сразу проверить:
- не осталось ли дублей страниц из-за старых адресов;
- не генерируются ли лишние редиректы;
- не дублируются ли sitemap и canonical;
- не тянутся ли изображения из старого домена в виджетах и блоках.
Если после всех правок mixed content остаётся только на отдельных страницах, почти всегда виноват конкретный шаблон, блок или вставка из старого редактора. Тогда проще найти источник через поиск по базе, чем пытаться лечить весь сайт целиком.