HSTS looks simple: send one header, force HTTPS, move on. In e-commerce, especially on Shopify, that simplicity is deceptive.

I’ve seen teams assume HSTS is “handled by the platform,” then get burned by custom domains, broken subdomains, mixed redirect chains, or a preload decision they couldn’t easily undo. Shopify removes a lot of infrastructure pain, but it doesn’t remove responsibility. You still own the domain, the DNS, any subdomains, third-party assets, and the customer experience when HTTPS behavior goes sideways.

Here are the most common HSTS mistakes I see on Shopify and e-commerce setups, and how I’d fix them.

Mistake #1: Assuming Shopify covers every hostname you use

Shopify usually serves your storefront over HTTPS just fine. That does not mean every hostname under your brand is protected correctly.

Typical examples:

  • www.example.com points to Shopify
  • example.com redirects to www
  • blog.example.com runs somewhere else
  • help.example.com is on a SaaS platform
  • checkout.example.com or campaign subdomains exist from old systems

If you enable HSTS with includeSubDomains, every HTTPS-capable subdomain must be ready. If one subdomain still has weak TLS, a certificate mismatch, or doesn’t support HTTPS at all, users can get hard failures.

A basic HSTS header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Fix

Inventory every hostname before treating HSTS like a global switch.

I’d check:

  • apex domain
  • www
  • support/help center
  • blog/content subdomains
  • image/CDN hostnames you control
  • old marketing subdomains still resolving in DNS

If you want a quick read on your live headers, run a scan at headertest.com.

For Shopify stores, this usually means separating what Shopify manages from what your wider brand ecosystem still owns.

Mistake #2: Turning on includeSubDomains too early

This is the classic e-commerce footgun.

includeSubDomains is great when your domain estate is clean. It’s painful when you forgot an old ESP landing page on offers.example.com that only works over HTTP or has a stale cert.

Once a browser has cached this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

it will refuse HTTP for that subdomain. No warning, no fallback. Just failure.

Fix

Roll out HSTS in phases.

Start with a short max-age and without includeSubDomains:

Strict-Transport-Security: max-age=300

Then increase it:

Strict-Transport-Security: max-age=86400

Then:

Strict-Transport-Security: max-age=31536000

Only after validating subdomains should you add:

Strict-Transport-Security: max-age=31536000; includeSubDomains

That sequence gives you room to back out before clients cache the policy for months.

Mistake #3: Preloading before your domain is actually ready

A lot of teams treat HSTS preload like a badge of honor. Sometimes it is. Sometimes it’s a trap.

Preloading means browsers ship with your domain hardcoded as HTTPS-only. That’s great for first-visit protection. It’s terrible if you later discover some forgotten subdomain or vendor integration can’t meet the preload requirements.

Preload generally requires:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

And not just on one route. Your domain needs to consistently satisfy the preload rules. The official details live in the Chromium documentation: https://chromium.org/hsts/

Fix

Don’t preload just because you can.

For a Shopify store, I’d only consider preload when:

  • all active subdomains are known
  • every subdomain supports valid HTTPS
  • redirect behavior is clean
  • there’s no dependency on HTTP-only legacy endpoints
  • ops and marketing both confirm there are no surprise DNS entries

If your organization is messy with subdomains, preload is risky. Be honest about that.

Mistake #4: Sending HSTS only on some responses

HSTS is only honored when delivered over HTTPS, and browsers refresh the timer when they see it again. If your header appears only on the homepage but not on product pages, collection pages, blog pages, or custom app routes, your policy becomes inconsistent.

This can happen when:

  • a reverse proxy injects headers only for certain paths
  • a help center or blog is hosted separately
  • app proxies bypass your normal header setup
  • redirects terminate on infrastructure you don’t control

Fix

Make sure the final HTTPS response consistently includes Strict-Transport-Security.

For non-Shopify services in your stack, check your edge config. Example Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

The always matters. Without it, some responses won’t include the header.

On platforms where you can’t directly control headers for every route, verify behavior route by route instead of assuming. Test:

  • homepage
  • product detail pages
  • cart
  • account pages
  • blog pages
  • 404 pages
  • redirects from apex to www

Mistake #5: Forgetting that redirects still matter

HSTS doesn’t replace proper redirects. It reduces future HTTP exposure after the browser learns the rule.

For a first-time visitor, this chain still matters:

http://example.com -> 301 -> https://www.example.com

Bad e-commerce setups often have ugly redirect paths like:

http://example.com
-> 302 http://www.example.com
-> 301 https://www.example.com
-> 302 https://www.example.com/en

That’s slower, messier, and increases the chance of mistakes.

Fix

Clean up the redirect chain so HTTP goes straight to the canonical HTTPS URL in one hop where possible.

Preferred pattern:

http://example.com -> 301 -> https://www.example.com

Then serve HSTS on the HTTPS destination:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Shopify handles a lot of canonicalization, but your DNS, domain forwarding, and any fronting CDN can still introduce junk redirects.

Mistake #6: Ignoring third-party subdomain hosting

This one hits e-commerce teams constantly. You don’t just have a storefront. You have reviews, support, localization, returns, personalization, and campaign tooling.

Sometimes those tools live on your subdomains. That means your HSTS policy affects them.

Examples:

  • returns.example.com
  • support.example.com
  • de.example.com
  • vip.example.com

If a vendor-managed subdomain has broken TLS, expired certs, or weird redirect handling, your HSTS rollout will surface it immediately.

Fix

Treat vendor-hosted subdomains as part of your security boundary.

Before enabling includeSubDomains, verify:

  • valid certificates
  • modern TLS support
  • HTTPS redirects from any HTTP endpoint
  • no mixed hostname confusion
  • no dependency on insecure embedded resources

If a vendor can’t support HTTPS properly on your subdomain, don’t pretend HSTS will fix that. It won’t.

Mistake #7: Trying to “remove HSTS” like a normal config change

This is where people underestimate browser caching.

If you’ve served:

Strict-Transport-Security: max-age=31536000

clients may remember it for a year. You can’t just remove the header and expect instant recovery.

The usual way to disable HSTS is:

Strict-Transport-Security: max-age=0

But that only works after the browser successfully reaches your site over HTTPS and sees the new header.

If your cert is already broken, users may never get that far.

Fix

Be conservative early. Use a short max-age first. I’d rather spend a week ramping than spend a month cleaning up a bad one-year policy.

A practical rollout:

Strict-Transport-Security: max-age=300

then

Strict-Transport-Security: max-age=86400

then

Strict-Transport-Security: max-age=2592000

then annual max-age if everything is stable.

That rollout is boring. Boring is good in production commerce.

Mistake #8: Not verifying what the customer actually receives

Teams often check origin config and stop there. Customers don’t connect to your Terraform. They connect to whatever final response comes through Shopify, a CDN, an app proxy, or a third-party support platform.

Fix

Test the actual public response headers.

You can inspect with curl:

curl -I https://www.example.com

Look for:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Test redirects too:

curl -I http://example.com
curl -I https://example.com
curl -I https://www.example.com

And test multiple paths:

curl -I https://www.example.com/products/sample-product
curl -I https://www.example.com/collections/all

For a broader check of headers, use headertest.com.

Mistake #9: Treating HSTS as the whole HTTPS story

HSTS is one control. A good one. But if your store still has mixed content, weak cookie settings, or inconsistent TLS across subdomains, HSTS won’t save you.

For e-commerce, I care about the whole transport picture:

  • force HTTPS redirects
  • valid certs everywhere
  • secure cookies
  • no mixed content
  • HSTS after validation
  • preload only when you really mean it

If you’re managing custom infrastructure around Shopify, keep header policy explicit. Official header behavior and broader Shopify platform details should always be checked against the current docs: https://shopify.dev/docs

A sane HSTS approach for Shopify stores

If I were rolling this out on a Shopify-backed brand today, I’d do it like this:

  1. Verify all brand-owned hostnames and subdomains
  2. Fix HTTPS and certificate issues everywhere
  3. Clean up redirect chains
  4. Start with:
   Strict-Transport-Security: max-age=300
  1. Increase max-age gradually
  2. Add includeSubDomains only after full validation
  3. Add preload only if the domain estate is genuinely under control

That’s the difference between “we enabled HSTS” and “we deployed HSTS without breaking the business.”

For e-commerce, I’ll take the second one every time.