Structures d’Urls, Urls relatifs et Urls absolus


zenobral

zenobral

Depuis 9 ans, le SEO c'est mon dada. Mais ce que j'aime particulièrement, c'est le traitement de data : crawl, logs, outils en ligne de commande, excel, python.... Je partage avec vous, sur CanYouSeoMe, une partie de mon expérience, en espérant vous débloquer ou vous guider vis à vis de problèmes fréquemment rencontrés.
zenobral

Cet article était normalement voué à être intégré dans un autre article, mais chemin faisant au cours de l’écriture, il m’a semblé plus logique et simple de l’extraire pour en faire un article de référence à part.

Je m’attarde donc à cette notion d’Url relatif et d’Url absolu qui n’est pas toujours claire pour tous les SEOs, et notamment parce que les crawlers finissent toujours par donner l’Url absolu d’une page ou d’une image dans leurs rapports (ce qui est le bienvenu). Mais lorsque l’on fait soit même de l’extraction de contenu dans les pages, on récupère très souvent les Urls au format relatif et il est parfois utile de comprendre comment reconstruire l’Url absolu pour exploiter le contenu.

Structure d’un Url

Soit l’Url suivant ( on se croirait en cours de maths ) :

http://login:password@monsite.com:80/chemin1/chemin2/index.php?filtre=chaussure&page=2#paragraphe2

Celui-ci est constitué des parties suivantes :

  • protocol ou scheme : http, https, ftp, sftp, etc..
  • username : le login
  • password : le mot de passe
  • host : nom du domaine (en incluant les sous domaines) ou IP du serveur
  • port : le port sur lequel le serveur recevant la requête va écouter. Les protocoles ont des ports par défaut, ainsi http sur le port 80, https sur le port 443, etc…
  • path : la partie incluant le premier « / » après l’host et avant le « ? »
  • query string : toute la partie après le « ? » et avant le « # » si présent
  • hash fragment : après le « # », généralement pour pointer vers un id spécifique dans la page, ou pour router les urls des apps js

Il y a des éléments qu’on ne retrouvera jamais (99,9% du temps) dans les urls d’un site. Ainsi l’username, le password et le port n’ont pas vraiment vocation à se retrouver dans des urls de navigation, et si c’est le cas, on a toutes les chances d’être plutôt sur un portail d’entreprise. Si par hasard votre dev vous a collé cela sur votre site public, c’est le moment d’aller le voir et de lui gueuler bien fort dans l’oreille : « Alerte au gogol !!!! Alerte au gogol !!! »

Url absolu

Un Url est dit « absolu » lorsqu’il est indépendant du contexte de la page. Le navigateur est donc en capacité de reconstruire l’Url final en se basant uniquement sur le serveur. On distingue 3 types d’Urls absolus :

« Totalement absolu » : http://monsite.com/chemin1

Ici, pas de surprise, quelque soit, le domaine ou le protocole, le navigateur ira toujours vers http://monsite.com/chemin1

Notez bien que si vous oubliez le protocole devant le domaine (ici http://), vous n’aurez plus un Url absolu du tout, mais un Url relatif qui ne voudra au final sans doute rien dire !

Donc si vous avez un lien « monsite.com/chemin1 »  au lieu de « http://monsite.com/chemin1  » sur monsite.com, cela a toutes les chances (voir les règles de résolution plus bas) de terminer en lien « http://monsite.com/monsite.com/chemin1 » ( ceux qui n’ont jamais vu cela en préprod, levez la main)

« Relatif au protocole » : //monsite.com/chemin1

Le protocole de l’Url est déterminé depuis le protocole du serveur. C’est particulièrement intéressant lorsque l’on veut s’affranchir des problématiques d’appel de ressources externes à la page selon le protocole du serveur de celle-ci.

Admettons que l’on appelle des fichiers JS depuis un autre domaine avec:

  • sur http://monsite.com, l’url va se résoudre en « http://cdn.autresite.com/assets/slider.js »
  • sur https://monsite.com, l’url va se résoudre en « https://cdn.autresite.com/assets/slider.js »

Pour information, l’url de la librairie analytics.js de universal analytics est appelée de cette manière, ce qui évite de lever des exceptions de sécurité quand le site est en https.

« Relatif au domaine » : /chemin1

Le protocole et le nom de domaine sont déduits depuis le nom du serveur. Ainsi admettons que l’on ait un lien interne vers /chemin1 :

  • sur http://monsite.com, l’url va se résoudre vers « http://monsite.com/chemin1 »
  • sur http://monsite.com/truc/bidule, l’url va se résoudre vers « http://monsite.com/chemin1 » ( on ne tiens pas compte du path de l’url d’origine)
  • sur https://monsite.com, l’url va se résoudre vers « https://monsite.com/chemin1 »
  • sur http://preprod.monsite.com, l’url va se résoudre vers « http://preprod.monsite.com/chemin1 »

De mon point de vue, lorsque l’on rédige des textes et que l’on fait des liens internes dans le site, c’est la forme d’Url à privilégier absolument :

  • On garde une cohérence de maillage entre les versions en dev, preprod et prod
  • Lorsque l’on migre de domaine, on a pas à se retaper tous les textes pour changer les ancres de liens
  • Si on duplique le site sur un autre domaine ( par exemple pour géotargeter des users au niveau de l’offre), de la même manière on a pas à tout se retaper

Il faut néanmoins faire attention à un point… si l’envie vous prend de restructurer votre site en sous domaines, vous risquez d’avoir besoin en revanche de tout refaire :

Admettons que vous ayez un site de Vêtements avec des catégories déclinées par type de vêtements. Dans l’édito de la catégorie « vestes » vous décidez de placer un lien vers les jeans :

http://www.monsite.com/vestes contient un lien vers /jeans –>http://www.monsite.com/jeans

Puis vous restructurez les catégories en sous domaines

http://vestes.monsite.com/ contient le même lien vers /jeans –> http://vestes.monsite.com/jeans

Au pire vous vous retrouvez avec une 404, au mieux avec du duplicate content… pas top

Urls relatifs

Les urls relatifs sont toujours résolus par rapport à un « base uri » qui doit être lui aussi déterminé pour le contexte de la page en cours. Selon le format de l’url relatif, il sera relatif au « base uri » complet ou au répertoire de ce même « base uri » … nommons le « base directory » ( pas sûr que cela soit la bonne appellation)

Base uri

Pour déterminer la valeur absolue d’un Url relatif, il faut donc trouver le « base uri » du document qui sera :

  • si une balise <base> existe dans le head, son attribut « href » une fois résolu
  • sinon l’url du document

Je précise bien « une fois résolu » pour le href de la balise <base>, car dans de rare cas il peut être également donné en relatif et doit donc également être résolu, cette fois par rapport à l’url du document.

on a donc au global cette dépendance :

« url relatif » –> « href de la balise base » –> « url du document »

Le tableau suivant résume les dépendances, notamment avec des urls relatifs, même si on a pas encore vu les règles

Url du document href de la balise base Base uri
http://monsite.com/jeans/femme/ http://monsite.com/jeans/femme/
http://monsite.com/jeans/femme/guess.html http://monsite.com/jeans/femme/guess.html
http://monsite.com/jeans/femme/ http://monsite.com/ http://monsite.com/
http://monsite.com/jeans/femme/ / http://monsite.com/
http://monsite.com/jeans/femme/ http://autresite.com/ http://autresite.com/
http://monsite.com/jeans/femme/ http://monsite.com/jeans/femme/collections/ http://monsite.com/jeans/femme/collections/
http://monsite.com/jeans/femme/ ./collections/ http://monsite.com/jeans/femme/collections/
http://monsite.com/jeans/femme/ ../homme/ http://monsite.com/jeans/homme/
http://monsite.com/jeans/femme/ ../../pantalons/enfant/japan-rags.html http://monsite.com/pantalons/enfant/japan-rags.html

Base directory

le base directory est est lui déterminé une fois que l’on a le base uri. Il correspond simplement au répertoire contenant le fichier en cours et c’est donc le dernier « / » qui détermine le répertoire, sauf lorsque l’on est à la racine.

Base uri Base directory
http://monsite.com/ http://monsite.com/
http://monsite.com http://monsite.com/
http://monsite.com/jeans http://monsite.com/
http://monsite.com/jeans/ http://monsite.com/jeans/
http://monsite.com/jeans/femme.html http://monsite.com/jeans/
http://monsite.com/jeans/femmes/ http://monsite.com/jeans/femmes/

Urls relatifs au base directory

Dès qu’un Url ne commence ni par un protocole (http, ftp, etc..) ni pas un « / » ni par un « # » ni par un « ? », il est considéré comme un Url relatif au base directory.

On peut également spécifier explicitement qu’on utilise le répertoire en cours avec un « . », voire remonter dans l’arborescence avec « .. ». Le tableau suivant résume ceci :

Base directory Url relatif Url résolu
http://monsite.com/jeans/femmes/ guess http://monsite.com/jeans/femmes/guess
http://monsite.com/jeans/femmes/ guess.html http://monsite.com/jeans/femmes/guess.html
http://monsite.com/jeans/femmes/ guess/ http://monsite.com/jeans/femmes/guess/
http://monsite.com/jeans/femmes/ ./guess http://monsite.com/jeans/femmes/guess
http://monsite.com/jeans/femmes/ ./guess.html http://monsite.com/jeans/femmes/guess.html
http://monsite.com/jeans/femmes/ ./guess/ http://monsite.com/jeans/femmes/guess/
http://monsite.com/jeans/femmes/ ../hommes/ http://monsite.com/jeans/hommes/
http://monsite.com/jeans/femmes/ ../hommes/diesel.html http://monsite.com/jeans/hommes/diesel.html
http://monsite.com/jeans/femmes/ ../../vestes/ http://monsite.com/vestes/
http://monsite.com/jeans/femmes/ ../../vestes/hommes/diesel.html http://monsite.com/vestes/hommes/diesel.html

Urls relatifs au base uri complet

Enfin le dernier type d’Url, relatifs directement au base uri complet, va commencer par « ? » s’il représente la query string ou bien par « # » s’il représente le hash fragment.

Sa résolution est du coup hyper simple, car on a qu’a concaténer les deux Urls:

Base uri Url relatif Url résolu
http://monsite.com/jeans/femmes/ ?page=2 http://monsite.com/jeans/femmes/?page=2
http://monsite.com/jeans/femmes/guess.html ?page=2 http://monsite.com/jeans/femmes/guess.html?page=2
http://monsite.com/jeans/femmes/ #detail http://monsite.com/jeans/femmes/#detail
http://monsite.com/jeans/femmes/guess.html #detail http://monsite.com/jeans/femmes/guess.html#detail

Quelques outils pour résoudre cela?

Avant extraction : xpath 2.0

Avant de vous retrouver à faire du retraitement d’url dans un tableur, il faut savoir que le xpath 2.0 propose une fonction qui est très sympa : resolve-uri

Donc imaginons que vous fassiez de l’extraction des liens dans un <div> ayant l’id « texte », vous pouvez vous en sortir directement en faisant le xpath suivant :

Du coup le href sera en absolu au lieu d’être en relatif, ce qui vous simplifiera la vie !

Le problème c’est que je ne connais pas beaucoup de tools SEO qui font de l’extraction en xpath 2.0, et c’est d’ailleurs un de mes gros regrets sur screaming frog dans l’extraction custom ou même dans la console de Google chrome

Je peux vous recommander malgré tout de vous tourner vers l’excellent xidel, un tool en ligne de qui est une véritable tuerie pour l’extraction de contenu, mais qui demande à être bien fouillé

Après extraction : Excel et power query

Power query est une extension de Excel ultra-puissante que j’affectionne particulièrement et sur laquelle on reviendra. Parmi ses nombreux outils, elle propose deux fonction spécifiques aux Urls dont une permettant de combiner des urls relatifs par rapport à un URL de base : Uri.Combine

C’est un peu long pour rentrer dans le détail maintenant, mais sachez que cela existe.

Après extraction : avec un tableur et à la mimine !

Cette méthode a au moins le mérite d’exister, même si elle est potentiellement longue selon la complexité de ce que vous avez extrait.

Il vous faudra importer dans un tableur les données sous la forme suivante :

url du doc, base href, url relatif

et bidouiller avec des règles de concatener selon les différents cas

Clairement pas la méthode la plus marrante, mais si les schémas d’urls relatifs sont simples et qu’il n’y a pas trop de cas différents, cela se fait bien…

 

 

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *