Session et Cookies

Tout dépend de ce que tu veux faire. Un accès à certaines zones de ton site par cookie n'est pas non plus forcément souhaitable en terme de référencement.

Peux-tu préciser :?:

 

Salut,

En effet, les sessions ajoutent des SESSION ID à la fin de tes urls lorsque le visiteur n'accepte pas les cookies de sessions (google par ex)

ton lien : "index.php?page=news" devient "index.php?page=news&SID=1564387384413131"

Et les moteurs ne suivent pas ces liens...

Tu as plusieurs solutions :

1 - N'activer les sessions dans les parties de ton site que lorsque cela est vraiment nécessaire...

2 - Si tu as besoin, comme moi sur mon site, d'activer les sessions tt le temps, il te suffit de vérifier que ce n'est pas un moteur avant d'activer les sessions sur ta page...

Voici le code PHP que j'ai chez moi :wink: :

Code:

/* Si le visiteur est un crawlers d'un moteur de recherche, on désactive les sessions pour qu'il puisse naviguer sur toutes les pages et on envoie un mail */

if(
	(!ereg('216.239.46.',$_SERVER['REMOTE_ADDR'])) 		/* 	GoogleBot 	*/
	AND 
	(!ereg('64.68.8',$_SERVER['REMOTE_ADDR']))			/* 	GoogleBot 	*/	
	AND 
	(!ereg('212.27.33.',$_SERVER['REMOTE_ADDR']))		/* 	Pompos Dir 	*/
	AND
	(!ereg('66.77.73.',$_SERVER['REMOTE_ADDR']))		/* 	FastSearch 	*/
	AND 
	(!ereg('66.28.250.',$_SERVER['REMOTE_ADDR']))		/* 	Alexa 		*/
	AND
	(!ereg('209.237.238.',$_SERVER['REMOTE_ADDR'])) 	/* 	Alexa	 	*/
	AND 
	(!ereg('204.123.28.',$_SERVER['REMOTE_ADDR']))		/* 	Mercator 	*/	
	AND 
	(!ereg('216.35.116.',$_SERVER['REMOTE_ADDR']))		/* 	Inktomi 	*/
	AND
	(!ereg('66.237.60.',$_SERVER['REMOTE_ADDR']))		/* 	OpenFind 	*/
	AND 
	(!ereg('64.152.75.114',$_SERVER['REMOTE_ADDR']))	/* 	Astalavista	*/
	AND 
	(!ereg('209.73.162.54',$_SERVER['REMOTE_ADDR']))	/* 	Astalavista */
	AND 
	(!ereg('216.39.48.',$_SERVER['REMOTE_ADDR']))		/* 	Astalavista */
	AND
	(!ereg('64.140.48.30',$_SERVER['REMOTE_ADDR'])) 	/* 	SlySearch 	*/
	AND 
	(!ereg('66.147.154.3',$_SERVER['REMOTE_ADDR']))		/* 	Almaden 	*/	
	AND 
	(!ereg('65.214.36.150',$_SERVER['REMOTE_ADDR']))	/* 	AskJeeves 	*/
	AND
	(!ereg('64.68.84.',$_SERVER['REMOTE_ADDR']))		/* 	GoogleImage	*/
	AND 
	(!ereg('195.101.94.209',$_SERVER['REMOTE_ADDR']))	/* 	Voila		*/
	AND
	(!ereg('209.249.66',$_SERVER['REMOTE_ADDR']))		/* 	WiseNut		*/
	AND 
	(!ereg('209.249.67',$_SERVER['REMOTE_ADDR']))		/* 	WiseNut		*/		
	AND
	(!ereg('195.154.174',$_SERVER['REMOTE_ADDR']))		/* 	Exabot		*/		
	AND
	(!ereg('66.196.',$_SERVER['REMOTE_ADDR']))			/* 	Inktomi		*/
	AND
	(!ereg('217.154.244',$_SERVER['REMOTE_ADDR']))		/* 	Migrabot	*/
	AND
	(!ereg('18.29.1.50',$_SERVER['REMOTE_ADDR']))		/* 	W3c	-XHTML	*/
	AND
	(!ereg('216.88.158.',$_SERVER['REMOTE_ADDR']))		/*  Looksmart	*/
	AND
	(!ereg('161.111.200.',$_SERVER['REMOTE_ADDR']))		/*  Moteur ES	*/
	
  ){

	/* Ce n'est pas un crawler recensé, on démarre la session */
	session_start();

}

 

Limite cloaking ton affaire :wink:

 

Ah tiens c'est vrai ! Je n'avais pas remarqué... :lol:

 

Merci, je ne dis pas qu'il n'y a pas mieux mais, au moins, cela a le mérite de fonctionner...

De rien, je pense que je vais bientôt revoir le code d'ailleurs... Pense aussi à mettre à jour les IP d'autres crawlers qui pourraient apparaître...

Pierre-Louis

 

Cela dépend aussi des langages, et puis, ils ne font pas ça en amateurs non plus !

Ah, j'oubliais, ils passent aussi peut-être sur WRI...

 

Si l'amateur arrive vraiment à faire un site de niveau professionnel (style fnac.com), la différence entre lui et le professionnel est... qu'il est un peu c** de ne pas en vivre

 

En passant comme ca, c'est bizarre cette histoire de session passé en paramètre en PHP, j'ai jamais compris ca... EN ASP par exemple, les Session c tout bétement du type Session("LE_NOM_DE_SESSION") et puis basta, ca ne rajoute rien dans l'url de la page... Bref je comprend pas là... (enfin c'est un peu hors sujet)

 

PArce qu'elles sont passées par des cookies. Mais si les cookies ne sont pas acceptés, il faut passer par l'url.

François

 

Pas du tout. Ca ne change pas le contenu de la page, ca permet juste aux moteurs de voir ce qu'ils verraient s'il acceptaient les sessions/cookies.
Il y avait eu des discussions sur cela à propos entre autres des sessions de PHPBB avec entre autre la participitation de Googleguy.

François

 

C'est bizarre ca... En ASP, les variables de session n'ont besoin ni de cookie, ni de rien d'autre, tout se passe sur le serveur...

 

Bonjour,

Oui moi non plus je n'ai pas trouvé d'autre solution que de détecter s'il s'agit d'un robot avant de lancer la session.
Mais ce problème se pose surtout pour un hébergement mutualisé, pour ceux qui ont accès au php.ini il suffit de mettre :
session.use_only_cookies = 1
Il y a aussi la possibilité de modifier la valeur d'une variable du php.ini uniquement pour un script :
ini_set
Mais cette fonction est souvent bloquée par les hébergeurs

galerie-net.com > Je pense que les grosses boutiques rendent obligatoire l'utilisation des cookies pour prendre une commande et utilise session.use_only_cookies = 1, en tout cas c'est le cas de certaines.

 

Peut-etre, je ne connais pas trop ASP
Mais si c'est comme cela, il fait comment pour détecter les AOLiens qui changent d'IP toutes les 5 minutes?

François

 

D'accord avec toi, si c'est fait dans cet esprit, ça n'a pas lieu d'être sanctionné.
En revanche à partir du moment ou GG accepte ce "cloaking pour la bonne cause", il faut qu'ils oublient l'idée de sanctionner le "cloaking malhonnête" (que pourtant ils condamnent officiellement). Comment en effet peuvent-ils espérer faire la différence entre le "bon" et le "mauvais" cloaking... à part sur dénonciation.

 

Je sais pas... A vrais dire, je ne me suis jamais vraiment posé la question... Faut dire que c'est stupide leurs système de changer d'ip toute les 5 minutes... Enfin bon, je m'arreterai là pour ce débas, car il n'a pas sa place dans ce thread effectivement...
Encore désolé pour l'initiateur de ce thread.

 

Pour détecter du cloaking, il faut qu'ils vérifient si version "google" <> version "normale".
Si supprimer les cookies pour google ne change rien, pas de pb.

François

 

Disons que le site utilise enable_trans_id = 0 ce qui force la "transmission" des sessions php par cookies :arrow: ... GGBot va t'il prendre la session (les cookies) ?????

:arrow: Le "start_session()" à chaque page va t'il perturber gg ? :arrow: Même si la page affiche tout le contenu sans utiliser de sessions. :?: :?:

C'est compréhensible ce que j'ecris? :?: 8O

 

Bonjour tout le monde,

A ma connaissance ce n'est pas le session_start () qui perturbe google mais le SID dans l'URL.

Pour pallier à ce problème, on peut ne pas afficher ce dernier dans l'URL, il suffit, pour cela de modifier l'option du tran_sid soit activée. Chez certains hébergeurs, cette option est activée par défaut donc aucun problème de passage de bot. (c'est le cas d'OVH mutualisé).

Loïc.

 

Ici on parle de désactiver le phpsessid par url.

https://www.webrankinfo.com/forum/t/url-rewriting-et-sessions.5008/


Normalment ton hebergeur devrait accepter de paramétrer cette variable par .htaccess.

 

Bonne question...

 

Oui.
Pour faire ça de façon efficace à l'échelle de GG, il faut que ce soit fait par des robots.
Il faut donc que GG envoie des robots "anti-cloaking" dont le user-agent n'est plus "Googlebot etc..." et dont l'adresse IP n'est pas l'une des IP des GGbots connus.

Mais là, ils pénaliseront injustement le site de binarythinking: dilemme.

 

:cry:

Sinon pour en revenir à la discussion, je conseille quand même à tt ceux qui se posent la question de garder les sessions. Revenir en arrière vers les cookies serait une absurdité à mon sens.

De mon côté, comme j'ai la chance d'avoir mon propre serveur :lol: , je vais pouvoir modifier la config d'Apache grâce à vos conseils et éliminer les SID dans les url. Pour ceux qui n'ont pas cette opportunité, faites en sorte que votre site s'adapte aux bots afin que le fait de refuser les cookies ne les empêche pas de crawler votre site (ça présente aussi des avantages pour vous ! :wink: ). Tant que vous ne basculez pas du côté obscur de l'adaptabilité de votre site, c'est justifié !

Quant à la mini-discussion sur ASP, je tiens à préciser que les systèmes de sessions (PHP ou ASP) utilisent forcément des cookies en local chez le visiteur. Pour info, les sessions PHP ne sont, ni plus ni moins, qu'un système de cookies amélioré.

A+ Tout le monde et bon courage, Binary