Как исправить смешанный контент на HTTPS-сайте

Сайт может открываться по HTTPS и при этом запрашивать изображения, стили или скрипты по обычному HTTP. Это называется смешанным контентом. Браузер часть таких запросов обновляет до HTTPS, а часть блокирует; в результате исчезают картинки, ломаются формы или перестают работать элементы страницы.

Исправление состоит в поиске источника HTTP-ссылки и замене её на рабочий HTTPS-адрес либо удалении небезопасной зависимости. Повторная установка сертификата не переписывает адреса в базе, шаблонах и стилях.

В статье разберём диагностику через браузер, исправление WordPress и собственных шаблонов, безопасную замену в базе и проверку результата. Если HTTPS ещё не настроен, начните с установки бесплатного сертификата.

Что считается смешанным контентом

Когда защищённая страница загружает ресурс через незащищённое соединение, безопасность страницы становится зависимой от этого ресурса. Например, HTTP-скрипт может быть подменён по пути и изменить содержимое HTTPS-страницы.

Не всякая ссылка с http:// в тексте является смешанным контентом. Обычная ссылка, по которой пользователь отдельно перейдёт на другой сайт, отличается от автоматически загружаемого скрипта, изображения, iframe или запроса fetch.

Поведение для разных видов ресурсов описано в документации MDN о mixed content. Для диагностики важно смотреть конкретный заблокированный запрос, а не оценивать проблему по общему числу строк http:// в исходнике.

Отдельно существуют ошибки сертификата, CORS, CSP и недоступность сервера. Они могут выглядеть похожими в интерфейсе, но требуют разных исправлений. Если HTTPS-ресурс не проходит проверку сертификата, простая замена протокола ещё не завершает задачу.

Почему проблема появляется после перехода на HTTPS

В базе могли остаться старые абсолютные адреса картинок. Тема могла содержать жёстко заданный HTTP-адрес шрифта. Внешний виджет мог подключаться по устаревшей инструкции. Генератор CSS или кеш мог сохранить прежний домен и схему.

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

После переноса сайта на другой хостинг добавляются временные домены, другой CDN и старые настройки путей. Поэтому проверка смешанного контента должна входить в приёмку переезда, а не выполняться только при первом выпуске сертификата.

Шаг 1. Найдите проблему в браузере

Откройте проблемную страницу по HTTPS и инструменты разработчика. Перейдите в Console и Network. Перезагрузите страницу, чтобы увидеть запросы текущей загрузки.

В Console найдите сообщение о mixed content и сохраните URL ресурса, тип запроса и страницу, где он используется. В Network проверьте статус и причину блокировки. Для повторной проверки можно временно отключить кеш в DevTools, пока панель открыта.

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

Полезно составить таблицу:

Именно источник, а не только итоговый URL, определяет правильное место исправления.

Шаг 2. Проверьте, работает ли ресурс по HTTPS

Откройте HTTPS-версию ресурса отдельно. Проверьте сертификат, код ответа, содержимое и конечный адрес после редиректов. Сервер может отвечать 200, но возвращать HTML-заглушку вместо JavaScript или картинки.

Для собственного ресурса пример проверки:

curl -sS -L -o /dev/null \
  -w 'HTTP: %{http_code}\nURL: %{url_effective}\n' \
  https://example.com/assets/site.css

Подставьте нужный адрес. Не отключайте проверку сертификата: браузер посетителя также будет её выполнять. Если URL после переходов снова становится HTTP, исправьте перенаправление на стороне ресурса.

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

Шаг 3. Найдите источник ссылки

HTTP-адрес может находиться в HTML-шаблоне, тексте записи, настройке CMS, CSS-файле, JavaScript, ответе API или сгенерированном кеше. Исправление только итогового HTML в браузере не сохраняется на сервере.

В DevTools используйте столбец или вкладку Initiator: она помогает понять, что вызвало запрос. Например, шрифт может загружаться из CSS, а не прямо из HTML. Изображение может появляться после выполнения JavaScript, поэтому поиск в исходном коде страницы его не покажет.

В репозитории проекта можно искать точное имя домена или фрагмент адреса. На Linux, если установлен ripgrep:

rg -n 'http://example\.com' ./templates ./static

Это поиск, а не массовая замена. Каталоги выбирайте по структуре своего проекта. Не включайте в вывод файлы с секретами и не публикуйте найденные конфигурации целиком.

Если ссылка генерируется из настройки базового URL, исправьте настройку. Если она записана в тексте десяти статей — понадобится корректная обработка контента. Если адрес приходит от внешнего API, проверьте формат ответа и возможность защищённого источника.

Исправление обычных HTML-ссылок

Для ресурсов того же сайта часто удобно использовать путь от корня:

<img src="/images/example.webp" alt="Пример настройки сайта">
<link rel="stylesheet" href="/assets/site.css">
<script src="/assets/site.js" defer></script>

Такой путь использует схему и имя текущего сайта. Но для CDN или другого домена нужен явный корректный HTTPS-адрес. Учитывайте также <base>, если он присутствует: он меняет разрешение относительных ссылок.

Не заменяйте все абсолютные адреса относительными без анализа. Ссылки в письмах, RSS и некоторых структурированных данных должны оставаться пригодными вне контекста текущей страницы.

Проверьте srcset, CSS url(...), @import, iframe, видео, постеры, формы и JavaScript-запросы. Иногда основной src исправлен, а браузер выбирает HTTP-вариант из srcset для другого размера экрана.

WordPress: сначала настройки, затем содержимое

Проверьте адрес WordPress и адрес сайта в настройках. Если они определены константами в wp-config.php или переменными окружения, значение из панели может не быть действующим источником.

Затем изучите записи, блоки редактора, меню, настройки темы и плагинов. В конструкторах страниц могут храниться собственные структуры данных и сгенерированные CSS-файлы. Используйте штатный способ обновления адресов и пересоздания файлов конкретного конструктора.

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

Пример пробной проверки через WP-CLI в каталоге правильного сайта:

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

Посмотрите отчёт: какие таблицы и сколько значений будут изменены. Для multisite и нестандартных таблиц область нужно выбирать отдельно. Только после проверки копии и результата выполняйте согласованную замену без --dry-run.

Поведение команды описано в документации WP-CLI. Не добавляйте --all-tables без необходимости: в одной базе могут лежать данные других приложений.

Почему плагин «исправить SSL» не всегда решает проблему

Некоторые расширения меняют ссылки на этапе вывода. Это может помочь временно, но источник старого адреса остаётся в базе или шаблоне. После отключения расширения, смены кеша или другого способа вывода проблема возвращается.

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

Предпочтительнее устранить неверный базовый URL, обновить шаблон и корректно заменить сохранённые адреса. После этого можно убрать временную обработку и повторить проверку.

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

Внешние шрифты, карты, видео и виджеты

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

Виджет может сам загружаться по HTTPS, а затем запрашивать HTTP-скрипт или изображение. Поэтому нужно пройти сценарий после его запуска, а не только проверить первый тег подключения.

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

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

API-запросы и формы

Проверьте адреса fetch, XMLHttpRequest и WebSocket. Защищённая страница должна обращаться к совместимому защищённому endpoint. Для WebSocket это обычно wss://, если соединение идёт из HTTPS-контекста.

Замена HTTP на HTTPS может выявить другую проблему — CORS или ограничения авторизации. Это не повод отключать браузерную защиту. Настройте разрешённые источники и передачу учётных данных согласно архитектуре приложения.

У формы проверьте action, редирект после отправки и все шаги подтверждения. Страница может выглядеть исправно, пока пользователь не нажмёт кнопку. Для платежей и реальных заявок используйте тестовый режим или согласованные безопасные данные.

Не передавайте секретные API-ключи в браузер, пытаясь обойти серверную интеграцию. Если ключ предназначен для backend, он должен оставаться на серверной стороне.

CSP upgrade-insecure-requests: дополнительная мера

Директива CSP upgrade-insecure-requests может предписать браузеру использовать защищённые варианты запросов. Она полезна в определённых сценариях перехода, но не создаёт HTTPS на внешнем сервере и не исправляет его сертификат.

Если у ресурса нет рабочего защищённого адреса, обновлённый запрос завершится ошибкой. Поэтому сначала проверьте зависимости и только затем оценивайте политику. Не используйте CSP как замену исправлению сохранённых адресов.

Не добавляйте противоречивые CSP-заголовки из панели, приложения и CDN без анализа итогового ответа. Несколько политик могут совместно ограничивать страницу сильнее, чем ожидается.

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

Очистка кеша после исправления

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

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

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

Ограничения места и бесконтрольный рост кеша разобраны в статье сколько места на диске нужно сайту.

Как проверить результат

Повторите исходный сценарий с открытыми Console и Network. Проверьте не только отсутствие предупреждения, но и работу ресурса: изображение отображается, скрипт выполняется, форма сохраняет результат.

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

Убедитесь, что внутренние ссылки, canonical и карта сайта используют правильный основной адрес. При этом не заменяйте обычные внешние HTTP-ссылки без проверки доступности их HTTPS-версий: задача относится прежде всего к загружаемым зависимостям.

Если после исправления страница стала медленнее, проверьте цепочку редиректов и новый внешний источник. Подробный порядок — диагностика медленной загрузки.

Типичные неудачные решения

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

Практический пример: картинка в старой статье

Допустим, статья открывается по HTTPS, а в Console есть HTTP-адрес изображения с того же домена. Сначала откройте HTTPS-вариант картинки и убедитесь, что она действительно доступна.

Затем найдите адрес в редакторе записи или блоке галереи. Исправьте ссылку, проверьте srcset и сохраните статью. Очистите её кеш и повторите просмотр на обычной и мобильной ширине.

Если таких записей много, сначала испытайте массовую замену на копии базы. Не запускайте её по всем таблицам без отчёта. После обработки выборочно проверьте старые и новые статьи, галереи, обложки и письма с абсолютными ссылками.

Пример: внешний виджет ломает страницу после HTTPS

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

Откройте официальную инструкцию сервиса и сравните подключение. Если есть актуальный HTTPS-вариант, испытайте его на копии страницы. Проверьте не только появление карты, но и её дополнительные запросы, поиск адреса и мобильное поведение.

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

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

Пример: HTTP-адрес приходит из API

У приложения может быть правильный HTTPS-шаблон, но данные для галереи загружаются из API с абсолютными HTTP-ссылками. Тогда поиск по файлам темы ничего не найдёт: адрес появляется только после запроса.

Посмотрите ответ API и участок кода, который строит URL. Если это ваш backend, исправьте конфигурацию публичного адреса и проверьте, как определяется исходная схема за прокси. Если это внешний источник, выясните, предоставляет ли он защищённые URL официально.

Не выполняйте слепую замену схемы на клиенте для любого произвольного адреса. Внешний сервер может не поддерживать HTTPS, а URL может содержать подпись, зависящую от точного значения. Проверка должна учитывать формат конкретной интеграции.

После исправления пройдите несколько записей API, включая старые и новые данные. Иногда только исторические объекты содержат прежний адрес, а новые уже формируются правильно. Для массового обновления сохранённых значений сначала нужен отчёт и резервная копия.

Смешанный контент в стилях и шрифтах

Если предупреждение указывает на файл шрифта, найдите CSS, из которого он загружается. Проверьте @font-face, @import и адреса фоновых изображений. HTML может вообще не содержать проблемную строку.

У конструктора страниц CSS иногда генерируется из настроек в базе. Ручная правка сгенерированного файла даст временный результат: при следующем сохранении он появится заново. Нужно исправить исходную настройку и пересоздать стили штатным способом.

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

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

Как не повредить содержимое массовой заменой

Сначала определите точные старый и новый адреса. http://example.com и http://www.example.com — разные строки. В базе могут встречаться также экранированные JSON-значения и данные сторонних расширений.

Испытайте инструмент на копии и просмотрите отчёт по таблицам. Затем откройте несколько материалов с разными типами блоков. Если редактор перестал понимать структуру записи, восстановите копию и разберитесь с форматом, а не продолжайте замену на рабочей базе.

Не меняйте внешние ссылки и исторические цитаты только ради исчезновения строки http:// из поиска. Задача — исправить реально загружаемые небезопасные ресурсы и корректные адреса собственного сайта. Широкая замена без различения контекста создаёт лишние ошибки.

После успешной обработки сохраните отчёт и контрольную точку. Если позднее понадобится понять, откуда изменился адрес документа, будет известен момент и область операции.

Что добавить в проверку публикации

После сохранения новой статьи открывайте её обычной страницей и проверяйте изображения, видео и встроенные элементы. Вставка из старого документа может принести HTTP-адрес, даже если шаблон уже исправен.

Если редактор позволяет выбирать медиа из собственной библиотеки, предпочитайте этот способ ручному копированию абсолютных старых URL. Для внешних вставок используйте актуальный защищённый код сервиса.

Полезно включить проверку нескольких типовых материалов в приёмку обновления темы. Тогда проблема будет замечена до того, как одинаковый старый адрес распространится по десяткам страниц.

Частые вопросы

Почему браузер сам исправляет часть картинок?

Для некоторых типов смешанного контента браузеры используют автоматическое обновление до HTTPS. Это не означает, что исходная ссылка корректна или что все посетители и ресурсы будут обработаны одинаково. Лучше исправить адрес в источнике.

Считается ли ссылка на другой HTTP-сайт ошибкой mixed content?

Обычный переход по ссылке отличается от загрузки зависимости внутри HTTPS-страницы. Смотрите тип запроса и сообщение браузера, а не только наличие протокола в тексте.

Можно ли заменить http на //?

Ссылка без явной схемы наследует схему контекста, но это не универсальное решение. Для современных защищённых зависимостей понятнее явный HTTPS, а для собственных ресурсов — корректный относительный путь.

Почему после замены проблема осталась?

Проверьте кеш, сгенерированный CSS, srcset, service worker и источник JavaScript-запроса. Возможно, исправлено одно место, а ресурс подключается ещё из другого шаблона.

Нужно ли менять хостинг?

Обычно нет: причина находится в ссылках или настройках приложения. Смена площадки нужна только при реальном ограничении услуги, а не из-за самого факта старого HTTP-адреса.

Контрольный список

• Найдены конкретные запросы и страницы с ошибками.

• HTTPS-версии ресурсов проверены без обхода сертификата.

• Исправлен источник адреса в настройках, контенте или шаблоне.

• Перед массовой заменой сохранена и проверена копия базы.

• Проверены изображения, стили, скрипты, формы и API.

• Обновлены кеш и сгенерированные файлы.

• Повторены исходные сценарии и мобильный просмотр.

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

Команды в Windows

Многострочные команды с обратной косой чертой в этой статье рассчитаны на Bash в Linux и macOS. В PowerShell используйте curl.exe; простой пример в одну строку:

curl.exe -I https://example.com/

Подставьте свой домен. Заголовки главной страницы не показывают все смешанные ресурсы: ошибки отдельных изображений и скриптов проверяйте также во вкладках Console и Network браузера.