Is it really necessary to redirect HTTP to HTTPS, or is the preferred domain enough?

What is the 'preferred domain' that Mueller refers to?

The preferred domain (or canonical domain) refers to the URL version that you want to be indexed as a priority by Google. Historically, Search Console allowed users to set this parameter to choose between www and non-www, or HTTP and HTTPS.

This feature has been gradually deprecated in favor of canonical tags and server redirects. But Mueller reminds us that it can still serve as a signal — albeit a weak one — when no redirection is in place.

Why does Google still recommend 301 redirects?

Because the preferred domain remains a declarative signal, not a binding technical mechanism. Google can ignore this parameter if other signals (backlinks, sitemaps, conflicting canonical tags) point to the non-preferred version.

301 redirects, on the other hand, force browsers and bots to land on the target version. They consolidate PageRank, avoid authority dilution between duplicated versions, and ensure that only the correct URL appears in the index. It's mechanical, not declarative.

When can the preferred domain alone be sufficient?

Theoretically, when a site serves strictly identical content on both HTTP and HTTPS without structural changes or internal link variations, and the HTTPS migration is recent or ongoing. Typically, a site in transition before permanently switching all URLs.

However, this situation is temporary and risky. As soon as a third party links to the HTTP version or a sitemap mentions both versions, Google may index both and create apparent duplicate content, even with the preferred domain declared.

• The preferred domain is a weak declarative signal, not a technical instruction.
• 301 redirects consolidate PageRank and force the indexing of the correct version.
• Using only the preferred domain exposes one to risks of duplicate indexing and authority dilution.
• This approach should only be considered as a temporary solution, never a permanent setup.
• Google may ignore the preferred domain if other signals (backlinks, sitemaps) contradict the declared choice.

Is this statement consistent with observed practices in the field?

Yes and no. In practice, sites that rely solely on the preferred domain without a 301 redirect frequently experience mixed indexing issues: Google indexes either the HTTP or HTTPS version, especially if external backlinks point to both protocols.

Mueller adopts a cautious, almost diplomatic tone here. He technically validates the approach but clearly directs towards 301 redirects. What he doesn't openly say: the preferred domain has become obsolete since Google prioritizes on-page signals (canonical, HSTS) and server signals (redirects). [To verify] if this parameter still holds real weight in the current algorithm, as field tests show it is often ignored.

What concrete risks does one run by not redirecting?

The first risk: PageRank dilution. If Google indexes both versions, it may distribute authority between them instead of concentrating it on one URL. Result: loss of ranking potential on each version.

The second risk: contradictory signals. Imagine a powerful backlink pointing to the HTTP version, but your sitemap only declares HTTPS. Google may interpret this as a signal of inconsistency and hesitate on which version to prioritize. In doubt, it indexes both — or worse, favors the HTTP version.

Are there exceptions where redirection is not essential?

Very rare. One might imagine a completely new site, with no historical backlinks, launched directly in HTTPS with preloaded HSTS and strict canonical. In this case, the preferred domain might suffice… but why take this risk when a 301 redirect resolves the issue permanently with a single server config line?

The other hypothetical exception: a site undergoing gradual migration where some sections temporarily remain in HTTP for technical reasons (APIs, third-party integrations). But again, it's better to redirect at the application level as soon as possible. Relying on the preferred domain in this case is like playing with fire.

What concrete actions should be taken on a site with mixed HTTP/HTTPS?

First step: audit current indexing. Run a site:votredomaine.com query to check which versions (HTTP vs HTTPS, www vs non-www) appear in the index. If you see a mix, it's a symptom of a structural issue.

Next, implement permanent 301 redirects at the server level (Apache, Nginx, CDN) to force all HTTP requests to HTTPS, and/or www to non-www according to your choice. Test with curl or a tool like Screaming Frog to ensure every URL redirects in a single hop, without a redirection chain.

What mistakes should be avoided when setting up redirects?

Never redirect only the homepage while leaving deep pages accessible via HTTP. Google will continue to index them if backlinks or the sitemap mention them. The redirection must be global, at the protocol and/or subdomain level.

Another classic trap: redirection chains. If HTTP redirects to www in HTTPS, which then redirects to non-www, you're losing PageRank at each hop and slowing down the crawl. One redirect = one direct 301 hop to the final version.

How to check if my site is correctly configured?

In Search Console, check that only the canonical version (e.g. https://www.exemple.com) is accumulating impressions and clicks. If you see data across multiple properties (HTTP and HTTPS), it means Google is still indexing both.

On the server side, test several random URLs with an HTTP header checker tool to confirm the response code is 301 Moved Permanently (not 302, not 307). Finally, crawl the site with Screaming Frog or Oncrawl to detect any conflicting canonical tags or internal links pointing to the wrong version.

• Implement permanent 301 redirects at the server level to force HTTP → HTTPS and/or www → non-www.
• Check indexing with site: in Google to detect mixed indexed versions.
• Test redirects with curl or Screaming Frog to avoid redirection chains.
• Ensure that canonical tags all point to the desired final version.
• Update the XML sitemap to mention only canonical URLs in HTTPS.
• Monitor Search Console to confirm that only the canonical property accumulates data.