AbaqueInside

Il s'agit bien d'un bogue de mon programme, merci de l'avoir identifié. Il ne distingue pas les redirections serveur des redirections client. Je pense qu'en testant le code retour HTTP (301 dans ton cas si j'ai bien compris), ça devrait pouvoir le faire. J'ai d'autres sangliers sur le feu aussi je ne pense pas pouvoir regarder ça avant quelques jours, après une sérieuse analyse des transactions dans ce cas précis. Aucune crainte, je trouverai la solution. De toutes façons ça n'aurait pas d'impact sur un éventuel projet "Internaute Mystère" car la page remontée serait la seconde, identique à ce qu'a vu le robot du MR.

J'utilise aussi intensivement MS Office, particulièrement en automation à partir de mon langage de développement préféré, en fait j'en suis fan : Microsoft Visual FoxPro (si si il existe toujours, V. 9 aujourd'hui) Avec l'intellisense c'est génial de créer des classeurs, les modifier, bref tout ce qu'on veut à partir d'un programme comme si on était en interactif (sans compter l'import export dans des tables DBF) Plus la doc abondante, précise et accessible. Le tout avec la version ... 97 !

Je ne sais pas ce que signifie au juste "indexation". Tout ce que nous ferions c'est lui envoyer les pages réellement vues par l'internaute moyen pour comparaison avec son cache, rien de plus, en tous cas sans jugement de valeur. Il doit être sûr que la page est vue comme l'internaute. En physique, on dit que l'observateur est neutre dans l'observation, par opposition au robot Google qui influence l'observation. A lui d'apprécier les différences éventuelles, c'est son métier. De toutes façons il s'agirait de vérifier essentiellement les mieux classés, comme à l'arrivée d'une course cycliste.

Qu'est-ce qui redirige ? pointer.js ? Les deux pages sont différentes : - URL demandée : http://membres.lycos.fr/destroyedlolo/galerie/ Poids : 11.35 kb - URL après redirection : http://destroyedlolo.homeunix.org:8080/galerie/ Poids : 8.34 kb Je vais enlever le "trompeur" pour te faire plaisir Je n'ai jamais prétendu avoir un outil parfait, juste une ébauche qui donne des résultats que je trouve encourageants. Il a besoin d'être perfectionné et vos contribs mesurées y aideront. Ce serait pas mal, et agréable, que ceux qui obtiennent de bons résultats en fassent état, pas seulement les failles.

Ma proposition est bien éloignée de ce scénario. Clarifions la donc. Le système s'apparente aux "Clients Mystères" utilisés par la plupart des chaines de magasins franchisés. Les Internautes Anonymes signent un accord avec Google (ou autre). Ce faisant ils lui donnent leur adresse IP fixe qu'ils s'engagent à ne dévoiler à personne (croix de bois croix de fer si je mens etc.) Périodiquement Google identifie un lot d'adresses à vérifier qu'il distribue à ses x Internautes Anonymes (par HTTPS, FTPS ou autre) Les machines des Internautes Anonymes recoivent les adresses, font tourner leur programme dessus et communiquent à Google le contenu des pages lues à ces adresses, après redirection javascript éventuelle bien sûr. Google fait sa sauce derrière, compare à son cache, fait les gros yeux, ce qu'ils veulent. Il ne s'agit en aucun cas de flicage à l'insu de quiconque, mais un programme auquel chacun est libre de souscrire ou non.

Tant mieux si le problème est réellement résolu, je m'en réjouis comme toi. Pour ma part je me méfie un peu des effets de manche Marketing tendant à conforter auprès de la communauté des Webmaster l'image de marque de Google comme "le moteur de recherche donnant les résutats les plus pertinents". En effet, si cet image se dégrade, adieu les AdWords et autres AdSense qui rapportent tant à Google (1.5 milliards de dollars l'an dernier à coups de .02 centime le clic) et leur donne une valeur en bourse double de celle de General Motors. N'oublions jamais que Google est désormais en bourse et doit être gérée comme tel. Ce que je peux dire à coup sûr, c'est que j'ai pas mal de concurrents qui utilisent encore ce "cloaking du pauvre" sans aucun souci.

Bien sûr dans ma proposition les Anonymes ne font rien manuellement. Ils mettent simplement à disposition une machine équipée d'un programme qui visite les adresses et remonte automatiquement les résultats. D'où l'intérêt d'un programme pouvant déjouer les redirections JS. Une sorte de robot bis vraiment anonyme lui.

Il faudrait constituer une association (par exemple "les Internautes Anonymes") et proposer le deal à Google et à ses concurrents. Je pense que ça leur épargnerait des prises de tête pas possibles pour lutter contre les méthodes déloyales. Pour certaines d'entre elles (cloaking), vu que les IP's des robots sont bien connues et ne peuvent changer à tout champ (je rejoins tout à fait l'avis de nos camarades), ils ne peuvent pas faire grand' chose. L'idée serait que, peu après avoir fait passer le robot, Google envoie aux Internautes Anonymes une liste d'adresses fraichement mises en cache. Les IA remontent le contenu des pages réellement vues par l'internaute et Google les compare au cache. Au bout de x comparaisons bien différentes, l'adresse est rétrogradée. Google pourrait Gérer : - les adresses à vérifier (donc pourrait écarter celles qu'il juge sensibles d'un point de vue commercial) - la comparaison avec le cache (comment apprécier la différence, est-elle fortuite ou maligne) - la politique de déclassement éventuel Juste une idée. Pour que le système puisse fonctionner, il faut que les Internautes Anonymes déjouent à coup sûr les redirections par JavaScript. Bien sûr il faut mettre au point les modlités garantissant l'anonymat des Internautes et la fiabilité des visites anonymes.

En effet, coquille dans mon post Que St Google vous entende ! Je vais de ce pas brûler un cierge Je garde un doute sur Jagger car il aurait dû réévaluer les pages en cache et donc les redirections dont je parle plus haut. Mais laissons du temps au temps ... Google est aujourd'hui un paquebot qui ne manoeuvre plus comme un dériveur. Ma proposition, que je répète (la répétition étant paraît-il l'art de la pédagogie), serait de constituer un groupe d'internaute mystère qui remonte à Google (ou autre) les pages réellement vues par l'internaute aux URL données dans les résultats de recherche. D'où l'intérêt d'un outil non Google contournant les redirections JS. Avec un tel outil (le nôtre par exemple), nous pourrions (modestement) lutter contre le cloaking ET les redirections JS. Nous avons eu le même conseil au mois de février que nous avons appliqué scrupuleusement ... et je dois dire que parfois je perds un peu patience ...

Bonjour c.klouchi, Je vais tenter de réexpliquer, plus clairement j'espère, je vais tout faire pour. Comme nous tous, notre société a un site que nous essayons de bien placer dans Google sur certains mots clés. Nous y travaillons depuis plusieurs mois avec des moyens respectueux de la charte de référencement : du vrai contenu que nous espérons pertinent pour nos prospects, placé dans les titres, nous utilisons <em> au lieu de <b> etc.. Nous n'utilisons aucune redirection, page satellite, cloaking, texte caché, ou autres. Il se trouve que, sur les mots clés que nous visons, la première page de Google est peuplée de pages que j'avais qualifiées, à tord semble-t-il, de "satellite", qui sont en fait des pages ayant de nombreux liens et textes non pertinents, dont le but est de leurrer le moteur de recherche, et, quelque part, un JavaScript qui renvoie l'internaute sur la page d'accueil du site. Cette page d'accueil, elle, ne fait bien sûr aucune mention des mots clés en question. Après : - avoir suivi attentivement ces colonnes, - plusieurs Google Dances, - plusieurs Google spam reports infructueux, J'en suis arrivé à la conclusion que Google et ses confrères ne savaient pas détecter les redirections JavaScript. Je me suis dit qu'il y avait peut-être quelque chose à faire et ai travaillé à l'outil présenté en tête de ce fil qui sait détecter ces redirections JavaScript. S'en sont suivi des échanges nourris avec le Hub, dont le dernier a été l'hypothèse légitime de Dan selon laquelle les sites en question pouvaient pratiquer le cloaking, c'est à dire montrer au robot du moteur de recherche une page sans redirection, et à l'internaute lambda la même page avec redirection. J'ai donc poursuivi mon enquête en regardant ce que Google avait en cache, c'est à dire ce que les sites lui avaient effectivement montré. J'ai constaté que les redirections sont bien en cache, que Google en a connaissance et n'a pas su pas la détecter. (rappellons que la redirection trompeuse fait partie des critères du Google spam reports) J'ai mis un bémol en constatant que Google avait mis ces pages en cache il y a un mois ou deux, avant la dernière version de son "Jagger" (je ne saurais dire ce que c'est exactement) réputé pouvoir résoudre ces problèmes. J'attends donc un peu pour tirer des conclusions plus affirmatives. Voilà donc où nous en sommes. N'hésite pas si cela reste obscur ... Il plus décidément facile de s'exprimer par oral que dans une boite de texte !

Tu as raison Dan, Je dois veiller à ne pas émettre d'affirmations hâtives dont ce fil(et) est déjà largement garni. J'ai donc vérifié le contenu du cache Google qui a confirmé mes doutes. Voici ce que j'y ai trouvé pour les deux sites les mieux placés sur nos mots clés : (les URL sont maquillées en "Site Concurrent") Le premier ne fait pas dans le subtil (extraite le 31 août 2005 17:50:34 GMT) <script>location.href="http://www.Site Concurrent.fr"</script> Le second est plus futé (extraite le 10 oct 2005 15:52:46 GMT) <mwhook href="http://www.Site Concurrent.com/" oldref="http://www.Site Concurrent.com/" flags="1"> <script Language="JavaScript" mwhook> <!-- function mwhook(data,id) { if ( data =='http://www.Site Concurrent.com/') return '../index.html' else return data; } //--> </script> Dans les deux cas Google n'a pas détecté la redirection JavaScript. Je conviens que les dates d'extraction sont antérieures à la dernière Google Dance. Je vous propose donc de faire la même vérification d'ici un mois sur les mêmes pages. Si vous avez des exemples de redirections récents, je me ferai un plaisir d'y jeter un coup d'oeil. (j'ai dû utiliser un outil HTTPGet car les redirections empêchent de lire le cache Google avec un fureteur).

En effet, avec le Web, on tombe souvent dans des inventaires à la Prévert :spyder, bot, crawler, cloaking, doorway, etc. , etc., etc.

Merci pour ces conseils. Je vais réfléchir à un algorithme que je soumettrai à la sagacité du Hub

Merci pour ta réponse. En fait, lorsque le visiteur n'est pas une araignée, je lui sers l'anglais par défaut. Je prévois de mettre des petits drapeaux pour les visiteurs qui ne déclarent pas leur langue et n'aiment pas l'anglais par défaut mais les robots ne les verront pas ... En ce qui concerne Google, bizarrement, je vois toujours le même USER AGENT: Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html) Je n'ai jamais vu passer Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.fr/bot.html) Je ne sais comment résoudre le problème, si ce n'est de mettre une page de sélection de langue à la racine du site, ce que je voulais précisément éviter. Je trouve la sélection automatique de la langue assez cool, "user friendly" et "accessibility friendly".

Bonjour, Depuis quelques semaines, les pages de notre site se localisent automatiquement selon le HTTP_ACCEPT_LANGUAGE du fureteur client. Voici le code (ASP, désolé) ' En tête de page <% Dim gcLang, goLoc, gcResult gcLang = Request.QueryString("Lang") If IsEmpty(gcLang) Then gcLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") Set goLoc = Server.CreateObject("abSiteLoc.abSiteLoc") gcResult = goLoc.PageLocSetup _ ("E:\...\monSite.DBF" _ , gcLang _ , Request.ServerVariables("HTTP_USER_AGENT") _ ) Response.AppendToLog(gcResult) %> ' Pour chaque texte <%=goLoc.cTextLoc(448)%> ' 448 est l'index du texte dans la table de localisation Le problème est : Les araignées des MR fournissent un HTTP_ACCEPT_LANGUAGE vide Dans ce cas, nous choisissons une langue au hasard, d'où le paramètre Request.ServerVariables("HTTP_USER_AGENT") (cloaking vertueux) Depuis la mise en place de ce système, notre référencement chute. Quelle est la meilleure méthode pour que le robot prenne en compte la langue de la page ? <html lang="xx"> ? <meta name="language" content="xx" /> ? autre ? Merci.