Lien href sans préfixe http(s) et SEO

[urmila]

Bonjour,

3 sites d'un de mes gros clients pour du référencement sont codés d'une telle manière que les liens sont du type :

<a href="//www.google.com">Google</a>

Surement par souci d’allègement maximal du code, ou un oubli ?

Du point de vue de l'internaute, cela ne pose aucun souci a la majorité des browsers qui interprètent correctement la chose.

Mais les liens ainsi amputés, internes comme externes, semblent poser des soucis à un bon nombre de robots. Majestic ne les index pas, ni le flow qui va avec. SEMRush a un mal fou à trouver les pages internes.

Cela pose-t-il d'autres problèmes a l'indexation Google ? Quelqu’un a déjà été confronté à cette situation ?

 

[rick38]

Ca évite de se demander si un site est https ou http, le browser va tenter tout seul https et sinon http.

C'est parfaitement valide, que Majestic et SEMRush aient un problème avec c'est juste qu'ils ne comprennent pas ce standard, mais Google évidemment le comprend.

 

[emualliug]

Sauf erreur, l'interprétation ne dépend pas tant du browser que de la page consultée ; on parle de "protocol relative URL" ; donc si la page est consultée en HTTP, le lien sera supposé en protocole HTTP et HTTPS si la page est HTTPS.

C'est en effet conforme à la norme (https://tools.ietf.org/html/rfc3986#section-4.2), puisque les URL peuvent être relatives, cela peut être utilisé pour des liens externes, mais cela avait surtout un intérêt pour les composants.

Ce type d'URL permettait d'éviter l'avertissement relatif à du contenu non sécurisé lorsqu'une page consultée en HTTPS appelait un composant en HTTP. Cela permettait en outre à des sites accessibles en HTTP et en HTTPS de fournir tous les composant en HTTPS dès lors que HTTPS était utilisé et sans toucher à une ligne de code ; le HTML étant identique quel que soit le protocole.

Pourquoi ne pas tout passer en HTTPS ? des raisons de performances initialement puisque les requêtes HTTPS sont un peu plus longues à traiter, et également d'hétérogénéité des sites lorsque HTTPS n'était pas aussi massivement utilisé.

J'en parle au passé, parce ce type d'URL n'est plus trop conseillé, parce que HTTP lui-même n'est d'ailleurs plus trop conseillé, et qu'un site, même en HTTP, a grandement intérêt à appeler des ressources externes en HTTPS. En outre, l'apport en matière de performance est devenu négligeable.

Je mets un lien vers le blog de Paul Irish qui exposait l'utilisation en 2010, et l'update de 2014 pour qu'on y ait plus recours : https://www.paulirish.com/2010/the-protocol-relative-url/.

Édit : et je tombe là dessus : https://joonas.fi/2016/12/27/stop-using-protocol-relative-urls/, l'utilisation d'URL protocol relative est déconseillée parce que si la page est enregistrée en local (et donc consultée avec le scheme "file://"), le lien sera cassé. Je suis un peu étonné que le browser ne corrige pas le lien lors du téléchargement de la page, je n'ai pas vérifié ceci étant.

 

[eldk]

Bonsoir,

Voir également si ce n'est pas parce que les 3 domaines sont sur la HSTS Preload List, https://hstspreload.org/ . Dans ce cas, Chrome/ium par exemple, ne tente même plus de demander la page en http si le visiteur entre une url de type http://domain.tld au lieu de https://domain.tld , les dev ont cru bien faire en économisant quelques octets.

Si ce n'est pas le cas, (et même si ça l'est), il vaut mieux utiliser l'url avec le préfixe https:// pour les robots ...

Cordialement,

Eric

 

[urmila]

Merci pour vos 3 réponses intéressantes, rapides. C'est exactement le genre d'infos que je recherchais.

Mission du jour : convaincre le client qu'on perd un flow de dingue

Urmila

 

[urmila]

Ca évite de se demander si un site est https ou http, le browser va tenter tout seul https et sinon http.

C'est parfaitement valide, que Majestic et SEMRush aient un problème avec c'est juste qu'ils ne comprennent pas ce standard, mais Google évidemment le comprend.

Apparemment Google a du mal aussi car les sous-pages ainsi linked ne sont pas indexées!

 

[eldk]

Un petit complément :

https://www.seroundtable.com/google-double-slashes-url-30061.html