Le lancement de Froogle UK (Royaume Uni) semble imminent (comme l'avaient prédit plusieurs personnes dont Zorgloob récemment). Déjà accessible sur www.google.co.uk/froogle, le site n'est pas encore lié depuis la page d'accueil www.google.co.uk/.

Même si Froogle gère plusieurs monnaies (le dollar américain, le dollar australien, le dollar canadien, l'euro, la livre sterling et le yen), l'affichage des prix semble être par défaut en dollars y compris sur le site UK.

A quand la version française ?

L'éditeur de solutions de géolocalisation Multimap et Google s'allient pour fournir des liens sponsorisés ciblés par zone géographique. Le partenariat va permettre à Google de proposer des campagnes publicitaires locales via le programme Google Adsense. D'après Multimap, un quart des annonceurs est aujoud'hui intéressé par des offres publicitaires ciblées géographiquement.

Source : Le Journal du Net

Jusqu'à 8 annonces Google sont affichées à côté des informations fournies sur l'ensemble des sites internationaux grand publicde Multimap. D'après Sean Phelan, le PDG de Multimap, les annonces seront prochainement rendues encore plus ciblées (elles sont pour limitées à une ville).

Google connait déjà Multimap : son centre d'assitance AdWords recommande Multimap à ceux qui cherchent à déterminer leur localisation géographique précise ;-)

D'après Tim Bray, Google Images accorde bien plus d'importance au nom du fichier qu'au texte alternatif fourni par l'attribut ALT de la balise IMG.

C'est bien dommage car le nom du fichier est bien moins caractéristique du contenu de l'image, surtout depuis la multiplication des photos prises par les appareils photo numériques qui numérotent les fichiers images à l'aide d'un identifiant unique (en général ce nombre est lié au nombre de photos prises depuis le début de l'appareil).

Google vient de sortir une nouvelle version de sa barre d'outils (v2.0.114-5) pour corriger des vulnérabilités découvertes la semaine dernière. Il n'est plus possible d'injecter du code distant dans MS Internet Explorer.

Selon SecurityTracker, la rubrique "A propos" de la barre d'outils de Google ne filtrait pas correctement le code HTML. Il était possible de créer un fichier HTML qui, une fois chargé dans le navigateur de l'internaute, pouvait invoquer la page "A propos" et exécuter ainsi les scripts situés dans cette page.

Americas, un membre de WebRankInfo, a annoncé dans le forum référencement de WebRankInfo que Google vient d'ajouter en haut des pages de résultats des liens vers des plans de villes - pour peu que votre recherche porte sur le nom d'une ville. Cela fonctionne aussi si vous ajoutez le mot "plan" à votre requête, mais cela ne fonctionne plus si vous utilisez un autre mot.

Voici un exemple avec Lyon :

Google affiche d'abord des liens vers des articles répertoriés dans Google Actualités, liés à la recherche de l'internaute (s'il en trouve). Il affiche désormais ensuite un lien vers le plan de la ville, avant les résultats traditionnels.

Cela fonctionne aussi pour des petits villages (Génat, 25 habitants !) et des villes européennes (Berlin, Bruxelles mais pas Prague). Il y a encore quelques problèmes avec les accents mais cela sera sûrement rapidement corrigé.

Deux liens sont pour l'instant proposés (ViaMichelin et Map24) avec une préférence semble-t-il pour ViaMichelin (le lien sur la phrase "Plan de {VILLE}" pointe vers ViaMichelin). Que vont en penser les concurrents de ces deux services ? Et que vont en penser ceux qui proposent des plans et optimisent leur référencement sur des milliers de villes ? Car être en concurrence avec un lien situé à côté d'une imagette dans les pages de résultats de Google, ça n'est pas facile... Zorgloob se demande également qui paye qui dans ce système.

Cette nouvelle fonctionnalité n'est rien comparé à la recherche locale qui devrait arriver sur Google France d'ici peu... Après les Etats-Unis, le Canada en bénéficie depuis cette semaine.

Nous avons expliqué dans notre article Le détournement de page par redirection comment certains arrivent à prendre la place d'autres sites dans les résultats de Google. Revenons sur quelques points de détails :

Ce phénomène est loin d'être nouveau et ne semble pas être limité aux cas des redirections par meta refresh.

Dès janvier 2004, une discussion sur WebRankInfo abordait le sujet de la redirection par meta refresh avec plusieurs exemples d'annuaires. Régulièrement des discussions similaires ont vu le jour, comme ce fut le cas aujourd'hui. Les participants aux différents concours de positionnement ont également constaté des cas de ce genre, perturbant parfois les positionnements dans Google...

Concrètement, comment peut-on savoir quel type de redirection est utilisé ? Il suffit d'utiliser un analyseur d'entête HTTP et d'entrer l'URL de la page qui fait la redirection. Dans les quelques lignes indiquées par l'outil, vous voyez le code de retour HTTP. En général vous trouverez les 3 cas suivants :

1. code 200 : la page a été trouvée et ne présente aucune redirection gérée par le serveur. S'il y a une redirection, c'est sans doute via une balise meta refresh (ou un code JavaScript mais pour l'instant il est ignoré par les moteurs en règle générale)
2. code 301 : le serveur indique que la page n'existe plus et qu'elle a été définitivement déplacée à une autre URL (celle de l'URL redirigée donc)
3. code 302 : le serveur indique que de manière temporaire la page n'existe plus et qu'elle a été temporairement déplacée à une autre URL (celle de l'URL redirigée donc)

Il est intéressant de constater que le cas de figure le plus problématique est celui où le webmaster faisant la redirection a jugé utile de consacrer une page spécifique à chaque lien. Quel est l'intérêt pour un annuaire de prévoir une page par site référencé ? A part bien entendu te profiter de la notoriété du site inscrit pour être visible dans Google pour les requêtes associées... Ou bien encore pire d'afficher une bannière de publicité sur la page contenant la redirection, profitant ainsi d'un affichage à chaque fois que l'internaute arrive sur cette page en provenance de Google, croyant arriver en fait directement sur la page de destination...

Le cas des redirections serveur (301 ou 302) est plus délicat à analyser, puisqu'il existe des exemples et des contre-exemples. Théoriquement, une redirection telle qu'elle est utilisée par les annuaires devrait être de code 301 puisqu'elle doit toujours renvoyer vers l'URL finale (ce n'est pas temporaire). Il se trouve que c'est très rarement le cas, et que malheureusement parfois Google confond là encore les deux pages, comme dans le cas de la redirection par balise meta refresh.

Par exemple prenez le site http://www.absolutecover.net référencé dans l'annuaire genhit.com qui utilise des redirections de type 302. Une recherche sur le titre du site tel qu'il apparaît dans l'annuaire genhit renvoie la page de redirection http://genhit.com/out/akro9 au lieu du site lui-même. Dans ce cas précis le site absolutecover existe aussi avec l'extension .com mais absolutecover.net semble être passé aux oubliettes dans les pages de Google.

Certains ont pensé qu'une mauvaise configuration de la redirection serveur de business.com vers www.business.com avait pu être à l'origine de la disparition de ce site dans Google. Depuis tout semble rentré dans l'ordre puisque d'une part la redirection a été corrigée et d'autre part le site est revenu dans l'index de Google. Difficile de dire si c'était lié...

D'après Dan Thies notamment, le problème de redirections 302 se pose notamment dans le cas de double redirection (qui peut arriver avec les liens affiliés par exemple). Dans ce cas Google se mélange dans pratiquement tous les cas, attribuant le contenu de la page finale à l'URL de la première page faisant la redirection.

Et qu'est-ce que conseille Google ? Tout simplement de faire des redirections permanentes, de type 301. Vous êtes prévenus...

Ce billet est une traduction de l'article "Spammers hijack web site listings in Google" rédigé par Per Koch le 13/09/2004. Je remercie son auteur de m'avoir autorisé à traduire son article.

Un grand nombre de webmasters doivent faire face à un nouveau cauchemar lié aux moteurs de recherche : se faire piquer leurs positionnements dans Google par d'autres sites.

Les moteurs de recherche luttent constamment contre des spammeurs, c'est-à-dire des personnes qui essaient de manipuler les résultats des moteurs de recherche pour augmenter leur trafic (NDLR : ce qu'on appelle le spamdexing). En début d'année Pandia a même trouvé quelqu'un qui avait copié de grandes parties du site Pandia en les faisant passer pour son propre site.

C'est évidemment un problème de droit fondamental puisque cette personne vole un contenu sans tenir compte du droit d'auteur.

Du point de vue du moteur de recherche, le problème est vu différemment, car Google considère que les contenus dupliqués sont des tentatives de spam du moteur de recherche. C'est pour cette raison que Google bannit l'un voire les deux sites. Oui ! Votre site peut se retrouver banni parce que quelqu'un d'autre l'a copié !

Des cas de ce type enfreignent les lois internationales sur le droit de propriété intellectuelle et peuvent être jugées au tribunal. Cependant, les spammeurs ont trouvé aujourd'hui une nouvelle façon de s'appropier des positionnements dans les moteurs de recherche : ils utilisent la redirection par la balise "meta refresh".

La balise meta refresh est une balise meta que vous mettez au début du code HTML, dans l'entête du document (entre les balises <head> et </head>), et qui indique au navigateur qu'il faut charger une autre page au bout d'un certain temps.

Imaginez qu'un spammeur utilise une balise de ce type sur sa page www.spammeur.com/index.html :

<meta http-equiv="Refresh" content="0; url=http://www.honnete-homme.com/index.html">

Ce code indique au navigateur qu'il faut charger la page www.honnete-homme.com/index.html au bout de 0 seconde, c'est-à-dire immédiatement. Google de son côté interprète ce code en retenant que la page www.spammeur.com/index.html possède le même contenu que la page www.honnete-homme.com/index.html, c'est-à-dire qu'elles sont identiques.

Cela dit, cela ne devrait pas poser de problème dans la mesure où Google reconnaît que www.honnete-homme.com/index.html est le site d'origine et www.spammeur.com/index.html est la copie. Il pourrait bannir le site www.spammeur.com pour manipulation de l'index.

Cependant, comme l'ont indiqué de nombreux webmasters dans le forum WebMasterWorld, Google semble en réalité bannir le site d'origine, considérant que le nouveau site remplace l'ancien. Au final les internautes tombent toujours sur la même page, mais ce n'est plus votre site qui apparaît dans Google, c'est celui du spammeur.

Pourquoi diable le spammeur fait-il cela ? Après tout, l'internaute pourra toujours lire votre page sur votre site. Une motivation possible est de chercher à nuire à un concurrent, en l'occurrence vous, en faisant disparaître vos positionnements dans les résultats de Google. Une autre raison est de bénéficier des backlinks qui pointent vers votre site (NDLR : vers votre page pour être plus précis), et de remplacer plus tard cette page avec un meta refresh par une page classique de leur site.

Si Google considère vraiment que le site du spammeur remplace le site d'origine, le spammeur peut même hériter du PageRank du site d'origine (NDLR : de votre page pour être plus précis). Certains ont remarqué qu'il existe des outils de gestion des liens (NDLR : par exemple le module de liens de Xoops) basés sur ce système. D'ailleurs certains webmasters détournent ainsi d'autres pages sans même le savoir.

Google n'a pas encore réglé le problème et n'a pas fourni de réponse aux webmasters de WebMasterWorld qui ont expliqué le problème. C'est ennuyeux surtout que Google doit être au courant de ceci depuis déjà longtemps. Nous espérons que Google fasse quelque chose le plus rapidement possible.

Copyright Pandia.com 2004

La question peut sembler simpliste ou naïve puisqu'il existe une commande bien pratique sur Google : site:URL où URL est un nom de domaine par exemple. Mais nous allons voir ensemble que ce n'est pas si simple... Examinons ensemble plusieurs exemples avec le site WebRankInfo :

Pour chercher toutes les pages indexées du site, la requête site:webrankinfo.com renvoie environ 94 000 résultats. Bien entendu si vous faites le test, vous trouverez peut-être un nombre différent, même si vous le faites peu de temps après la publication de cet article. Ceci est dû au fait que Google utilise plusieurs centres de données et qu'il n'est pas garanti que ce soit le même qui soit utilisé pour répondre à nos requêtes (chaque centre de données a sa propre version de l'index de Google, ces index ayant quelques différences qui peuvent être analysées sur cet outil).

Si nous cherchons les pages de WebRankInfo ne contenant pas le "mot" kjertoiusfjqhgfdgddsg (a priori cela revient à chercher toutes les pages du site) nous obtenons par la requête site:webrankinfo.com -kjertoiusfjqhgfdgddsg environ 95 000 résultats. Cela correspond à peu près aux 94 000 trouvés précédemment, ce qui n'est pas étonnant (mais pour d'autres exemples les résultats peuvent être très différents !).

Si nous cherchons les pages de WebRankInfo ayant le mot webrankinfo dans l'URL (a priori toutes) nous obtenons par la requête inurl:webrankinfo site:webrankinfo.com environ 155 000 résultats. Etonnant, non ?

En prenant un autre exemple (DMOZ), nous voyons que les résultats peuvent être inversés. La requête site:dmoz.org renvoie environ 784 000 résultats tandis que la requête inurl:dmoz site:dmoz.org en renvoie environ 440 000.

Google a donc du mal à fournir des bonnes estimations sur le nombre de résultats dès lors que le site possède plusieurs milliers de pages dans l'index. Notons que parmi les résultats des requêtes site:URL, il existe souvent de nombreux résultats sans titre ni description.

En y regardant de plus près, on s'aperçoit que Google ne connait pas la taille du document et qu'il ne propose pas de lien vers la version en cache. C'est logique puisque cela correspond à des pages dont Google connaît l'existence grâce à des liens issus d'autres pages, mais qu'il n'a pas encore été visiter.

Une astuce révélée sur Zorgloob par Alexis Berger nous indique que ces pages n'ont pas non plus été "localisées". C'est-à-dire que Google n'a pas encore déterminé dans quelle langue elles sont écrites (et sans pas non plus dans quel pays elles sont hébergées, mais ceci n'est pas certain). Si bien qu'il est facile de les éliminer de nos recherches de pages indexées en choisissant par exemple l'option "Pages francophones" du formulaire de recherche de Google.

Cela fonctionne bien avec l'exemple de WebRankInfo et en choisissant l'option "Pages francophones" nous ne voyons plus de résultats de ce type. Mais chose encore une fois surprenante la requête site:webrankinfo.com avec l'option "Pages francophones" renvoie environ 159 000 résultats (à comparer aux 94 000 indiqués sans restriction de langue)...

Ce genre de problème ne semble apparaître que pour les sites ayant un grand nombre de pages indexées.

Nouvelle version 2.0.114

Google vient de sortir une nouvelle version de sa barre d'outils : la v2.0.114. Normalement, cette barre d'outils se met à jour toute seul, comme l'explique Google:

Chaque fois qu'une nouvelle version de la barre d'outils Google est disponible, elle est installée automatiquement (à condition que vous soyez connecté à Internet). Cette installation ne se produira peut-être pas immédiatement, mais elle aura lieu dès que la nouvelle version sera prête.

Pour mémoire, les 4 dernières mises à jour ont été les suivantes (dates de disponibilité de la version française):

• version 2.0.111 : 2004-05-14
• version 2.0.112 : 2004-07-15
• version 2.0.113 : 2004-07-30
• version 2.0.114 : 2004-09-09

Le checksum de la toolbar

Comme vous le savez certainement, la Google Toolbar utilise un code (programmé dans une DLL) pour calculer le checksum associé à chaque URL affichée dans le navigateur. Ce checksum dépend uniquement de l'URL. Il est indispensable au dialogue entre la barre d'outils et les serveurs de Google, pour pouvoir afficher le PageRank. Depuis quelques temps déjà, cet algorithme du checksum avait été "piraté" mais en Juin 2004 le code a été rendu public sur le web. Depuis lors, de nombreuses personnes ont développé des outils fournissant le PageRank d'une URL, en se basant sur ce code "craqué". C'était d'ailleurs la première fois qu'on pouvait récupérer le PageRank sans utiliser la barre d'outils de Google.

Le nouvel algorithme

De nombreux référenceurs ou webmasters se sont demandés combien de temps Google allait laisser cette situation durer, en laissant cet algorithme "craqué" fonctionner... Nous nous sommes d'ailleurs demandés récemment si le fait que Google ne mette plus à jour le PageRank dans la barre d'outils depuis cette époque n'avait pas un rapport avec la diffusion de cet algorithme "craqué").

Nos tests effectués aujourd'hui montrent que Google vient de changer son algorithme. Voyons quelques exemples :

URL testée : http://www.prweaver.com/

• Avec la vieille version (2.0.113), le checksum était 6963020688.
• Avec l'algorithme "craqué", le checksum était bien entendu aussi 6963020688
• Avec la nouvelle version (2.0.114), le checksum est 62294342280

URL testée : http://www.prweaver.com/blog/

• Avec la vieille version (2.0.113), le checksum était 6754577502.
• Avec l'algorithme "craqué", le checksum était bien entendu aussi 6754577502
• Avec la nouvelle version (2.0.114), le checksum est 6831794505

Conclusion

Google vient de changer l'algorithme du checksum de sa barre d'outils (ce n'est pas la première fois, mais ce n'est pas très fréquent). Pendant une période de transition, les deux algorithmes fonctionnent (de manière à ce que la barre d'outils fonctionne encore pour ceux qui n'ont pas la dernière version) mais dans le futur il semble évident que Google n'utilisera que la nouvelle version de l'algorithme. Si c'est bien le cas, alors tous les outils basés sur l'algorithme "craqué" du checksum ne fonctionneront plus...

C'est la raison pour laquelle nous avons choisi de baser notre logiciel d'analyse du PageRank et des Backlinks PR Weaver sur la barre d'outils de Google et non sur des versions "craquées" de l'algorithme.

Google a en effet été créé le 7 septembre 1998. Voici un petit extrait de l'historique de Google, issu d'un livre à paraître très bientôt...

Le 7 septembre 1998, la société Google Inc. ouvre donc ses portes à Menlo Park, Californie, dans le garage d'un ami (comme il se doit pour un projet Internet qui a des ambitions), entre une machine à laver et une autre à sécher le linge. Le premier employé de la société est Craig Silverstein, resté depuis fidèle et aujourd'hui directeur de la technologie du moteur.

Le site, à cette époque, traite déjà 10 000 recherches par jour. Le Web gronde et commence à parler de Google. Les discussions vont bon train sur les forums. Le moteur fait l'objet de plusieurs articles dans la Presse. L'Histoire est en cours... Rapidement, la société doit déménager à Palo Alto dans des locaux plus grands. En février 1999, elle compte 8 salariés et le site répond à 500 000 requêtes quotidiennes. La société RedHat conclut un premier marché avec l'entreprise, qui utilisera dorénavant le système d'exploitation Linux sur ses serveurs.

Google fête l'événement sur son site par cette image :

Bon anniversaire Google :-)

Les serveurs de test www2.google.com et www3.google.com redirigent dorénavant vers www.google.com (redirection temporaire, code HTTP 302).

Ces 2 adresses étaient les plus connues dans les outils liés à la Google Dance, du temps où il y avait de réels changements lors de la Google Dance. Ces serveurs n'étaient pas des data centers comme www-sj.google.com ; Google choisissait au début de la Google Dance un data center sur lequel était "branché" www2-google.com (même chose pour www3 avec un data center identique ou non)

Voici une photo prise dans un data center de Google :

Autres blogs :

• Zorgloob