Start here if your site is old
This is the one that catches people, and almost nobody checks it.
Squarespace sites connected before October 2016 may still be in "Insecure" mode, serving your site over plain HTTP. The certificate is not missing. The site is simply not set to use it.
If your site predates late 2016, or you inherited it and do not know its history, check the SSL setting in your Squarespace security settings first. If it is set to Insecure, switching it to a secure setting is your entire fix, and it is a genuine finding worth closing today. Everything after this section assumes you have already looked.
How SSL works on Squarespace
You do not buy, install or renew anything. Squarespace handles all of it.
The certificate costs nothing and is included. There is no SSL upsell to fall for.
It is provisioned for you when your domain connects, and renewed automatically. There is no expiry date for you to diarise.
Squarespace uses Let's Encrypt. This matters if you publish CAA records, because a CAA record that does not permit Let's Encrypt will block issuance.
You cannot bring your own certificate to Squarespace. If you have one you paid for, it has no home here. That is a hard limit, not a plan gate.
If the certificate has not appeared yet
Provisioning can take up to 48 hours after you connect a domain. Browser warnings during that window are normal and not a sign anything is broken.
Before you raise a ticket, check the obvious things:
- →Give it the full 48 hours. Most certificates arrive much sooner, but the window is real. Reconnecting the domain repeatedly does not speed it up.
- →Check your DNS actually points at Squarespace. A certificate cannot be issued for a domain that does not resolve to the site.
- →Check your CAA records if you have any. A CAA record that omits letsencrypt.org will stop issuance dead. Most domains have no CAA records at all, and that is fine.
Mixed content: the padlock is there, but broken
A different failure, and a common one. Your certificate is valid, but the padlock is missing or marked as not fully secure. That is mixed content: your HTTPS page is loading something over plain HTTP.
On Squarespace the culprit is almost always something you added by hand, because Squarespace serves its own assets over HTTPS. Look at:
- →Code Injection and code blocks. Any script, stylesheet or iframe pointing at an http:// address. Change it to https://.
- →Embedded images hotlinked from elsewhere. An image pulled from an http:// URL on another site will break the padlock. Upload it to your site instead.
- →Third-party embeds and widgets. Older widget snippets sometimes still use http://. If the provider does not offer HTTPS in 2026, that is a reason to replace the provider.
- →Protocol-relative URLs (//example.com). These are a legacy pattern and no longer recommended. Write the full https:// URL.
Do things in the right order
This order matters on every platform, and getting it wrong is how people lock themselves out of their own site.
Certificate first. Then force HTTPS. Then HSTS.
Get the certificate working. Confirm every page loads cleanly over HTTPS with no mixed content. Only then think about HSTS, which tells browsers to refuse HTTP for your domain entirely. Turn on HSTS while something is still broken and you have made the breakage sticky.
On Squarespace this is mostly academic, because Squarespace already sends HSTS for you with a max-age of 180 days at the time of writing, and you cannot change it. That is not a bad thing. Just be aware it means the HTTPS side needs to genuinely work. Our HSTS explainer covers what that header is doing.
One warning while we are here: do not casually chase HSTS preload. Getting on the preload list requires a year-long max-age, includeSubDomains, the preload directive, a valid certificate, an HTTP to HTTPS redirect on the same host, and every subdomain on HTTPS. Inclusion cannot easily be undone, and removal takes months to reach users through a Chrome update. It is not a checkbox to tick for a scanner score.
What we would actually do
Check the Insecure-mode setting if your site is old. Give a new domain the full 48 hours. Then hunt mixed content in your own Code Injection and embeds, because that is where it always is.
Once HTTPS is solid, move on to the things Squarespace does not do for you: your SPF record and DMARC record.
Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.
Run a free checkFrequently asked questions
Do I have to pay for SSL on Squarespace?
No. The certificate is free, included on every plan, provisioned automatically when your domain connects, and renewed automatically. There is nothing to buy and no renewal date to track.
Can I install my own SSL certificate on Squarespace?
No. Squarespace does not support third-party certificates. If you already bought one, it cannot be used here. This is a platform limit rather than something a higher plan unlocks.
My site says not secure but Squarespace says SSL is on. Why?
Two likely causes. If your site was connected before October 2016 it may still be in Insecure mode, serving HTTP despite the certificate existing. Otherwise it is mixed content: something on the page is loading over http://, usually a script, embed or hotlinked image you added by hand.
How long does the certificate take to appear?
Up to 48 hours after connecting your domain. Warnings during that window are expected. If it is still failing afterwards, check that your DNS points at Squarespace and that any CAA records permit Let's Encrypt, which is the certificate authority Squarespace uses.
Should I turn on HSTS preload?
Not casually. Preload requires a max-age of at least a year plus includeSubDomains and preload, a valid certificate, an HTTP to HTTPS redirect on the same host, and every subdomain on HTTPS. Inclusion cannot easily be undone and removal takes months to reach users. Squarespace already sends HSTS with a 180-day max-age at the time of writing, which covers the practical benefit.