Ви поставили 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 проблемного файлу.

Поруч, на вкладці Security, зібрано зведення: статус сертифіката, перелік небезпечних запитів і рекомендації щодо виправлення. Для швидкої оцінки ситуації цього достатньо.

Якщо помилок багато й потрібно отримати повний список одним звітом, на допомогу приходять онлайн-інструменти.

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

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.

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

• виставляє 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 і пропонує п’ять рівнів фільтрації:

• Simple, базовий рівень для новачків, виправляє посилання в контенті та налаштуваннях;
• Content, додатково перевіряє текстові віджети та шорткоди;
• Widgets, фокус на вмісті віджетів, включно з кастомним HTML;
• Capture, перехоплює всю сторінку до рендерингу та замінює кожен http:// на https://. Повільніше, але ефективніше;
• Capture All, максимальне охоплення: скрипти, інлайн-стилі, зовнішні виклики. Найбільш ресурсомісткий режим.

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

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

Якщо ви принципово проти зайвих плагінів або помилка поодинока, ось прямий шлях.

Крок A. Примусовий HTTPS-редирект у.htaccess. Додайте на початок файлу (перед # BEGIN WordPress):

1
RewriteEngine On
2
RewriteCond %{HTTPS} off
3
RewriteRule ^(.*)$ 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](/orig_post/8-best-wordpress-ssl-plugins-2022-free-amp-paid) чи 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://. Кілька хвилин профілактики зараз заощаджують години налагодження потім.