URL Rewriting : resultats decevants

[sgueg1352]

Bonjour,

Je débute un peu en matiere de referencement.

Je viens de transformer mon site avec la methode de l'URL Rewriting.
Il etait auparavant pas trop mal placé sur GG, un peu parcequ'il a quelques années d'existence.
La mise en ligne en URL Rewriting s'est faite il y a environ un mois, et depuis, le referencement est beaucoup moins bon. J'ai en outre pas mal de pages referencées avec seulement l'URL de la page, est l'affichage du cache est terrible.
De plus, je viens d'apprendre sur WRI que l'usage des sessions est peu apprecie par Google, or mon site est totalement basé sur ce système, une session est créée a chaque connection.

Que faire ?
Faut-il simplement attendre ?
Merci d'avance

[mf]

pour les sessions, ca dépend si le phpsessid est dans l'url c'est pas le top...

pour le passage en url rewriting moi j'ai refait mon site avec ca en mai et en 15 jours j'ai perdu presque 30% de visiteur sur google mais là en septembre tous est revenu dans l'ordre je pense pas que cela soit aussi long (car pour moi les vacances c'est une mauvaise période) mais je pense que 2 bon mois seront nécessaire pour l'indexation des nouvelles pages et le repositionnement.

[WebRankInfo]

avec ou sans URL Rewriting, les sessions (dans les URL) sont très pénalisantes voire bloquantes pour le référencement.

[sgueg1352]

Merci de vos reponses rapides.

Donc, pour les effets de l'URL Rewritng, ca me rassure un peu, on va attendre.

Par contre, en ce qui concerne les sessions, j'ai pas mal lu les articles et posts sur ce sujet, et je ne vois pas la solution.
Puisque GG refuse les cookies, il est inevitable de passer l'id de session dans l'url, soit "en dur" (par exemple avec SID), soit en activant le parametre :
session.use_trans_sid = 1 dans le php.ini, ce qui est le cas dans mon site.
Dans ce cas-la, l'id de session n'apparait pas dans l'url (browser), mais est transmis de maniere transparente, ce qui gene quand même GG.

Etes-vous d'accord avec mon analyse, ou connaissez-vous une parade qui m'échappe ?

[e-kiwi]

as tu vraiment besoin de gerer le parcours de google sur ton site en session ?

[sgueg1352]

Le probleme, c'est que ce site est énorme, avec plein de fonctionnalités, et que ce n'est pas moi qui l'ai développé.
Le site est bilingue francais anglais, et des qu'un visiteur se connecte, une session est automatiquement créée (avec la langue entre autres).
De plus, il contient un panier virtuel basé sur les sessions. Donc, pour ne pas perdre le contenu du panier, je suis obligé d'avoir un session_start() a chaque page !

Si je peux repérer que le visiteur est GG, je peux peut-être éviter de demarrer une session. Encore que ce probleme de langue semble vraiment bloquant, car on interroge la base anglaise ou francaise selon la variable de session definie.

La solution serait peut-etre que je mette une variable langue par defaut (si la variable langue de session est vide, ce qui ne serait le cas que pour GG), qui me permette d'interroger une ou l'autre des bases.
Dans ce cas, le site ne serait plus reference que dans une langue, a moins que je ne change cette variable regulierement.

Peut-on repérer que le visiteur est un robot ?

[mf]

si la session n'est pas transmise dans l'url , a mon avis sa gène pas google

[sgueg1352]

L'id de session est inevitablement transmise je pense, même si on ne la voit pas dans l'URL.

[e-kiwi]

et bien ne fait pas demarrer la session desuite :

qd le client s identifie, ca créer un cookie. et tu ne fait partir la session que si l utilisateur s est identifié :
if ($HTTP_COOKIE_VARS["ta-variable-de-controle"]) session_start();

et hop, google ne s identifiant pas sur ton formulaire, il ne crée pas le cookie, donc la session ne part pas

tadaaaam

[sgueg1352]

Ohh la, si c'était si simple !

Merci pour vos reponses, je vais creuser un peu du coté du traitement des sessions.