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.

Sur les mots clés qui nous concernent, les premières places sont toujours trustées par des pages satellites, pardon des Pages statiques à redirections douteuses. Google et son compère Jagger semblent avoir encore du mal à détecter les redirections JavaScript.

Content qu'une de mes idées ait pu trouver un accueil favorable dans ces colonnes Perso. je suis convaincu que les MR devront un jour envisager de recourir à des "internautes mystères". Sur les mots clés qui nous concernent, les premières places sont toujours trustées par des pages htm avec redirections douteuses. J'insiste sur htm car cela signifie que, sauf si le Webmestre de ces sites est un virtuose, ce dont je doute, ce sont des pages statiques, donc pas "cloakées" (le cloaking nécessite des pages dynamiques type PHP, ASP, etc.). Il semble que Jagger ait encore un peu de mal avec le "cloaking du pauvre", c'est à dires les redirections JavaScript de base. C'est justement l'objet de l'outil présenté par ce fil. Je veux bien qu'il faille s'attaquer au cloaking sophistiqué, mais il reste encore tant de redirections "basiques" ... On pourrait résoudre d'abord les problèmes les plus simples, non ? Disons qu'il s'agit plutôt de pages dont le contenu dépend du visiteur. C'est un bon principe pour, par exemple, localiser un site selon les HTTP_ACCEPT_LANGUAGE du fureteur client. En revanche il est détourné pour leurrer les moteurs : selon le visiteur, le programme serveur envoie un contenu différent ou parfois redirige vers une autre page. AMHA la clarification réelle de ces techniques, même si elle peut mal inspirer ceux qui ne les connaissent pas encore, permettrait de lutter plus efficacement contre. Comme dans le cyclisme, il reste à savoir si la majorité des Webmestres préfèrent un web propre ou bricolé. A la lumière de cette longue conversation, je me permets d'avoir quelques doutes sur la pureté des intentions moyennes. Je ne sais pas si ça a déjà été organisé ici, mais un sondage sur "Voulez-vous réellement un web clean" serait assez intéressant.

Okayyyy, d'où les incompréhensions. Il faut dire que la littérature sur ces sujets est pour le moins hermétique et qu'on a bien du mal à s'y retrouver. (cf. spam report et autres de Google, que ceux qui comprennent lèvent le doigt ) Naïvement je voyais les pages satellites tournant autour de la page cible vers laquelle elles renvoient toutes. Le terme anglais "doorway page" me semblait illustrer à peu près la même chose. Tout ça aura au moins eu le mérite d'apporter cette clarification. Et je ne suis sûr de ne pas être le seul à faire cette confusion. Vaut mieux ne pas imaginer ce que peuvent comprendre les clients sur le sujet ... J'ai changé le titre erroné du fil ... Merci encore de vos contribs.

Ahum, tu n'as peut-être pas bien compris. Notre outil de détecte pas les pages référençant des pages satellites mais les pages satellites elle-mêmes, qui redirigent vers une autre

En effet, et je ne vois pas l'intérêt de le détecter, seul le résultat compte, non ? Voyons les choses autrement. Le cloaking sur IP/USER AGENT consiste pour le serveur à envoyer, pour une même adresse de page, un contenu différent à l'araignée du moteur de recherche et à l'internaute. Si cette différence de contenu est une redirection masquée au MR, mon outil la voit (normalement), c'est d'ailleurs son seul but. Si c'est tout le contenu de la page qui est trafiqué, c'est un autre problème que mon outil n'a nullement l'ambition d'adresser. La seule solution envisageable serait de passer après le robot comme internaute lambda, lire la page et l'envoyer au MR pour comparaison avec le cache. Et c'est une toute autre histoire... A nouveau, je pense que ce genre d'approche "internaute mystère" serait très intéressante. Il ne s'agit pas de vérifier toutes les pages mais, disons, les dix premières sur les 20 % de mots clés représentant 80 % des recherches, et ce de façon aléatoire. Contrôle anti-dopage est probablement la meilleure analogie. Et je verrais très bien une communauté comme le Hub jouer les contrôleurs.

Parfaitement d'accord avec cet exemple. Le Web dynamique complique l'analyse. Néanmoins je reste convaincu de la validité du principe : analyser la page telle l'internaute la verra. Les textes apparaissant de ci de là devraient avoir moins de poids que ce qui est directement visible. Sinon, j'aurais peut-être une solution ... mais pas sous le coude là tout de suite.

Enfin ça devient sportif et fair play, j'aime ça ... Disons une bouteille de champagne ça va ? Justement je ne la verrai surtout pas, je verrai la page comme l'internaute. Par exemple J'interroge Google sur 'webmaster' Il me retourne une page avec des hyperliens, où le Hub en bonne place Je vérifie chaque adresse comme si je l'avais copié - collé dans ma page de test, comme n'importe quel internaute standard. J'ignore ce que Google a en cache ou autre, je regarde la page comme un internaute. Est-ce plus clair ? (cross finger)

Mon cher Dan, Tout d'abord je te renouvelle perso. mes félicitations pour le Hub dont, je crois, tu es l'auteur. Ma dernière proposition n'allais pas dans ce sens où j'ai bien compris que ne peux rien faire. Je ne suis plus dans l'optique "Araignée" mais plutôt "Client Mystère" Je vais tâcher d'être clair J'ai un serveur indépendant de Google et consorts Je dresse une liste de mot(s) clé(s) à surveiller Pour chaque mot(s) clé(s) surveillé(s) : - Je requête à Google sur ces mots clés - Je vérifie en douce les 10 premières adresses de page. Pour cela j'envoie des requêtes à partir de mon serveur, avec un USER AGENT et une IP complètement indépendante de Google et consorts, a priori indétectable sauf Gross Sapotache oder Espionnache . Je remonte les pages satellites à qui de droit.

Ben si ou alors je dois prendre un aspegic au plus vite Pourquoi indexer des textes que ne verra pas l'internaute ? Bon d'accord pour le "alt" car il décrit le contenu d'une information graphique inaccessible à l'araignée (bien qu'il existe, paraît-il des logiciels capables de reconnaître des formes d' image, par exemple certaines parties du corps humain ) Mais pour le reste ? 90 % des internautes acceptant les Scripts, seuls 10 % d'entre eux verront le texte dans <noscript>. Sachant que lorsqu'il reçoit une demande de recherche, Google ou autre ne sait pas si l'émetteur accepte les scripts ou non, le texte <noscript> devrait, AMHA, être pondéré pour tenir compte de la moindre audience. etc. Bon, c'est peut-être une controverse philosophico-sémantique et là je dois avouer que, en tant que technicien de base, je ne tiens pas la route.

Désolé de te contredire mais tabuler les balises d'une page même lourde et analyser leur contenu se chiffre en millisecondes. Avec plus de 80.000 machines tournant 24 heures sur 24, Google a encore de la marge.