Porn Sex Viagra Casino Spam

Il ne manque pas grand chose sur l’Ipad et pour ceux qui comme moi passent de plus en plus de temps dessus voici quelques astuces pour ajouter les fonctions suivantes au navigateur Safari intégré :

• Sauver la page dans Delicious
• Voir les headers HTTP de la page courante
• Faire un whois sur le domaine courant
• Montrer les liens nofollow (à la manière de l’extension Firefox Search Status)
• Afficher le source de la page

Pour ce faire nous allons ajouter des bookmarks spéciaux ; je vous recommande de les installer dans la barre des signets, d’aller dans les préférences Safari et de mettre « Toujours afficher la barre de signets » à 1.

Comme j’ai la flemme d’expliquer aux noobs comment procéder pour ajouter un bookmarklet, ceux qui ne savent pas peuvent commencer par suivre la procédure pour ajouter le bookmarklet Instapaper. C’est en anglais mais c’est très bien expliqué, et Instapaper est un service que je vous recommande de toutes façons ! Ceux qui utilisent par exemple Echofon Pro peuvent aussi ajouter le bookmarklet « Tweet this » et leur barre des signets sera complète (suivre les instructions indiquées dans votre client Twitter).

Pour les autres, voici les liens et le code à copier-coller pour obtenir les fonctionnalités promises (vous pouvez cliquer les liens avant pour vérifier que ça fonctionne correctement chez vous).

Sauver la page dans Delicous

javascript:(function(){f=’http://delicious.com/save?url=’+encodeURIComponent(window.location.href)+’&title=’+encodeURIComponent(document.title)+’&v=5&’;a=function(){if(!window.open(f+’jump=doclose’,'deliciousuiv5′,’location=yes,links=no,scrollbars=no,toolbar=no,width=550,height=550′))location.href=f+’jump=yes’};if(/Firefox/.test(navigator.userAgent)){setTimeout(a,0)}else{a()}})()

Afficher les headers HTTP

javascript:(function(){function%20read(url){var%20r=new%20XMLHttpRequest();r.open(‘HEAD’,url,false);r.send(null);return%20r.getAllResponseHeaders();}alert(read(window.location))})();

Faire un whois

javascript:window.open(‘http://whois.domaintools.com/’+encodeURIComponent(location.hostname));

Mettre en valeur les liens nofollow

javascript:function%20highlightNofollow(){var%20newStyle=document.createElement(’style’);newStyle.type=’text/css’;newStyle.appendChild(document.createTextNode(‘a[rel~=nofollow]{border:1px%20dashed%20#852!%20important;background-color:#fcc!%20important;}’));document.getElementsByTagName(‘head’)[0].appendChild(newStyle);};highlightNofollow();

Pour le bookmarklet qui affiche la source d’une page, je vous invite à suivre les instructions sur la page de l’auteur ou à copier directement le code ici : http://www.ravelrumba.com/wp/wp-content/code/view-source.txt.

Voici un petit script générique pour vos tests d’indexation (par exemple si vous voulez savoir si googlebot suit les liens js, ou meta, ou autres…).

L’utilisation est très simple : vous pouvez définir un répertoire où le script pourra écrire ses logs (sinon par défaut il le fera dans le répertoire courant, sous réserve qu’il ait les droits en écriture) et votre clef d’API Google que vous pouvez obtenir ici : http://code.google.com/apis/ajaxsearch/signup.html. Si la constante GOOGLE_API_KEY reste vide, ça marche quand même…

Ensuite, votre page de test devra être en PHP et inclure le script. Donc par exemple, une page testindexationgg-djhsfgsdjhfgjsdg.php avec le contenu suivant :

C’est tout !

Le nom de la page est utilisé pour le nom du test, donc soyez explicite. Pour surveiller les résultats, vous n’avez qu’à consulter l’url de la page de test elle même, mais en y ajoutant une QUERY_STRING ! Par exemple dans le cas présent : testindexationgg-djhsfgsdjhfgjsdg.php?consultation. Ceci afin que le fait de consulter la page ne perturbe pas les résultats du test (si vous utilisez la toolbar google ou autre par exemple).

En passant un paramètre cela évite aussi que le script log inutilement l’accès à la page.

La page vous présentera les logs des derniers accès, les résultats de recherche Google pour l’identifiant unique de votre test (automatiquement généré) et des infos sur vous (IP, referer, agent, etc. En fait cela sert à vérifier le cache des moteurs de recherche).

Bref, tout ce qu’il faut pour conduire rapidement des tests sérieux !

Vous pouvez récupérer le script ici : http://paste.taggle.org/index.php/view/28750015

Une lettre en principe n’est en vérité valable que dans la minute où elle a été écrite.

…disait je ne sais plus qui (Sacha Guitry ?). Et bien pour les listes de proxies, c’est pareil ! Encore plus lorsqu’il s’agit de proxies anonymes. Les Black Hat SEO le savent bien : trouver et maintenir des listes de proxies anonymes relève du casse-tête et on est souvent tenté de recourir à des solutions payantes pour pouvoir spammer en paix.

Et bien cette époque est révolue ! Dans un soucis de justice sociale, j’ai décidé de mettre à la disposition de tous un petit script PHP qui s’occupera de façon totalement automatisée de découvrir, tester et maintenir à jour votre liste de proxies anonymes. Le pourrissement des commentaires de blogs est donc désormais à la portée de tous !

Continue reading « Recherche et vérification automatique de proxy anonyme »

Twitter est l’application de microbloging à la mode en ce moment, il n’y a qu’à voir comment des gurus du marketing tels Guy Kawazaki se la sont appropriée pour s’en convaincre !

La taille des « tweets » a beau être limitée à 140 caractères et le processus de publication réduit à son plus simple élément, ça reste tout de même très fatigant à gérer, d’autant que les beaux jours approchent et que nous passerons bientôt plus de temps à la plage que devant l’ordinateur (je suis désolé pour les gens du Nord…).

Alors que faire ?

Une fois de plus, la réponse tient en un mot : automatisation. Et en quelques lignes de PHP !

Continue reading « Poster sur Twitter avec PHP »

Vous avez été des milliers à vous plaindre du manque d’articles sur le référencement sur ce blog, je profite donc d’un petit script d’analyse de logs pour revenir dans le droit chemin !

Le suivi de l’activité des robots des moteurs de recherche sur votre site, et tout particulièrement du Googlebot, fait partie intégrante d’un bon référencement. Certes, Google mets à disposition des éditeurs depuis quelque temps déjà une série d’outils de suivi, les Google Webmaster Tools (GWT). C’est bien, mais pas toujours très complet et les mises à jours souvent aléatoires…

Les webmasters ont pourtant tout ce qu’il faut sous la main pour avoir des stats précises et surtout en temps réel pour suivre les bots : les logs du serveur Apache, souvent les meilleurs amis du référenceur !

Que faire avec ces logs ?

Les logs ne sont qu’un indicateur de plus pour l’analyse de la crawlabilité d’un site mais il y a de nombreuses façons de les utiliser. En vrac :

• Identifier des liens cassés (404) ou d’autres erreurs rencontrées par le bot lors de ses visites
• Si une page du site ne ressort pas dans l’index de Google, la première chose à faire est de vérifier si cette page a ou pas été crawlée par le googlebot
• On peut également s’amuser à corréler la fréquence de passage du bot au PageRank dune page, ou à son traffic réel, ou encore à sa position dans les SERP
• L’étude des visites du googlebot peut aussi servir à améliorer la structure des liens internes, détecter des pages isolées, etc.

Il y a encore sans doute de nombreuses autres apllications mais entrer dans le détail n’est pas l’objet de cet article.

Continue reading « Suivre l’activité de Googlebot sur votre site grâce aux logs Apache »

Alors que la communauté des référenceurs français est encore sous le choc de la récente pénalité infligée par Google à un célèbre forum de référencement, il apparait que le drame aurait pu être évité si nous avions su tendre l’oreille aux mises en garde pourtant claires de Nostradamus.

Ainsi, dans son ouvrage Petrus Crinitus, on peut lire Centurie 2, quatrain 41 :

La grand’estoile par sept iours bruslera,
Nuée fera deux soleils apparoir:
Le gros mastin toute nuit hurlera
Quand grand pontife changera de terroir.

Le doute n’est pas permis, c’est bien de la perte de pagerank de WRI qu’il s’agit !

Pour preuve, analysons ensemble cette prophétie :

Centurie 2, quatrain 41

Pour qui sait interprêter les signes, cette indication nous fournit une date très précise : centurie 2 = 2 ans après Paco Rabanne, soit le 01/01/2001 qui est habituellement la date qui sert de point de départ à tout prophétologue sérieux. 2×41 = 82, 82 mois après cette date et nous voilà en Octobre 2007 ! Première coïncidence, et vous admettrez qu’elle est troublante !

Ligne 1 : La grand’estoile par sept iours bruslera

L’allusion à WRI et à son PR 7 est évidente, et l’avertissement est clair : La grande étoile PR 7 brûlera…

Ligne 2 : Nuée fera deux soleils apparoir:

On voit bien ici qu’il s’agit d’une allusion à la deuxième mise à jour du Page Rank de l’année.

Lignes 3 et 4 : Le gros mastin toute nuit hurlera quand grand pontife changera de terroir.

Le grand pontife, c’est bien sûr Google. A partir de là, le sens de la prophétie devient limpide.

Espérons qu’à l’avenir, nous saurons accorder plus d’attention à ces prophéties, et que cette mésaventure aidera à mieux comprendre la technique du référencement prophétique, encore trop méconnue des référenceurs français.

C’est je crois sans précédent, l’ACCC (Australian Competition and Consumer Commission, l’équivalent australopithèque de notre DGCCRF) a décidé de trainer Google en justice au motif que le géant de la recherche sur Internet ne marque pas suffisamment la distinction entre les résultats naturels et les liens publicitaires dans ses pages de résultats !

D’après ce que j’ai compris, l’affaire est née en 2005 d’un différent entre deux sites australiens de vente de voiture et un site de petites annonces automobiles. Le site d’annonces aurait utilisé le système Adwords pour faire afficher des liens en se faisant passer pour les sites des concurrents !

L’ACCC estime donc que Google, en ayant échoué à marquer une distinction nette entre ses résultats et les liens publicitaires est responsable de ces pratiques frauduleuses. L’organisme de défense du consommateur australien a donc assigné Google Inc., Google Ireland Limited et Google Australia Pty Ltd. à répondre devant les tribunaux, aux côtés du site d’annonces Trading Post.

Google Australia ont déjà fait savoir qu’ils contestaient cette action et qu’ils allaient se défendre avec vigueur contre cette accusation qu’ils jugent évidemment complètement infondée (Google traité comme un vulgaire MFA, pis quoi encore !).

Une première audience devrait donc se tenir à la Cour Fédéral Australienne le 21 août 2007, affaire à suivre…

Voici une traduction en français d’un article d’Adam Lasnik (Google) publié le 5 juillet 2007 sur le blog officiel des webmasters de Google. Les anglophones prendront plaisir à lire l’article original ici.

Utiliser Flash au mieux

Nous recevons régulièrement des questions sur le groupe d’aide de Webmasters au sujet de la façon dont les webmasters devraient travailler avec le flash d’adobe. J’ai pensé qu’il serait intéressant d’écrire quelques mots au sujet des considérations en matière de référencement auxquelles les concepteurs de sites devraient penser lorsqu’ils développent un site en Flash.

Comme beaucoup le savent déjà, flash est en soi un environnement visuel, et le Googlebot ne voit pas. Googlebot peut typiquement lire les dossiers instantanés et extraire le texte et les liens d’une application Flash, mais la structure et le contexte sont absents. D’ailleurs, le contenu textuel est parfois stocké dans le flash comme graphique, et puisque Googlebot n’a pas actuellement les yeux algorithmiques requis pour lire ces graphiques, ces mots-clés importants peuvent être ignorés. Tout ceci signifie que même si votre site est dans notre index, il pourrait manquer quelques textes, contenus, ou liens. Pire, alors que Googlebot peut comprendre quelques parties d’un document Flash, beaucoup d’autres robots d’indexation eux ne le peuvent pas.

Que doit alors faire un concepteur honnête ? La seule règle est de montrer à Googlebot exactement la même chose qu’à vos utilisateurs. Dans le cas contraire, vos pages pourraient être pénalisées par nos algorithmes de recherche. Cette règle simple couvre beaucoup de cas comprenant la dissimulation, les redirections Javascript, le texte caché, et les pages satellite. Nos ingénieurs ont donc imaginé quelques suggestions plus pratiques :

1. Essayez d’employer le flash seulement où il est nécessaire. Beaucoup d’emplacements riches en médias tels que le flash ou l’utilisation de vidéos YouTube peuvent s’intégrer dans du HTML. En plus de rendre votre site compatible avec Googlebot, ceci rend votre site accessible au plus grand nombre, y compris, par exemple, les personnes aveugles qui utilisent des lecteurs d’écran, des utilisateurs de navigateurs vieux ou non standard ou ceux qui surfent depuis un téléphone de cellulaire ou un PDA. De plus, vos visiteurs peuvent employer des signets efficacement, ou envoyer par email vos pages à leurs amis.
2. sIFR : Quelques sites Web emploient le flash pour forcer le navigateur à afficher du texte dans une police que l’utilisateur peut ne pas avoir installée sur son ordinateur. Une technique comme le sIFR laisse toujours des lecteurs de non-Flash lire une page, puisque le contenu est réellement dans le HTML et est juste embelli par du Flash.
3. Versions Non-Flash : on voit couramment le flash utilisé pour faire une page d’accueil pour l’URL de racine d’un site Web. Dans ces cas, assurez-vous qu’il y a bien un lien régulier en HTML sur cette page qui pointe vers la partie non-Flash du site.

Si vous avez d’autres idées qui ne violent pas ces directives que vous voudriez voir évaluées, vous êtes libres de poser vos questions dans le groupe d’aide de Webmasters. De nombreux webmasters bien informés ainsi que des employés de Google pourront vous répondre.