HTTPS, redirects and HSTS in plain words

The short answer: HTTPS protects the connection between a visitor's browser and your server while data travels; redirects send visitors from the old HTTP URL to the HTTPS one; and HSTS tells supporting browsers to go straight to HTTPS on later visits without asking the network first. Three different mechanisms, often confused: HSTS is a policy header, not the redirect itself, and none of them is a reputation or ranking guarantee. Each is documented precisely — Google's site-move guidance (Google: Site moves with URL changes), RFC 6797 for HSTS (IETF RFC 6797), and web.dev's server guide (web.dev: Enabling HTTPS on your servers).

HTTPS: protecting the connection

HTTPS is HTTP over TLS: the server presents a certificate, the browser verifies it, and the traffic between them is encrypted and integrity-protected in transit. What it gives a business is twofold: buyers' details cannot be read or altered on the way, and browsers show the site without the "not secure" warning that erodes trust. What it does not give: HTTPS says the connection is protected, not that the site is honest, reputable or endorsed. The practical requirements are a valid, correctly installed certificate and page resources (scripts, images, styles) loaded over HTTPS too — mixed content is both a browser warning and a functional break (web.dev: Enabling HTTPS on your servers).

Redirects: one preferred HTTPS hostname

After enabling HTTPS, every visitor should land on one preferred host — for example https://example.com/ — and the old forms should redirect to it permanently (301). The typical chain is http://example.com and https://www.example.com each 301-ing to the canonical host. Google's site-move guidance covers the HTTP-to-HTTPS case directly: prepare the new version, use permanent redirects from the old URLs, update internal links, sitemaps and canonicals, and monitor afterwards (Google: Site moves with URL changes). The after-migration checklist that matters most:

internal links point to the HTTPS URLs directly, not through a redirect;
canonical tags and sitemap URLs use the HTTPS forms;
no mixed content remains;
the old HTTP URLs still redirect, and will for a long time — keep them.

HSTS: remembering, in policy form

HSTS (HTTP Strict Transport Security) is an HTTPS response header: Strict-Transport-Security: max-age=.... Once a browser has received it, for max-age seconds that browser will connect to your host over HTTPS without first making an HTTP request that could be intercepted (IETF RFC 6797). Two consequences deserve plain words:

HSTS is not the redirect. The redirect moves a request that has already arrived; HSTS removes the need for that first unencrypted request at all.
It binds the browser to HTTPS before it can reconsider. If your HTTPS setup breaks mid-policy, affected browsers cannot reach the site over plain HTTP until the max-age expires. That is the feature working — and the reason RFC 6797's provisions deserve care.

The includeSubDomains directive extends the policy to every subdomain, and preload lists ask browsers to apply the policy even on the first-ever visit. Both raise the stakes: every subdomain and every certificate must be right before switching them on, and reversing course is slow, since the browser's commitment does not lift until the policy expires (IETF RFC 6797). The standard advice follows from the mechanism: start with a short max-age, raise it gradually, add includeSubDomains only after verifying every subdomain serves HTTPS, and treat preload as an owner-level decision with a rollback plan.

Who does what

HTTPS, redirects and HSTS are server configuration. The business owner's job is to decide the preferred hostname and understand the trade-offs; the technical configuration belongs to the site's technical owner or specialist (web.dev: Enabling HTTPS on your servers). What none of it buys is guaranteed search performance: HTTPS is a documented best practice and part of a clean migration, but rankings and AI-answer inclusion remain platform decisions (Google: Site moves with URL changes). If you would like a scoped review of how your site handles HTTPS, redirects and HSTS — findings explained, changes you approve, retested under the same conditions — our GEO & SEO services work that way. Write to us via contact.

First visit redirects; later visits follow the HSTS policy.

Frequently asked questions

Does switching to HTTPS improve my rankings?

HTTPS is a documented best practice and part of a correct migration (Google: Site moves with URL changes), but no transport setting guarantees rankings or AI citations. Do it for security and trust, not as an outcome promise.

Why do I still need redirects if I have HSTS?

HSTS only applies to browsers that have already received the policy, and not every client supports or honours it. Permanent redirects remain the general route to the HTTPS URLs (IETF RFC 6797).

What can go wrong with HSTS?

If HTTPS breaks while a policy is active, affected browsers cannot fall back to HTTP until the max-age expires — and includeSubDomains extends that exposure to every subdomain. Start with a short max-age and increase it gradually (IETF RFC 6797).

Who should make these changes on my site?

The technical owner or specialist who controls the server configuration. The business owner decides the preferred hostname and approves the plan; the implementation is not a content task (web.dev: Enabling HTTPS on your servers).

Sources

developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes (read 10 November 2026)
rfc-editor.org/rfc/rfc6797 (read 10 November 2026)
web.dev/articles/enable-https (read 10 November 2026)

GEO & SEO optimisation service · Make an enquiry · More GEO and AI search answers

Owned editorial content by TopGEOClaim (ACN International Pte. Ltd., Singapore). Drafted with AI assistance, reviewed, and checked against the linked sources. It describes public documentation, not customer results, and does not promise any search or AI placement. Vendor behaviour may change; check the linked sources.