HTTPS на Тильде включается автоматически, как только домен подтверждён и DNS-записи настроены правильно, но на практике я регулярно вижу два сценария: сертификат не выпускается часами, или он выпущен, а браузер всё равно показывает «сайт не защищён» из-за кода на самой странице. Разбираю оба случая по порядку, с конкретными причинами и тем, что проверять в первую очередь.
Как Tilda выпускает SSL-сертификат
Tilda использует Let’s Encrypt и выпускает сертификат сама, без загрузки файлов вручную. Это отличает её от WordPress на своём хостинге, где сертификат часто приходится подключать через панель хостинг-провайдера или Cloudflare отдельно. На Тильде всё завязано на домен: как только вы привязываете его к проекту в настройках сайта и DNS-записи начинают указывать на серверы Tilda, система сама инициирует выпуск сертификата.
Проблема в сроках. Официально Tilda обещает активацию HTTPS в течение суток после корректной настройки DNS, но по моим наблюдениям на десятках проектов чаще всего сертификат появляется за 15-40 минут, если записи прописаны верно и TTL у старых записей не слишком большой. Если TTL был выставлен на 24-48 часов у прежнего провайдера, обновление может реально растянуться на этот срок, потому что браузеры и промежуточные DNS-серверы продолжают отдавать закешированный ответ.
Подключение домена и проверка, что сертификат реально выпустился
Последовательность стандартная: домен покупается у любого регистратора, в настройках сайта на Tilda он добавляется как основной, дальше нужно прописать либо A‑запись на IP Tilda, либо CNAME, в зависимости от того, корневой это домен или поддомен. Для корневого домена (example.ru) большинство регистраторов не позволяют поставить CNAME, поэтому используется A‑запись, а для www или произвольного поддомена (shop.example.ru) - CNAME на proxy.tilda.ws.
После того как записи прописаны, в панели Tilda в разделе «Домен» появляется статус подключения. Пока там не зелёная галочка, а «домен не подключен» или «идёт проверка», сертификат не выпустится вообще, и торопиться с диагностикой ошибок HTTPS в этот момент бессмысленно. Проверить фактическое распространение DNS можно через whatsmydns.net: если по разным точкам мира записи ещё расходятся, ждите, пока не станут одинаковыми хотя бы у 80% серверов.
Есть нюанс с поддоменами: если у вас на Tilda несколько проектов на поддоменах одного домена (например, blog.example.ru на Tilda, а сам example.ru на другом движке), сертификат для каждого поддомена Tilda выпускает отдельно и независимо от того, есть ли HTTPS на основном домене.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Почему браузер пишет «сайт не защищён», хотя сертификат активен
Это самая частая причина обращений именно с готовыми сайтами на Tilda, а не с только что подключенным доменом. Сертификат стоит, замочек в адресной строке вроде должен быть, но Chrome или Safari показывают предупреждение или перечёркнутый https. В 90% случаев на моей практике причина в миксконтенте: часть ресурсов на странице (скрипты, изображения, iframe) продолжает загружаться по http, хотя сама страница уже отдаётся по https.
Чаще всего это происходит в трёх местах:
- Кастомный код в Zero Block - формы, виджеты, скрипты аналитики, вставленные вручную и не обновлённые при переезде на новый домен
- Виджет эквайринга или доставки, вставленный по инструкции трёхлетней давности, где ссылка на скрипт ещё указывала на http
- Картинки и файлы, залитые не через файловый менеджер Tilda, а подключённые внешней ссылкой на сторонний http-хостинг
На практике я разбирал такую ошибку на интернет-магазине, где после переезда с поддомена на свой домен форма оплаты через Т‑Банк (Тинькофф) продолжала обращаться к старому скрипту эквайринга по http, и это блокировало не только замочек в браузере, но и саму отправку формы в некоторых версиях Chrome с включённой строгой политикой Mixed Content. Похожая история бывает с виджетами СДЭК: если код виджета вставлен через внешний блок и ссылка на js-файл начинается с http://, а не https://, браузер помечает это как небезопасный контент, даже если сам скрипт технически рабочий.
Разница между «активным сертификатом» и «полностью защищённым сайтом» в этом и заключается: Tilda отвечает за шифрование канала между сервером и браузером, а за то, что именно грузится внутри страницы, отвечает автор кастомного кода. Если такие правки нужно делать регулярно, разумнее не редактировать код руками при каждом переезде домена, а сразу заказать разработку и сопровождение кастомных скриптов для Tilda, чтобы интеграции с эквайрингом и службами доставки не ломались при смене адреса сайта.
Как найти незащищённые ресурсы через DevTools
Открываю страницу в Chrome, нажимаю F12, перехожу во вкладку Console и обновляю страницу с зажатым Ctrl (жёсткая перезагрузка без кеша). Если на странице есть миксконтент, в консоли появятся предупреждения вида «Mixed Content: The page was loaded over HTTPS, but requested an insecure resource». Там же указан конкретный URL ресурса, который грузится по http, - дальше остаётся найти этот адрес в коде блока Zero Block или в настройках подключённого стороннего скрипта и заменить http:// на https://.
Отдельно проверяю вкладку Security в DevTools: она показывает не просто факт наличия сертификата, а его валидность целиком - на какой домен выпущен, не истёк ли срок действия, нет ли ошибок цепочки доверия. На Tilda срок действия сертификата Let’s Encrypt - 90 дней, продление происходит автоматически, но если домен был отвязан и снова привязан, старый сертификат может повиснуть в кеше CDN на несколько часов, и тогда Security покажет «сертификат для другого домена» или «истёк».
Таблица: типичные причины ошибки и что с ними делать
| Причина | Как проявляется | Что делать |
|---|---|---|
| DNS ещё не распространился | Статус домена в Tilda «не подключен», сертификата нет вообще | Подождать до 24 часов, проверить записи через whatsmydns.net |
| Миксконтент от кастомного скрипта | Перечёркнутый замок, предупреждение в консоли Chrome | Найти http-ссылки в Zero Block и заменить на https |
| Старый кеш браузера или CDN | Сертификат валиден, но браузер показывает ошибку у части посетителей | Жёсткая перезагрузка страницы, проверка через отдельный чистый браузер или инкогнито |
| Внешние картинки со стороннего http-хостинга | Отдельные изображения не грузятся или помечены как небезопасные | Перезалить файлы через встроенный файловый менеджер Tilda |
| Поддомен подключён отдельно от основного домена | На blog.site.ru HTTPS есть, на site.ru нет или наоборот | Проверить статус сертификата отдельно для каждого поддомена в панели Tilda |
Пример: как выглядит проблемный код и его исправление
Вот типичная ситуация из практики - в Zero Block вставлен скрипт виджета доставки со старой ссылкой:
<script src="http://widget.example-delivery.ru/embed.js"></script>Исправление простое - меняется только протокол, но найти такую строку среди десятка вставленных за годы блоков вручную не всегда быстро:
<script src="https://widget.example-delivery.ru/embed.js"></script>Если виджет вообще не поддерживает https на своей стороне (бывает у совсем старых интеграций служб доставки), придётся либо искать альтернативный вариант подключения через API, либо переписывать интеграцию с нуля под текущий протокол.
Перенос домена на Tilda: на что смотреть отдельно
Когда домен переезжает с другого движка на Tilda, часто забывают про 301-редиректы со старых адресов страниц и про то, что старый сертификат у прежнего хостинга нужно отвязать, иначе браузер может закешировать предыдущий сертификат через HSTS. Если на старом сайте был включён HSTS-заголовок с длинным max-age, браузер какое-то время будет требовать https даже раньше, чем Tilda успеет выпустить свой сертификат, и тогда пользователь увидит не «сайт не защищён», а полную блокировку загрузки страницы.
В таких случаях помогает временно снизить max-age у HSTS на старом сервере перед переездом или воспользоваться сервисом hstspreload.org, чтобы проверить, не попал ли домен в предзагруженный список Chrome - если попал, откатить это быстро не получится, и миграцию нужно планировать заранее, за несколько дней до смены DNS.
От лендинга до интернет-магазина
Сайт / Tilda
от 30 000 ₽
Подробнее →Частые вопросы
Сколько времени занимает выпуск SSL-сертификата на Тильде после подключения домена
Обычно от 15 минут до нескольких часов при корректно настроенных DNS-записях. Если у предыдущего провайдера домена был выставлен большой TTL, процесс может растянуться до 24 часов из-за кеширования записей на промежуточных серверах.
Почему на Tilda нельзя загрузить свой собственный SSL-сертификат
Tilda работает как облачная платформа с единой инфраструктурой Let’s Encrypt для всех проектов и не даёт доступа к серверу для ручной установки сторонних сертификатов. Это ограничение по архитектуре сервиса, а не временная недоработка.
Что делать, если сертификат выпущен, а сайт всё равно показывает «не защищено» у части посетителей
Чаще всего это кеш браузера или CDN на стороне пользователя. Проверьте сайт в режиме инкогнито и на мобильном интернете без Wi-Fi - если там ошибки нет, проблема временная и снимется сама в течение суток по мере обновления кеша у провайдеров.
Может ли ошибка HTTPS быть связана не с самим сертификатом, а с кастомным кодом на странице
Да, и это самая частая причина на уже работающих сайтах. Проверяйте консоль браузера на предупреждения о Mixed Content - обычно проблема в скриптах эквайринга, доставки или сторонних виджетах, вставленных через http вместо https.