Google confirme qu\'il utilisera l\'Authorship si beaucoup de gens l\'implémentent

Ils sont nombreux les marketeurs et autres qui ont appris que , par la voix de son Googler Gary Illyes, recommandait de ne pas définitivement abandonner l’Authorship.

Google confirme qu\'il utilisera l\'Authorship si beaucoup de gens l\'implémentent

En d’autres termes, soit il fallait le remettre dans le code source, soit il fallait continuer à le garder s’il n’avait pas encore été supprimé de votre site.

Il est vrai que jusqu’à maintenant, ça paraît quand même assez curieux cette proposition presqu’indécente de Google, après nous avoir déclaré qu’il ne tenait plus compte de l’Authosrhip et qu’on pouvait le supprimer.

Pour ma part, j’ai donné mon point de vue sur ce retour hypothétique de l’authorship ici.

Mais, voilà que le même Gary Illyes en remet une couche, comme nous le rapporte Barry Schwartz.

Dans le Tweet ci-dessous, c’est Mark Traphagen qui commente l’annonce de Gary Illyes en disant que ce n’est pas une promesse. Mais, c’est juste Gary Illyes qui donne son opinion en disant que cela fait sens de ne pas le supprimer.

Gary Illyes répond donc à ce Tweet en disant (voir ci-dessus) : “En général, si nous voyons que des gens utilisent toujours quelque chose, nous allons alors essayer d\’en faire usage”.

C’est alors que Mark Traphagen revient à la charge pour réclamer une réponse plus précise en disant : “Si beaucoup de gens se mettaient à utiliser “rel=author” (le tag de l’authorship, NDLR), vous pourriez l\’utiliser à nouveau ?

Ce à quoi répond sans détours Gary Illyes (voir ci-dessus) : “Ce serait honnête de dire Oui.

A mon avis, Google sait (en fonction du signal émis) que la grande majorité des webmasters qui avaient mis en place le code HTML “rel=author” ne l’ont toujours pas retiré. Par conséquent, et peut-être qu’il le faisait déjà sans l’annoncer, il pourrait dans les temps à venir s’en servir … à nouveau.

Google confirme qu\'il existe bel et bien un index mobile en cours de test

Cela fait des mois que des échos nous parviennent sur le développement par d’un index strictement dédié au mobile.

Google : Gary Illyes confirme qu\'il y a bel et bien un Index mobile encore en test

Le premier à l’avoir évoqué est bien Gary Illyes, Webmaster Trends Analyst chez Google. Mais, quelques jours après en avoir parlé, sans doute après avoir été rappelé à l’ordre, il a tenté de nuancer son propos.

Ensuite, c’est +Maile Ohye, Senior Developer Programs Engineer chez Google, qui a confirmé cet index mobile à venir.

Et aujourd’hui, c’est encore Gary Illyes, comme le révèle Barry Schwartz, qui vient de publier un Tweet qui confirme bel et bien que Google est train de travailler sur un moteur de recherche mobile avec son propre algorithme de classement, et donc ses propres critères de classement.

Gary Illyes déclare ceci dans son Tweet:

”.

Certainement que Google a besoin d’un index exclusivement dédié au mobile, notamment pour son projet d’intégration des contenus web dans ses pages de résultats sur mobile. Ce qui devrait faciliter l’indexation et le stockage en cache des contenus mobile-friendly.

Google : Une page d\'erreur 404 ne pénalise pas le site

Selon une certaine légende qui perdure, de nombreuses pages à l’intérieur d’un site web renvoyant un code erreur 404, parce qu’introuvables, seraient un mauvais signal pouvant pénaliser le référencement dudit site.

Erreur 404

Bien entendu, pour une bonne expérience utilisateur de vos visiteurs, il est préférable de faire en sorte que ces derniers ne tombent pas sur de telles pages.

Il est donc normalement recommandé de mettre en place des redirections si le contenu a changé d’adresse, surtout lors d’une migration du site ou s’il a été remplacé par un autre contenu actualisé, ou encore s’il n’existe même pas sur le site..

Non, si l’on en croit le Tweet ci-dessous de +Gary Illyes, Webmaster Trends Analyst chez :

Gary Illyes déclare donc :

Si vous vous faîtes à l’idée qu’avoir des erreurs 404 génère une quelconque pénalité, vous vous trompez. Vous avez tout à fait tort.

Ce qui est somme toute logique. Car, à l’heure du negative SEO, il suffirait qu’une personne de mauvaise foi ou un concurrent pointe des liens fictifs ou incorrectement transcrits vers des contenus qui existent ou n’existent même pas sur votre site pour que votre référencement s’en trouve pénalisé.

D’autre part, l’erreur 404 peut être due à un bug ou une panne technique du support CMS (, par exemple), ou à une mauvaise configuration du serveur ou encore à une mauvaise configuration lors d’une migration vers un serveur sécurisé ou lors d’une refonte du site

Autant de raisons qui ne sauraient donc justifier qu’un site soit pénalisé.

D’ailleurs, dans sa page d’aide relative aux “erreurs de type page introuvable (404)”, Google confirme bien les propos de Gary Illyes en ces termes :

En règle générale, les erreurs 404 n\’ont aucune incidence négative sur les performances de votre site dans les résultats de recherche Google. Vous pouvez les ignorer sans problème.

Toujours est-il qu’avoir une bonne page d’erreur personnalisée avec un moteur de recherche interne pourrait aider vos visiteurs à retrouver le contenu recherché. Et ils vous en sauront gré de les avoir aidés.

Google Search Console va mieux cibler les destinataires de ses messages d\'alerte

+Gary Illyes, Webmaster Trends Analyst chez , vient de publier le post ci-dessous pour annoncer un changement à venir dans Google Search Console (ex Google webmaster Tools).

Selon Gary Illyes, dans les toutes prochaines semaines, Console va changer comment et à qui il envoie les messages d’alerte et les notifications concernant les sites web validés.

Google Search Console

Sont donc concernés des plateformes d\’hébergement de sites et de blogs gratuits tels que Blogger, .com, Wix, etc…

Gary Illyes annonce donc que les propriétaires de ces plateformes ne recevront plus de messages, concernant des ou virus par exemple, à propos des sites ou blogs qu’ils hébergent à titre gratuit ou payant en sous-domaine.

Pour ma part, je pense que cela éviterait que les administrateurs de ces sites soient dorénavant surpris par une pénalité manuelle ou une quelconque désactivation de la part de Google. N’ayant pas reçu de message d’alerte, ils ne peuvent agir rapidement.

Ainsi, avec comme exemple de site en sous-domaine “wordpress.com/monsite”, ce n’est plus “Wordpress.com” qui recevra les messages d’alerte provenant de , mais bel et bien le propriétaire de “monsite” hébergé par wordpress.com qui recevra les messages.

Mais, Gary Illyes précise que bien que cette modification s\’appliquera à la plupart des messages, des messages critiques (par exemple, une alerte concernant le piratage d’un site) peuvent encore être envoyés à tous les propriétaires de plateformes d’hébergement web en sous-domaine.

Google n\'indexe pas toutes les URL rencontrées durant son exploration

En dehors de tous les liens privés interdisant leur accès pour indexation, Gary Illyes de chez vient de faire une déclaration intéressante lors de la SMX Advanced de Seattle (2 et 3 Juin).

Google

Gary Illyes aurait laissé entendre que Google a accès à plus de 30 mille milliards d’URL (en anglais : 30 Trillion) sur le web. Un chiffre qui, selon Barry Schwartz, aurait déjà été révélé par Google en 2013.

Mais, poursuit Gary Illyes, Google n’a pas suffisamment de serveurs pour stocker toutes ces URL. En d’autres termes, ce n’est pas parce que Google connaît l’existence d’un lien pour l’avoir exploré qu’il va forcément l’indexer.

Pendant l’exploration de Googlebot, celui-ci déciderait alors si le contenu visité mérite d’être indexé ou pas.

S’en suit le LiveTweet ci-dessous qui rapporte les propros de Gary Illyes (alias @methode) en disant qu’il y a 30 mille milliards d’URL dans l’index de Google, mais ce dernier n’a pas les moyens de les stocker toutes.

Ce à quoi répond plus tard Gary Illyes par le Tweet ci-dessous pour indiquer que Google connaît l’existence de ce nombre d’URL mais qu’il ne peut effectivement pas les indexer toutes.

Bref, ce qu’il faut bien comprendre, c’est que Google ne va pas s’embêter à indexer des contenus qu’il juge complètement inutiles.

Je profite de l’occasion pour vous présenter cet autre LiveTweet ci-dessous:

Traduction du Tweet selon lequel Gary Illyes aurait aussi déclaré lors de cette même conférence que “lorsque Google avait supprimé l’Authorship des résultats de recherche, il n’a pas pour autant renoncé à l’Autorité des auteurs des contenus ainsi qu\’à celle des Editeurs ou des Marques (Publishership).

Comprenne qui pourra…

Google poursuit le développement d\'un index mobile

Au mois de Mars dernier, Gary Illyes, Webmaster Trends Analyst chez , avait fait savoir, peut-être malencontreusement, que Google s’apprêtait à lancer un moteur de recherche exclusivement dédié au mobile.

Google continue de travailler sur un moteur de recherche pour le mobile

Ce qui voulait dire que la recherche mobile allait tôt ou tard bénéficier d’un index mobile, différent de celui de l’ordinateur, pour mieux appliquer les critères de l’algorithme Mobile-Friendly.

+Maile Ohye, Senior Developer Programs Engineer chez Google, qui vient de révéler à la SMX London (20 et 21 Mai 2015) qu’il existe quelques problèmes qui empêchent Google d’être en mesure d’afficher la bonne URL sur mobile.

D’où, sans doute, ce retard dans le lancement…

L’un des problème de cet index mobile en développement se situerait au niveau de certains sites ayant des contenus avec pagination. Vous vous souvenez sans doute de la déclaration de John Mueller disant que Google n’indexera plus les contenus mobiles invisibles parce que cachés dans des onglets ou dans des accordéons ?

Enfin, on sait pourquoi John Mueller l’avait dit. C’est parce que cela compliquant la tâche aux développeurs de Mobile.

Ainsi, Google Search Mobile aurait des problèmes pour, par exemple, indexer totalement un contenu publié sur plusieurs pages.

Je comprends aussi maintenant pourquoi Google avait relancé le débat entre site mobile et site en responsive design.

Ce qui éviterait d’ailleurs les erreurs souvent courantes avec une URL identique pour un même contenu sur mobile et sur desktop.

Pourquoi le Mobile-Friendly a-t-il accouché d\'une souris ?

Apparemment, l’algorithme Mobile-Friendly récemment lancé par n’a pas eu au final l’impact tant redouté par les webmasters.

Par conséquent, le chamboulement auquel on pouvait s’attendre dans le classement des pages lors des recherches sur mobile n’a vraiment pas eu lieu.

Pourquoi le Mobile-Friendly a-t-il accouché d\'une souris

C’était à se demander si finalement Google avait vraiment lancé son nouveau critère de classement sur mobile. Alors, pourquoi cette impression que le critère “compatible mobile” pourrait n’avoir jamais été réellement lancé ?

C’est encore John Mueller qui apporte des précisions lors d’un Hangout réalisé la semaine dernière en ces termes (vidéo 12:20) :

Donc vous aurez aimé qu’il (le mobile-friendly, NDLR) soit plus visible ?

Et pourtant, le Mobile-Friendly a été complètement déployé…  

C\’est quelque chose qui affecte un grand nombre de sites différents, un grand nombre de requêtes différentes. Mais, il n’est pas tel que les sites disparaissent totalement des résultats de recherche parce qu’ils ne sont pas encore compatibles avec le mobile.

D\’une part, cela fait beaucoup sens pour les sites qui ne sont pas encore Mobile-Friendly, ce qui peut être le cas des petites entreprises qui n\’ont pas eu le temps ou l\’argent pour régler leurs sites pour cela.

Ce sont donc des résultats (Sites pas encore compatibles mobile, NDLR) qui sont toujours assez pertinents dans les résultats de recherche, nous avons donc besoin de les garder là quand même.

L\’autre aspect que nous avons remarqué, c\’est que beaucoup de sites ont vraiment migré vers la compatibilité mobile. Alors, là où nous nous attendions à un plus grand changement, parce que nous pensions qu’un plus grand nombre de sites n\’étaient pas compatibles avec le mobile, n\’ayant pas eu le temps de le faire, finalement ce grand changement n’a pas eu lieu (dans les résultats de recherche, NDLR).

Ce qu’explique ici John Mueller, c’est qu’en raison du teasing lancé par Google à la mi-Février dernier pour un début de l’application du Mobile-Friendly en tant que critère de ranking à compter du 21 Avril 2015, beaucoup de sites ont eu le temps d’être améliorés dans le sens de la compatibilité mobile.

Beaucoup plus, à tel point qu’ils ont été surpris chez Google. Il ne reste vraisemblablement qu’une poignée de sites qui seraient en train de faire le nécessaire. Par conséquent, l’impact du Mobile-Friendly ne pouvait qu’être beaucoup moins visible dans les résultats de recherche sur mobile.

Toutefois, John Mueller laisse entendre que l’algorithme mobile friendly va entamer une deuxième phase en incluant d’autres critères plus adaptés au mobile (le temps de chargement, par exemple) qui, eux, pourraient avoir un impact dans les SERP.

C’est sans doute alors que Google pourrait annoncer, comme le faisait déjà savoir Gary Illyes, le lancement d’un moteur de recherche exclusivement dédié au mobile qui serait alors différent de celui du desktop.

80% des URL en HTTPS s\'affichent en http sur Google pour cause d’erreurs

C’est encore +Gary Illyes qui se signale à nouveau dans un post sur + pour publier une analyse sur l’affichage des URL en dans les pages de résultats de Google.

Et ce, en complément de tout ce qu’il a récemment dit concernant le HTTPS lors de la SMX West Conference de San José.

80% des URL en HTTPs ne peuvent s’afficher ainsi dans Google pour cause d’erreurs

Il s’agit donc d’une mise au point de Gary Illyes pour faire comprendre aux webmasters ayant migré du HTTP vers le HTTPs qu’il y a encore de nombreux réglages techniques à faire.

Car, il y a va aussi de la visibilité de la mention HTTPs sur leurs liens dans les SERP.

Gary Illyes révèle donc que 80% des URL en HTTPS qui sont éligibles pour s’afficher ainsi dans les pages de résultats de Google n’y sont pas encore parce que les webmasters auraient oublié d’utiliser la bonne URL canonique (rel=”canonical”).

En ce sens que 80% des sites sécurisés en HTTPS n’ont pas remplacé l’URL canonique des pages en HTTP par celle des pages en HTTPS.

Alors, webmasters, si vous voulez que Google affiche le label https dans votre URL, il vous revient à vous de le lui faire savoir à travers la bonne URL canonique en HTTPS. Pour ce faire, vous devez corriger ou remplacer les anciennes rel=\ »canonical\ » avec les nouvelles faisant référence à votre hébergement sécurisé.

Et surtout, soumettez un fichier Sitemap dont les URL sont en https. Et faîtes en de même avec vos notifications de version en langues étrangères (rel-alternate-hreflang).

N’oubliez pas, soit dit en passant, les liens de vos images pour éviter que votre site ne soit signalé aux utilisateurs comme ayant un certificat de sécurité non valide.

Le contenu dupliqué n\'est pas une pénalité Google

Depuis le lancement de Google Panda, nous avons toujours dit que le contenu dupliqué étaient à surveiller de très près afin d’éviter toute pénalité .

Le contenu dupliqué ne serait pas une pénalité Google

Mais voilà, +Gary Illyes, Webmaster Trends Analyst chez Google, très loquace en ce moment, notamment lors de la dernière SMX de San José, aurait déclaré lors de l’un de ses exposés que la pénalité pour duplicate content est un mythe .

.

ne classera pas de résultats de recherche avec des doublons.

A moins que l’utilisateur ne clique sur le lien “afficher les résultats de recherche similaires aux pages indiquées ci-dessus” placé tout en bas des SERP.

Ce n’est pas, poursuit Gary Illyes, parce que vous avez du contenu dupliqué que ceux-ci ne seront jamais visibles dans . Seulement, Google préfère les masquer et ne les afficher que si l’utilisateur souhaite les voir.

Quand Google décide-t-il de ralentir ou d\'arrêter l\'indexation d\'un site ?


lors du SMX East de New York

Exploration et indexation par GoogleBot


noindexnofollow\ » ainsi que le fichier \ »robots.txt\ ».

Selon +Gary Illyes

  • Délai de connexion au serveur

  • Les codes de statut HTTP des serveurs : va également arrêter ou ralentir son exploration quand il obtient des codes de statut serveur dans la classe des 500 (500 à 520).

    Les codes d\’erreur 5xx du serveur