urlrewriting + sessions => duplicate content ?
6 messages • Page 1 sur 1
Consultez la formation au référencement naturel Google de WebRankInfo / Ranking Metrics
urlrewriting + sessions => duplicate content ?
Bonjour
Voilà, j'ai mis en place les sessions sur mon site, et j'ai fait en sorte, que ces sessions soient valables, que le visiteur accepte les cookies, ou non.
Ce qui fait que, pour transmettre l'identificateur de sessions, je le place dans l'url. Or pour les Courses anciennes de mon site, les pages sont urlrewritées, ce qui fait qu'il y a autant d'urls différentes que de visiteurs, pour un même contenu résultant de la page.
Les urls en questions, diffèrent seulement par un token alphanumérique ( l'identificateur de session ), qui est situé en fin d'url, avant la terminaison ".html"
Les paramètres dans l'urls, sont séparés par des virgules, celà n'a pas d'importance, puisque les virgules sont acceptées par la norme qui régit le format des urls. ( Je ne sais pas le numéro RFC de cette norme, mais j'ai suivi les indications sur le site Wri pour faire l'urlrewriting. )
Donc, sachant qu'un grand nombre d'urls ( autant que de visiteurs ), vont aboutir aux mêmes contenus de pages, y aura-t-il un duplicate content de la part de GG, quand les pages en questions, seront ( ou ne seront pas ) indexées par GG ? ( prochaine GD je présume ).
En fait, j'ai fait cet url rewriting, précisément pour que ces pages soient indexées par GG, et aussi car leur longueurs ( noms des paramètres + paramètres ), étaient telles, que le serveur me donnait une erreur car les urls sans urlrewriting, étaient trop longues...
Quant aux sessions, ce n'est peut-être pas indispensable, c'était l'autre raison de la longueur excessive des urls avec paramètres.
Merci beaucoup à vous pour vos réponses à ma question.
Bien à vous.
Amicalement.
Jean-François Ortolo
Voilà, j'ai mis en place les sessions sur mon site, et j'ai fait en sorte, que ces sessions soient valables, que le visiteur accepte les cookies, ou non.
Ce qui fait que, pour transmettre l'identificateur de sessions, je le place dans l'url. Or pour les Courses anciennes de mon site, les pages sont urlrewritées, ce qui fait qu'il y a autant d'urls différentes que de visiteurs, pour un même contenu résultant de la page.
Les urls en questions, diffèrent seulement par un token alphanumérique ( l'identificateur de session ), qui est situé en fin d'url, avant la terminaison ".html"
Les paramètres dans l'urls, sont séparés par des virgules, celà n'a pas d'importance, puisque les virgules sont acceptées par la norme qui régit le format des urls. ( Je ne sais pas le numéro RFC de cette norme, mais j'ai suivi les indications sur le site Wri pour faire l'urlrewriting. )
Donc, sachant qu'un grand nombre d'urls ( autant que de visiteurs ), vont aboutir aux mêmes contenus de pages, y aura-t-il un duplicate content de la part de GG, quand les pages en questions, seront ( ou ne seront pas ) indexées par GG ? ( prochaine GD je présume ).
En fait, j'ai fait cet url rewriting, précisément pour que ces pages soient indexées par GG, et aussi car leur longueurs ( noms des paramètres + paramètres ), étaient telles, que le serveur me donnait une erreur car les urls sans urlrewriting, étaient trop longues...
Quant aux sessions, ce n'est peut-être pas indispensable, c'était l'autre raison de la longueur excessive des urls avec paramètres.
Merci beaucoup à vous pour vos réponses à ma question.
Bien à vous.
Amicalement.
Jean-François Ortolo
e-kiwi a écrit:il y a vraiment un interet à demarrer une session des que l utilisateur arrive sur ton site ? tu ne peux pas la faire demarrer que lorsque c est nécéssaire ?
Bonjour e-kiwi
Ben, le problème est que, de toute façon, à terme ( quand mon site sera payant, pas avant quelques années ), il devrait être possible aux visiteurs, de passer de la partie payante à la partie gratuite, et inversement, sans perdre l'authentification.
Celà nécessite évidemment que ce soit la même session qui se déclenche, au moins sur la partie privée. Or, je veux que même les visiteurs refusant les cookies, puissent garder l'authentification. Celà nécessite donc, que l'identificateur de session, soit mémorisé quelque part, et il ne peut l'être qu'en le transmettant par les urls...
A la rigueur, je pourrais simplement ne pas urlrewriter la partie privée ( la partie publique ne l'est pas ), et nommer la session comme je l'ai fait ( j'ai choisi SES comme nom d'identificateur de session ), mais à ce moment-là, il y aurait trop de paramètres dans les urls, et GG n'indexerait pas les pages de toute façon.
L'autre option étant, bien sûr, de demander aux personnes voulant s'identifier, de permettre les cookies, mais les turfistes ( le public de mon site ), n'y connait en général rien à la config des navigateurs.
Ceci étant, le seul intérêt des sessions dans mon cas, sera, le moment venu, d'assurer l'authentification pour les visiteurs abonnés. Or, les firmes intermédiaires de paiement, proposent toutes des packages PHP d'interface, assurant cette authentification. Il est vrai que ces packages requièrent l'usage des cookies pour fonctionner...
Donc, quel serait ton conseil ?
- Ne plus mettre de sessions, laisser le rôle d'authentification aux packages des firmes intermédiaires de paiement ?
- Laisser les sessions, obliger les visiteurs à accepter les cookies ?
- Autre ?
Merci beaucoup pour ta réponse à ce problème, qui concerne surtout la faisabilité d'associer l'urlrewriting et les sessions.
Bien à toi.
Amicalement.
Jean-François Ortolo
pour ma part, les gens refusant les cookies ne sont pas les bienvenus sur mes catalogues
j'ai la chance de ne jamais avoir eu de plainte de client (donc je ne suis jamais tombé sur un les refusant) et à choisir, je preferes perdre 1/1000ieme des commandes à cause des cookies mais gagner 200% de trafic grace à google
si vraiment tu penses que la plupart de tes visiteurs interdisent les cookies (tu en est sûr?) et que la session demarre tout le temps, tu as aussi la possibilité de ne pas faire demarrer la session si le visiteur est un robot, je ne penses pas que cela soit considéré comme une technique frauduleuse, tu ne caches rien, ne trompes aps, ou ne modifie pas ce qui compose ta page. je ne sais pas ce qu'en penses les autres ?
si vraiment tu penses que la plupart de tes visiteurs interdisent les cookies (tu en est sûr?) et que la session demarre tout le temps, tu as aussi la possibilité de ne pas faire demarrer la session si le visiteur est un robot, je ne penses pas que cela soit considéré comme une technique frauduleuse, tu ne caches rien, ne trompes aps, ou ne modifie pas ce qui compose ta page. je ne sais pas ce qu'en penses les autres ?
Bonjour e-kiwi
Merci beaucoup de ta réponse.
Je vais suivre ton conseil.
Je vais donc retirer l'identificateur de session des urls, comme celà il n'y aura plus de problème.
Je m'y met dès ce soir.
J'espère que GG ne m'aura pas filé un duplicate content entre temps...
Bien à toi.
Amicalement.
Jean-François Ortolo
Merci beaucoup de ta réponse.
Je vais suivre ton conseil.
Je vais donc retirer l'identificateur de session des urls, comme celà il n'y aura plus de problème.
Je m'y met dès ce soir.
J'espère que GG ne m'aura pas filé un duplicate content entre temps...
Bien à toi.
Amicalement.
Jean-François Ortolo
6 messages • Page 1 sur 1
Formation recommandée sur ce thème :
Formation Référencement naturel Google : apprenez une méthode efficace pour optimiser à fond le référencement naturel dans Google de façon durable... Formation animée par Olivier Duffez et Fabien Facériès, experts en référencement naturel.
Tous les détails sur le site Ranking Metrics : programme, prix, dates et lieux, inscription en ligne.
Lectures recommandées sur ce thème :
- Gestion des langues et des sessions en PHP / MySQL
- Incidence du PHP sur le référencement
- Comment éviter les contenus dupliqués (avec/sans le www)
- Référencement : le problème des sessions des pages PHP
- Le référencement de pages PHP
- link rel=canonical pour réduire les contenus dupliqués
- Formation au référencement Internet plébiscitée : Ranking Metrics
- Début du Full Crawl
- Comment créer une page web en PHP
- Google Developer Day 2007 : à Paris et dans 9 autres villes
- Analyse de similarité textuelle
Cet outil vous permet de calculer la similarité entre 2 pages web. L'algorithme utilisé repose sur l'analyse des occurrences des mots (mais pas sur leur positionnement dans les pages). Google utilise cette notion à certains endroits dans son algorithme, mais de façon bien plus évoluée que ce petit outil... Avoir des pages trop similaires peut entraîner des problèmes d'indexation... Cet outil vous permettra peut-être de résoudre certains problèmes de contenus dupliqués.
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités




le forum