The meta tag <link rel="alternate"> should be added for each language and subdomain with the same content right? But do I need to add 2 versions of each, namely http:// and https:// ?

Like this:

<link rel="alternate" href="http://www.example.com/en/" hreflang="en" />
<link rel="alternate" href="http://www.example.com/nl/" hreflang="nl" />
<link rel="alternate" href="https://www.example.com/en/" hreflang="en" />
<link rel="alternate" href="https://www.example.com/nl/" hreflang="nl" />

or is this enough:

<link rel="alternate" href="http://www.example.com/en/" hreflang="en" />
<link rel="alternate" href="http://www.example.com/nl/" hreflang="nl" />
  • 4
    Is there a reason why you offer HTTP in addition to HTTPS, instead of enforcing HTTPS?
    – unor
    Nov 13, 2015 at 11:07
  • @unor Yes there is a reason. I do enforce HTTPS, but only for pages with visitor information. For pages containing general information exclusively (mostly landing pages) I allow (and make referred) the HTTP version so that automated page ranking bots could read the traffic and analyze it.
    – Slava
    Nov 13, 2015 at 14:03
  • 1
    What do you mean by "make referred"? Also, "automated page ranking bots could read the traffic" - what kind of bots are these?
    – MrWhite
    Nov 13, 2015 at 14:49
  • 1
    The question is: why do you think bots can't read HTTPS pages? They can. Nov 14, 2015 at 1:46
  • 3
    What third party traffic do you think bots try to read? If you mean external scripts/etc, then they can read those too as they make their own connections to those servers. Nov 14, 2015 at 11:38

2 Answers 2


You can definitely use the alternate, nothing stopping you from using the first example, you won't be penalized directly unless you try to canonical alternate a http area that defaults to SSL normally, causing obvious errors. I have nothing to cite this besides this is what rel="alternate" is for; whether or not services support then trigger stuff is up to the service.

However, you will lose out on ranking signal due to not enforcing strong encryption everywhere. Besides that reason, in my opinion you should encrypt pages of generality too. Visitors now prefer [and they deserve] to be protected on the whole realm. It's turning into a conversion factor very quickly, and soon it will be the norm to see a green lock. Chrome Canary branch is a telling sign too. As of Nov 2015, there is an opt-in Chrome flag showing an insecure icon (similar to the busted red lock) when visiting normal http pages, anywhere on any site. I estimate, expect this to come to Chrome stable in about 10-12 months. Chrome stable has a massive chunk of userbase, and a surprising sum of the canary flags have come to life through its branch into stable.

Your server will be fine, encrypt everything! If you are worried about lag/speed/cost/etc, there are helpers around -- Cloudflare comes to mind first due to the free plan, cached all (varnish-ish), SPDY/HSTS/DNSSEC/Strong-Cipher, various other securities and pool size. It could help off-load some of the hurdle VS liability.

  • "have nothing to cite" - maybe this is because it's not really what rel="alternate" is for?
    – MrWhite
    Nov 14, 2015 at 16:15
  • @w3d Its because there is no spec regarding alternate specifically. All you will find is various providers using it for their various triggers. Rel="alternate" simply means "here is another version of the resource"...whether due to language, display, aggregation, securities, intra, etc. This is absolutely how its used, however as I stated, I wouldn't expect support for HTTP alternate in an HTTPS world.
    – dhaupin
    Nov 14, 2015 at 18:42

From the Google Search Console help pages:

Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are conflicting signals such as -

  • The HTTPS page has an invalid SSL certificate.
  • The HTTPS page contains insecure dependencies.
  • The HTTPS page is roboted (and the HTTP page is not).
  • The HTTPS page redirects users to or through an HTTP page.
  • The HTTPS page has a rel="canonical" link to the HTTP page.
  • The HTTPS page contains a noindex robots meta tag

Although our systems prefer HTTPS pages over HTTP pages by default, you can ensure this behavior by taking any of the following actions:

  • Add 301 or 302 redirects from the HTTP page to the HTTPS page.

  • Add a rel="canonical" link from the HTTP page to the HTTPS page.

  • 2
    Whilst this is all useful relevant information, you don't actually answer the OPs question. (And please link/quote any references.)
    – MrWhite
    Nov 13, 2015 at 10:27
  • Hello wed, I will consider for sure. Nov 16, 2015 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.