Les moteurs de recherche personnalisés (ou CSE – pour Custom Search Engines) vous permettent de profiter de la puissance de la recherche Google sur votre site. Vous pouvez rechercher sur un ou plusieurs sites, personnaliser l’apparence des résultats de recherche, et même monétiser ces recherches avec Google AdSense. A partir d’aujourd’hui, vous pouvez créer et gérer vos moteurs depuis les Outils pour les Webmasters.

Si vous n’avez jamais créé de CSE, cliquez sur le lien « Recherche personnalisée » dans la section Labs, et nous créerons automatiquement un moteur de recherche par défaut pour votre site. Vous pouvez ensuite le configurer à votre guise avec quelques options de base, ou récupérer immédiatement le code afin de l’intégrer sur votre site. Et vous pouvez bien entendu continuer à utiliser le site dédié aux CSE pour accéder à l’ensemble des options de configuration.

Une fois que vous avez créé votre CSE (ou si vous en avez déjà un), cliquez sur le lien « Recherche personnalisée » dans la section Labs pour gérer votre moteur de recherche sans quitter les Outils pour les Webmasters.

Nous espérons que ces nouvelles fonctionnalités vous permettront de plus facilement offrir une recherche de qualité à vos visiteurs. Si vous avez des questions, vous pouvez nous la poser soit dans le forum d’entraide des webmasters, soit dans le forum d’aide des CSE.

Posté dans sa version originale par Sharon Xiao, Stagiaire ingénieur,
et Ying Huang, Ingénieur logiciel, Google

® Goopilation, 2011. | Lien vers l'article | Aucun commentaire
Publier sur : del.icio.us, Facebook, Twitter

En juin dernier, nous annoncions un programme pilote permettant à nos utilisateurs de voir les données de recherche dans Google Analytics en y associant leurs comptes Webmaster Tools. Nous avons depuis apporté une série d’améliorations basées sur les retours des utilisateurs, et nous sommes aujourd’hui ravis d’ouvrir ces nouveaux rapports à tout le monde.

La nouvelle section contient trois rapports basés sur des données provenant de Webmaster Tools, qui nous l’espérons vous permettront de mieux comprendre les performances de votre site dans les résultats de recherche. Nous avons créé une nouvelle section pour ces rapports baptisée « Optimisation du référencement » classée sous « Sources de trafic » :

• Requête : impressions, clics, position, et infos sur le CTR pour le top 1000 des requêtes quotidiennes
• Pages de destinations : impressions, clics, position, et infos sur le CTR pour le top 1000 des pages de destination chaque jour
• Résumé géographique : impressions, clics, et CTR par pays

Pour commencer à utiliser ces rapports, vous devez d’apport associer vos comptes Google Analytics et Webmaster Tools. Pour des instructions détaillées sur l’association des comptes et sur les rapports, referez-vous à cet article du centre d’aide. Si vous n’utilisez pas encore Webmaster Tools, nous vous recommandons chaudement de vous lancer. C’est un outil gratuit destiné à vous aider à mieux comprendre comment Google perçoit votre site. Inscrivez-vous sur la page d’accueil des Outils pour les Webmasters. Prenez le temps d’étudier ces nouveaux rapports, et dites-nous comment ils vous aider à mener à bien vos analyses.

Posté dans sa version originale par Kate Cushing, Chef de produit, Google Analytics

® Goopilation, 2011. | Lien vers l'article | 3 commentaires
Publier sur : del.icio.us, Facebook, Twitter

Nous entendons constamment les webmasters nous dire qu’ils doivent prioriser leur temps. Certains gèrent des dizaines, voire des centaines, de sites pour des clients, d’autres gère leur entreprise et n’ont pas beaucoup de temps à consacrer à leur site. Afin de vous aider à mieux organiser vos efforts, nous introduisons le concept d’état de santé d’un site au sein de nos Outils pour les Webmasters, ainsi qu’une nouvelle page d’accueil sur laquelle vous verrez en un coup d’oeil si il y a des problèmes sur vos sites.

Voici à quoi ressemble la nouvelle page d’accueil :

Vous pouvez voir que les sites ayant des problèmes remontent en tête de liste. Vous pouvez bien entendu revenir à un tri par ordre alphabétique. Pour en savoir plus sur les problèmes que nous avons détecté sur un site, cliquez sur l’icône  ou sur le lien « Afficher les détails ».

Cette nouvelle page n’est actuellement active que si vous avez moins de 100 sites inscrits sur votre compte Outils pour les Webmasters (vérifiés ou pas). Nous travaillons afin de rendre cette fonctionnalité accessible à tous. Si vous avez plus de 100 sites, vous pouvez consulter l’état de santé sur le tableau de bord de chaque site.

L’examen de santé de votre site tient pour le moment compte de trois problèmes :

1. Avons-nous détecté des logiciels malveillants sur votre site ?
2. Est-ce que certaines de vos pages importantes ont été supprimées via notre outils de suppression d’URL ?
3. Est-ce que certaines de vos pages importantes ont été bloquées via robots.txt ?

Il vous suffit de cliquer sur l’un de ces trois problèmes pour obtenir plus d’informations sur ce que nous avons détecté. Si l’icône d’alerte et le lien « Afficher les détails » n’apparaissent pas sur vos sites, alors nous n’avons détecté aucun problème (félicitations !).

Une précision à propos des « pages importantes » : comme vous le savez, vous pouvez obtenir une liste exhaustive de toutes les URLs qui ont été supprimées via Configuration du site > Accès du robot d’exploration > Supprimer l’URL ; ainsi que la liste des URLs que nous n’avons pas pu indexer à cause du robots.txt via Diagnostic > Erreurs d’exploration > Accès restreint par un fichier robots.txt. Les webmasters supprimant ou bloquant souvent du contenu intentionnellement, nous ne voulons vous alerter que si nous pensons que le bon référencement de votre site est en péril suite à la suppression ou au blocage accidentel d’une URL. C’est pourquoi nous nous concentrons sur les « pages importantes », que nous identifions par le nombre de clics qu’elles obtiennent.

Bien entendu, ces trois problèmes – logiciels malveillants, URLs supprimées et URLs bloquées — ne sont pas les seuls facteurs susceptibles de mettre à mal un site. Nous espérons, par le futur, étendre la liste des vérifications d’usage pour déterminer l’état de santé d’un site, et il n’y a évidemment aucun substitut à votre propre jugement de ce qu’il se passe sur votre site. Nous espérons cependant que ces changements faciliteront l’identification de problèmes majeurs sans que vous n’ayez à parcourir tous vos rapports.

Après la résolution d’un problème remonté par nos alertes, il faudra plusieurs jours pour que l’icône et le lien disparaissent de votre compte, car nous avons à réindexer le site, repérer les changements apportés, et traiter ces informations à la fois pour la recherche Web et pour les données des Outils pour les Webmasters. Si vous continuez à voir une alerte sur la santé de ce site après une semaine, c’est sûrement que le problème n’est pas résolu. N’hésitez pas à demander de l’aide dans nos forums, et dites-nous ce que vous pensez de tout ceci !

Posté dans sa version originale en anglais par Susan Moskwa, équipe Google Webmaster Tools

® Goopilation, 2011. | Lien vers l'article | Un commentaire
Publier sur : del.icio.us, Facebook, Twitter

De la même façon que la balise rel= « canonical » donne des indications sur une possible duplication de contenu, vous pouvez désormais utiliser les éléments HTML rel= « next » et rel= « prev » pour indiquer une relation entre différentes URLs d’une série paginée. Sur le Web, une série paginée de contenus peut prendre plusieurs formes : un article divisé en plusieurs pages, une catégorie de produits répartis sur plusieurs pages, ou encore une discussion de forum. Si vous choisissez d’inclure les éléments rel= « next » et rel= « prev » sur les différents éléments d’une série paginée, vous indiquez à Google que vous aimeriez que nous :

• Consolidions les propriétés indexées, comme les liens, en une seule et même entité (par exemple, les liens page-1.html, page-2.html, etc, devraient être regroupés).
• Envoyions les utilisateurs vers la page/URL la plus pertinente, la plupart du temps la première page de la série.

Il y a une exception à l’implémentation de ces balises : si, en plus d’une série paginée, vous offrez également à vos visiteurs une page rassemblant tous les composants de la série, referez-vous à notre article sur le sujet. Les pages consolidées étant généralement préférées par les visiteurs provenant des moteurs de recherche, nous faisons de notre mieux pour leur proposer cette version plutôt qu’un des éléments paginés. Si vous utilisez rel= « next » et rel= « prev », les éléments paginés sont plus susceptibles de ressortir dans les résultats de recherche.

Si vous n’avez pas de page consolidée, ou si vous ne voulez pas que Google la propose aux internautes, vous pouvez utiliser les balises citées

En résumé

Vous avez trois options pour référencer une série paginée :

1. Ne touchez à rien. Le contenu paginé existe sur le Web depuis toujours, et nous continuerons à faire de notre mieux pour proposer le contenu le plus pertinent aux utilisateurs.
2. Si vous avez une page consolidée, referez-vous à notre article.
3. Indiquez à Google la relation entre les différents composants de votre série avec rel= « next » et rel= « prev ». Ceci nous aidera à mieux indexér votre contenu et à offrir à nos utilisateurs des résultats plus pertinents.

Implémenter rel= « next » et rel= « prev »

Si vous optez pour l’option 3, voici comment vous y prendre. Imaginons que vous ayez une série composées des URLs suivantes :

http://www.example.com/article?story=abc&page=1

http://www.example.com/article?story=abc&page=2

http://www.example.com/article?story=abc&page=3

http://www.example.com/article?story=abc&page=4

Sur la première page, http://www.example.com/article?story=abc&page=1, incluez dans la section <head> :
<link rel="next" href="http://www.example.com/article?story=abc&page=2/>

Sur la seconde page, http://www.example.com/article?story=abc&page=2:
<link rel="prev" href="http://www.example.com/article?story=abc&page=1" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3" />

Sur la troisième page, http://www.example.com/article?story=abc&page=3:
<link rel="prev" href="http://www.example.com/article?story=abc&page=2" />
<link rel="next" href="http://www.example.com/article?story=abc&page=4" />

Et sur la dernière page, http://www.example.com/article?story=abc&page=4:
<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

Quelques remarques :

• La première page ne contient que l’élément rel= « next ».
• Les pages 2 et 3 doivent contenir les deux éléments.
• La dernière page ne contient que rel= « prev ».
• Les valeurs de rel= « next » et rel= « prev » peuvent être en URLs absolues ou en relatives. Et si vous ajoutez un élément <base> à votre document, les chemins relatifs seront résolus selon l’URL de base.
• rel= « next » et rel= « prev » ne doivent être déclarés que dans la balise <head>, pas dans le <body>.
• Nous autorisons la variante rel= « previous ».
• rel= « next » et rel= « previous » d’une part et « rel= « canonical » d’autre part constituent deux concepts indépendants. Les deux déclarations peuvent être inclues dans la même page. Par exemple, http://www.example.com/article?story=abc&page=2&sessionid=123 peut contenir :
  <link rel="canonical" href="http://www.example.com/article?story=abc&page=2”/>
<link rel="prev" href="http://www.example.com/article?story=abc&page=1&sessionid=123" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3&sessionid=123" />
• rel= « prev » et rel= « next » ne sont que des indications pour Google, pas des directives strictes.
• Si l’implémentation est incorrecte, par exemple si l’un des éléments de la série ne comporte pas de balise rel= « prev » ou rel= « next », nous continuerons à indexer les pages en nous basant sur nos propres algorithmes pour comprendre l’organisation de votre contenu.

Des questions ?

Vous trouverez plus d’informations sur notre centre d’aide, ou joignez-vous aux discussions sur notre forum d’aide aux webmasters.

Posté dans sa version originale en anglais par Benjia Li & Joachim Kupke, Ingénieurs logiciels, Google

® Goopilation, 2011. | Lien vers l'article | Aucun commentaire
Publier sur : del.icio.us, Facebook, Twitter

Nous avons eu une semaine très chargée au Googleplex. Dans un premier temps, nous avons permis l’intégration du bouton +1 sur tous les sites Web, et nous avons annoncé la sortie du projet Google+.

Le bouton +1 et le projet Google+ permettent tous deux de vous connecter avec les personnes à qui vous faites confiance en ligne. Concernant le bouton +1, il permet de donner des conseils à ses contacts et à ses amis, directement dans les résultats de recherche Google, et permet aux internautes appréciant le contenu de votre site web de le recommander à l’instant même où ils viennent de le lire, ou de le voir.

Mais quand on gère un site Internet, tout cette histoire de bouton +1 n’est pas vraiment palpable tant que l’on peut pas mesurer ses effets sur son trafic. C’est pourquoi, nous somme heureux de vous dire que l’on a encore une annonce à vous faire — aujourd’hui nous mettons à votre disposition des rapports qui vous permettent de mesurer la valeur que nos boutons +1 apportent à votre site.

Dans un premier temps, la métrique +1 dans les Google Webmaster Tools permet d’apprécier comment le bouton +1 impacte le trafic entrant sur vos pages web:

• Le rapport Impact sur le Réseau de Recherche vous donne une idée sur la manière dont vos +1 impactent votre trafic en provenance du moteur de recherche Google. Vous pouvez alors voir si votre taux de clic (CTR) évolue lorsque votre contenu est recommandé. Pour ce faire, comparez le nombre de clics et d’impressions dans les SERPs avec, et sans annotations +1. Nous vous apportons ces statistiques d’évolution de taux de clic que lorsque vous avez une nombre d’impression assez important pour que la comparaison soit significative.
• Le rapport d’activité vous informe sur le nombre de fois que vos page ont reçu un clic sur un bouton +1, que ce soit directement sur votre site ou sur d’autres page (dans les résultats de recherche Google par exemple).
• Pour finir, le rapport d’audience agrège les informations géographiques et démographiques concernant les utilisateurs Google ayant attribué un +1 à vos pages. Pour conserver la vie privée de nos utilisateurs, nous n’affichons ces statistiques que lorsque nous avons un nombre significatif d’entre eux ayant attribué un +1 aux pages de votre site.

Utilisez  dès maintenant le menu de statistiques +1 pour voir tous ces rapports. Si vous n’avez pas encore vérifié votre site sur Google Webmaster Tools, suivez ces informations pour pouvoir ensuite avoir accès à ces statistiques.

En plus de tout ces rapports, vous pouvez aussi voir comment les utilisateurs partagent votre contenu en utilisant les autres boutons de partage que vous placez autour du bouton +1 en utilisant le plugin Social Plugin Tracking que vous trouverez à votre disposition dans Google Analytics (retrouvez comment le faire votre tracking des partages Facebook / Twitter …). Une fois votre code Javascript pour Analytics configuré pour ces boutons de partage, les rapports de la section Réseaux sociaux vous aideront à comparer les différents type de partages qui se produisent sur vos pages.

• Le rapport intérêt et interactionpermet de voir comment le comportement des internautes diffère pour les internautes ayant effectué un clic sur un bouton +1 ou sur le bouton d’un autre partage social. Ça permet de savoir, par exemple si les personnes faisant un +1 au cours de leur visite reste plus longtemps sur le site que ceux qui n’en font pas.
• Le rapport d’Activité sociale permet de suivre le nombre d’actions sociales ( clics +1, Twitter …) effectuées sur votre site, rassemblées au même endroit.
• Le rapport sur les Pages sociales vous permet de remonter les pages de votre site recensant le plus d’actions sociales.

Au cours des prochains jours (et si vous utilisez la version par défaut du code de suivi Google Analytics); et si vous avez ajouté le bouton +1 à votre site, nous activerons automatiquement le suivi  des +1 (Social Plugin Tracking) pour votre compte. Vous pouvez activer le suivi des autres boutons de partage sociaux en quelques étapes très simples.

C’est juste le début des rapports statistiques sur les interactions sociales. Comme les gens continue toujours de trouver de nouvelles façon d’interagir sur le Web, nous réfléchissons encore à de nouveaux rapports pour aider les chefs d’entreprise pour comprendre la valeur qu’apportent les actions sociales à leur business. Donc +1 au contenu!

Posté dans sa version originale par Dan Rodney, Ingénieur logiciel

Note de florentM: De notre coté, chez Goopilation, les premiers +1 sont apparus dans nosrapports Google Webmaster Tools et Google Analytics, coté Google Analytics on a des statistiques sociales depuis mardi 28, et on voit (pour l’instant on a pas énormément de jour pour vraiment tirer des conclusions) que les personnes socialement engagées restent plus longtemps sur Goopilation et par conséquent, leur taux de rebond est plus faible, la page ayant reçu le plus de clics sur les +1 est l’annonce de Google+. Sinon, il faut que je regarde avec Vincent pour voir si l’ajout du tracking sur les Like Facebook et le bouton Twitter dans le plugin WordPress que l’on utilise n’est pas trop compliqué .

® Goopilation, 2011. | Lien vers l'article | 2 commentaires
Publier sur : del.icio.us, Facebook, Twitter

Nous annonçons aujourd’hui schema.org, une nouvelle initiative lancée conjointement par Google, Bing et Yahoo! pour créer et prendre en charge un ensemble de formats structurés de données sémantiques. Schema.org a pour objectif d’être le site de référence pour tous les webmasters désirant ajouter des microformats à leurs pages Web afin d’aider les moteurs de recherche à mieux comprendre les sites.

Chez Google, nous prenons en charge les formats de données sémantiques depuis plus de deux ans. Nous avons introduit les extraits enrichis en 2009 pour mieux présenter les résultats de recherche décrivant des personnalités ou contenant des avis. Nous avons depuis étendu notre catalogues d’extraits enrichis pour y inclure les produits, les évènements, les recettes, et bien plus.

L’adoption par la communauté des webmasters a été très rapide, et nous sommes aujourd’hui en mesure de présenter 10 fois plus d’extraits enrichis que lorsque nous avons commencé l’année dernière.

Nous voulons continuer à rendre le Web plus riche et plus utile. Nous savons qu’ajouter de telles données à vos pages demande du temps et des efforts, et cela devient quasiment impossible si chaque moteur de recherche demande les données dans des formats différents. C’est pourquoi nous nous sommes unis à d’autres moteurs de recherche pour prendre en charge un ensemble défini de schémas, de la même façon que nous nous étions unis en 2006 pour définir le format standard des sitemaps. Avec schema.org, les éditeurs de sites peuvent améliorer la façon dont leurs sites apparaissent dans les résultats de Google, Bing et Yahoo!, et peut-être d’autres moteurs de recherche par le futur.

Voyons maintenant les détails importants pour vous en tant que webmaster :

1) Schema.org contient de nombreux nouveaux marqueurs

Nous avons ajouté plus de 100 nouveaux types de données sémantiques, en plus de ceux existants. Si vous aviez envisagé d’ajouter des données sémantiques à vos sites Web mais qu’aucun des types proposés n’était pertinent, regardez à nouveau. En voici certains :

• Créations : Oeuvres Créatives, Livres, Films, Musique, Recette, Série TV
• Objets embarqués non textuels : Objets audio, Objets illustrés, Objets vidéo
• Evènements
• Organisations
• Personnes
• Lieux, Commerces locaux, Restaurants
• Produits, Offres, Offres groupées
• Avis, Avis agrégés

Voir la liste complète des types de données sémantiques.

2) Schema.org utilise les microdonnées

D’un point de vue historique, nous prenons en charge 3 standards de données sémantiques : microdonnées, microformats, et RDFa. Nous avons décidé de nous concentré sur un seul formats pour schema.org, afin de simplifier le travail des webmasters et d’uniformiser les moteurs de recherche. Chaque type de format a ses avantages, mais nous avons conclu que les microdonnées représentent un compromis entre l’extensibilité du RDFa et la simplicité des microformats.

Pour une explication sur la mise en place des microdonnées, jetez un oeil à ce guide pour débutant.

3) Nous continuerons à prendre en charge les autres formats.

Si vous avez déjà ajouté des données sémantiques en utilisant les microformats ou RDFa, nous continuerons à les prendre en charge. Il faut cependant garder un détail à l’esprit : quelque soit le type de données que vous utilisiez, cantonnez-vous à ce dernier. Utiliser plusieurs types de formats de données sur une même page peut perturber nos robots d’exploration.

4) Testez vos marqueurs grâce à l’outil de test des extraits enrichis

Il est très utile de tester vos pages Web afin de vous assurer que nous serons en mesure de traiter les données correctement. Comme pour les formats de données précédents, vous devez utiliser l’outil de test. Notez que même si les données relatives à vos marqueurs seront affichées, la prévisualisation des extraits enrichis n’est pas encore active pour schema.org. Nous ajouterons cette fonctionnalité ultérieurement.

Le site schema.org et l’outil de test sont en anglais. Toutefois, Google prend en charge les extraits enrichis mondialement, il n’y a donc aucune raison de ne pas implémenter ces marqueurs immédiatement.

Pour en savoir plus sur les extraits enrichis et sur schema.org, consultez notre FAQ sur le sujet.

Posté dans sa version originale en anglais par Kavi Goel et Pravir Gupta,
équipe Recherche Qualité chez Google

® Goopilation, 2011. | Lien vers l'article | Un commentaire
Publier sur : del.icio.us, Facebook, Twitter

Depuis le déploiement du bouton +1 en mars dernier, vous avez été en mesure de recommander du contenu à vos amis et à vos contacts directement depuis les résultats de recherche et la publicité Google.

Parfois, il se peut que vous désiriez recommander une page pendant que vous la visitez. Après tout, comment pourriez-vous savoir si vous allez recommander la recette d’un flan au chocolat avoir de l’avoir essayer ?

C’est pourquoi nous lançons aujourd’hui les boutons +1, que vous devriez commencer à voir apparaître sur plusieurs sites. Nous avons conclu des partenariat avec quelques sites, sur lesquels vous verrez les boutons +1 dans un futur proche :

Vous verrez également les boutons +1 sur d’autres produits Google comme l’Android Market, Blogger, Product Search et YouTube.

Recommander un site est aussi simple sur le reste du Web que sur les résultats de recherche Google. D’un seul clic, vous pouvez recommander cette veste, cet article d’actualité, ou ce film de science fiction à vos amis, contacts et au reste du monde. Une fois que vous avez +1 un site, vos amis pourront voir votre +1 directement dans leurs résultats de recherche.

En attendant, nous continuons à déployer le bouton +1 pour les recherches en anglais sur Google.com. Si vous souhaitez commencer dès maintenant à recommander des résultats de recherche, vous pouvez activer la fonctionnalité expérimentale. Pour voir les recommandations de vos amis dans vos résultats de recherche, n’oubliez pas de vous connecter à votre compte Google.

Si vous êtes un webmaster, vous pouvez obtenir le code du bouton +1 et en savoir plus sur son implémentation sur notre site dédié aux webmasters. Vous pourrez configurer un petit bout de code JavaScript et l’insérer sur votre page là où vous souhaitez ajouter le bouton. Vous avez le choix entre plusieurs tailles et styles, donc choisissez le bouton qui correspond au mieux à votre site.

Si votre site est à destination d’utilisateurs en dehors des Etats-Unis et du Canada, vous pouvez quant même installer le bouton dès aujourd’hui, puisque ce dernier est traduit en 44 langues. Toutefois, gardez à l’esprit que les annotations +1 n’apparaissent que sur les résultats de recherche en anglais sur Google.com. Nous travaillons sur le déploiement de +1 dans le monde entier.

Posté dans sa version originale en anglais par Evan Gilbert, Ingénieur Google +1

® Goopilation, 2011. | Lien vers l'article | 3 commentaires
Publier sur : del.icio.us, Facebook, Twitter

Vous voici donc en train de vérifier que tout tourne bien pour votre site sur Google Webmaster Tools… Mais attendez ! La page Erreurs d’exploration est pleine d’erreurs 404 (introuvables) ! Désastre à l’horizon ??

N’ayez aucune crainte, jeune padawan. Regardons ensembles les 404 et comment elles affectent (ou pas) votre site :

Q : Est-ce que les erreurs 404 signalées dans les outils pour les webmasters affectent mon classement dans Google ?

R : Les pages 404 sont un phénomène normal sur le Web ; Internet est en constante mutation, du contenu nouveau apparaît, et du contenu ancien meurt, et lorsqu’il meurt, il renvoie un code d’erreur 404. Les moteurs de recherches en sont conscients. Nous avons des erreurs 404 sur nos propres sites, comme vous pouvez le voir ci-contre, et nous en trouvons partout sur le Web. Nous préférons d’ailleurs que les pages supprimées sur vos sites renvoient un code 404 ou 410 au lieu de ne rien renvoyer du tout. Gardez à l’esprit que, pour que nos robots soient en mesure de voir la réponse HTTP d’une URL, cette URL doit être accessible. Si l’URL est bloquée par votre robots.txt, nous ne pourrons pas l’indexer et voir son code HTTP. Le fait que certaines URLs sur votre site n’existe plus ou renvoie un code d’erreur 404 n’affecte en rien le classement de vos autres URLs (celles qui renvoient un code 200) dans nos résultats de recherche.

Q : Donc les 404 ne nuisent pas du tout à mon site ?

R : Si certaines URLs sur votre site renvoient une erreur 404, alors pas de problème. Cependant, certaines 404 peuvent nécessiter une action de votre part. Par exemple, si certaines des pages en 404 sont des pages importantes pour vous, vous devriez regarder pourquoi nous les voyons en 404 lorsque nous les indexons ! Si vous remarquez une URL mal orthographiée (par exemple www.exemple.com/superpage au lieu de www.exemple.com/super-page), il est fort probable qu’un site tiers ait voulu faire un lien vers vous mais se soit trompé dans l’URL. Au lieu de renvoyer 404, vous pourriez rediriger l’URL mal orthographiée en 301 vers la bonne version. Vous devriez également faire en sorte que votre page 404 ne soit pas un cul de sac et permette aux visiteurs d’aller explorer d’autres pages de votre site.

Q : Dites m’en plus sur les « soft 404″

R : Une erreur « soft 404″, c’est quand un serveur renvoie un autre code que 404 pour une page qui n’existe pas. Nous voyons fréquemment des webmasters désirant afficher une page 404 utile pour le visiteur, et qui pensent qu’ils doivent renvoyer le code 200. Que néni ! Vous pouvez renvoyer le code 404 tout en affichant n’importe quel contenu. Autre exemple : un site qui redirige toutes les pages qui n’existent pas vers la page d’accueil au lieu renvoyer un code 404. Cas deux cas peuvent affecter négativement votre référencement, donc nous vous recommandons de toujours retourner le bon code d’erreur pour les pages inexistantes. Sachez aussi que parce qu’une page affiche « 404 introuvable », ça ne signifie pas pour autant que son code HTTP soit 404. Utilisez la fonctionnalité « Analyser comme Googlebot » dans les outils pour les webmasters pour bien vérifier. Si vous ne savez pas comment faire en sorte de retourner les bons codes HTTP, voyez avec votre hébergeur.

Q : Comment savoir si une URL doit renvoyer 404, 301, ou 410 ?

R : Lorsque vous supprimez une page de votre site, déterminez si ce contenu est déplacé autre part, ou si vous n’avez simplement plus besoin de ce contenu. Si vous le déplacez vers une nouvelle URL, vous devriez faire une redirection 301 de l’ancienne vers la nouvelle URL. De cette façon, lorsque les utilisateurs atterrissent sur l’ancienne URL, ils sont automatiquement redirigés vers la nouvelle. Si vous supprimez purement et simplement le contenu, alors l’ancienne URL doit retourner un code 404 ou 410. Actuellement, Google traite les codes 410 (contenu supprimé) et 404 (contenu introuvable) de la même façon.

Q : La plupart des mes erreurs 404 concernent des URLs qui n’ont jamais existé sur mon site. D’où viennent-elles ?

R : Si Google trouve un lien quelque part sur le Web qui pointe vers une URL chez vous, il pourrait essayer de l’indexer, que le contenu existe ou pas. Si il n’existe pas, votre serveur doit retourner un code 404. Ces liens découlent peut-être d’erreurs dans les liens sur des sites tiers, d’une erreur de configuration (si les liens sont automatiquement générés, par exemple par un CMS), ou des efforts de Google d’indexer les URLs présentes dans les bouts de code JavaScript. Google peut aussi tester comment votre serveur répond à un contenu inexistant. Si vous voyez des pages qui n’existent pas sur votre en 404, vous pouvez tout simplement les ignorer. Nous ne pouvons pas savoir quelles URLs sont importantes pour vous et lesquelles ne le sont pas, nous les affichons donc toutes dans le rapport afin que vous puissiez décider lesquelles nécessitent une action de votre part.

Q : Quelqu’un a aspiré mon site et a généré énormément de 404. Cela peut me poser un problème ?

R : En général, vous n’avez pas besoin de vous soucier des liens erronés. Nous comprenons que les webmasters n’aient aucun contrôle sur les gens qui aspirent leurs sites, ou sur les liens qui pointent vers eux. Si vous êtes un as de l’expression régulière, vous pouvez essayer de rediriger toutes ces URLs comme décrit ici, mais de manière générale vous n’avez pas besoin de vous en préoccuper.

Q : La semaine dernière, j’ai corrigé toutes les 404s signalées par Webmaster Tools, mais elles sont toujours listées dans le rapport. Cela veut dire que je ne les ai pas bien corrigé ? Combien de temps avant que le rapport se mette à jour ?

R : Regardez la colonne « détecté » sur le rapport d’erreurs d’exploration. Vous y verrez la date à laquelle nous avons repéré chaque erreur. Si la date indiquée est d’avant vos corrections, alors nous n’avons pas rencontré cette erreur depuis vos corrections.

Q : Puis-je utiliser l’outil de suppression d’URL de Google pour accélérer la procédure ?

R : Non. L’outil de suppression d’URL de Google supprime les URLs des résultats de Google, mais ne les supprime pas des rapports présents sur les outils pour les webmasters. Cet outil est destiné aux demandes urgentes, et l’utiliser n’est pas nécessaire lorsqu’une URL renvoie déjà un code 404 puisque cette dernière disparaîtra de nos résultats avec le temps.

Article original en anglais par Susan Moskwa, de l’équipe Google Webmaster Tools

® Goopilation, 2011. | Lien vers l'article | 3 commentaires
Publier sur : del.icio.us, Facebook, Twitter

Pour les webmasters hébergeant eux-même leur blogs WordPress, il y a désormais un plugin WordPress pour la vérification de site dans les Outils pour les webmasters Google qui automatise le process de vérification! Vous pouvez dès à présent l’installer directement depuis le menu WordPress permettant d’Installer des extensions, sinon, vous pouvez toujours télécharger l’archive ZIP depuis le site de plugins WordPress. Ce plugin peut uniquement être installé sur des blogs WordPress hébergés en direct par son Webmaster, et donc ne peut pas être installé sur un blog hébergé sur WordPress.com.

En vérifiant le fait que vous êtes bien le propriétaire de votre site dans les Outils pour les webmasters Google, vous pouvez obtenir de Google des statistiques et informations spécifiques à votre site (par exemple les requêtes de recherche sur lesquelles votre site remonte, la détection de la présence de logiciels malveillants … ). Pour des informations récentes à propos de la vérification des sites dans les Outils pour les webmasters, n’hésitez pas à lire notre article “Your fast pass through security.”

Article rédigé dans sa version originale en anglais par Kevin Marshall, Ingénieur logiciel

® Goopilation, 2011. | Lien vers l'article | Aucun commentaire
Publier sur : del.icio.us, Facebook, Twitter

Nous avons remarqué une augmentation du nombre de questions portant sur la structure des sites pour les mobiles et sur les interactions avec Googlebot-Mobile. Nous décrivons dans cet article  la situation actuelle, et vous donnons des recommandations précises sur ce que vous pouvez faire dès maintenant (voir aussi Aidez Google à référencer votre site mobile).

Navigateurs et contenus mobiles

Commençons par une question simple : que signifions-nous par « téléphones mobiles » lorsque nous faisons références aux sites optimisés mobile ?

Un bon moyen de répondre à cette question est de penser aux capacité des navigateurs mobiles, et de les mettre en relation avec les capacités des navigateurs de bureau modernes. Pour simplifier notre sujet, nous pouvons diviser les téléphones mobiles en deux catégories :

1. Téléphones traditionnels : les téléphones dont les navigateurs ne peuvent pas afficher des pages Web classiques. Ces derniers inclus les navigateurs cHTML (iMode), WML, WAP, et ainsi de suite.
2. Smartphones : les téléphones dont les navigateurs affichent les pages classiques, à un certain degré. Cette catégorie inclue toute une diversité d’appareils, dont Windows Phone 7, Blackberry, iPhone, et Android, ainsi que les tablettes et les lecteurs eBooks.Nous pouvons différencier plusieurs types de téléphones dans cette catégorie selon leur prise en charge du HTML5 :
   • Les appareils dont les navigateurs prennent en charge le HTML5
   • Les appareils dont les navigateurs ne prennent pas en charge le HTML5

Il y a fort longtemps, les téléphones mobiles se connectaient à Internet via des navigateurs à capacités limitées ; ce qui est en train de changer avec l’adoption massive des smartphones dotés de navigateurs rivalisant avec les navigateurs de bureau. Il est donc important de noter que les distinctions que nous faisons aujourd’hui sont basées sur la situation actuelle et sont susceptibles de changer dans le futur.

Googlebot et contenu mobile

Google a deux robots concernés par notre sujet : Googlebot et Googlebot-Mobile. Googlebot explore les pages destinées au navigateurs de bureau, tandis que Googlebot-Mobile explore le contenu mobile. Les nombreuses questions que nous avons reçu peuvent plus ou moins être résumées en une seule question :

Connaissant la diversité des capacités des navigateurs mobiles, quel contenu devrais-je monter au Googlebot-Mobile ?

La réponse réside dans le User-Agent que Googlebot-Mobile délivre lors de son exploration. Il y a plusieurs User-Agent pour le Googlebot-Mobile, qui suivent tous le format ci-dessous :

[Nom du(des) téléphone(s)] (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

Pour décider quel contenu délivrer au Googlebot-Mobile, déterminez quel contenu est le plus adéquat selon le téléphone concerné par le user-Agent. Vous trouverez ici une liste complète des User-Agents du Googlebot-Mobile.

Notez que Googlebot-Mobile n’explore actuellement pas les pages en utilisant le User-Agent d’un smartphone. Par conséquent, en l’état actuel des choses, un système correctement configuré délivrera au Googlebot-Mobile du contenu destiné aux téléphones traditionnels cités plus haut. Ceci est susceptibles de changer à l’avenir, et cela se traduirai par de nouveaux User-Agents.

Pour le moment, nous attendons des smartphones qu’ils affichent le contenu tel qu’il serait affiché sur un navigateur de bureau, il n’est donc pas absolument nécessaire de prendre des mesures spécifiques. Toutefois, pour beaucoup de sites Web, il peut être intéressant de formatter le contenu différemment pour les smartphones, et la décision de le faire devrait être basée sur la meilleure façon de servir vos utilisateurs.

Structure des URL pour les contenus mobiles

D’autres questions concernent les URLs d’accès au contenu mobile. Regardons quelques exemples d’utilisation classique :

Sites Web contenant uniquement du contenu destiné aux navigateurs de bureau

La plupart des sites ne proposent qu’une seule version de leur contenu, principalement destiné aux navigateurs de bureau. Tous les navigateurs accèdent donc au même contenu depuis la même URL.

Ces sites Web ne possèdent sans doute pas de contenu pour les téléphones traditionnels. La qualité du site affiché sur un smartphone dépend de la qualité du navigateur, et peut être aussi bonne que sur un navigateur de bureau.

Si vous affichez le même contenu pour tous les User-Agents, vous devriez en faire de même pour Googlebot-Mobile. Traitez Googlebot-Mobile comme n’importe quel autre User-Agent. Dans ces cas, Google peut modifier vos pages Web pour une expérience mobile améliorée.

Sites Web avec contenu dédié au mobile

Beaucoup de sites proposent du contenu spécialement optimisé pour les utilisateurs mobiles. Le contenu peut être mis en page pour une largeur d’écran moindre, ou peut être dans un format différent (par exemple via WAP).

Une question particulièrement courante est : cela a-t-il une incidence si les différents types de contenus sont délivrés par la même URL ou par plusieurs URLs ? Par exemple, certains sites ont www.exemple.com pour les navigateurs de bureau, et m.exemple.com pour les navigateurs mobiles, ou encore wap.exemple.com. D’autres sites offrent tous les types de contenus depuis une seule et même URL.

Pour Googlebot et Googlebot-Mobile, la structure de l’URL n’a aucune incidence à condition que le robot voit exactement ce que voient les utilisateurs. Par exemple, si vous redirigez les utilisateurs mobiles de www.exemple.com vers m.exemple.com, Googlebot-Mobile en tiendra compte et les deux sites seront explorés et ajoutés aux index correspondant. Dans ce cas, utilisez une redirection 301 pour à la fois les utilisateurs et Googlebot-Mobile.

Si vous servez tous les types de contenus sur www.exemple.com selon le User-Agent, Googlebot et Googlebot-Mobile les exploreront aussi correctement. Ce n’est pas considéré comme du cloaking par Google.

Il est bon de répéter que quelque soit la structure de l’URL, vous devez correctement détecter le User-Agent tel que fournit par vos visiteurs et par Googlebot-Mobile, et leur afficher à tous le même contenu. N’oubliez pas de délivrer un contenu par défaut au cas où le User-Agent ne seraient pas reconnu.

Sitemaps mobiles dans les Outils pour les Webmasters

Enfin, nous recevons pas mal de questions sur quelles URLs mettre dans le Sitemap Mobile. Comme expliqué dans notre centre d’aide, vous devrez seulement inclure des URLs de contenu mobile dans les Sitemaps Mobile, même si ces URLs affichent aussi du contenu non-mobile lorsqu’elles sont demandées par un navigateur de bureau.

Plus de questions ?

Un bon endroit pour commencer est notre centre d’aide pour les sites mobiles, ainsi les sections concernées dans le guide SEO pour débutant. Nous avons aussi créé une discussion dans les forums dédiées aux questions liées à cet article.

Posté dans sa version originale en anglais par Pierre Far, Webmaster Trends Analyst

® Goopilation, 2011. | Lien vers l'article | 2 commentaires
Publier sur : del.icio.us, Facebook, Twitter