Смешанный контент после перехода на HTTPS: как найти HTTP-ресурсы и убрать предупреждения

Коротко: что сделать сразу

1. Откройте проблемную страницу по https:// и нажмите F12 → «Console/Консоль».
2. Найдите сообщения Mixed Content и выпишите адреса ресурсов, которые начинаются с http://.
3. Проверьте, открывается ли каждый такой ресурс по https://.
4. Замените источник ссылки: в HTML/CSS, настройках CMS или базе, а не только через редирект.
5. Очистите кэш сайта и снова проверьте страницу в приватном окне.

Что браузер считает смешанным контентом

Страница https://example.ru может ссылаться на картинку http://example.ru/photo.jpg или на скрипт http://cdn.example.ru/app.js. Для пользователя это выглядит как один сайт, но технически браузер получает часть данных по защищённому каналу, а часть — по незашифрованному.

Риск разный. Изображение обычно менее опасно, чем JavaScript, который способен менять содержимое страницы. Поэтому современные браузеры особенно жёстко блокируют активный смешанный контент. Не ориентируйтесь только на значок замка: проверяйте консоль и Network, если после перехода на HTTPS что-то ведёт себя странно.

Как быстро найти виновника через инструменты браузера

В Chrome и Edge откройте страницу, нажмите F12 и перейдите на вкладку Console. В Firefox раздел называется примерно так же. Названия пунктов и расположение кнопок могут отличаться между версиями браузера, но смысл один: сообщения безопасности показывают исходный URL проблемного ресурса.

Если консоль говорит, что HTTPS-страница запросила небезопасный ресурс, скопируйте именно его адрес. Затем откройте вкладку Network, перезагрузите страницу и посмотрите, откуда ресурс вызывается и какой ответ получает. Так можно отличить три ситуации: ссылка жёстко записана как HTTP; сервер ресурса не поддерживает HTTPS; ресурс уже недоступен и его нужно заменить.

Не редактируйте сразу все вхождения «http» по проекту. В коде могут быть внешние ссылки, документация и данные, которые не являются загружаемыми ресурсами страницы.

Если сайт состоит из обычных HTML, CSS и JavaScript

Ищите точный адрес из консоли в файлах проекта. Для собственных ресурсов обычно удобнее относительный путь, если файл находится на том же домене. Для внешнего ресурса используйте https:// только после проверки, что поставщик действительно поддерживает HTTPS.

Особое внимание уделите CSS: фоновые изображения, шрифты и файлы через url(...) часто забывают при миграции. Ещё один источник — inline-стили и скрипты, а также старые шаблоны, которые собирают полный адрес из настройки сайта.

Перед правкой .htaccess, config.php и файлов шаблона сделайте копию. Если после изменения сайт отдаёт 500, верните предыдущую версию и посмотрите журнал PHP или веб-сервера. Не ставьте права 777 — это не имеет отношения к смешанному контенту.

Если HTTP-ссылки лежат в CMS или базе данных

В WordPress, самописной CMS и интернет-магазинах старый адрес сайта часто сохраняется в настройках и содержимом базы. Сначала проверьте базовый URL сайта в панели управления. Затем ищите конкретный http://домен в контенте.

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

Если сайт на shared-хостинге, названия разделов различаются: база может открываться через phpMyAdmin, файловый менеджер — через отдельный раздел, а SSL — через «Домены», «Сертификаты» или «HTTPS». В cPanel и ISPmanager интерфейс отличается, поэтому ориентируйтесь на назначение раздела.

Почему редирект HTTP → HTTPS не всегда решает проблему

Редирект хорошо переводит посетителя с http://example.ru на https://example.ru. Но браузер может заблокировать небезопасный скрипт до того, как безопасно воспользуется перенаправлением. Поэтому правильное решение — изменить ссылку в исходном месте, а редирект оставить для старых внешних адресов.

Если переход на HTTPS совпал со сменой хостинга или DNS, не меняйте всё одновременно. DNS-записи кэшируются, и разные пользователи некоторое время могут попадать на разные серверы. В зависимости от TTL и кэшей обновление может занять до 24–48 часов.

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

Не забудьте про формы, iframe и внешние виджеты

Форма может визуально выглядеть нормально, но отправлять данные на http://-адрес. Это особенно критично для имени, телефона, e-mail и других персональных данных. Проверьте action формы и сетевые запросы при отправке тестовой заявки.

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

Как понять, что проблема решена

• Console после полной перезагрузки страницы не содержит сообщений Mixed Content.
• Во вкладке Network нет запросов ресурсов по http:// с HTTPS-страницы.
• Стили, скрипты, изображения, шрифты и формы работают после очистки кэша.
• Страница одинаково работает в нескольких актуальных браузерах.
• Проверены не только главная, но и старые статьи, карточки и другие шаблоны.

Когда лучше остановиться и не экспериментировать

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

Сначала сохраните файлы и базу, затем составьте список конкретных проблемных URL. Исправление смешанного контента, SSL и миграцию сайта можно поручить CompMaster / Remote Help.

Вывод

Смешанный контент лечится не отключением защиты, а поиском конкретного HTTP-ресурса и исправлением его источника. Безопасный порядок: резервная копия, точечная замена, очистка кэшей и проверка разных типов страниц.