[Duplicate content] URL canoniques et le Hash qui remplace le "?"

[XIV-V]

Bonjour,

Première fois que je poste sur votre forum. Je félicite d'ailleurs tous les participants pour la qualité des infos qu'on y trouve. Etant donc assez récent sur votre site, je craint quelque peux d'aborder une question déjà débattue vu la date de son annonce, bien que la recherche ne m'ai pas apportée de réponses.

Ca concerne les URL. J'ai lû un article qui vante les mérites du Hash # dans les url au lieu du "?". P.ex www.monsite.com/?id=123 deviendrait www.monsite.com/#id=123.

Si j'ai bien compris, les moteurs de recherche ignorant ce qui suis le #, ils n'indexent pas des url pouvant provoquer du duplicate content... Très bien, mais quelque chose m'échappe : le ?id=123 permet d'envoyer une requête en GET au serveur, et donc d'avoir une page en conséquence. Mais avec le #, mon serveur (Apache) ignore les paramètres qui lui sont passés !!!

Je me suis documenté, et un peu partout où on parle de ce remplacement "?" contre "#", on procède à cette substitution comme si de rien n'était que tout était beau dans le meilleur des mondes sans aborder la problématique de l'utilité des paramètres passés au serveur qui du coup ne les reconnait plus.

Quelqu'un pourrait-il m'expliquer la subtilité qui m'échape ? Faut-il configurer Apache pour qu'il comprenne le # comment étant le nouveau "?" ou faut-il faire du URL rewriting dans le htaccess afin de remplacer le # transmit par url en "?" qui sera lui compris par le serveur ?

Je vous en remercie d'avance

Sam.

[jcaron]

Je ne sais pas très bien où tu as vu ça et dans quel contexte exactement... Le # est assez fortement utilisé dans des contextes Ajax quand on veut pouvoir charger d'autres pages sans faire de reload, mais qu'on veut quand même que l'utilisateur puisse bookmarker la "nouvelle" page (le code JS change le #fragment quand il charge une nouvelle page (ce qui ne provoque pas de rechargement par le browser), et le vérifie au chargement d'une page pour voir s'il doit sauter à cette nouvelle page).

Mais dans ce contexte les moteurs voient encore les "vraies" URLs sans le #fragment (dans les href, pendant que la partie Ajax est dans les Onclick par exemple).

Aurais-tu quelques liens de pages qui expliquent une autre utilisation de #?

Jacques.

[XIV-V]

Voici le lien principal : http://www.seoland.fr/utilisation-hash-urls-seo/ publié en février 2009.

Il y a une video à la fin qui l'explique (en anglais).

Je me dis bien que je dois me mélanger les pinceaux, mais j'en ai parlé autour de moi et apparemment la même incompréhension est née.

Si je me suis trompé et que j'ai compris l'article de travers, je te serais reconnaissant de m'expliquer où je me suis planté.

Merci en tout cas pour ta réponse.

A bientôt.

[jcaron]

Je n'ai pas regardé la vidéo, mais l'article est plutôt clair sur les cas de figure où c'est utile, ce n'est pas du tout un truc général genre on remplace ?id=123 par #id=123 si id=123 donne un contenu différent. C'est plutôt pour des choses comme des liens d'affiliation (mais ça a l'inconvénient qu'il faut gérer le tracking en JS côté client, alors qu'un bon 301 côté serveur fera largement l'affaire).

Jacques.

[XIV-V]

D'accord, j'en avait fait une généralité.

Merci pour ta réponse.

[XIV-V]

En faite, j'ai encore une suspicion...

Concernant les URL d'affiliation... on appelle un lien genre www.monpremiersite.com/?ref=2340234234

Mais ce paramètre ref=... doit pouvoir être récupéré par le serveur de www.monpremiersite.com afin d'être traité non ? Si on remplace par www.monpremiersite.com/#ref=2340234234 alors même problème que ce que je citait plus tôt : le serveur ne tient pas compte de ce qui viens après le "#" et donc ignore qu'on lui passe un paramètre...

Me trompes-je ?

[jcaron]

Oui, le serveur ne verra jamais cette partie-là, en tous cas pas directement. Tout dépend de la façon dont le tracking est fait. Un tracking par redirect, ou directement par le serveur cible ne fonctionnera pas avec ça, c'est sûr. Un tracking par un code JS (comme celui d'Analytics et d'autres) n'aura pas de problème pour lire ça. Il faut évidemment qu'il soit conçu pour...

Jacques.

[XIV-V]

merci