Redirecting a Domain That Used HSTS

Michel Bardelmeijer is Tech Lead and Sales at redirect.pizza, where he helps DevOps and IT teams solve domain redirect challenges at scale. Michel has guided organizations like SD Worx, Zurich Airport and Harvard through complex redirect scenarios involving thousands of domains.

Have questions about bulk redirects, HTTPS migrations, or domain consolidations? Connect with Michel on LinkedIn or reach out to the redirect.pizza team.

Congrats, your new site is finally live. You've moved the content, checked the links and set the old domain to forward. What you probably didn't check is the Strict-Transport-Security header the old site has been sending all along. Huh?

That header tells browsers to use nothing but HTTPS for the domain, and they keep doing so long after the server that sent it is gone. If the old domain now forwards without a valid certificate, visitors whose browsers enforce HSTS get an error page they can't click past instead of your redirect. Oops.

Here's how to trace the policy behind the error, get the redirect working again and manage HSTS without running your own server.

For the basics of forwarding, start with URL redirects explained.

Header for Redirecting a Domain That Used HSTS, with the term HSTS on redirect.pizza tiles

Key Takeaways

An HTTPS redirect needs a valid certificate at the source. HSTS forces HTTPS and takes away the option to click past a certificate error.
Stored policies survive a migration. Removing the header from your server doesn't remove it from the browsers that already hold it.
A hostname can be covered by its own policy, a parent's includeSubDomains policy or a preload entry. Each one is removed in a different way.
HSTS on the destination doesn't protect a separate old domain. Serve valid HTTPS on the old hostname and send an HSTS header there to establish its policy.
HSTS and preloading are separate decisions. hstspreload.org currently recommends HSTS but advises against preloading as a general practice.

What is HSTS?

HTTP Strict Transport Security is a policy mechanism defined in RFC 6797. A site sends it in the Strict-Transport-Security response header, telling the browser to use HTTPS for that hostname for a specified period.

So, for example:

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

Use that long-lived configuration only after testing a shorter policy.

max-age=31536000 means one year. Each valid HTTPS response carrying the header refreshes the expiry time.

includeSubDomains extends the policy to hostnames below the one that sent it.

The final token, preload, is an extension used by the preload service, rather than one of the directives defined in the RFC. It signals consent to preloading. Adding it does not, by itself, put a domain into browsers' built-in lists.

Scope matters here. A header from www.example.com doesn't cover example.com. A header from example.com with includeSubDomains covers www.example.com, deeper subdomains and new subdomains created later, while that policy remains in force.

Browsers accept the header only over a valid HTTPS connection. Sending it over HTTP has zero effect. Once a browser knows a hostname is covered, it upgrades an HTTP URL locally, before sending an HTTP request. Chromium may show this as a 307 Internal Redirect with Non-Authoritative-Reason: HSTS in DevTools. Your server didn't send that response.

HSTS has one more consequence.

If the certificate doesn't check out, HSTS requires the browser to terminate the connection without offering the normal option to proceed anyway. RFC 6797 calls this "no user recourse".

Browsers remember HSTS after the site is gone

A browser only has to receive the header once over valid HTTPS. It then enforces that stored policy until it expires or receives a valid update, whether your server is still around or not.

Let's say old-brand.com has served a one-year HSTS policy. After a rebrand, someone replaces the hosting with a registrar's forwarding service that handles HTTP but has no valid certificate for the old name.

A visit that actually uses HTTP, in a browser with no applicable HSTS policy, may reach the forwarder successfully. A browser with an unexpired policy will insist on HTTPS and hit a wall. Modern browsers also upgrade many navigations independently of HSTS, so typing the bare domain is not a reliable way to test the HTTP route.

Chrome may display a message along these lines:

"You cannot visit old-brand.com right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later."

Don't count on it.

A cached policy can expire, but an inherited policy or preload entry may still apply. Restoring valid HTTPS on the old hostname fixes the certificate problem for everyone trying to reach it. This includes visitors following an explicit https:// URL who have never encountered its HSTS header.

This is the underlying issue in why HTTPS redirects break: the browser must establish TLS with the old hostname before it can read a redirect pointing elsewhere. A valid certificate on the destination cannot help with that first connection.

Which policy is actually in force

First identify what the browser is enforcing. More than one of these can apply at the same time:

Source of the policy	How it covers the hostname	What removing it involves
A header from the hostname itself	The browser previously received it over valid HTTPS.	Send max-age=0 over valid HTTPS. It clears that stored policy only in browsers that receive the new response.
A parent's includeSubDomains policy	A policy on example.com, for instance, covers shop.example.com.	Change or remove the parent's policy. Browsers must receive the update or let their stored policy expire. The child cannot override it.
A preload entry	The browser ships with the domain already designated as HTTPS-only, potentially including its subdomains.	Request removal from the preload list and allow time for browser updates to reach users.

Clearing a parent policy does not clear separate policies its children have set. Likewise, removal from the preload list does not erase an unexpired policy learned from a response header. The RFC's hostname-matching rules explain how these policies overlap.

To inspect what the old hostname sends now, you can request it over HTTPS without following its redirect:

curl -sS -D - -o /dev/null https://old.example/path

This prints the response headers and keeps certificate verification enabled. If the TLS handshake falls over, fix that first: the browser cannot receive either the redirect or a replacement HSTS policy through the failed connection.

A missing header proves only that this response didn't contain one. It says nothing about a policy already stored in a visitor's browser. In Chrome, chrome://net-internals/#hsts lets you query local HSTS state, including dynamic policies learned from headers and static policies from preloading. Chromium documents the query here. Other visitors may have different policies stored.

curl output for www.github.com: a 301 to github.com with an HSTS header of one year, includeSubDomains and preload

Three ways HSTS can break a redirect

The retired domain above is the obvious one. The other two are easier to miss.

Subdomains first. An apex policy with includeSubDomains can reach a campaign hostname managed by a vendor, an old redirect at the registrar or an internal web tool that never supported HTTPS. The browser doesn't know those services belong to different teams. If the hostname falls under the policy, it absolutely needs working HTTPS.

So before enabling that directive, check every web service it will cover. Build the same check into the process for creating new subdomains. Otherwise the next team can introduce a failure long after the rollout appeared successful.

Redirect loops need a different diagnosis. Consider this sequence:

Browser requests https://old.example/page
Server redirects to http://old.example/page
HSTS upgrades it to https://old.example/page
The same server redirect starts the sequence again

Here, the server's downgrade conflicts with the browser's policy. Correct the redirect target so the chain stays on HTTPS.

A reverse proxy can also cause a loop if the application misidentifies the original connection as HTTP and repeatedly redirects to an HTTPS URL the browser is already using. That can happen without HSTS. Inspect the actual Location headers and how the proxy communicates the original scheme before blaming the browser's internal 307. The article on HTTP redirect status codes explains the different responses you may see.

Don't make the opposite mistake: redirecting domains without HSTS

Dropping HSTS from the old domain to avoid all this leaves a different gap. A policy on new-brand.com does not protect a separate domain, old-brand.com, just because one redirects to the other.

Modern browsers upgrade many HTTP navigations automatically, so an old HTTP link doesn't necessarily produce a plaintext request. Where a request does go over HTTP, however, an attacker able to intercept that connection can alter the response before the visitor reaches your secure destination.

To establish an HSTS policy on the redirecting hostname, use this sequence:

Serve a valid certificate for the old hostname.
Redirect HTTP to HTTPS on that same hostname.
Return the redirect to the destination over HTTPS, with the old hostname's Strict-Transport-Security header on that response.

The order lets the browser learn the old hostname's policy. A header delivered only by the destination cannot do that.

It also has a limit. Receiving HSTS does not retroactively protect the first HTTP request. It protects subsequent requests while the browser remembers the policy. An applicable parent policy or preload entry can provide protection before that first visit, but preloading carries a longer commitment, as we'll see below.

Gi Group Holding ran into the certificate gap with its old redirect setup. The Italian staffing group holds roughly 400 domain variants across about 35 countries, most with no website behind them. Two IT people look after all of it. Their regex-based 301 rules worked over HTTP, but visitors who tried HTTPS on a legacy domain got a certificate warning. Country teams often found out just before a campaign launched.

Since the group moved to redirect.pizza, its most recent rebrand took 90 minutes for 25 redirects. Each redirect used to take 20 minutes.

Every portfolio has a few domains nobody thinks of as sites anymore. The campaign domain from three rebrands ago, the typo domain someone bought in a panic, the old product name. They're separate domains, so they need their own certificate and their own header. Preload and a year of max-age on your main site do nothing for them. My rule is simple: if a hostname sends traffic anywhere, treat it like production, or retire it properly.
Michel Bardelmeijer, Tech Lead at redirect.pizza

Preload is no longer the advice (and that is a change)

Preloading used to be the finishing touch on a serious HTTPS setup. You submit your domain to a list that ships inside Chrome, Firefox, Safari and Edge, and those browsers insist on HTTPS before they've ever received a header from you.

That closes the initial gap. It also makes a policy slower to undo.

hstspreload.org currently recommends HSTS but advises against preloading, citing the smaller additional security benefit as browsers increasingly upgrade navigations themselves, alongside the operational risks of a persistent policy. It also asks software providers not to include the preload directive by default.

If you still choose to submit a domain, the requirements include a valid certificate, an HTTP-to-HTTPS redirect on the same host if port 80 is open, and HTTPS support across its subdomains, including internal services and www when it has a DNS record. The base domain must send a header with at least one year of max-age, plus includeSubDomains and preload. If its HTTPS response is itself a redirect, that response must carry the header too.

Submission, acceptance and distribution in browser releases are separate from adding the directive.

Removal takes patience. You must remove preload from the header, keep serving a valid HSTS header over valid HTTPS, and request removal. The service estimates 6 to 12 weeks to reach most Chrome users, potentially longer for other browsers. Previously learned dynamic policies can remain after that.

Remember this when you sell a domain, park it or move its redirects. The paperwork may be done, but visitors' browsers won't know that.

HSTS on a redirect without running your own server

DNS can point a hostname at a redirect service. The service then accepts the connection, serves the certificate and returns the HTTP redirect.

Those jobs still happen. You've just handed the server work to the provider.

Registrar forwarding is a mixed bag. Some registrars now serve the forward over HTTPS with a valid certificate, others still only handle HTTP, and setting your own HSTS header is a separate feature again. Test the old hostname over HTTPS and check whether you can configure HSTS, instead of assuming the forwarding option covers both.

Registrar forwarding: test HTTPS and HSTS separately

redirect.pizza provides automatic certificate issuance and renewal, using Let's Encrypt and ZeroSSL. DNS changes can still disrupt issuance or renewal, and a restrictive CAA record can prevent the chosen certificate authority from issuing a certificate. Keep certificate monitoring in place even when renewal is automated.

HSTS is opt-in, with settings at team and domain level. According to the HSTS setup documentation, enabling it adds the header to the HTTPS redirect response and sends HTTP requests to HTTPS on the same hostname before forwarding to the configured destination.

Check the settings before switching it on. The documented default header value is:

max-age=31536000

You can adjust max-age and add includeSubDomains or preload. Start with a shorter duration, and only add preload once you have deliberately chosen to pursue it.

That default leaves preload out, which is exactly what hstspreload.org asks of software providers.

HSTS and SEO: no ranking boost, still worth having

HSTS protects browser connections. In its June 2023 Search Central office hours, Google said the HSTS header does not affect Search and that it does not rely on headers like HSTS for canonicalization.

HTTPS itself is another story. Google made it a lightweight ranking signal back in 2014, and people still stretch that into "HSTS helps SEO". It doesn't follow. The signal rewards pages served over HTTPS. A header that tells browsers to insist on HTTPS adds nothing to it.

So, keep normal HTTP-to-HTTPS redirects and consistent canonical URLs.

Those settle your http:// duplicates. HSTS doesn't. In a browser with a stored policy, HSTS can save the HTTP redirect round trip where it would otherwise be needed. That's a useful consequence for visitors. It doesn't replace the server responses used to handle your HTTP URLs.

Do this before you set max-age to a year

A one-year policy can linger long after a migration, so run these checks before you commit to it.

1
Map the scope. List the web hostnames the policy will cover, including vendor-managed and internal services. If you plan to use includeSubDomains, make HTTPS a requirement for future subdomains too.
2
Verify valid HTTPS on each one, including hosts that only redirect. Where both address types exist, test IPv4 and IPv6.
3
Follow the forwarding chains. Check registrar redirects as well as your own infrastructure, and look for any hop back to HTTP.
4
Start with max-age=300, a five-minute policy. Add includeSubDomains only once the covered services are ready.
5
Increase gradually: a week (604800), then a month (2592000), then a year (31536000). Monitor failures, resolve them and let each stage run for at least its full duration before increasing it. The preload service's deployment guidance describes this staged approach. Preloading remains a separate decision.
6
Record who owns the certificates, where the header is set and what must survive a migration. Put that information in the domain retirement runbook. The person retiring this domain in two years may not be you.

Six checks before a one-year HSTS policy, starting with max-age=300 and raising it in stages

Try redirect.pizza on your own domains

Create a redirect, point your DNS at redirect.pizza and let the service handle the certificate and forwarding. You can then enable HSTS with a duration that fits your rollout, without maintaining a web server of your own.

Get started for free

Frequently Asked Questions

An HSTS policy applies to the hostname, and the browser cannot establish a valid secure connection. A missing, expired or mismatched certificate is a common cause. The request may have started as HTTPS or been upgraded from HTTP. Either way, HSTS prevents the usual click-through on a certificate error.

Restore valid HTTPS on the hostname that fails. Clearing a dynamic policy in your own browser doesn't repair the service for other visitors, and an inherited policy or preload entry may still apply.

Google says the header doesn't affect Search and is not something it relies on for canonicalization. Keep your server-side redirects and canonical URLs consistent, and enable HSTS for its security benefits.

Request its HTTPS URL and inspect the response headers. The curl command earlier in this article shows the initial response without following redirects, which helps you avoid mistaking the destination's header for the source's.

Then check browser state. A hostname that sends no header today may still be covered by a cached policy, a parent's includeSubDomains directive or a preload entry. Chrome's chrome://net-internals/#hsts shows local policies, while hstspreload.org provides a preload status check. Neither a single response nor a fresh browser tells you what every returning visitor has stored.