HTTPS is default; mixed content is the self-inflicted wound

StaticHost provides HTTPS on preview hostnames immediately—no DNS required for that certificate path. For your custom domain, HTTPS arrives after DNS verifies and the certificate issues. In both cases you are not shopping for a separate “SSL product,” and you are not configuring cPanel AutoSSL. You can still break the padlock experience with mixed content: an HTTPS page that loads active or important assets over plain http://.

This guide focuses on how TLS shows up on StaticHost and how to keep pages clean once they are encrypted.

Two certificate moments

Preview. Deploy a site; open the preview URL with https://. TLS is already there. Use this for QA, client reviews, and CORS allowlisting during development.

Custom domain. Add the domain, create DNS records, wait for verification, wait for certificate issuance—detailed in static hosting with a custom domain. Until issuance completes, do not market the custom URL as secure.

There is no forever-free hosting tier; TLS is part of paid plans after a short trial (~1 day), not a separate SKU. Plans remain Starter $9 (1×2 GB), Pro $30 (3×10 GB + staging), Scale $65 (10×30 GB), Business $130 (30×100 GB + teams).

What mixed content looks like

View source or the browser console on an HTTPS page:

<script src="http://cdn.example.com/old.js"></script>
<img src="http://images.example.com/hero.jpg" alt="" />

Browsers block active mixed content (scripts, many modules) and may warn on passive content (images). Users see broken interactivity or half-styled pages that “worked on HTTP localhost.”

Fix patterns

  1. Relative URLs for your own assets: src="/assets/app.js" stays on the current scheme/host.
  2. Explicit HTTPS for third parties: https://cdn….
  3. Protocol-relative (//cdn…) is legacy; prefer explicit HTTPS.
  4. Rebuild static generators after fixing templates—old http:// in Markdown or theme configs regenerates dirty HTML.
  5. Search the output before upload:
grep -R "http://" dist _site public build out 2>/dev/null | head

Ignore intentional non-browser cases if any; treat browser-loaded assets as must-HTTPS.

HSTS and redirects

Once the custom domain certificate is stable, you may want HSTS via whatever controls the product exposes or via a CDN you place yourself. StaticHost does not include a full built-in CDN product; do not assume edge header theater. Get basic HTTPS right first.

SPAs and TLS

HTTPS does not change routing. History-mode deep links still 404 under try_files $uri $uri/ =404. Secure empty responses are still empty—SPA guide.

Service workers registered on HTTPS can cache aggressively; version them so a secure origin does not pin a broken deploy forever.

Third-party embeds

Maps, videos, fonts, analytics: all need HTTPS endpoints. Fonts loaded over HTTP are a classic padlock breaker. Prefer self-hosting fonts as static files on StaticHost when vendors make HTTPS awkward.

Operational checklist

  • [ ] Preview is HTTPS and clean in console.
  • [ ] Custom DNS verified; cert issued.
  • [ ] Grep output for http:// assets.
  • [ ] CORS allowlist includes https://your-domain.
  • [ ] Generator baseURL/site/url uses https://.
  • [ ] Rollback plan ready if a “quick content edit” reintroduces HTTP asset links.

No email, cPanel, or WordPress TLS panels here—those belong on other hosts if you need them.

Worked example: cleaning a Hugo theme after HTTPS cutover

You pointed docs.example.com at StaticHost. Verification succeeded; the certificate issued. The padlock still complains.

hugo --minify
grep -R "http://" public | head -50

Findings: theme footer hard-coded http://cdn.example.com/legacy.js; Markdown image http://…/diagram.png; baseURL still http://docs.example.com/.

Fixes:

  1. Set baseURL = "https://docs.example.com/" in hugo.toml.
  2. Replace footer script with https:// or drop the legacy tag.
  3. Fix Markdown images to HTTPS or copy diagrams into static/ and use site-relative paths.
  4. Rebuild locally—StaticHost will not run Hugo.
  5. Deploy; confirm console clean on HTTPS preview and on the custom domain.
  6. If a bad fix ships, roll back from deploy history, then iterate.

Order stays sacred: preview HTTPS first (already true), then DNS, then cert, then mixed-content hygiene on the real hostname.

Failure table: TLS and padlock issues

SymptomLikely causeFix
Custom domain HTTP onlyCert not issued yetFinish DNS verify; wait for issuance
Padlock broken; scripts blockedActive mixed contentUpgrade script src to HTTPS
Images warnPassive mixed contentHTTPS or relative images
www insecure; apex finewww hostname not verifiedAdd/verify www; wait for its cert
SW serves ancient HTTP-era assetsService worker cacheUnregister/bump version
“Free SSL” expected without planForever-free assumptionTrial ~1 day; then paid plans
API cookies weird across schemesMixed HTTP/HTTPS originsStandardize on HTTPS URLs

Extra procedure: pre-launch TLS gate

  1. Open HTTPS preview; DevTools console must show no mixed content.
  2. Run the grep -R "http://" pass on the exact artifact you will upload.
  3. Confirm generator canonical URLs are https://.
  4. Complete custom domain DNS → verification → certificate.
  5. Retest console on the custom hostname (not only preview).
  6. Hit one deep link if you have an SPA—TLS will not invent fallback files.
  7. Document that StaticHost includes certs with hosting, not as a separate forever-free SSL SKU, and does not include email or a CDN product.

Related: custom domain, fast static (TLS is not your LCP problem—hero weight is).

CORS, cookies, and the HTTPS origin switch

Moving from HTTP localhost or an old HTTP site to HTTPS on StaticHost changes the origin browsers enforce. Absolute API URLs must use https://. Cookie Secure attributes suddenly matter. If your SPA stored tokens while you developed against mixed environments, clear site data on the custom domain after cutover so stale cookies do not create “TLS works but login loops” mysteries.

When allowlisting CORS, include both the HTTPS preview origin (for QA) and the final custom HTTPS origin. Forgetting the preview origin wastes hours during client review; forgetting production breaks launch day. None of this is fixed by a higher plan tier—Starter through Business include the same certificate story after DNS verifies. If a third-party widget vendor only offers HTTP embed codes, replace the vendor or self-host the asset; do not ship mixed content and hope. Roll back content deploys that reintroduce http:// script tags even if “the cert is fine.”

FAQ

Is SSL really free on StaticHost?

Certificate issuance for previews and verified custom domains is included with hosting—not a separate upsell. Hosting itself is paid after the short trial.

Can I bring my own certificate file?

Follow the product UI; most users rely on managed issuance after DNS verify. Do not invent ACME steps the dashboard does not show.

Why does the apex work on HTTPS but www fails?

www may be unverified or without its own cert. Add and verify both hostnames you use.

Does HTTPS make my API keys safe in frontend JS?

No. TLS protects transit; it does not hide JS from the user. Use publishable keys only.

Will Let’s Encrypt rate limits affect me?

Managed issuance handles renewals; unusual mass domain experiments can still hit provider limits—add domains you actually need.