Google : Pas de backlink ? Pas d\'indexation de votre contenu

Google : Pas de backlink ? Pas d\'indexation de votre contenu

Sauf, comme le précise Barry Schwartz, si vous utilisez la fonctionnalité “Explorer comme Google” ou la fonctionnalité “Sitemap” depuis la Search Console pour indiquer à l’existence de l’URL de votre contenu.

Et bien évidemment, en dehors de ces 2 options de Google, si votre URL ne reçoit aucun backlink, Google dit ne pas être en mesure de la découvrir, quelle que soit la méthode d’exploration utilisée..

Ceci étant dit, si vous avez soumis un fichier Sitemap au format XML à Google via la Search Console (Exploration -> Sitemaps), il n’y a pas de raison qu’il ne découvre pas les URL de vos nouveaux contenus.

A condition toutefois de ne pas avoir bloqué Googlebot.

36 Conseils pour passer sans faute de HTTP à HTTPS ?

Depuis que a annoncé qu’il allait commencer à utiliser le HTTPS comme un signal de référencement, de nombreux sites Web ont commencé à migrer vers HTTPS.

Checklist pour migrer HTTPS

Et ce, non seulement pour des raisons de sécurité, mais aussi pour bénéficier du boost supplémentaire dans le classement dans les pages de résultats de Google.

Néanmoins, même si Google a publié les meilleures pratiques pour passer de HTTP à HTTPS, la réalité est que, dans de nombreux cas, elles ne sont pas suivies.

Ou encore certaines étapes sont manquées puisqu’il y a tant de différents domaines impliqués, ainsi que des vérifications et validations à faire avant, pendant et après le passage au .

Par exemple, Gary Illyes, Webmaster Trends Analyst chez Google, a publié un Tweet pour quelques rappels utiles appelant à vérifier et modifier le suivi et les scripts des annonces pour éviter tout blocage :

La vraie question lors d’un passage du HTTP au HTTPS n’est vraiment pas une absence totale de connaissance des webmasters, car, même si les gens connaissent certaines bonnes pratiques à prendre en considération, le problème est souvent plus dû à un manque de ressources complètes avec toutes les validations, spécifiant quand les mettre en œuvre.

Ce qui pourrait être facilement partagé et suivi par toutes les parties impliquées dans la migration, et qui sauraient dès le début quand faire quoi, afin de planifier les bonnes ressources au moment opportun.

Voici donc une checklist HTTPS qui vous indique les tâches à accomplir avant, pendant et après la migration.

 

Comment démarrer le passage de HTTP au HTTPS ?

 

  1. Certificat SSL : Achetez, configurez et testez le certificat sécurisé SSL/TLS à l’aide de SHA-2 pour SSL sur le serveur.
  2. Enregistrez et validez à la fois le en http et https dans Console, et dans les versions avec www et sans www. Si vous avez également enregistré des sous-domaines ou des sous-répertoires dans la Search Console, répliquez ces enregistrements et ces configurations avec leur version https.
  3. Installez et commencez le suivi des classements en parallèle avec le HTTPS du nom de domaine dans vos outils SEO ou logiciels de tracking.
  4. Identifiez les meilleures pages du site dans la Search Console et dans Google Analytics, ainsi que les requêtes connexes, qui vous assurent la visibilité organique et le trafic. Vous en ferez une priorité lors de la validation et du suivi référencement et des performances du site.
  5. Analysez la version HTTP du site afin d’identifier et corriger tous les liens internes brisés, ainsi que la structure actuelle avant migration.
  6. Configurez la nouvelle version du site Web afin de la modifier, tester et mettre à jour les liens dans un environnement de préparation, pour les pointer vers des URLs (pages et ressources telles que les images, js, pdfs, etc.) avec HTTPS.
  7. Mettez à jour les balises canoniques (rel=”canonical”) pour inclure des URLs absolues utilisant le protocole https.
  8. Vérifiez que toutes les réécritures et redirections déjà existantes (avec ou sans www, avec ou sans slash (barre oblique), etc.) sont également implémentées dans la version HTTPS comme elles ont l’habitude de fonctionner sur le http.
  9. Préparez et testez les règles de réécriture des redirections 301 de toutes les URL existantes identifiées (pages, images, js, etc) sur le nom de domaine http vers le https, sur le serveur.
  10. Générez un nouveau fichier Sitemap au format XML avec les URLs pour HTTPS afin de le télécharger dans la version HTTPS du nom de domaine dans la Search Console, une fois que le site aura été déplacé en HTTPS.
  11. Préparez le fichier robots.txt qui sera téléchargé sur la version HTTPS du nom de domaine lorsque le site sera déployé en répliquant les directives actuelles de la version HTTP, mais en pointant vers les URLs HTTPS si nécessaire.
  12. Préparez les modifications sur toutes les campagnes publicitaires, d’emailing ou d’affiliation pour commencer à les pointer vers les versions HTTPS des URLs dès que la migration sera faite.
  13. Vérifiez si des demandes de désaveu de liens ont été soumises par le passé afin de les soumettre à nouveau pour les versions HTTPS des URLs via la propriété du nom de domaine en HTTPS dans .
  14. Si vous migrez un gTLD (nom de domaine de premier niveau) que vous ciblez géographiquement via la Search Console (autant que ses sous-domaines ou sous-répertoires, au cas où vous les ciblez géographiquement de façon individuelle), assurez-vous de les ciblez à nouveau géographiquement avec la version HTTPS du nom de domaine.
  15. Si les paramètres des URLs sont gérées via Google Search Console, la configuration existante doit être répliquée dans le profil ou propriété HTTPS du site.
  16. Si un CDN (Content Delivery Network) est utilisé, vérifiez qu’il sera en mesure de bien servir la version du nom de de domaine du site en HTTPS et gérer le SSL lorsque la migration sera effective.
  17. Vérifiez que tous les codes des annonces publicitaires servies, les extensions tierces et les plugins sociaux utilisés sur le site fonctionneront correctement lorsqu’ils seront déplacés dans le HTTPS.
  18. Assurez-vous que la configuration existante de Web Analytics surveillera également le trafic du domaine HTTPS.

Comment vérifier pendant la migration vers HTTPS ?

 

  1. Publiez la version HTTPS du site en ligne (en mode production).
  2. Vérifiez que la structure des URLs sur la version HTTPS du site est la même que celle de la version HTTP.
  3. Vérifiez que les liens du site pointent effectivement vers les bonnes URLs HTTPS.
  4. Vérifiez que la balise canonicale (rel=”canonical”) dans le header des pages pointent également vers les bonnes URLs HTTPS.
  5. Vérifiez que la nouvelle version HTTPS canonique implémente les réécritures et redirections des versions avec ou sans www, avec ou sans slash à la fin, etc, dans la nouvelle version HTTPS.
  6. Mettez en place les redirections 301 de chaque URL du site depuis HTTP vers sa version HTTPS.
  7. Annotez la date de la migration dans votre plateforme de Web Analytics et vérifiez que la configuration a été bien définie pour suivre les performances de la version HTTPS.
  8. Vérifiez que la configuration SSL de votre serveur Web est correcte. Vous pouvez utiliser un service tel que SSLLabs pour la tester.
  9. Actualisez les paramètres du fichier robots.txt dans le nom de domaine en HTTPS avec les modifications pertinentes.

Les vérifications après passage au HTTPS

 

  1. Analysez le site pour vérifier que les URLs HTTPS sont celles qui devraient être accessibles, liées et servies sans erreurs, sans noindex erronées ni redirections ni balises canoniques erronées.
  2. Vérifiez que les règles de redirection de http et https, avec www et sans www, avec slash et sans slash sont correctement mises en œuvre.
  3. Téléchargez et vérifiez le fichier sitemap XML généré avec les versions d’URL HTTPS dans la propriété HTTPS (du nom de domaine) de Google Search Console.
  4. Mettez à jour, tant que peut se faire, les liens externes (backlinks) pointant vers le site avant de bien vérifier qu’ils sont redirigés vers la version HTTPS.
  5. Vérifiez que les plugins, ainsi que les boutons sociaux, annonces et extensions tierces fonctionnent correctement dans les versions HTTPS des URLs. Vous pouvez scanner votre site pour vérifier s’il existe encore du contenu non-sécurisé avec JitBit.
  6. Mettez en place les modifications pertinentes des campagnes publicitaires, d’emailing et d’affiliation pour qu’elles soient correctement redirigées vers la version Web HTTPS du site.
  7. Surveillez l’exploration, l’indexation, la visibilité et les erreurs des deux versions HTTP et HTTPS du site. Car, vous ne devez en aucun cas supprimer la version HTTP.
  8. Surveillez le trafic des versions HTTP et HTTPS du site, ainsi que leurs classements.
  9. Vérifiez les paramètres du fichier robots.txt dans le nom de domaine en https pour vous assurer que la configuration a été correctement mise à jour.

En principe, avec toutes ces consignes d’implémentation et de migration vers un hébergement sécurisé via HTTPS, vous devriez faire un sans faute.

Mais, il est également important de mentionner qu’une fois que vous déplacez votre site vers votre serveur HTTPS, vous pourriez considérer servir les pages via HTTP/2.

En effet, HTTP/2 (nommé initialement HTTP/2.0) est une version majeure du protocole réseau HTTP utilisé sur le World Wide Web. Il est issu du protocole expérimental SPDY (à prononcer comme le mot anglais speedy) développé par Google.

Pour la petite histoire, sachez que HTTP/2 ne demande pas de modification des applications web existantes, un effort ayant été apporté sur la rétro-compatibilité avec HTTP 1.1. Mais les applications webs existantes ou futures peuvent être développées pour bénéficier des nouveautés proposées notamment pour les gains de vitesse de transmission.

HTTP/2 conserve la majorité de la syntaxe de HTTP 1.1, comme les méthodes, les codes, les URI ou les headers. Un élément a été modifié : la manière dont la donnée est segmentée et transportée entre le client et les serveurs. Ce qui n’a pas d’impact sur les applications existantes.

Google Actualités lance un outil de dépannage des erreurs d’extraction d\'article

Google News

Google Actualités

Cet outil de dépannage offre donc plus de visibilité dans le processus d’extraction des articles d’actualité. Il permet surtout aux éditeurs de tester eux-mêmes si un article spécifique peut être correctement extrait, ou s’il génère une erreur pour “article trop long”, par exemple.

Ainsi, les erreurs retournées par l’outil de dépannage de peuvent aider à résoudre les erreurs potentielles. Ce qui signifie que cela peut vous éviter de soumettre indéfiniment votre sitemap pour Actualités.

Centre Google Actualités pour les éditeurs,  puis cliquez sur “Dépannage”

Rapports d’erreurs affichés aussi dans Search Console

Vous pouvez toutefois . Mais, il faudrait dans ce cas tenir compte du fait que toutes les erreurs ne correspondent pas toujours entre l’outil de dépannage et Google Search Console.

Ensuite, suivez les étapes ci-dessous dans la Search Console :

  • Sur la page d\’accueil, cliquez sur l\’URL du site.
  • Dans le Tableau de bord, cliquez sur ”Exploration > Erreurs d\’exploration”.
  • Cliquez sur l\’onglet ”Google Actualités” pour afficher les erreurs d\’exploration spécifiques au contenu relatif à l\’actualité. Seuls les éditeurs de News peuvent voir ce lien.
  • Les erreurs d\’exploration sont organisées en catégories, telles que \ »Extraction de l\’article\ » ou \ »Erreur de titre\ ». Cliquez sur l\’une de ces catégories pour afficher une liste des URL affectées et les erreurs d\’exploration qu\’elles génèrent.

Comment résoudre les erreurs

Voici les indication de Google pour résoudre les problèmes liés aux rubriques :

  • Pour vérifier si Google peut découvrir des articles sur une URL de rubrique (example.com/technology, par exemple) ou un sitemap spécifique, sélectionnez ”Dépannage > Rubriques” depuis le Centre Google Actualités pour les éditeurs.
  • Saisissez ensuite l\’URL de rubrique ou le sitemap pertinent dans le champ situé au milieu de la page.
  • Puis cliquez sur \ »Tester\ ».

Vous voyez ensuite s\’afficher jusqu\’à 100 articles détectés sur l\’URL de rubrique fournie. Pour tester l\’extraction d\’article pour n\’importe quelle URL d\’article, cliquez sur le bouton ”Tester” situé à droite de chaque URL.

Résoudre les problèmes liés aux articles :

  • Pour tester l\’extraction d\’article pour un article d\’actualité spécifique, sélectionnez ”Dépannage > Articles” depuis le Centre Google Actualités pour les éditeurs.
  • Saisissez ensuite l\’URL de rubrique correspondant à l\’article que vous souhaitez examiner, ou sélectionnez \ »Aucune ou sitemap\ ».

    L\’URL de rubrique ou le sitemap par le biais duquel votre contenu est découvert par Google Actualités a une influence sur les libellés qui sont appliqués à votre article. L’outil de test imite ce comportement.

    Par conséquent, au moment de choisir l\’URL de rubrique à utiliser, sachez que le test de l\’extraction est alors effectué comme si l\’article avait été découvert dans cette rubrique.

    De plus, les libellés pertinents sont appliqués en fonction de cette sélection. En revanche, si vous sélectionnez \ »Aucune ou sitemap\ », l\’extraction a lieu comme si l\’article avait été découvert via une URL de rubrique sans libellé ou sur un sitemap.

  • Après avoir complété le champ \ »URL de la rubrique\ », saisissez l\’URL de l\’article d\’actualité que vous souhaitez tester.
  • Puis cliquez sur ”Tester”.

Google Search Console introduit le rapport d\'erreurs des pages AMP

pages Accelerated Mobile Page (AMP), a récemment proposé aux webmasters qui le désiraient de s’inscrire pour participer au test AMP en avant-première.

Google AMP

Il s’agit pour Google d’obtenir des feedbacks sur la qualité des pages légères pour un affichage rapide des contenus sur mobile.

Et pour aider ces webmasters, et plus tard tous ceux qui auront des pages mobiles allégées, Google vient de lancer le rapport d’erreurs des pages dans Console (Apparence de la recherche -> Accelerated Mobile Pages).

Quitte aux webmasters de corriger les erreurs éventuelles dans leurs pages Accelerated Mobile Page (AMP)

Bien évidemment, pour que ce rapport s’affiche pour indiquer vos erreurs ou pour vous notifier qu’il n’existe aucune erreur, vous devez ajouter le code AMP dans le code source de vos pages web actuelles.

Google Search Console introduit le rapport d\'erreurs des pages AMP

En général, Google aura surtout besoin de rel=amphtml de la page web et rel=canonical de la page AMP pour créer son rapport d’erreurs dans la Search Console, si erreurs il y a.

Le rapport AMP montre que les pages AMP ont été correctement indexées ou les erreurs AMP spécifiques rencontrées lorsque Google analyse les pages AMP trouvées sur votre site.

A savoir l’affichage dans le carrousel des résultats AMP.

Comment utiliser le rapport AMP ?

  • Pour voir les erreurs par type :

A cela s’ajoute la date de détection de chaque erreur afin de mieux repérer quand le problème a pu survenir.

Si vous avez corrigé l’erreur mais que cette erreur est toujours indiquée dans le rapport Accelerated Mobile Page (AMP)

Vous pouvez attendre la prochaine visite régulière de Googlebot ou vous pouvez demander une nouvelle analyse rapide via l’outil Explorer comme Google via .

En cas d’erreur signalée dans le rapport AMP et corrigée par vous, Google se fiera à la propriété “lastmod” qui indique la date de la dernière modification de la page pour l’indexer à nouveau si elle dispose du lien alternatif amphtml.

Google entend améliorer et affiner ce rapport d\’erreurs des pages Accelerated Mobile Page au fil du temps.

Google privilégie l\'indexation des pages HTTPS par défaut


Google favorisera les pages HTTPS par défaut

En d’autres termes, le référencement HTTPS devient maintenant la priorité pour Google, après en avoir fait un critère de classement avec un tout petit \ »boost\ » au départ.

Toutefois, les pages HTTP ne seront probablement pas pour l’instant affectées dans les résultats de recherche. Google ne cherche qu’à fournir plus de pages sécurisées dans ses résultats, mais on peut s’attendre à ce que l’étape suivante, comme il l’a fait avec le mobile-friendly, sera de déclasser les pages non-sécurisées.

Ainsi, maintenant, lorsqu’un site web aura deux pages aux contenus identiques dont l’une est en HTTP et l’autre en page sécurisée HTTPS dans ses résultats de recherche. Et ce, mêmes si cette page HTTPS ne bénéficie d’aucune redirection à partir d\’une autre page HTTP.

Comme le dit John Mueller (voir tweet ci-dessus) de chez Google, le référencement HTTPS s\’imposera à long terme.

Mais, pour l\’instant, pour que cette indexation par défaut puisse se faire, certains critères devront être remplis.

Critères de l’indexation du HTTPS par défaut

Comme le dit Google, lorsque deux URL associées au même nom de domaine semblent avoir le même contenu, mais sans avoir le même protocole de diffusion, la priorité sera accordée à l\’URL HTTPS, si cette dernière remplit les conditions suivantes :

  • Elle ne contient pas de dépendances non sécurisées.
  • Son exploration n\’est pas bloquée par un fichier robots.txt.
  • Elle ne redirige pas les internautes vers ou via une page HTTP non sécurisée.
  • Elle ne possède pas de lien \ »rel=\ »canonical\ »\ » vers la page HTTP.
  • Elle ne contient pas de balise Meta \ »noindex\ » pour les robots.
  • Elle ne comprend pas de liens sortants à partir de l\’hôte redirigeant vers des URL HTTP.
  • Le sitemap répertorie l\’URL HTTPS, ou ne mentionne pas la version HTTP de l\’URL.
  • Le serveur dispose d\’un certificat TLS valide.

Donc, en ce qui concerne Google, la version HTTPS de votre site, si vous en avez, sera prioritaire par défaut.

Mais, en ce qui concerne les autres moteurs de recherche, vous pouvez les forcer à considérer vos pages HTTPS comme prioritaires en configurant votre site HTTP de sorte qu\’il redirige vers la version HTTPS équivalente et en mettant en œuvre l\’en-tête HSTS (HTTP Strict Transport Security) sur votre serveur.

Qu’est-ce que le HTTP Strict Transport Security (HSTS)

Le HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu\’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS).

La politique est donc communiquée à l\’agent utilisateur par le serveur via la réponse HTTP, dans le champ d\’en-tête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l\’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

Ainsi, lorsque la politique HSTS est active pour un site web, l\’agent utilisateur compatible opère comme suit :

  • Si la sécurité de la connexion ne peut être assurée (par exemple, le certificat TLS est auto-signé), celui-ci affiche un message d\’erreur et interdit à l\’utilisateur l\’accès au site à cause de cette erreur.

La politique HSTS aide à protéger les utilisateurs de sites web contre quelques attaques réseau passives (écoute clandestine) et actives. Une attaque du type man-in-the-middle ne peut pas intercepter de requête tant que le HSTS est actif pour ce site.

Google Actualités n\'exige plus les 3 chiffres dans les URL des news

Depuis pratiquement le lancement de , les éditeurs étaient contraints d’intégrer 3 consécutifs dans leurs URL pour qu’elles puissent être intégrées dans l’index de News.

La seule exception qui était autorisée pour une indexation complète, c’était jusqu’à maintenant de fournir un sitemap dédié à Google Actualités.

Google Actualités n\'exige plus les 3 chiffres dans les URL

Mais ça, c’était avant.

Google vient en effet d’annoncer la fin de l’utilisation impérative de 3 chiffres consécutifs dans les URL soumises à indexation à Google Actualités.

Voici ce que dit le post de Stacie Chan de chez Google :

En clair, autant la règle des 3 chiffres consécutifs n’est plus de mise, autant vos URL devront continuer à être uniques et permanents. Aucune modification n’est permise après indexation et publication dans Google Actualités.

Auparavant, Google disait que l\’URL associée à chaque article doit comporter un numéro unique composé d\’au moins trois chiffres. Par exemple, il ne pouvait pas explorer un article dont l\’URL est la suivante : http://www.google.com/actualites/article23.html. Il pouvait en revanche explorer un article dont l\’URL est la suivante : http://www.google.com/actualites/article234.html.

Alors, à la question de savoir pourquoi Google Actualités procède à la suppression de cette règle des 3 chiffres dans les URL maintenant, Stacie Chan écrit :

“Pendant des années, les URL de vos articles ont évolué et tous les contenus d’actualités n’avaient pas intégré les 3 chiffres uniques. Notre équipe a donc pris cela en considération et a décidé de supprimer cette règle afin d\’inclure plus de contenus d’actualités. Et nous pensons que plus de contenu de qualité de votre part veut dire plus de lecteurs satisfaits.” 

Désormais, pour que votre publication figure dans Google Actualités, les URL de vos articles doivent respecter les consignes suivantes :

Elles doivent être uniques. Chaque page affichant l\’intégralité du texte d\’un article doit posséder une URL unique. Google déclare ne pas pouvoir faire figurer dans Google Actualités les sites qui permettent l\’accès à plusieurs articles via une seule URL, ni les sites qui ne proposent pas de liens permettant d\’accéder à une page dédiée à chaque article.

Elles doivent être permanentes. Par exemple, Google n\’est pas en mesure d\’explorer la page \ »http://www.votresite.com/actualite1.html\ » si son contenu varie d\’un jour à l\’autre. Pour que nos liens vers les articles fonctionnent correctement, chaque article de votre site d\’actualités doit être associé à une URL unique et permanente (elle ne doit donc pas être recyclée).

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.

Google+ a 2,2 milliards d\'utilisateurs. Qu\'en est-il du nombre d\'utilisateurs actifs ?

En Octobre 2014, + avait atteint la barre symbolique des 2 milliards d’utilisateurs.

Aujourd’hui, selon le calcul réalisé par l’outil Miernicki.com de +Greg Miernicki et +François Beaufort (Googler), Google+ compte plus de 2,2 milliards de comptes.

Un chiffre avec un taux de croissance exponentiel puisqu’il nous indique que Google+ réalise la belle performance de 1,6 millions de nouveaux comptes par jour !

Vu ainsi, Google+ ferait pratiquement jeu égal avec . Même si comparaison n’est pas raison.

Il importe donc désormais d’avoir une idée, même approximative, du nombre d’utilisateurs actifs que compterait Google+ à ce jour.

Combien d’utilisateurs actifs sur Google+

Selon les derniers officiels de Google, Google+ compterait 540 millions d’utilisateurs actifs mensuels.

Des utilisateurs comptabilisés comme actifs pour s’être connectés au moins une fois avec leurs comptes Google+ sur l’un des services de Google : , , Docs, Google+, Play, etc.

Toujours est-il que les chiffres de Google+ date d’Octobre 2013 ! Peut-être qu’il serait temps que Google donne à nouveau des chiffres officiels pour éviter toutes sortes de spéculations comme celle dont je vais vous parler maintenant.

Il s’agit d’un certain +Edwards Morbius qui a réalisé sa propre analyse qui lui a permis de comptabiliser aussi 2,2 milliards d’utilisateurs pour Google+. Tout comme +Greg Miniercki, il a scanné le Sitemap des profils Google+ à partir de cette adresse : http://www.gstatic.com/s2/sitemaps/profiles-sitemap.xml

Et selon ses propres méthodes de calcul et surtout d’algorithmes, il estime qu’aujourd’hui (en Janvier 2015), Google+ aurait entre 4 et 6 millions d’utilisateurs actifs (mensuels ?).

C’est à dire que pour Edward Morbius, il n’y aurait que 4 à 6 millions de personnes qui publient des posts publics, engagent et interagissent sur Google Plus .

Voici le résumé de sa trouvaille posté sur ello.co (il y détaille sa méthode) :

Image via Kevinanderson.nl
  • 2,2 milliards de profils Google+ dont seuls 9% publient des posts publics.
  • Sur ces 9% qui postent publiquement, environ 37% ont comme récente activité un commentaire sur Youtube et 8% ont changé leur photo de profil Google+. Soit un total de 45% des profils actifs.
  • 6% des profils considérés comme publiquement actifs n’avaient aucune activité sur Google+ en 2015 (du 1er au 18 Janvier pour cette analyse).
  • Sur ces 6% de profils actifs, 3% ne sont pas des commentateurs sur Youtube.
  • Ainsi, selon l’auteur de cette analyse, tout ceci nous donnerait entre 0,2% et 0,3% (d’où ça vient ?) du total des profils Google+, soit 6,6 millions d’utilisateurs, qui ont publié un post public sur Google+ en 2015.

    Soit 367.000 utilisateurs Google Plus qui postent chaque jour au moins une fois.

Morbius précise bien que son analyse n’est qu’une estimation des utilisateurs actifs de Google+ ayant publiquement posté sur Google+ en Janvier 2015 mais ne prend pas en compte ceux qui ont commenté sur Youtube.

Déjà, la polémique sur Google+ \ »ville fantôme\ » reprend de plus belle outre-Atlantique.

Il faut tout de même préciser que Morbius n’a pas non plus pris en compte les commentaires publics sur Google+, les posts privés (messages privés ou partages strictement à des Cercles), les posts dans les Communautés privés, les posts dans les Hangouts, etc…

Bref, il ne tient qu’à Google de fournir à nouveau des chiffres officiels de Google+ pour que s’arrête ce genre de spéculations stériles parce qu’incomplètes.

SEO : Comment Google peut-il reconnaître différentes versions d\'un même site ?




notamment pour les sites multilingues.

Annotations à ajouter dans le fichier sitemap.

En terme de linking entre marques, Matt Cutts explique que ces liens ne peuvent être considérés ni comme payants, ni comme artificiels. Seulement, il demande que les choses se fassent de façon organique dans les règles de l\’art.

Toutefois, il précise que si vous avez 50 sites web, ne les reliez pas tous ensemble, les uns aux autres. Il préconise alors d\’utiliser une page principale pour lister tous les sites multilingues de l\’entreprise.

C\’est pourquoi Matt Cutts demande d\’être prudent lorsqu\’on veut relier 50 à 100 sites web qui ont le même nom de domaine mais avec différentes extensions.

Dans un tel cas où Matt Cutts exige de la prudence, ne veut-il pas dire qu\’il vaut mieux l\’éviter tant que peut se faire ?

12 Moyens d\'améliorer son trafic web sans faire de Netlinking

Et donc, leur importance en terme de visibilité et de trafic web.

Et pourtant, comme nous le présente Cyrus Shepard

1. In-Depth Articles

Selon Moz.com, 6% des résultats de recherche de contiennent désormais des liens In-Depth Articles.

2. Améliorer la satisfaction de l\’utilisateur

3. Les extraits enrichis issus des données structurées

extraits enrichis susceptibles de s\’afficher

4. Optimisation des contenus vidéo

La capture d\’extrait vidéo (miniature)

balises de schema.org pour les vidéos.

Wistia qui peuvent vous aider à créer un sitemap vidéo incluant automatiquement le balisage de Schema.org. Ce qui va vous permettre de choisir la miniature à afficher sur les pages de résultats.

Et comme les miniatures vidéos encouragent très souvent les clics, vous pouvez espérer alors améliorer votre trafic web.

5. Google AuthorShip

Certes Google ne vous garantit pas plus de clics si vous participez à l\’Authorship

6. Améliorer le temps de chargement des pages

Par temps de chargement, il faut comprendre le temps que prend votre serveur pour envoyer sa première réponse à une requête.

7. Optimisation pour mobile

Comme mentionné plus haut, votre site web devra être aussi configuré pour le mobile. Google ayant confirmé

8. Accroître votre audience en dehors de votre zone géographique

9. Visibilité avec Google+

vous devez être actif sur Google+.

10. Optimisation des balises meta et title

Et comme dit Matt Cutts : \ »\ ». Ce qui veut dire que toute duplication de balises pourra être pénalisée et constituer un frein à votre trafic web.

11. Publier régulièrement de nouveaux contenus

Sur certaines thématiques et pour certaines requêtes, avoir du contenu frais peut toujours aider pour plus de visibilité sur Google.

12. Optimisation interne du site