Помилки SSL і змішаного контенту часто виникають після перенесення сайту, зміни хостингу, встановлення нового сертифіката або оновлення WordPress. У результаті браузер може показувати попередження про небезпечне з’єднання, блокувати частину ресурсів або позначати сторінку як незахищену. Для власника бізнесу це означає не лише втрату довіри відвідувачів, а й можливі проблеми з формами, оплатою, авторизацією та SEO.
Безпечне виправлення починається з діагностики. Не варто одразу масово змінювати записи в базі даних чи видаляти налаштування сервера: помилка в таких діях може призвести до втрати даних або непрацездатності сайту. Перед змінами зробіть резервну копію файлів і бази даних та переконайтеся, що її можна відновити.
Сертифікат і строк дії
Спочатку перевірте, чи сертифікат SSL встановлений саме для потрібного домену та його варіантів: з www і без нього. Браузер може показувати помилку, якщо сертифікат випущений для іншого домену, завершився його строк дії або не передається повний ланцюжок сертифікації.
- відкрийте сайт у браузері та перегляньте деталі сертифіката;
- перевірте дату початку і завершення його дії;
- переконайтеся, що домен у сертифікаті відповідає адресу сайту;
- перевірте налаштування автоматичного продовження сертифіката;
- з’ясуйте, чи не використовується окремий проксі або CDN із власним SSL.
Якщо сертифікат начебто чинний, але браузер повідомляє про небезпеку, причина може бути на рівні сервера: неправильний ланцюжок довіри, помилкова конфігурація вебсервера або невідповідність між доменом і встановленим сертифікатом. У такій ситуації краще не перевстановлювати сертифікати навмання, а спочатку перевірити конфігурацію хостингу.
HTTP-посилання в базі
Змішаний контент з’являється, коли сама сторінка відкривається через HTTPS, але окремі ресурси завантажуються через HTTP. Це можуть бути зображення, таблиці стилів, JavaScript-файли, шрифти, відео, посилання в меню або адреси, збережені в налаштуваннях плагінів.
У WordPress частина таких адрес зберігається в базі даних. Зазвичай потрібно перевірити значення siteurl і home, а також контент записів, налаштування теми, віджети та параметри плагінів. Перед масовою заміною http:// на https:// обов’язково створіть резервну копію бази даних.
Безпечніше використовувати інструмент, який враховує серіалізовані дані WordPress. Пряма заміна через SQL може пошкодити структуру серіалізованих значень і спричинити нові помилки. Окремо перевірте зовнішні ресурси: якщо сторонній скрипт доступний лише через HTTP, браузер може блокувати його навіть після виправлення внутрішніх адрес.
Також зверніть увагу на жорстко прописані URL у файлах теми та плагінів. Якщо адреса містить HTTP у шаблоні, CSS або JavaScript, зміна даних у базі не вирішить проблему. У цьому випадку потрібно оновити код або налаштування відповідного компонента, попередньо перевіривши сумісність змін.
Редирект на HTTPS
Після встановлення сертифіката всі варіанти сайту мають коректно вести на HTTPS. Наприклад, адреси http://example.com і http://www.example.com повинні перенаправлятися на узгоджену HTTPS-версію. Якщо редиректи налаштовані суперечливо, можуть виникати цикли перенаправлення, помилки 301/302 або недоступність адміністративної панелі.
- Визначте основну адресу сайту — з
wwwчи без нього. - Перевірте адресу WordPress у розділі загальних налаштувань або через конфігурацію, якщо панель недоступна.
- Переконайтеся, що сервер має лише один логічний маршрут перенаправлення до HTTPS.
- Перевірте правила у файлі
.htaccess, конфігурації Nginx або панелі хостингу. - Очистіть кеш після внесення змін і повторіть перевірку в приватному вікні браузера.
Обережність особливо потрібна під час редагування .htaccess або конфігурації вебсервера. Синтаксична помилка може зробити сайт недоступним. Перед редагуванням збережіть копію файлу, а якщо немає доступу до серверних налаштувань — зверніться до хостинг-провайдера або фахівця.
CDN і кеш
Навіть після виправлення сертифіката та URL проблема може залишатися через CDN, серверний кеш або кеш браузера. CDN може використовувати окремий режим SSL, кешувати стару HTTP-версію файлів або звертатися до сервера за неправильним протоколом.
- перевірте режим шифрування між CDN і сервером;
- переконайтеся, що SSL-сертифікат активний і на стороні CDN, якщо це необхідно;
- очистіть кеш CDN, плагіна кешування та хостингу;
- перевірте, чи не закешовані старі редиректи або HTML-файли;
- тимчасово порівняйте роботу сайту через CDN і без нього, якщо така можливість доступна.
Не змінюйте режим SSL у CDN без розуміння схеми підключення. Наприклад, режим, за якого CDN підключається до сервера через HTTP, може створити додаткові ризики або спричинити змішаний контент. Після очищення кешу перевіряйте не лише головну сторінку, а й адміністративну панель, форми, кошик та інші критичні функції.
Якщо сайт регулярно потребує перевірки сертифікатів, кешу, оновлень і конфігурації, доречно організувати Технічна підтримка сайту WordPress для бізнесу, щоб зменшити ризик повторних збоїв.
Перевірка сторінок
Після виправлень перевірте сайт у кількох браузерах і на різних типах пристроїв. У консолі розробника браузера відкрийте вкладку безпеки або Console та знайдіть повідомлення про Mixed Content. Вони зазвичай містять точну адресу ресурсу, який завантажується через HTTP.
- перевірте головну сторінку, ключові посадкові сторінки та записи;
- відкрийте сторінки з формами, авторизацією та оплатою;
- перевірте зображення, шрифти, стилі, скрипти та вбудовані відео;
- переконайтеся, що немає циклічних редиректів і помилок сертифіката;
- перевірте мобільну версію та роботу сайту після очищення кешу;
- перегляньте журнали сервера, якщо окремі ресурси все ще не завантажуються.
Якщо після цих дій частина сторінок залишається недоступною, не працюють форми або WordPress втратив доступ до адміністративної панелі, проблема може бути пов’язана не лише зі змішаним контентом. Причиною здатні бути конфлікт плагінів, помилки прав доступу, неправильна конфігурація проксі чи пошкоджені дані. У такому випадку потрібна технічна діагностика з резервною копією та перевіркою змін у контрольованій послідовності.