Skip to content

Всё для WordPress, веб-разработки — и не только

🔒 Как исправить смешанный контент в WordPress: 2 шага

🔒 Как исправить смешанный контент в WordPress: 2 шага

Вы поставили SSL-сертификат, настроили HTTPS, а браузер все равно показывает предупреждение «подключение не защищено». Знакомо?

Так выглядит ошибка смешанного контента. Сайт вроде бы работает, посетители не жалуются, но Google видит проблему и занижает позиции в выдаче. С 2018 года Chrome помечает страницы со смешанным контентом как небезопасные, и с каждым обновлением политика ужесточается.

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

💡 Быстрый обзор:

  • находим источник смешанного контента через Chrome DevTools или онлайн-инструменты
  • устанавливаем плагин (автоматический способ) либо правим.htaccess и базу данных (ручной способ)
  • проверяем результат и закрепляем HTTPS-редирект на будущее

Что такое смешанный контент и почему он опасен

Смешанный контент (Mixed Content), это ситуация, когда страница загружена по HTTPS, но отдельные элементы на ней, изображения, скрипты, стили, шрифты, подтягиваются по незащищенному протоколу HTTP.

Браузер видит это как дыру в безопасности. Злоумышленник может перехватить HTTP-запрос, подменить скрипт или картинку и получить доступ к данным пользователя. Поэтому Chrome, Firefox и Safari блокируют «активный» смешанный контент (скрипты, iframe) полностью, а «пассивный» (изображения, медиа), с предупреждением в адресной строке.

Типичная причина появления, переезд с HTTP на HTTPS. Старые ссылки в контенте, настройках темы, CSS-файлах и виджетах остаются с префиксом http://. WordPress не меняет их автоматически, отсюда и конфликт.

С 2020 года Google прямо заявляет: HTTPS, сигнал ранжирования. Страница со смешанным контентом теряет «зеленый замочек», а вместе с ним, доверие посетителей и позиции в SERP. Исправлять нужно сразу после установки SSL, не откладывая.

Шаг 1: Диагностика, находим источник проблемы

Прежде чем чинить, нужно понять, какие именно ресурсы грузятся по HTTP. Универсальный способ, Chrome DevTools.

Откройте сайт в Chrome, нажмите F12 (или Ctrl+Shift+I), перейдите на вкладку Console и обновите страницу. Каждая строка с предупреждением «Mixed Content» показывает точный URL проблемного файла.

Консоль Chrome DevTools с ошибками смешанного контента

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

Вкладка Security с перечнем небезопасных запросов

Если ошибок много и нужно получить полный список одним отчетом, на помощь приходят онлайн-инструменты.

Панель инструментов разработчика с фильтрацией ошибок безопасности

Jitbit SSL Checker, бесплатный онлайн-сканер. Вводите URL, получаете перечень всех HTTP-ресурсов на странице: картинки, скрипты, CSS, внешние вызовы. Бесплатная версия проверяет до 200 страниц.

Результат проверки SSL в сервисе Jitbit

Why No Padlock, еще один бесплатный сервис с детальным разбором: какие именно элементы не защищены, откуда они грузятся и какому типу контента принадлежат. Поддерживает проверку страниц с авторизацией.

Детальный отчет Why No Padlock о смешанном контенте на странице

HTTPS Checker, десктопная утилита для macOS, которая сканирует сайт локально и показывает ошибки после каждого изменения. Работает с лимитом 100 страниц, удобна при пошаговой отладке.

Когда список проблемных URL перед глазами, переходим к исправлению.

Шаг 2: Исправление, три рабочих метода

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

Метод 1: Really Simple Security, автоматическое решение

Really Simple Security (ранее Really Simple SSL), самый популярный SSL-плагин WordPress с 3 миллионами активных установок и рейтингом 4,9/5 на WordPress.org.

Страница плагина Really Simple Security в админке WordPress

Установите плагин через «Плагины → Добавить новый», активируйте и запустите мастер настройки. Плагин автоматически:

  • выставляет HTTPS в настройках WordPress (адрес сайта и домашний URL),
  • настраивает 301-редирект с HTTP на HTTPS,
  • подменяет HTTP-ссылки в контенте «на лету» через output-буфер,
  • проверяет сертификат и предупреждает об истечении срока.

После установки откройте сайт в режиме инкогнито и убедитесь, что замочек в адресной строке зеленый, а в DevTools → Console, ни одного Mixed Content Warning. Для подавляющего большинства сайтов этого достаточно.

Метод 2: SSL Insecure Content Fixer, гибкая настройка уровней

Если Really Simple Security не справился (например, часть контента грузится через сторонние API), подключайте SSL Insecure Content Fixer. Плагин имеет 100 000 активных установок, рейтинг 4,8/5 и предлагает пять уровней фильтрации:

Настройки уровней фильтрации плагина SSL Insecure Content Fixer
  • Simple, базовый уровень для новичков, фиксит ссылки в контенте и настройках;
  • Content, дополнительно проверяет текстовые виджеты и шорткоды;
  • Widgets, фокус на содержимом виджетов, включая кастомный HTML;
  • Capture, перехватывает всю страницу до рендеринга и заменяет каждый http:// на https://. Медленнее, но эффективнее;
  • Capture All, максимальный охват: скрипты, инлайн-стили, внешние вызовы. Самый ресурсоемкий режим.

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

Метод 3: Ручное исправление,.htaccess и база данных

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

Шаг A. Принудительный HTTPS-редирект в.htaccess. Добавьте в начало файла (перед # BEGIN WordPress):

1RewriteEngine On
2RewriteCond %{HTTPS} off
3RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Сохраните, проверьте, главная страница и все внутренние URL должны редиректиться на HTTPS. Перед правкой скачайте резервную копию.htaccess: одна опечатка ломает сайт.

Шаг Б. Замена HTTP-ссылок в базе данных. Старые URL внутри постов, мета-полей и настроек остались с http://. Менять их прямым SQL-запросом рискованно, сериализованные данные PHP ломаются. Используйте:

  • WP-CLI: wp search-replace 'http://example.com' 'https://example.com' --dry-run (сначала без --dry-run, чтобы увидеть количество замен);
  • плагин Better Search Replace, делает то же самое через админку с предпросмотром.

После замены очистите кеш браузера (Ctrl+Shift+Del), кеш плагина (WP Rocket, LiteSpeed) и проверьте сайт в режиме инкогнито.

Полезное видео по теме

Автор канала GoTechWizard показывает процесс исправления смешанного контента от диагностики до чистого HTTPS без единой строчки кода:

⁉️🤔 Частые вопросы

Почему после установки SSL сайт все равно показывает «не защищено»?

SSL-сертификат активирован на сервере, но часть контента грузится по HTTP. Сертификат покрывает соединение между браузером и сервером, а HTTP-ссылки внутри страницы идут мимо него. Браузер видит смесь протоколов и предупреждает пользователя. Главных причин три: старые ссылки на изображения в постах (вставлялись до установки SSL), жестко прописанные HTTP-URL в теме или плагинах, внешние ресурсы (шрифты Google, скрипты CDN), которые подгружаются по http:// вместо https://. Диагностируйте через DevTools → Console и действуйте по шагам из статьи.

Нужно ли покупать SSL-сертификат или хватит бесплатного?

Для подавляющего большинства сайтов бесплатного SSL от Lets Encrypt достаточно. Он признается всеми браузерами и поисковыми системами. Платные сертификаты (OV, EV) имеют смысл для интернет-магазинов, банков и сайтов с платежными формами: они требуют проверки компании и отображают название организации в адресной строке. Для блога, портфолио или корпоративного сайта Lets Encrypt, стандарт. Большинство хостингов (Timeweb, Beget, Hostinger) выдают его автоматически при создании сайта.

Можно ли исправить смешанный контент без плагинов и правки кода?

На некоторых хостингах, да. Cloudflare включает опцию Automatic HTTPS Rewrites в бесплатном тарифе: она на лету исправляет HTTP-ссылки на HTTPS для всего трафика, проходящего через CDN. Однако это полумера: проблема остается на уровне сервера, и при отключении Cloudflare ошибки возвращаются. Лучше устранить причину, заменить HTTP-ссылки в базе данных и настроить.htaccess-редирект. Тогда сайт будет чистым при любом способе доставки трафика.

SSL Insecure Content Fixer* или Really Simple Security, что выбрать?*

Зависит от задачи. Really Simple Security, решение «включил и забыл»: подходит для типового сайта на WordPress без сложных интеграций. SSL Insecure Content Fixer, инструмент с градацией уровней для тонкой настройки. Если после активации Really Simple Security ошибки остались (такое бывает при нестандартной структуре темы, кастомных эндпоинтах или плагинах с прямыми HTTP-вызовами), переходите на SSL Insecure Content Fixer и повышайте уровень фильтрации. Практика показывает: большинство кейсов закрывает первый плагин, оставшиеся, второй.

Безопасно ли использовать режим Capture All в SSL Insecure Content Fixer?

Capture All перехватывает и перезаписывает каждый байт страницы перед отправкой браузеру. Это надежно, но увеличивает нагрузку на процессор. На слабом хостинге или высоконагруженном сайте возможна задержка ответа на 100-300 мс. Кеширующие плагины (WP Rocket) нивелируют эффект: страница генерируется один раз и раздается из кеша. Перед включением Capture All убедитесь, что более мягкие уровни не решили проблему, и сделайте бэкап.

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

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

Закрепите результат: настройте автоматическую проверку SSL (UptimeRobot или мониторинг хостинга шлет уведомление за 30 дней до истечения сертификата) и возьмите за правило вставлять новые ссылки сразу с https://. Пара минут профилактики сейчас экономит часы отладки потом.