Protocol-relative URL’s are a URL format that is often used by those leveraging CDN’s to allow the browser to pick the protocol. This is great when you have a mix of secure and non-secure elements on the page. The browser can mix and match them.
This is an example of the HREFLang Implementation on Aliexpress. They are using these protocol relative URL’s and the pages load wiht both http and https pointing to the same page.
<link rel=”alternate” hreflang=”en” href=”//www.aliexpress.com”/>
<link rel=”alternate” hreflang=”id” href=”//id.aliexpress.com”/>
<link rel=”alternate” hreflang=”ar” href=”//ar.aliexpress.com”/>
<link rel=”alternate” hreflang=”de” href=”//de.aliexpress.com”/>
<link rel=”alternate” hreflang=”es” href=”//es.aliexpress.com”/>
<link rel=”alternate” hreflang=”fr” href=”//fr.aliexpress.com”/>
<link rel=”alternate” hreflang=”it” href=”//it.aliexpress.com”/>
Why is this bad for your HREFLang Implementation?
The HREFLang is telling the search engine that the page in the element is the “alternative” of this URL – if I am on the http version of the page then it matches to the alternative page’s http version. However, If Google if it finds the HTTPS version this page is also the alternative of that page causing confusion and duplicated.
So far, on all sites where this is used we have seen Google give on a few sites where this has been implemented, we find Google gives “No Return Tag” errors since they cannot correctly map the pages.
What is the fix:
The easiest fix is to add a full path to your HREFLang Elements. If you have the HTTPS use that.
Google specifically tells us not to run both HTTP and HTTPS simultaneously and to specifically use a 301 redirect from all http to https pages. This should effectively eliminate the http version of the URL removing the potential for both protocols at a URL level. You can still use it for all other elements on the page.