Coup de baton sur le PR Sculpting

Depuis une semaine, la nouvelle fait du bruit dans le Landerneau SEO, à tel point que même ce blog sort de la torpeur dans laquelle il se trouvait depuis quelques mois. La nouvelle ? Matt Cutts a devancé la Corée du nord en lançant une véritable bombe : les liens en nofollow vont partiellement être inclus dans le calcul du Pagerank. L’exemple donné par Matt est relativement simple : En gros, si vous aviez 10€ de popularité à distribuer vers les pages de votre site à travers 10 liens, et que vous bloquiez 5 de ces liens via un attribut nofollow, avant les 5 pages restantes auraient acquises 2€ chacune de popularité, aujourd’hui elles devront se contenter d’1€ chacune. Et les 5€ restant ? Evaporés tout simplement.

Plus précisément, en reprenant la formule initiale et certainement déprécié du Pagerank, les choses se passent comme si les liens en nofollow étaient pris en compte dans le calcul des C(Ti).

Pour rappel, le pagerank d’une page (ici A) est égal à la somme des pagerank des pages qui font un lien vers elle (PR(Ti)) divisé par le nombre de liens qu’elles possèdent (C(Ti)) à un facteur d’amortissement près (d).

Avant ce changement, les liens en nofollow étaient totalement ignorés dans le calcul du pagerank. Ce n’est plus totalement vrai. Ce qui reste vrai, c’est qu’une page A recevant un liens en nofollow d’une page B ne verra pas cette page comptabilisé dans son calcul de PR. Par contre pour les pages qui font des liens en dofollow vers A, les liens en nofollow qu’elles portent seront comptabilisé dans le C(Ti).

Conséquences sur le PR Sculpting

Sur la forme tout et pas grand chose. Tout, parce que ceux qui basaient leur Sculpting sur l’utilisation du nofollow vont devoir revoir leur copie. Pas grand chose, car beaucoup de spécialistes SEO avait déjà anticipé ce changement en misant sur les liens en Javascript. Solution certes hautement efficace d’un point de vue pragmatique, mais qui ne va pas sans faire grincer des dents (à raison) les fidèles de l’accessibilité.

Des arbitrages vont devoir être trouvés pour concilier les deux, mais au moins dans une optique de PR sculpting, Flash et Ajax ont de beaux jours devant eux. Il faudra sans doute également réévaluer la pertinence de certains liens.

Sur le fond cette annonce est importante. Cela traduit un changement au moins partiel de politique quand à l’acceptation de ce type de pratique. Si tout les sites se mettent à faire du PR sculpting via Javascript, nul doute que cette optimisation critiquable va se retrouver parmi les actions réprimés par Google avec le cloaking et les liens cachés.

Les solutions ? Comme toujours, une prise en compte plus en amont des problématiques SEO avec des structures de sites orientées dès le début vers une distribution optimale du pagerank. Les liens JS faisant tâche ne survivront pas aux 5 prochaines années, par contre, le siloing et les menus Ajax ont certainement de bonnes années devant eux.

A quand les effets ?

Bien que d’après Matt Cutts le changement vient d’être opéré, les effets ne se feront probablement pas sentir de suite. Pour qu’un site puisse en constater les effets il faudra d’abord attendre que le Pagerank de ses pages soit recalculé. Pour les petits sites usant avec parcimonie du PR Sculpting les conséquences ne seront probablement pas visible, par contre on peut légitimement se demander quel en sera l’effet sur des gros sites comme Wikipédia pour lesquels l’ensemble des liens sortant est en nofollow. Voilà qui pourrait favoriser un peu knol.

Conclusion

Je serais tenté de dire, beaucoup de bruit pour rien. Mais quand même je me demande bien dans quelles mesures cela aura un impact sur des sites comme wikipédia ou encore des blogs bourrés de commentaires avec des liens en nofollow. Si l’impact est conséquent, voilà qui devrait soulager certains grand groupes de presse qui se plaignaient auprès de Google de voir squatter les premières places par des blogs… A moins qu’ils ne doivent eux aussi revoir leur politique de nofollow :).

Faire de l’Ajax avec mootools

Continuons notre petite exploration des fonctionnalités de Mootools en découvrant à quel point ce dernier nous facilite la mise en place d’appels Ajax. Cet article aurait même pu s’appeler : “de l’utilité de l’usage d’un framework Javascript” tant notre propos est ici surtout de comparer l’approche Ajax traditionnelle et celle utilisant un framework.

Qu’est-ce qu’un framework ?
Au sens large, c’est un cadre de travail destiné à améliorer la productivité ainsi que la qualité de code du développeur. Plus concrètement ce sont principalement des bibliothèques de fonctions parfois accompagnées de conventions de codage. L’intérêt ? Imaginez que vous recommenciez indéfiniment à coder à partir de zéro, réinventant la roue à chaque fois. Si vous avez déjà plusieurs développements derrière vous, vous savez que vous êtes souvent amenés à réutiliser le même code. Un framework ce sont des briques logicielles éprouvés qui répondent efficacement à des problématiques récurrentes. Bon passons au code.

L’Ajax façon grand mère.

function getXhr(){
	var xhr = null; 

		if(window.XMLHttpRequest)
			xhr = new XMLHttpRequest(); 

		else if(window.ActiveXObject){
			try {
			         xhr = new ActiveXObject("Msxml2.XMLHTTP");
			         } catch (e) {
			             xhr = new ActiveXObject("Microsoft.XMLHTTP");
			         }
			}
			else {
			  alert("Votre navigateur ne supporte pas Ajax");
			  xhr = false;
				}
                                return xhr
			}

function InsertDiv(ajax_url, calque){
	var xhr = getXhr()

		xhr.onreadystatechange = function(){

			if(xhr.readyState == 4 && xhr.status == 200){

				if(calque != 'none') {

				document.getElementById(calque).innerHTML = xhr.responseText;

					}
				}
			}

			xhr.open("GET",'ajax_url',true);
			xhr.send(null);
		}

En bref la fonction getXhr permet d’instancier un objet XMLHttpRequest dont nous avons besoin pour communiquer avec le serveur. La fonction InsertDiv prend en paramètres l’url qui sera chargé de nous répondre et le calque qui recevra le contenu de cette réponse par un assez brutal InnerHTML. Je passe les détails sur le “onreadystatechange“, “readyState” et “status“, qui dépasseraient du cadre de cet article. Il serait évidement possible d’améliorer cette fonction de multiples manière, ne serais-ce par exemple qu’en prévoyant une réponse en cas d’erreur 404.

Nous avons ici choisi d’envoyer nos données en GET mais nous pourrions tout aussi bien les envoyer en POST en remplaçant les dernières lignes par :

	xhr.open("POST","ajaxLivre.php",true);
	xhr.setRequestHeader('Content-Type','application/x-www-form-urlencoded');

	var = document.getElementById('maVariableId');
	maVariable = var.options[var.selectedIndex].value;
	xhr.send("maVariable="+maVariable);

Il faut admettre que même si nous avons un contrôle total sur notre code, ce dernier va vite devenir assez lourd. Imaginez les contorsions que vous allez devoir faire ne serais-ce que pour récupérer les paramètres en post si vous avez une dizaine de champs dans votre formulaire et plusieurs formulaire tant qu’on y est. Cela peut facilement tourner vite au casse tête. Et mootools face à ça ?

L’Ajax fête des fleurs !

Vous pouvez directement commencer par aller voir la démo proposé sur le site de mootools :
http://demos.mootools.net/Form.Send

Intéressons nous maintenant au code Javascript :

window.addEvent('domready', function() {

	$('monForm').addEvent('submit', function(e) {

		e.stop();

		var log = $('ajaxdiv').empty().addClass('ajax-loading');

		this.set('send', {onComplete: function(response) {

			log.removeClass('ajax-loading');
			log.set('html', response);
		}});

		//Send the form.
		this.send();
	});
});

Le fonctionnement est très simple : “monForm” est l’identifiant de votre formulaire qui devra être renseigné dans la balise <form>. Comme dans le précédent article, on a ajouté un gestionnaire d’événement. Cette fois pour le submit. Ce qui nous évite un tout moche “onsubmit=” dans la déclaration du formulaire. e.stop() nous permet d’éviter que le formulaire soit envoyé. “ajaxdiv” c’est ma div qui recevra le retour du serveur. Ici on le vide (empty) et on affiche un petit loader Ajax (addClass(’ajax-loading’)). Au retour du serveur (onComplete) on retire le loader (removeClass) et on affiche la réponse.

Remarquez deux petites choses qui finiront si nécessaire par définitivement confirmer l’élégance du procédé. D’une part, la déclaration du formulaire reste à un identifiant près ce qu’elle serait si on n’utilisait pas Ajax :

<form method=”POST” action=”monUrlAjax” id=”monForm”>

D’autre part, l’ensemble des variables du formulaire est envoyé comme ce serait le cas avec un formulaire normal sans avoir rien de plus à préciser que le nom des champs et leur valeur.

Conclusion

Je pense que ce petit exemple vous aura montré tout l’intérêt que peut avoir une approche via framework face à une approche classique. Bien sur utiliser un framework est moins bas niveau que l’appel direct à l’objet XMLHttpRequest, nos possibilités sont donc légérement réduites et le code un peu plus lourd. Mais au final le framework nous offre largement tout ce que nous avons besoin de faire et l’argument quand à la lourdeur est plus que discutable (surtout concernant mootools). Et cela est sans commune mesure face aux gains réalisés en terme de qualité de code et de maintenance.

Effet de slide avec mootools

Mootools est un excellent framework JS léger et modulaire qui saura vous rendre bien des services. Dans ce petit tutorial nous allons voir comment avec quelques lignes de code mettre en place un effet de slide simple et efficace. Pour commencer vous pouvez directement télécharger ici le code js.

L’archive comprend le code du framework et un fichier d’exemple avec différents effets de slide verticaux et horizontaux. Nous allons nous intéresser au toggle vertical, mais la démarche reste la même quel que soit l’effet choisi. Voici le code :

<script language="JavaScript" type="text/javascript">
<!--
window.addEvent('domready', function() {

	var myVerticalSlide = new Fx.Slide('slide');
	myVerticalSlide.toggle();

	$('v_toggle').addEvent('click', function(e){
		e.stop();
		myVerticalSlide.toggle();
	});

});
// -->
</script>

Evidemment il faudra veiller à ce que le framework soit bien appelé et conformément à l’exemple ci-dessus on mettra notre contenu dans une div avec un id égal à “slide”. Pour expliquer rapidement le code on met en place un gestionnaire d’événement au chargement du DOM. Lorsque un élément identifié par “v_toggle” sera cliqué cela lancera l’effet de slide.

Présentation de Google Analytics

Avant d’entamer une série d’article sur Google Analytics, je voudrais commencer par en faire une petite présentation.

Google Analytics est un service de Web Analytique basé sur les outils de la société Urchin Software Corporation racheté en 2005 par Google.

Sa première qualité est sa simplicité apparente. Il suffit de s’inscrire au service, copier le marqueur qui vous est fourni et la placer sur vos pages et vous aurez très vite tout un tas de données exploitables.

Mais en rester la ce serait passer à coté de ce qui fait toute la force de cet outil. En premier lieu, les toutes puissantes expressions régulières qui révèlent toutes leur force quand elle sont appliqués à l’impressionnant système de filtres que propose Google Analytics. Les profils sur lesquels vont s’appliquer ces filtres, mais aussi également les récents segments avancés et les rapports personnalisés qui permettent de sélectionner et croiser de multiples données avec une grande précision. Sans parler des valeurs personnalisées, du tracking d’événement, du module d’E-commerce ou de l’intégration automatique d’Adwords. Sans parler également non plus des prochaines features à venir comme l’intégration d’adsense ou l’API. Bref vous l’aurez compris j’aime beaucoup cet outil. Et nous aurons très prochainement l’occasion d’en parler plus en détail.

Je voudrais terminer en signalant une nouvelle assez récente que les lecteurs du blog d’Analytics n’auront pas manqués de noter. Des changements concernant la fonction _setVar(). En effet jusqu’à présent l’usage de cette fonction qui permet d’attribuer une valeur personnalisé avait pour effet malencontreux d’affecter le taux de bounce et le temps passé sur la page. (Ce qui pouvait ce comprendre dans certains cas, mais qui perdait son sens lorsque le setting se faisait au chargement de la page). Maintenant, si l’on peut dire, c’est réglé. Ne vous affolez pas si votre taux de rebond a grimpé en flèche depuis le 29 Janvier, c’est juste que le _setVar() n’a plus pour effet de l’annuler.

Google Adsense Premium

Présentation

Réservé aux gros éditeurs, le programme Adsense Premium* de Google augmente considérablement les possibilités qui leurs sont offertes et donc le taux de clics associé (Jusqu’à 500% selon certains [1]).

Cependant comme indiqué dans [2] :
“Google peut fournir (au compte-gouttes) les informations pour personnaliser les formats d’annonces. Il faut insister auprès du responsable commercial assigné au compte pour obtenir l’activation de certaines fonctionnalités.”

Le présent article a pour objectif de faire un tour relativement complet des possibilités qui peuvent être proposées avec ce programme.

Quelques exemples d’intégration

Priceminister

Avantages :
- Format custom des annonces
- Pas de liens Feedback.
- Texte cliquable.
- Pas d’intitulé “annonces Google“.

CBS Sports

Avantages :
- Format custom des annonces
- Pas de liens Feedback.
- Texte cliquable.

AOL

Avantages :
- Format custom des annonces
- Pas de liens Feedback.
- Texte cliquable.

Autres avantages du programme Adsense Premium

En plus de ces avantages, et cela va sans dire de l’ouverture en fenêtre externe des pages annonceur, le programme Adsense Premium offre des possibilités moins visibles mais pourtant extrêmement utiles.

La liste qui suit n’est pas exhausitive. Elle est issue d’articles présents sur Internet et du code de sites qui utilisent le programme Adsense Premium :

Mise en forme personnalisé des annonces.
Vu au dessus. Permet une meilleure intégration, et une augmentation du taux de clics.

Le ciblage des annonces.
Il est possible sous certaines conditions de fournir à Adsense une liste de mots clés pour lui voir renvoyer des annonces en rapport avec ces mots. Les avantages sont nombreux :

- Ciblage de marchés plus rémunérateurs.
- Non dépendance au contenu de la page.
- Possibilité de se positionner sur des termes associés mais moins concurrentiels.
- Possibilité de définir les annonces en fonction de la navigation du visiteur sur le site.

Possibilité de retirer le “Ads by Google”.
D’inscrire autre chose à la place, et / ou retirer le lien de feedback.

Possibilité d’afficher des adsenses sur des pages de contenu adulte ou jeux d’argent.
Présence également d’un mode safe pour s’assurer à l’inverse l’affichage d’annonces “acceptables”.

Amélioration notable du ciblage par section.
Pour rappel Google permet de cibler ou d’éviter l’analyse contextuelle de portions de pages à l’aide du morceau de code suivant :

<!– google_ad_section_start(weight=IMPORTANCE) –>
Texte…
<!– google_ad_section_end –>

Le programme premium développe cette possibilité en ajoutant le ciblage par section nommé. Le principe :

<!– google_ad_section_start(name=NOM_DE_LA_SECTION, weight=IMPORTANCE) –>
Texte…
<!– google_ad_section_end(name=NOM_DE_LA_SECTION) –>

Il est ainsi possible de lier une annonce à une section nommée.
Ainsi les annonces peuvent être fonction des morceaux de page, et non plus des pages entières.

Négociation du partage des revenues adsense.
Il semble également que pour les gros éditeurs la part des gains Adsense puisse se négocier [3].

Conclusion

Nous venons de faire un tour rapide présentant les principaux avantages du programme. A noter également que chaque ensemble d’annonce au format premium doit d’abord être soumis au gestionnaire de compte Adsense avant validation. De plus ces fonctionnalités ne sont pas incluses par défaut mais doivent être négociés.

Références

[ 1 ] - How Adsense Premium Publishers Boost their CTR by 500%.
[ 2 ] - Google Adsense - étude de fonctionnement.
[ 3 ] - The privilege of being an Adsense Premium Publisher.

*note : Le programme adsense premium n’existe plus en tant que tel mais ces fonctionnalités peuvent toujours se négocier (pour les très gros éditeurs).

Référencement et affiliation

Présentation

Généralement, les liens d’affiliation ne participent pas au référencement de vos sites alors qu’ils le pourraient. S’il existe pourtant des solutions, elle sont généralement mal connues ou mal employées des différents acteurs. D’autant qu’avec Google qui pénalise la vente de liens, c’est une situation pour beaucoup floue et ambiguë, que nous proposons ici d’éclaircir.

Paramètres d’affiliation et liens en dur

Souvent lorsque l’éditeur gère sont propre système d’affiliation, les liens qu’il propose sont de la forme “www.editeur.tld/?idaff=xxxxx“. Le problème principal de ce type de lien est bien sûr qu’ils génèrent du duplicate content. La première solution que propose en général Google et que beaucoup d’acteurs appliquent est de passer par un fichier robots.txt et d’utiliser des redirections 301 ou 302. Cette solution pose à mes yeux autant de problèmes qu’elle en résout. Pourquoi donc se priver de centaines ou milliers de backlinks ?

Les moyens pour reconnaitre un affilié tout en ayant un lien propre sont nombreux : l’utilisation du referrer souvent à tord jugé trop peu fiable (et donc à déconseiller à moins de vouloir tenter de convaincre un par un tout vos annonceurs), le passage des paramètres en parallèle en JS (fiable mais plus lourd à mettre en place autant chez l’éditeur que chez l’annonceur), la redirection 301 chez l’éditeur (propre, simple et efficace, même si une redirection n’a pas tout à fait autant de valeur qu’un lien dur). C’est ce dernier choix qu’a par exemple réalisé Amazon France depuis moins de trois mois.

Un lien d’affiliation n’est pas un lien acheté !

Beaucoup hésitent à mettre en place ce type de solutions par peur que Google les sanctionne. D’une part Google sanctionne bien plus la vente que l’achat, mais surtout un lien d’affiliation n’est pas un lien acheté. Il est vrai que la communication de Google sur ce point est assez floue. Mais il faut avoir à l’esprit ce qui est différent qualitativement entre ces deux types de liens. Dans le cas d’un lien acheté rien ne présume de la qualité de ce lien. C’est je te pais tant pour que tu fasses un lien vers mon site. Un lien d’affiliation est très différent car il suppose par nature que l’affilié a confiance en votre site dans sa qualité à transformer une visite en achat donc à satisfaire l’internaute. D’ailleurs Google s’est tout de même récemment prononcé à ce sujet :
http://www.searchenginejournal.com/affiliate-links-can-pass-link-juice-help-with-seo/7831/

…In no uncertain terms, that if affiliate links came from valuable, relevant, trust-worthy sources - bloggers endorsing a product, affiliates of high quality, etc. - they would be counted in link algorithms. Aaron from Google and Nathan from Microsoft both agreed that good affiliate links would be counted by their engines and that it was not necessary to mark these with a nofollow or other method of blocking link value.

Conclusion

Faites comme Amazon. Transformez vos liens d’affiliation boiteux en fontaine à link juice.
N’hésitez pas également à consulter cette page aux commentaires très intéressants et qui m’a donné l’envie d’écrire ce billet : Potentiel de référencement des liens créés en affiliation

Pirates of Silicon Valley

J’ai récemment eu le plaisir de voir “Pirates of Silicon Valley”, excellent téléfilm américain de 1999 qui décrit l’histoire d’Apple et Microsoft entre les années 70 et 90.

Ce téléfilm, relativement peu connu en France, retranscrit de façon assez fidèle comment Bill Gates et Steve Jobs ont réussis à amener l’informatique dans les foyers et comment les dirigeants d’IBM, Xerox, et Hewlett Packard ont laissés passer la manne fantastique de l’ordinateur personnel.

Des moments historiques de la micro-informatique sont fidèlement mis en scène : IBM qui accepte de payer une licence d’exploitation du futur DOS de Microsoft que ces derniers ne possèdent pas encore mais rachèteront une bouché de pain quelques jours plus tard, les dirigeants de Xerox qui se passent de mains en mains une des premières souris avec un air dubitatif*, ou encore ceux d’Hewlett qui ne voient pas le potentiel des premières machines d’Apple.

Autant qu’un film, “Pirate of Silicon Valley” est un documentaire. Un documentaire passionnant.

*Le cas de Xerox est un peut plus complexe en réalité. Les premières ébauches d’interface graphique viennent du Stanford Research Institute. Ce n’est que deux ans plus tard que les ingénieurs de Xerox au courant de ces travaux mettront au point leur interface, qui n’aura malheureusement pas le succès mérité. Mais les dirigeants de Xerox n’étaient pas à l’époque à une bourde prêt : en 1982 John Warnock et Chuck Geschke développeront chez eux un langage de description pour imprimante qui ne recevra aucune attention de la boite. Il démissionneront pour fonder leur propre entreprise, une certaine Adobe.

Je ne résiste pas au plaisir de terminer ce post par quelques images d’époque :

Bill Gates et la conduite automobile.

Xerox en avance sur son temps.

Microsoft au complet en 1978, l'entreprise s'est un peu agrandi depuis.

Le G2 d’HTC - Sous Google android

Enfin un iPhone killer ! Un vrai. Oubliez le Blackberry Storm, le HTC Touch HD, ou le Nokia 5800. La future merveille de chez HTC, le G2 est bientôt la.

Tout les caractéristiques sont la pour en faire un bête de concours. Androïd de Google bien sur, un écran de 3,2 pouces, un appareil photo 5 Mégapixels avec flash et autofocus, un capteur en facade pour la visio, le WIFI, Bluetooth, EDGE, et surtout un design de toute beauté qui dépasse largement celui du premier GPhone du même HTC.

Bref, le G2 motorisé par Androïd est une merveille qui devrait sortir aux US courant Janvier. Vivement qu’il arrive en France.

Quelques shoots pour le plaisir des yeux

Le cloaking, inutile ?

Présentation

“La technique du Cloaking (en français dissimulation) est une technique utilisée par les black hat pour optimiser leur positionnement dans les moteurs de recherche. [...] Le seul usage légitime qu’il peut être fait de cette technique est de proposer seulement aux clients qui peuvent l’interpréter des contenus spécifiques (par exemple, un contenu Adobe Flash n’est pas lisible par un robot). Aujourd’hui, de meilleures méthodes d’accessibilité sont à disposition, rendant le cloaking inutile.” Source : Wikipedia.

Le cloaking est une technique légitime de référencement consistant à proposer deux versions d’une même page selon que le visiteur soit un robot ou un humain. Si le cloaking à mauvaise presse il n’en est pas moins vrai que de nombreux sites très connus et bien classés dans Google l’utilisent à bon escient.

Mais d’abord techniquement, le cloaking, comment ça marche ?

Le premier problème qui se pose lorsqu’on veut réaliser un bon cloaking est de réussir à bien identifier Googlebot (Et les autres robots). Il existe plusieurs méthodes avec chacune avantages et inconvénients.

Identifier Googlebot grâce à l’user-agent :
Lorsqu’une application se connecte à un serveur web, elle envoi généralement dans sa requête HTTP un entête “user agent” contenant une chaîne de caractères permettant de l’identifier. Il suffit donc pour détecter Googlebot d’examiner l’user agent.

La darkseoteam analyse en permanence les crawls de Google fait sur leur site. Vous donnant ainsi un user agent toujours à jour : “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)“.

En général, si l’user agent au complet peu changer, certaines parties de la chaîne restent fixes dans le temps. Un bon moyen d’identifier les différents Googlebots est de vérifier la présence de “Googlebot” dans l’user agent. Exemple en Php :

if (preg_match("/Googlebot/", $_SERVER['HTTP_USER_AGENT'])) {

    echo 'Bonjour Google !';

} else {

    echo 'Toi tu n'es pas Google.';

}

Le gros problème de cette méthode est quelle est très facile à tromper. Un simple plugin Firefox comme User Agent Switcher permettra à n’importe qui de se faire passer pour Google à vos yeux. Bien sûr si vous faite du “whitehat cloaking” cela est sans importance, mais si par hasard vous avez des choses à cacher, vous aller au devant d’un spam report de la part de vos concurrents.

Identifier Googlebot grâce à l’IP :
Une méthode plus efficace consiste à identifier Google à partir de son adresse IP. La aussi la Darkseoteam propose une liste constamment mise à jour, mais le mieux consiste à exploiter vos logs apache pour réaliser votre propre liste qui sera alors à comparer avec la variable php $_SERVER['REMOTE_ADDR'] lors de l’identification.

Le problème ici, est que vous ne serez jamais sur de pas laisser parfois quelques Googlebots passer à travers les mailles de votre filet. Un moyen efficace est de faire un reverse DNS, c’est-à-dire transformer l’adresse IP de vos visiteurs en nom de domaine. Vous devriez alors voir apparaître “googlebot.com“.

> host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer
crawl-66-249-66-1.googlebot.com.

Il y a deux façons de mettre cela en place. La première en vérifiant bien que la directive “HostnameLookups” soit à “On” dans votre fichier de config Apache. Le nom de l’hôte sera alors présent dans la variable $_SERVER['REMOTE_HOST']. Le cas échéant, il vous est encore possible de faire un gethostbyaddr sur l’IP du client. Le code :

$hostname = gethostbyaddr($_SERVER['REMOTE_ADDR']);

if (preg_match("/google.com/", $hostname)) {

    echo 'Cloaking sur IP';

} else {

    echo 'Version visiteurs';

}

Si cette dernière méthode est la plus efficace elle n’est certainement pas à conseiller sur des sites à fort trafic, la résolution DNS inverse étant assez lourde.

Il existe d’autres solutions envisageables. On pourrait imaginer par exemple utiliser gethostbyaddr conjointement à une table HEAP contenant les dernières IP ayant demandées une page pour limiter de trop nombreuses résolutions inverses. On doit aussi pouvoir se baser sur le fait que les robots d’indexation ne gèrent pas les cookies et génèrent des sessions à chaque demande de pages. Les solutions finalement ne manquent pas mais sont à moduler en fonction de vos contraintes.

Le cloaking, toujours blackhat ?

Il existe plusieurs applications légitimes du cloaking. Si par exemple vous utilisez des variables de tracking sur votre site, il est plus que conseillé de faire un cloaking sur vos liens internes pour éviter de générer du duplicate content. Des sites réputés comme la Fnac ou Amazon usent de cette technique de façon modéré. Il n’y a qu’à aller sur ces sites avec l’user agent de Google pour voir les différences.

Si votre site nécessite une inscription pour accéder à son contenu, vous pouvez très bien envisager de mettre en place un cloaking pour permettre quand même à Google de l’indexer. On se rapproche ici d’une pratique assez borderline, mais c’est ce qu’ils conseillent eux même pour Google actualités.

Le plus dur étant en général, comme toujours avec Google, de savoir ou se situe la ligne.

Duplicate Content - Présentation

Présentation

Dans le but de ne pas présenter des résultats identiques dans les SERPs, Google a depuis longtemps mis en place des filtres pour lutter contre ce qui est généralement appelé le duplicate content. Longtemps, et encore aujourd’hui, et bien que Google se soit souvent exprimé à ce sujet, le duplicate content reste perçu par beaucoup comme une pénalité, alors que ce n’est bien évidement pas le cas.

Deux types de duplicate content

Il n’existe pas un, mais deux types de duplicate content. Le premier concerne les pages identiques qui différent seulement de leur url. Dans ce cas, comme Google l’explique très bien, ils considèrent les pages dupliquées comme une seule page à laquelle ils attribuent l’url de celle qui leur parait la plus représentative. Cette dernière bénéficiera également d’un report vers elle des propriétés des autres urls comme le PageRank. (C’est exactement comme si tous les différents liens n’étaient qu’un seul et même lien pointant vers celle qui pour Google fait office de référence). Le second type de duplicate concerne les copies partielles de contenu. C’est un filtre qui est activé en aval juste avant l’affichage des résultats et qui en cas de copies détectés vous affichera en bas de page “relancer la recherche en incluant les pages ignorées”. Entrons un peu maintenant dans les détails.

Le premier filtre anti duplicate content

Agissant en amont, durant la phase d’indexation, l’application de ce filtre est souvent causé par la présence de plusieurs urls menant vers le même contenu. Les exemples sont nombreux :

- Site accessible avec et sans “www“.
- Site renvoyant la même page avec ou sans “index.html” à la fin.
- Appeler une même page avec deux noms différents.

Les solutions : les corrections à apporter sont différentes selon chaque cas. Pour le premier problème, la solution la plus simple est de renseigner l’url principale de GWT (Google Webmaster Tools). Pour le second on utilisera en général des 301. Enfin dans le dernier cas, on veillera surtout a avoir une structure de liens homogène sur l’ensemble de site. Souvent Google s’en sortira très bien tout seul.

Le second filtre anti duplicate content

Google veille à bien afficher des résultats différents dans ses SERPs. Si deux pages portant le même texte devaient remonter sur une recherche, Google n’en affichera qu’une seule tout en vous présentant à la fin la possibilité de relancer votre recherche en affichant le contenu ignoré. Ce filtre est d’autant plus efficace pour des titres et metas identiques.

Le choix du résultat à afficher est aux dernière nouvelles basé sur le PageRank bien que Google parle parfois de l’historique d’indexation. Dans les faits cette prédominance du PageRank dans ce choix entraine souvent la dépréciation par Google de contenu originaux aux profits de sites mieux implantés. C’est un point qui dans l’avenir pourrait changer.

Un moyen bien connu des référenceurs blackhat pour échapper a ce filtre est de suffisament modifier leur texte pour que la correspondance entre l’original et la copie ne puisse pas être établie. Ce n’est pas vraiment le sujet de cet article mais le filtre anti duplicate de Google est relativement peu efficace (même quand il s’agit de textes identiques non retouchés).

Devez-vous toujours avoir peur du duplicate content ?

Oui et non. Non, car au risque de me répéter le duplicate content n’est pas une pénalité. Dans la majorité des cas Google s’en accommode très bien sans que cela vous soit préjudiciable. Oui, car le filtre est imparfait et qu’il privilégiera les gros sites au détriment du votre. Qui plus est si vous avez une quantité trop importante de duplicate cela peut avoir des effets indirects négatifs, comme par exemple sur l’indexation de votre site. Enfin nous ne parlons ici que de duplicate involontaire. Si votre site est basé sur la copie de contenu vous risquez à moyen terme les foudres de Google pour non respect de ses guidelines.

Références

[ 1 ] - Demystifying the duplicate content penalty - fr.
[ 2 ] - Une excellente analyse du site Rankspirit.
[ 3 ] - Compléments d’information du centre d’aide aux webmasters.

Page suivante »