Les informations suivantes viennent d’une confĂ©rence de Joachim Kupke, employĂ© chez Google pour la partie indexation du moteur de recherche.

Les trésors distribués par Joachim Kupke (Google) lors de la conférence SMX

Voici 9 trouvailles sur le référencement qui ressortent de la conférence SMX East qui s’est déroulée à New York en octobre. Globalement, c’était une conférence impeccable, mis à part les soucis de Wifi et autres de Javits Center  le maudit. Danny Sullivan (l’organisateur de la conférence pour ceux qui vivent sous un rocher) a répété que « Javits est pourri », « accusez Javits, ne nous mettez pas ça sur le dos ». Danny, nous accusons Javits !

Cette année, parmi les absences remarquées de SMX East, il fallait compter Matt Cutts et Nathan Buggia, mais c’était un plaisir d’écouter des googlers moins connus (Maile Ohye) et des intervenants de Microsoft/Bing (Sasi Parthasarathy).

En tant que référenceur, je suis particulièrement intéressé par ce que les moteurs de recherche vont dire au sujet de paramètres techniques spécifiques comme l’indexation, le contenu dupliqué, le crawl et les redirections. Cette conférence proposait quelques sessions extraordinaires où un grand nombre d’informations étaient au centre des débats.

Il y avait aussi quelques surprises (voir ci-dessous) et une paire de nouveautés, mais en général l’information partagée par Joachim et les autres représentants des moteurs de recherche portait sur des éléments spécifiques qui pourraient paraître obscurs à quiconque en dehors du cercle des « initiés » du référencement. J’adore vraiment tous ces trucs d’initiés !

Allons-y pour les 9 trouvailles utiles pour le référencement qui sont extraites de la contribution de Joachim Kupke lors de SMX East

Présentation de Joachim Kupke sur le contenu dupliqué

Joachim fait partie de l’équipe qui s’occupe de l’indexation chez Google. Il a partagé des bribes d’informations assez primordiales au sujet de la gestion du contenu dupliqué par Google. Joachim a également partagé quelques vues depuis l’intérieur du moteur et sa façon de voir le Web et indexer les URLs. Voici les points essentiels que j’ai retenus.

1. Impressions et Clics

Joachim a répété les termes « impressions » et « clics » dans le contexte d’une URL incluse dans l’index de Google. Il a mentionné qu’une URL qui reçoit peu ou pas d’impressions sera plausiblement plus longue à mettre à jour dans l’index (pas de surprise jusque là). Cependant, une URL recevant un grand nombre d’impressions et clics (ou provenant de domaines importants et crawlés fréquemment) sera mise à jour rapidement. C’est logique et connu de tous, mais il était intéressant d’avoir une confirmation sortie de la bouche d’un ingénieur de chez Google. Ainsi, ces redirections 301 et tags noindex sur certaines pages qui ne sont pas crawlés à nouveau et mis à jour viennent définitivement du fait qu’elles ne figurent pas sur la liste prioritaire du moteur de recherche (encore une raison pour laquelle les grandes marques l’ont facile en référencement)

2. Infrastructure de gestion du contenu dupliqué

Google est censé avoir « une tonne d’infrastructure pour éliminer le contenu dupliqué », parmi laquelle il faut citer :

• Redirection
• DĂ©tection de structure rĂ©currente d’URLs
• Le contenu de la page
• Le tag de lien canonical (si tout le reste Ă©choue)

A noter que Google reconnaît les structures des URLS, éliminant certains paramètres comme cause de duplication (bien sûr, ils ont également parlé de l’outil d’élimination de paramètre dans les Outils Webmaster Google).

Que veux-tu dire par « le contenu de la page » ? Ceci étant la partie la plus intéressante selon moi, voici la suite…

3. Enregistrement de l’historique des URLs

Google garde une sorte de archive.org du Web avec des versions plus anciennes du contenu (pas exactement comme cela, mais vous voyez ce que je veux dire : un enregistrement de l’historique des pages Web). Cela permet de comparer la version fraichement crawlée avec une version plus ancienne. Le contenu qui change peut être soustrait des éléments qui restent invariables au sein du site. Cela peut également donner à Google la faculté de s’assurer que les éléments globaux, zones et morceaux de contenu apparaissent à l’intérieur d’un site séparément du contenu définitivement unique et mis à jour.

4 . Google + rel=canonical = Amour

Google adore le tag « canonical » des liens. Selon Joachim, c’est une grande réussite qui a vu un rythme de déploiement exponentiel sur Internet. Chez Google, on traite ce tag avec le plus grand sérieux, en suggérant son importance comme Maile Ohye nous a expliqué à l’occasion de SMX Advanced en juin.  L’intérêt de ce paramètre est donc renforcé par les propos de Maile et Joachim. Cela engendre un « énorme impact » à propos des décisions de Google sur la canonicalisation : 2 fois sur 3, rel=canonical altère la décision organique. C’est assez énorme comme chiffre !

5. Les 302 suffisent comme cibles canoniques

Les redirections font des cibles canoniques correctes. Ce paramètre a été expliqué par Joachim à deux reprises. Cela comporte deux parties :

• A cause d’une mĂ©thode interne pour gĂ©rer les slashs de fermeture des URLs, Google avait besoin (et recommande Ă  tous les dĂ©veloppeurs d’agir de la sorte) d’un slash de fermeture sur les cibles canoniques et les liens internes. Sans le slash de fermeture, Google va ajouter un slash et mettre Ă  jour l’URL dans l’index.
  Maintenant, j’ai trouvé de multiples exemples de pages où cela ne se déroule pas de la sorte, mais Joachim était assez ferme sur le fait que c’est un problème du Web en général que Google est obligé de contourner.

• La trouvaille en la matière est que vous devriez toujours ajouter un slash de fermeture Ă  l’URL absolue de la cible canonique. Sans le faire, Google va l’ajouter automatiquement, mais en anticipant cette action, vous allez certainement accĂ©lĂ©rer la vitesse de rĂ©ponse du serveur (qui aurait un impact pour les sites de taille importante).

6. Comment les cibles canoniques en 302 peuvent être détournées

Les redirections 302 sont donc des cibles canoniques adéquates. Oui je sais que je me répète ! Voici la partie intéressante pour le référencement : si les 302 sont OK à utiliser dans ce cadre, je pense à une méthode pour utiliser le tag « canonical » du lien à des fins d’optimisation du référencement sans avoir à améliorer énormément la structure de l’URL. Comment cela ? Voici un exemple théorique :

Prenons, un site qui présente une structure d’URL à améliorer (voir cet exemple ) pour le référencement et des raisons d’usabilité évidentes. Cependant, les développeurs sont dans le jus, la plateforme technique est branlante, il n’y a pas assez d’argent pour un budget référencement de qualité, ou simplement les modifications ne valent peut-être pas la peine.

Un référenceur arrive avec la proposition suivante :

1. Créer un tableau avec une version optimisée pour le référencement de chaque URL à améliorer.
2. Ajouter ces URLs amies des moteurs dans le code source avec le tag « rel=canonical »
3. Effectuer une redirection 302 depuis les URLs canoniques vers les URLs dégueulasses existantes sur le site.
4. Bingo! Des jolies URLs au sein des résultats de recherche

Le tag « canonical » agit comme une redirection 301 et met à jour les indicateurs dans les résultats de recherche (comme c’est le cas). Puis la cible canonique redirige vers une 302 qui ne force pas la mise à jour (comme c’est le cas). Alors la jolie (et pseudo) URL dans le lien cible canonique va rester comme indicateur dans les résultats de recherche, pendant que la non-pseudo URL bien dégoutante va agir en tant que page temporaire aux yeux des moteurs. Pigé ? Avouez que c’est intéressant (voir le graphique basique ci-dessous pour un visuel de ce concept).

Non, je n’ai pas planifié de mettre en œuvre ceci incessamment sous peu, mais je connais au moins un site majeur d’e-commerce qui agit de la sorte (certainement de manière involontaire) et ça fonctionne parfaitement depuis le mois de juin.

7. Ne pas interdire votre contenu dupliqué ( ?)

Google dit « s’il vous plait, n’utilisez pas la directive « Disallow : » dans le Robots.txt afin d’éradiquer le contenu dupliqué ». Le contenu qui n’est pas disponible pour Google ne peut donc pas être visité et le moteur de recherche n’aime pas du tout cela. La préférence semble aller vers « mettez tout en ligne » et laissez nous décider ce qu’il y a de mieux à faire. Chaque fois qu’un contenu n’est pas disponible au crawl, les moteurs perdent la faculté de faire ce choix décisionnaire.

Ma préférence personnelle est de garder le contrôle complet, mais je comprends également leur raisonnement et la raison qui pousse à promouvoir cette méthode.

8. L’indexation peut prendre longtemps pour des URLs « impopulaires »

Joachim a expliqué qu’indexer peut prendre du temps (comme mentionné précédemment), mais c’est encore plus vrai pour des URLs obscures et peu populaires. Il faut savoir que la phase d’indexation prend du temps, mais que le nettoyage des parties existantes de l’index prend encore plus de temps. Bien entendu, il existe des manières d’initier le crawl de Google (phase séparée de la mise à jour dans l’index), mais il est indéniable que les sites moins connus ne reçoivent pas la même attention que les bons gros sites populaires.

9. Support du lien canonique au travers de différents domaines

Google va bientôt accepter le tag « canonical » sur différents noms de domaine. C’est une grande nouvelle ! Yahoo ! et Bing ont annoncé qu’ils travaillent sur la base qui est de comprendre rel=canonical.

Les autres trucs supers Ă  SMX East

Il y avait énormément d’autres sessions extraordinaires comme David Mihm, Will Scott, Andrew Shotland, Mike Blumenthal et Mary Bowling qui ont traité des paramètres locaux liés au référencement. La régionalisation est un secteur vraiment excitant en ce moment pour les référenceurs. Cette équipe a proposé une session vraiment géniale. Tout cela m’a tellement motivé que je suis revenu avec l’intention de creuser encore plus au niveau « local ».

Article original (en anglais)

Remerciements : Taggle & Altiref

L’annonce d’une mise Ă  jour surnommĂ©e CafĂ©ine (Caffeine en anglais) provoque des remous plus ou moins justifiĂ©s, au travers de ceux qui s’intĂ©ressent Ă  Google et au rĂ©fĂ©rencement de site Internet.

Faut-il que ceux, qui possèdent des sites positionnés convenablement parmi les résultats de recherche Google,  redoutent la mise à jour Caféine?

Comme d’habitude, les pseudo analyses, suppositions et autres interprétations fleurissent au travers des blogs et forums à propos de la mise à jour Caféine. C’est comme cela que naissent les mythes du référencement, habilement alimentés par Google causé par un manque de transparence récurent.

Qu’est ce que Google CafĂ©ine?

Il était évident que certains allaient sortir des théories alimentant la pompe à mythes et secrets du référencement.
En guise d’avertissement, nous avons reçu une annonce officielle de Google, plusieurs interviews de Matt Cutts, ainsi qu’un post sur son blog se voulant rassurant. Sur le Web, la discussion est bien lancĂ©e sur blogs, forums, Twitter, etc.
Une URL mettait Ă  disposition l’accès Ă  un aperçu de l’index Google CafĂ©ine. Cet accès est fermĂ© depuis le 10 novembre 2009.

Interview de Matt Cutts Ă  propos de Google Caffeine

Propagation de la rumeur et mise en route d’un mythe

Au départ, Mashable sort une analyse que je qualifie de tout à fait superficielle. Le point subjectif concerne une soi-disant pondération supérieure des mots clés sur Google Caféine.

Un blogueur français orientĂ© rĂ©fĂ©rencement  reprend la teneur de l’analyse Mashable Ă  son propre compte (sans citer la source d’origine qui l’a inspirĂ©) et d’autres vont citer ce billet sur leurs blogs, Twitter et autres sources de partage de contenu. MĂŞme le Journal du Net met les pieds dans le plat sans savoir de quoi il s’agit vĂ©ritablement.

Le pire de tous est celui là qui part dans un délire total, voulant sciemment propager une peur parmi ses lecteurs.

Ce qu’il faut retenir Ă  propos de Google CafĂ©ine

Google CafĂ©ine est un nouvel index hĂ©bergĂ© par une nouvelle infrastructure qui repose sur le Google File System V. 2., dont la structure nous est connue depuis 2004.  La V.2 conçoit une Ă©volution majeure du Google File System, permettant d’amĂ©liorer l’indexation et la gestion des donnĂ©es.

Cela entraine principalement:

• Une amĂ©lioration de vitesse d’indexation
• Une plus grande fiabilitĂ© sur les rĂ©sultats de recherche
• Des moyens dĂ©cuplĂ©s en interne pour le travail des ingĂ©nieurs Google

Les observateurs du rĂ©fĂ©rencement ont tellement envie de croire que cette mise Ă  jour va provoquer des remous qu’ils brouillent plus ou moins volontairement la comprĂ©hension gĂ©nĂ©rale. MalgrĂ© les efforts Ă©vidents de l’inusable Matt Cutts pour signifier qu’il s’agit d’une Ă©volution d’infrastructure, certains font l’amalgame entre index et algorithme.
Bien entendu, la communication Google n’Ă©tant pas limpide, tout le monde peut croire qu’il rĂ©side un piège au tournant. Sans doute que l’annonce du recul de dĂ©ploiement global après les fĂŞtes Ă©voque les remous de Florida au sein de l’imaginaire collectif.

Encore une fois, Google Caféine permet à Google de reposer sur une infrastructure plus performante, avec l’algorithme n’étant pas la principale cible de cette mise à jour. Ainsi, le plus gros changement que nous allons observer concerne l’index qui sera rafraîchi.

Et l’algorithme dans tout ça ?

Le principe de fonctionnement de Google est un algorithme par couches. Il existe une formule de base sur laquelle sont posés des filtres qui concernent des paramètres en particulier et/ou certaines parties de l’index.

Comme expliqué précédemment, Google Caféine ne focalise pas sur l’algorithme. Un peu comme si vous changiez de voiture pour passer d’une Twingo à une Porsche, mais vous n’êtes pas devenu Sébastien Loeb par l’intermédiaire de ce changement du véhicule.

Bien sĂ»r, l’index et l’algorithme sont liĂ©s, donc j’imagine qu’il faut accorder le bouzin pour qu’il dĂ©pote Ă  merveille. Par ailleurs, il est facile de comprendre que ce n’est pas non plus le meilleur moment pour coller des filtres Ă  foison qui pourraient mettre Ă  mal cette merveilleuse nouvelle machinerie.

Les effets et conséquences de Google Caféine

Ma plus grande attente concerne l’indexation en temps rĂ©el. Jusque Ă  maintenant, Google Search est Ă  la ramasse et Google Images est un dĂ©sastre. EspĂ©rons que cette nouvelle infrastructure va permettre Ă  Google de pouvoir tacler l’indexation en temps rĂ©el convenablement.

Les Ă©ventuelles perturbations observĂ©es ressortent l’excuse passe partout qui sont les effets de bord. Quand on bidouille un index de cette taille, il est Ă©vident que certains effets inattendus apparaissent pour des cas isolĂ©s. Bien Ă©videmment, ceux qui verront leurs sites tomber vont faire un ramdam pas possible, mais ils reprĂ©senteront une portion microscopique du total de l’index.

Si l’algorithme Ă©tait concernĂ© par cette mise Ă  jour, cela amplifierait les effets de bords. Essayez de changer une virgule dans une formule mathĂ©matique pour voir un peu les consĂ©quences…

Une autre Ă©vidence du rafraichissement de l’index concerne l’affichage du nombre de rĂ©sultats qui Ă©tait notoirement farfelu. J’ose espĂ©rer qu’on pourra dĂ©sormais se fier avec plus d’exactitude aux chiffres Ă©noncĂ©s dans les rĂ©sultats de recherche.

La lutte contre le spam reste au coeur des besoins de Google. Une meilleure manipulation des donnĂ©es contenues dans l’index pourrait aider dans cette lutte pour totalement vaine (pour l’instant).

Le paramètre dont parlent ceux qui ont compris de quoi il s’agit porte sur la vitesse de chargement des sites, dont les plus lents pourraient ĂŞtre dĂ©favorisĂ©s. Ce nouvel index focalise sur la vitesse, donc il semble viable de demander aux pages affichĂ©es parmi les meilleurs rĂ©sultats de suivre cette tendance. Matt Cutts mis le doigt sur ce point dans une interview rĂ©cente, ainsi que SearchEngineLand qui abonde dans ce sens. Attention, il ne faut pas faire partir une nouvelle rumeur suggĂ©rant qu’un site qui se charge en plus de 4 secondes va perdre 30 positions. Ce paramètre est Ă  inclure parmi les +200 qui composent l’algorithme, nĂ©cessitant de jauger son importante relative par rapport aux autres.

A propos de la vitesse de chargement des pages Web, je reste perplexe car j’ai testĂ© la rapiditĂ© de mon site et le facteur le plus ralentissant est … Google Analytics – par le biais du code JavaScript installĂ© en bas de chaque page.

Comment faire une analyse convenable ?

Le reverse engineering à la petite semaine est une perte de temps. Tout d’abord, il faut bien comprendre que l’affichage des résultats de recherche n’est pas forcément une retranscription exacte de ce qui se trame dans l’index. Sans parler des chiffres farfelus affichés comme compteur des résultats, Il existe toute une série d’opérations depuis le moment où GoogleBot crawle une page Web jusqu’au moment où elle ressort sous divers opérateurs au sein des résultats de recherche. Nous disposons uniquement de la plus petite lucarne qui sont les résultats de recherche du moteur. Toute la machinerie en amont est invisible et inconnue.

Tirer des conclusions à partir d’un résultat de recherche pour déterminer ce qui se passe en amont est voué à présenter une pitoyable interprétation du fonctionnement de Google.

Parmi les mythes du rĂ©fĂ©rencement, il demeure un paramètre que j’ai toujours combattu avec force. Il s’agit de la densitĂ© des mots clĂ©s au sein d’une page. Il suffit de savoir dans les grandes lignes comment Google fonctionne pour se rendre compte que ce critères est totalement farfelu.

Pour analyser le comportement du moteur par rapport aux mots clés, il faudrait évaluer le nombre d’occurrences sur la page. Jusque là c’est facile ; il suffit de compter les mots cibles sans prendre en compte le nombre total de mots clés comme le fait le calcul de densité. Ensuite, il faut évaluer ces occurrences par rapport aux occurrences exactes sur le reste du site, puis par rapport aux co-occurrences similaires et complémentaires.

Ce n’est pas fini ! Maintenant, il faut prendre chaque partie de ces résultats pour les évaluer en fonction des pages Web concurrentes et le reste du site des pages concurrentes qui sont elles même analysées comme précédemment.
Ensuite, il faut remonter ces donnĂ©es pour tenter d’en sortir une règle de pondĂ©ration qui sera toujours Ă  prendre avec prĂ©caution car je rappelle que l’index n’est pas traitĂ© de manière identique sur sa totalitĂ©.

Et là on dispose d’un petit début de piste concernant la prise en compte des mots clés. Tout cela doit évidemment se répéter sur un nombre suffisant de mots clés pour une seule page, plusieurs pages du même site, plusieurs sites sur la même requête, un seul site sur plusieurs requêtes, plusieurs sites sur plusieurs requêtes, etc.

Ainsi, je peux sereinement réfuter les résultats de Mashable, ainsi que tous les autres qui se sont inspirés de cette analyse bidon.

Si je comprends bien, je n’ai rien à craindre pour mon site ?

Pour la vaste majorité des sites Internet, il n’y aura pas ou très peu de changement. Ceux qui seront touchés seront sûrement affectés par un effet temporaire qui sera dégagé sans rien modifier sur le site. Malheureusement, c’est frustrant et je connais personnellement le phénomène.

Dans tous les cas, il ne faudra pas regarder du côté d’une éventuelle pénalité algorithmique, mais plutôt par rapport aux paramètres liés à l’indexation.

On verra bien en janvier lorsque Google CafĂ©ine sera dĂ©ployĂ© sur tous les DataCenters du moteur de recherche, mais je peux logiquement m’avancer en rejetant en bloc tous ceux qui font l’amalgame entre index et algorithme.

Plusieurs questions surgissent au travers de cet accord.

La première réflexion qui me vient à l’esprit se rapporte à la raison stratégique qui pousse le moteur de recherche Google à draguer un outil de micro-blogging tel que Twitter.

Au niveau du volume d’utilisateurs, Twitter n’est pas encore aussi répandu que d’autres outils sociaux tels que Facebook ou MySpace.  Donc, ce n’est pas pour avoir la main mise sur la masse d’utilisateurs que Google a décidé de nouer ce partenariat.

Pertinence et référencement

Concernant la pertinence des discussions qui transitent sur Twitter, je suis du même avis qu’ Olivier Duffez car il n’est pas certain que le niveau soit assez élevé pour croire que l’utilisateur du moteur de recherche va forcément trouver une information intéressante lorsqu’il va tomber sur un Tweet inséré dans les résultats de recherche.

Par ailleurs, David Degrelle pense que Google n’a pas le choix puisque le contenu Twitter sert déjà de base sur les sites Web afin de générer du contenu. En indexant les Tweets, le moteur de recherche recentre le contenu qui se déportait ailleurs.

En décortiquant l’annonce officielle parue sur le blog Google, il apparaît une notion qui ressort de plus en plus au sein de la stratégie Google ces derniers temps. Il s’agit de la mise à jour en temps réel. D’après le communiqué, Twitter présenterait un certain intérêt par rapport aux réactions sur un sujet en particulier. Donc, le moteur de recherche pourrait décider de présenter des Tweets en réponse à une requête qui tourne autour d’un sujet où la mise à jour immédiate est intéressante.

Cela mérite de voir comment ça ressort effectivement à l’usage, mais la mise à jour en temps réel concerne une masse colossale d’informations. Cette information est déjà traitée sur de nombreux supports, même si le facteur « temps réel » n’est pas forcément de mise sur ces derniers. C’est donc assez compliqué d’imaginer comment Google va décider de favoriser un Tweet par rapport à d’autres sources d’information dans l’espace temps.

Indexation du contenu protégé

Le Los Angeles Times révèle un problème par rapport à l’indexation des comptes Twitter protégés – non visibles à ceux qui ne font pas partie des contacts du compte. L’exemple choisi dans l’article concerne le compte de Bill Clinton, ancien président des Etats-Unis. Comme illustré par les screenshots ci-dessous, Google montre le début des Tweets de Clinto, alors que le compte est effectivement protégé.

Sans polémiquer plus encore, il est indispensable que le moteur de recherche répare cette énorme erreur au plus vite. Les implications possibles d’indexer un contenu protégé sont trop graves pour que ça perdure. Ca devient une sale habitude du moteur qui tend à ne pas respecter le contenu protégé d’une manière ou d’une autre.

Recherche d’information recentrée sur l’utilisateur

Bien souvent, dans toute annonce Google, il faut savoir lire entre les lignes. Ca engendre l’émergence de fantasmes  plus ou moins hallucinants, mais la communication Google est tellement basique que nous sommes bien obligé d’extrapoler pour tenter d’y voir clair.

Dans la présente situation, je vois une évolution de la recherche d’information qui échappe à Google. Il s’agit de la manière de plus en plus tendance qui consiste à demander l’avis d’autres personnes sur un sujet en particulier. Dans ce sens, la recherche d’information se recentre sur l’agent qualifiant humain et se dégage du sacro-saint algorithme du moteur de recherche. A chaque fois qu’un utilisateur Twitter pose une question sur Twitter, c’est une recherche qui échappe à Google.

Ainsi, il est plausible de penser que le partenariat entre Twitter et Google évoque l’incapacité du moteur de recherche à adresser cette évolution de la recherche d’information.

Et Twitter dans tout ça ?

Bien entendu, Twitter profite de ce partenariat sur deux points essentiels :

• Technique : les datacenters Google sont bien mieux Ă©quipĂ©s que ceux de Twitter pour supporter la masse de donnĂ©es qui transite sur l’outil de micro-blogging. Il semble Ă©vident que les efforts de Twitter sont vains pour prĂ©senter un service qui soit techniquement fiable. Du coup, nous verrons certainement disparaĂ®tre le message de surcharge du service qui apparaĂ®t encore rĂ©gulièrement.
• Visibilité : ĂŞtre prĂ©sent sur Google en position favorable est Ă©videmment un bienfait Ă©norme pour Twitter. L’outil est hyper tendance et engrange des utilisateurs sur un rythme effrĂ©nĂ©, mais il n’est pas encore largement propagĂ© auprès du grand public.

Un Tweet pour conclure

RT @Laurent8 : Twitter couche avec Google. Pas sûr que ça soit un bienfait – 140 caractères en réponse à une requête #Twitter #Google