0

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" />
Improve this question
8
  • 4
    Is there a reason why you offer HTTP in addition to HTTPS, instead of enforcing HTTPS? – unor Nov 13 '15 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 '15 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 '15 at 14:49
  • 1
    The question is: why do you think bots can't read HTTPS pages? They can. – Andrew Lott Nov 14 '15 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. – Andrew Lott Nov 14 '15 at 11:38
1

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.

Improve this answer
2
  • "have nothing to cite" - maybe this is because it's not really what rel="alternate" is for? – MrWhite Nov 14 '15 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 '15 at 18:42
-2

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.

Improve this answer
2
  • 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 '15 at 10:27
  • Hello wed, I will consider for sure. – Premnath321 Nov 16 '15 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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