Are 307 HSTS redirections really invisible to SEO?

What exactly is a 307 HSTS redirection?

When you enable HSTS (HTTP Strict Transport Security) on your site, you are asking browsers never to access your domain via HTTP. The browser stores this information in an internal list and automatically converts any attempt to access HTTP to HTTPS — even before contacting the server.

Chrome displays a 307 Internal Redirect status code in its development tools to signal this behavior. This is not a standard HTTP redirect: no network request is sent, and no server response is received. It's a local conversion performed by the browser.

Why is this distinction important for SEO?

Server redirections (301, 302, actual 307s) consume crawl budget, introduce latency, and require Googlebot to follow the redirect chain. HSTS redirections, however, simply do not exist for Googlebot — the bot crawls directly over HTTPS if the domain is in the preload list or if an HSTS header has already been received.

This nuance fundamentally changes the analysis of a technical audit. A tool that flags dozens of 307 redirections on an HSTS site is not detecting a real problem but rather a misinterpretation of browser logs. The server receives HTTPS requests directly — no redirection takes place.

How does Googlebot practically handle HSTS?

Googlebot respects the Strict-Transport-Security headers and remembers the directive for future crawls. If your domain is in the official preload list, the bot crawls directly over HTTPS without ever attempting an HTTP request. As a result: no server redirection is needed or executed.

But Googlebot doesn't behave exactly like Chrome. It does not generate a fictitious 307 in its logs — it simply goes directly to HTTPS. This means that Search Console will never report these 307s as errors or redirects, unlike what can be observed in a regular browser.

• 307 HSTS redirections are generated by the browser, not by the server — no actual network request
• Googlebot does not encounter these 307s if it's already crawling over HTTPS (preload list or memorized HSTS directive)
• Chrome-based audit tools may report these 307s as issues even though they are not
• A server 301 HTTP to HTTPS redirection remains necessary for users without HSTS history or bots that do not support the directive
• The HSTS preload list ensures that Chrome, Firefox, Safari, and Googlebot go directly to HTTPS without ever attempting an HTTP request

Is this statement consistent with real-world observations?

Absolutely. Real crawl tests confirm that Googlebot never reports these 307 HSTS in Search Console. If you analyze the server logs of an enabled HSTS site, you'll only see direct HTTPS requests — no trace of redirection for bots that respect the directive.

In contrast, Chrome-based SEO audit tools (Screaming Frog, OnCrawl, Sitebulb) often report these 307s as redirects to be addressed. This is a recurring source of confusion: clients panic at the sight of thousands of redirects that actually have no SEO impact. It's essential to distinguish between 307 HSTS (browser) and actual server 307s (which are much rarer).

What nuances should be added to this statement?

John Mueller clarifies a specific technical point: the 307s displayed in Chrome are not server redirects. But he does not say that HSTS eliminates the need for a 301 HTTP to HTTPS server redirection. Let's be clear: this redirection remains essential for first-time visitors, incompatible bots, and scenarios where HSTS history has not yet been established. [To be verified] — some believe being in the preload list is enough, but this overlooks third-party crawlers and older versions of bots.

Another nuance: if your site is not in the preload list and a user manually types http://yoursite.com for the first time, the browser will indeed attempt an initial HTTP request. This is where a true 301 or 302 server redirection comes into play — before the HSTS header is received and memorized. The 307 HSTS only comes into effect after this first exposure.

In what cases does this rule not apply?

If you set up a manual 307 server redirection (via .htaccess, nginx, or a CDN), then it is indeed a real HTTP redirection with crawling impact. This is no longer browser HSTS — it’s a classic server directive. Googlebot will follow it, consume crawl budget, and Search Console will report it in crawl reports.

Similarly, if you use temporary 307 redirects for A/B testing or partial migrations, these redirects do exist on the server side. They have a real SEO impact: they may not necessarily pass PageRank (depending on the duration), they introduce latency, and they may be ignored by Googlebot if they last too long without transitioning to a permanent 301.

What should you do concretely to avoid any confusion?

Start by auditing your server logs rather than blindly relying on reports from Chrome-based tools. If you see 307s in Screaming Frog but no trace in your Apache/Nginx logs, it's browser HSTS — no action needed. If you see 307s in both, then you have a server configuration problem to fix.

Next, ensure that your Strict-Transport-Security header is correctly configured with a sufficient duration (at least 1 year, or 31536000 seconds) and the includeSubDomains option if applicable. Test with Chrome's development tools: a 307 Internal Redirect in the Network tab indicates that HSTS is working — that's a good sign, not a problem.

What mistakes should be avoided when implementing HSTS?

Never remove your server 301 HTTP to HTTPS redirect on the grounds that HSTS will take care of it. HSTS only protects compatible browsers that have already visited the site — all others (first-time visitors, old bots, third-party crawlers) need this classic redirect. Both mechanisms coexist; they don't exclude each other.

Avoid confusing short max-age and preload list. A max-age of just a few days is not enough for a lasting effect — the browser forgets the directive after expiration. If you aim for maximum security and optimal Googlebot crawling, submit your domain to the official preload list. But be careful: it's an almost irreversible decision not to be taken lightly.

How can you verify that your HSTS configuration is correct?

Test with https://hstspreload.org to check your domain's eligibility for the preload list. Also, ensure that the header is present on all pages, including subdomains if includeSubDomains is enabled. A missing header on part of the site creates a security gap and inconsistent behavior for Googlebot.

Finally, monitor your Search Console crawl reports for any potential real server 307 redirects. If you don’t see any even though Screaming Frog is reporting hundreds, you have confirmation that these are indeed browser 307 HSTS — thus without SEO impact. Document this distinction in your audits to avoid recurring false alerts.

• Compare the 307s reported by audit tools with actual server logs to identify false HSTS positives
• Keep a server 301 HTTP to HTTPS redirect even with HSTS enabled — both mechanisms complement each other
• Configure the Strict-Transport-Security header with a max-age of at least 31536000 (1 year) and includeSubDomains if appropriate
• Test eligibility for the preload list on hstspreload.org before submitting (an almost irreversible decision)
• Ensure that the HSTS header is present on all pages, subdomains included if necessary
• Document in your audits the distinction between 307 HSTS (browser) and 307 server to avoid false alerts