Google в 2025 году сообщил, что Chrome будет включать режим Always Use Secure Connections для публичных сайтов: для части пользователей с Enhanced Safe Browsing с апреля 2026 года, а для всех пользователей по плану - с Chrome 154 в октябре 2026 года. Для владельца сайта это не абстрактная браузерная новость, а повод заранее проверить SSL, редиректы, формы, CDN, старые ссылки и интеграции, которые могут незаметно вести пользователя через HTTP.
Если сайт уже открывается по HTTPS, это еще не означает, что риска нет. Предупреждение может появиться на старом посадочном URL, в ссылке из рассылки, на поддомене, в скачиваемом файле, в API-эндпоинте или на странице, где часть ресурсов остается на HTTP. Ниже - практический чек-лист для владельца сайта и команды поддержки.
Почему тема стала срочной
Раньше многие проблемы с HTTP были скрыты. Пользователь вводил адрес без протокола, попадал на HTTP, сервер быстро делал редирект на HTTPS, и визуально все выглядело нормально. Но первый небезопасный переход уже произошел: на этом этапе трафик может быть перехвачен или изменен, а пользователь не всегда успевает увидеть привычный знак Not secure.
Новый подход Chrome усиливает именно этот слабый участок. Браузер сначала пытается использовать HTTPS и предупреждает пользователя, если публичный сайт не поддерживает безопасное соединение. Это особенно важно для сайтов с заявками, оплатой, личными кабинетами, каталогами, CRM-интеграциями и служебными поддоменами: доверие пользователя ломается еще до того, как он увидит форму.
В июле 2026 года у бизнеса еще есть время спокойно проверить проект без аварийного режима. Лучше провести технический аудит сайта сейчас, чем в октябре разбираться, почему часть пользователей видит предупреждение Chrome, а рекламные переходы и заявки просели.
Кому это актуально
Проверка нужна не только сайтам, которые явно работают на HTTP. В зоне риска часто оказываются рабочие проекты, которые уже много лет развиваются без единой карты URL и поддоменов.
Актуально владельцам корпоративных сайтов, интернет-магазинов и сервисов, где есть формы заявок, корзина, личный кабинет, оплата, загрузка файлов, CRM или 1С-обмен. Отдельно стоит проверить старые сайты после переезда на новый хостинг, проекты после смены подрядчика, сайты на CMS с большим количеством модулей и страницы, которые давно не трогали, но они все еще получают трафик из поиска, рекламы или рассылок.
Проверка также нужна компаниям, где рядом с основным доменом живут поддомены: test, lk, crm, api, old, m, img, cdn, files. Даже если главный сайт открывается корректно, пользователь может попасть на небезопасный участок через старую ссылку, документ, QR-код, письмо или рекламный кабинет.
Какие риски закрывает
Первый риск - потеря доверия. Предупреждение браузера выглядит для пользователя серьезнее, чем обычная техническая ошибка. Человек не обязан понимать разницу между просроченным сертификатом, HTTP-страницей и временным редиректом: он видит, что браузер просит подтвердить переход, и может уйти к конкуренту.
Второй риск - потеря заявок. Форма может быть на HTTPS, но скрипт отправки, капча, файл политики, внешний виджет или endpoint старой CRM может оставаться на HTTP. В итоге заявка не отправляется, аналитика показывает посещение без конверсии, а команда спорит о рекламном канале вместо проверки технической цепочки.
Третий риск - аварийная доработка без подготовки. Когда проблема проявляется после обновления браузера или волны жалоб, подрядчику приходится одновременно чинить SSL, редиректы, mixed content, CDN, кеши и старые ссылки. Такой режим дороже и рискованнее, чем плановая поддержка сайта с резервной копией, тестовым контуром и контролем после изменений.
Четвертый риск - ложное чувство безопасности. Зеленый или нейтральный индикатор в адресной строке на главной странице не подтверждает, что весь проект готов. Нужно проверять не только главную, но и посадочные страницы, формы, файлы, изображения, JavaScript, iframe, API, карту сайта, canonical, OpenGraph и редиректы с www и без www.
Что проверить на сайте
Начните с карты входных точек. Соберите основные URL: главная, коммерческие страницы, формы заявок, блоговые статьи, страницы оплаты, личный кабинет, API для мобильного приложения, поддомены, старые посадочные из рекламы и ссылки из популярных писем. Для каждой точки проверьте, открывается ли она по HTTPS без предупреждений и ведет ли HTTP-версия на корректный HTTPS-адрес.
Проверьте сертификат. Важно не только наличие SSL, но и срок действия, цепочка сертификатов, SAN-имена, покрытие www и без www, поддомены, автопродление, поддержка актуальных версий TLS и отсутствие странных ошибок на мобильных устройствах. Если сертификат обновляется вручную, это уже операционный риск: в регламенте поддержки должно быть понятно, кто отвечает за продление и кто видит предупреждение заранее.
Проверьте редиректы. Типовая ошибка - длинная цепочка HTTP -> HTTPS -> www -> без www -> новая страница. Такая цепочка медленнее, сложнее для диагностики и хуже переживает изменения в браузерах, CDN и прокси. Нужен прямой, предсказуемый 301-редирект на финальный канонический URL.
Проверьте смешанный контент. На HTTPS-странице не должно оставаться изображений, скриптов, стилей, iframe, шрифтов и файлов, которые загружаются по HTTP. Особенно часто это встречается в старом контенте CMS, баннерах, виджетах, счетчиках, WYSIWYG-блоках, импортированных карточках товаров и давно созданных статьях.
Проверьте формы и интеграции. Заявка может выглядеть успешно отправленной, но падать на стороне старого API, CRM, почтового шлюза, антиспама или внутреннего обработчика. После исправления HTTPS нужно сделать контрольную отправку формы, проверить письмо менеджеру, запись в CRM, событие аналитики и сообщение пользователю на сайте.
Проверьте служебные файлы и SEO-сигналы. В sitemap, robots.txt, canonical, hreflang, OpenGraph, фидах, XML-выгрузках и ссылках на скачивание не должно быть старых HTTP-адресов. Для SEO это не только вопрос безопасности: поисковая система и пользователь должны видеть один устойчивый адрес страницы.
Для первичной самопроверки можно использовать браузер, DevTools, curl, SSL Labs, логи сервера и мониторинг. Если нужна быстрая поверхностная проверка доступности и TLS, полезен публичный инструмент Web-Puls: https://web-puls.ru/tools/check-site/. Но он не заменяет полный аудит CMS, форм, CDN и интеграций.
Как это решает OpenStart
OpenStart подходит к такой задаче как к технической диагностике, а не как к простой установке сертификата. Сначала мы фиксируем симптомы: где пользователь видит предупреждение, с какого устройства, из какой сети, по какой ссылке пришел, какая страница открывается и что происходит с заявкой.
Дальше проверяем цепочку: DNS, хостинг, веб-сервер, SSL/TLS, редиректы, CMS, CDN, прокси, внешние скрипты и обработчики форм. Если проект уже на поддержке, изменения проходят через резервную копию, план отката, согласованное окно и контроль после релиза. Такой процесс снижает риск, что при исправлении HTTPS сломается оплата, каталог, авторизация или интеграция с CRM.
Для владельца сайта это можно оформить как разовую диагностику или как часть регулярной поддержки. Если нужно быстро закрыть риск по SSL и редиректам, подойдет технический аудит. Если проблема связана с формами, CMS, API или старым кодом, лучше планировать доработку сайта с приоритетами. Связанные направления OpenStart: поддержка сайтов, техническая поддержка, доработка сайта, ускорение и PageSpeed, восстановление сайта.
Что запросить у подрядчика
Попросите не общий ответ "SSL установлен", а проверяемый результат. Подрядчик должен показать список проверенных URL, статус HTTP и HTTPS, финальные адреса после редиректов, срок сертификата, покрытие поддоменов, найденный mixed content и список исправлений.
Отдельно запросите проверку бизнес-сценариев: отправка формы, создание заказа, оплата, вход в личный кабинет, загрузка файла, переход из письма, переход из рекламы, работа мобильного приложения или API. Для каждого сценария нужен понятный статус: проверено, есть риск, нужно исправить, нужно согласовать с внешним сервисом.
Хороший результат работ - не только исправленный конфиг Nginx или Apache. Должен остаться короткий регламент: где продлевается сертификат, кто получает уведомления, как проверить проблему после жалобы пользователя, какие URL мониторятся, где лежит резервная копия конфигурации и как откатить изменение.
FAQ
Если сайт уже открывается по HTTPS, нужно ли что-то делать?
Да, стоит проверить весь путь пользователя. Главная страница может быть в порядке, а старые посадочные, поддомены, изображения, формы, API или файлы для скачивания все еще могут использовать HTTP.
Нужно ли срочно покупать новый SSL-сертификат?
Не обязательно. Сначала надо понять, есть ли проблема: срок сертификата, цепочка, поддомены, редиректы, mixed content и автопродление. Во многих случаях достаточно корректной настройки и регламента продления.
Что важнее: HTTPS или PageSpeed?
Это разные уровни риска. HTTPS отвечает за доверие и безопасность соединения, PageSpeed - за скорость и удобство. Но на практике они пересекаются: длинные редиректы, тяжелые внешние скрипты и ошибки CDN могут одновременно портить безопасность, скорость и конверсию.
Можно ли просто отключить HTTP на сервере?
Обычно нет. Нужно настроить корректный редирект на HTTPS, проверить старые ссылки, интеграции, sitemap, canonical и формы. Резкое отключение без проверки может сломать часть сценариев и усложнить диагностику.
Как понять, что проблема уже влияет на заявки?
Сравните жалобы пользователей, логи ошибок, события формы, CRM-записи, рекламные переходы и веб-аналитику. Если есть посещения без отправок формы, всплеск отказов на старых URL или жалобы на предупреждение браузера, нужна техническая проверка цепочки.
Для редактора
Trust goal: reduce_risk.
Проверить перед публикацией: актуальность плана Google по Chrome 147 и Chrome 154; формулировку о включении Always Use Secure Connections для публичных сайтов; доступность источников Google и Chromium; корректность ссылки на инструмент Web-Puls. Клиентские имена, отзывы, награды, кейсы и непроверенные показатели OpenStart не использовались.
Связанные маркетинговые задачи
- Подготовить PDF-чек-лист "HTTPS перед октябрем 2026": stream sales_materials, priority high, next_action собрать одностраничный список проверок для первичного контакта с клиентом.
- Добавить на страницу поддержки блок про SSL/TLS, редиректы и предупреждения браузеров: stream website_trust, priority medium, next_action подготовить короткий текст и список признаков риска.
- Сделать FAQ для отдела продаж по жалобам "Chrome пишет, что сайт небезопасен": stream sales_materials, priority medium, next_action собрать 5 вопросов, которые менеджер задает до передачи в разработку.
- Проверить внутреннюю перелинковку между статьями про SSL, восстановление и поддержку: stream seo, priority medium, next_action составить список страниц, куда добавить ссылки на новый материал.
- Подготовить короткий пост для блога или рассылки о проверке HTTPS без паники: stream blog, priority low, next_action адаптировать чек-лист в 5 тезисов.