Mixed content после перехода на HTTPS: где искать старые HTTP-ссылки

После перехода сайта на HTTPS браузер может всё равно показывать предупреждение о небезопасной странице. Частая причина — mixed content: сама страница открыта по HTTPS, но внутри есть ресурсы по HTTP. Это могут быть картинки, CSS, JavaScript, iframe, шрифты, видео или старые абсолютные ссылки в базе.

Mixed content нужно исправлять не только ради значка замка. HTTP-ресурсы могут блокироваться браузером и ломать внешний вид или функциональность страницы.

Проверить Console в браузере

Самый быстрый способ — открыть проблемную страницу, затем Console в DevTools. Браузер обычно прямо показывает, какой ресурс загружается по HTTP.

Mixed Content: The page at 'https://example.ru/' was loaded over HTTPS,
but requested an insecure image 'http://example.ru/uploads/banner.jpg'.

Нужно сохранить список таких URL и понять, откуда они формируются.

Найти HTTP-ссылки в HTML

Можно проверить исходный код страницы:

curl -s https://example.ru/ | grep -i "http://"

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

Изображения и контент из админки

В старых CMS абсолютные HTTP-ссылки часто остаются в текстах страниц, описаниях товаров и баннерах. После перехода на HTTPS они не исправляются автоматически.

<img src="http://example.ru/upload/image.jpg">

Лучше хранить относительные ссылки, если ресурс находится на том же домене:

<img src="/upload/image.jpg">

CSS и JavaScript

Если CSS или JS подключается по HTTP, браузер может заблокировать ресурс. Тогда ломается верстка или скрипты.

<link rel="stylesheet" href="http://example.ru/css/app.css">
<script src="http://example.ru/js/app.js"></script>

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

Внешние сервисы

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

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

Canonical, Open Graph и sitemap

После перехода на HTTPS нужно проверить не только ресурсы, но и SEO-ссылки.

curl -s https://example.ru/ | grep -Ei "canonical|og:url|http://"

Canonical, og:url и sitemap должны указывать на HTTPS-версии, если HTTPS является основным протоколом.

Редирект HTTP на HTTPS

Все HTTP-страницы должны редиректить на HTTPS. Для nginx:

server {
    listen 80;
    server_name example.ru www.example.ru;

    return 301 https://example.ru$request_uri;
}

После настройки нужно проверить цепочку:

curl -IL http://example.ru/page/

Cookies

После перехода на HTTPS стоит проверить secure-флаг для важных cookies. Особенно для авторизации и сессий.

Set-Cookie: PHPSESSID=...; path=/; secure; httponly

Поиск по базе

Если старых ссылок много, можно искать http://example.ru в базе. Делать массовую замену нужно только после бэкапа.

SELECT id, content
FROM pages
WHERE content LIKE '%http://example.ru%';

В некоторых CMS данные сериализованы. Простая SQL-замена может сломать сериализованные строки. Сначала нужно понять формат хранения.

Чек-лист

1. Открыть Console и выписать mixed content URL.
2. Проверить HTML через curl и grep.
3. Исправить HTTP-ссылки в шаблонах.
4. Исправить контент из админки.
5. Проверить внешние виджеты и скрипты.
6. Проверить canonical, og:url и sitemap.
7. Настроить 301 с HTTP на HTTPS.
8. Проверить cookies с secure-флагом.
9. Проверить страницы после очистки кэша.

Mixed content обычно остаётся после неполного перехода на HTTPS. Исправлять нужно не только видимые картинки, но и шаблоны, контент, SEO-теги, sitemap, редиректы и внешние скрипты.