 Bonjour à tous et bienvenue à 7h pour les webmasters pour le marché français. Je m'appelle Vincent Courson, je travaille à l'équipe Search Quality de Google depuis environ 5 ans et je travaille dans tous les aspects de communication avec l'écosystème des webmasters en français pour répondre aux questions SEO, pour aller à des conférences, partager les meilleures best practices au niveau SEO etc. Ce hangout en air, ce YouTube live qu'on fait aujourd'hui, c'est quelque chose qu'on avait fait il y a plusieurs années, il y a un an et demi, le dernier il me semble, c'est quelque chose que Google veut faire beaucoup plus, ça m'intéresse beaucoup de participer à de répondre aux questions en direct à tout le monde qui a des questions et du coup on va essayer d'en faire un peu plus dans les mois qui viennent et en commençant par aujourd'hui. Donc je vois qu'on a deux personnes qui nous ont déjà rejoint dans le hangout directement, bonjour à eux déjà, il y a deux moyens de participer, d'abord être présent pendant le YouTube live avec nous en cliquant sur le lien que j'ai partagé sur Twitter il y a quelques minutes, le lien hangout et on peut, la deuxième solution est également de regarder le live en direct sur YouTube. Donc si vous voulez poser des questions en direct on pourra y répondre un peu plus tard, n'hésitez pas à aller trouver le lien sur Twitter pour rejoindre le ingabe. J'ai partagé dans la semaine dernière et avant un hashtag sur Twitter à utiliser pour poser des questions pour que je puisse les voir et sélectionner celles qui sont intéressantes et celles qui peuvent commencer une discussion ou apporter des précisions importantes pour les personnes qui veulent regarder actuellement, donc qui nous regardent actuellement, pardon, donc n'hésitez pas pour les prochaines itérations de ce YouTube live à poser vos questions directement sur Twitter et je les regarderai et j'essaierai d'y répondre. Donc je vais commencer par peut-être un peu quelques nouvelles rapidement avant de passer à des questions-réponses vraiment très très très haut niveau, donc je vais présenter un peu des slides pour quelques secondes. Donc lors des webmasters aujourd'hui, première itération en 2017, on va voir ce que ça donne, j'espère que ça aura du succès. Au niveau de l'actualité de cette rentrée 2017, tout d'abord l'index mobile first. Donc l'index mobile first avait été annoncé il y a un certain temps par les collègues de l'Internview de cette rentrée de mon type d'écho. Tout d'abord l'index mobile first. L'index mobile first a été annoncé par des collègues de l'Internview et de Zurich récemment pour indiquer qu'en fait Google allait un peu changer la façon dont était fait l'indexation des sites web, des pages web qui étaient trouvées en lit. Donc traditionnellement on avait les robots d'exploration de Google qui allait explorer toutes les pages qui existaient sur le web et qui utilisaient un user agent desktop pour aller comprendre le contenu pour interpréter la page et voir qu'elle était le contenu vraiment sur chaque URL. Ce qu'il va se passer à partir d'une date à définir toujours dans le futur, c'est que le Googlebot va se baser uniquement sur le user agent mobile pour comprendre le contenu. Ce que cela change c'est que si on a des versions différentes de ces pages pour les mobiles et pour les desktop à ce moment là, le contenu qui sera pris en compte par Google à l'avenir est le contenu mobile. Donc rien n'a changé quasiment si on est dans une configuration responsive web design, en revanche si on a des URL séparés à ce moment là c'est quelque chose à prendre en compte. Au niveau de l'agenda et de quand le lancement est prévu, actuellement on n'a pas de date définie, toujours pas, ce sera vraisemblablement pas avant 2018. On est sur une phase de test, Google est toujours une entreprise avec une forte direction utilisateur, chiffre qui nous permet de toujours tester, qui nous demande de toujours tester lorsque nous faisons des changements, lorsque nous faisons des modifications aux algorithmes ou à autre. Donc en ce moment on est dans des phases de test, le passage à un index mobile peut potentiellement avoir des répercussions et nous essayons de limiter ces répercussions de trouver le meilleur système pour faire passer ça. Donc actuellement rien de spécial à part que continuer à penser à vos sites de manière plus ou moins responsive. C'est vraiment le conseil général donné par Google. Deuxième point, Search Console évolue, on a posté des nouvelles à ce propos en début août. L'équipe Search Console est en train de mettre en place des bétas pour des nouveaux outils, d'une nouvelle façon de voir Search Console. Donc de passer d'une logique un peu outil, compartimenté, segmenté, un certain nombre d'outils un peu indépendant les uns des autres, à un ensemble, une solution qui va identifier des problèmes, les ramener sur le devant en page d'accueil de l'outil et donner ensuite des indications de la donnée pour montrer quel est le problème et ensuite essayer d'aider le Webmaster à résoudre le problème. Donc vraiment on va passer sur beaucoup plus une expérience de découverte d'un problème, optimisation pour résoudre le problème, problème résonne. Donc ça arrive aussi dans les mois qui viennent, on a déjà certains outils qui sont en test sur un petit nombre d'utilisateurs, c'est pareil, on fait du AB testing, certains utilisateurs ont la nouveauté, certains n'ont pas et on compare les chiffres pour vérifier que c'est effectivement une amélioration sur la version actuelle de Search Console. Donc c'est en cours également et si il se trouve qu'il y a des bétas publics à ce moment là, nous communiquons là-dessus. Troisième point, l'heure des Webmaster revient, donc c'est ce que nous faisons actuellement. Comme je disais tout à l'heure, on en avait fait un peu, il y a pas mal de temps maintenant et c'est une volonté de ma part et de l'équipe d'une certaine manière globale de faire plus de ce genre d'événement. Donc on va essayer de faire ça un peu plus souvent que par avant. C'était un peu les nouvelles rapides de cet été. Je vois qu'on a quelques personnes qui nous ont rejoint déjà. Est-ce qu'il y a des questions que je peux prendre déjà avant de commencer avec les questions précédentes ? C'est une question qui avait été posée auparavant pour commencer avec un peu d'interaction. Je vois que c'est un peu timide. Alors je vais aller directement dans les questions, on va pouvoir répondre ensemble. Et n'hésitez pas ceux qui sont présents dans le YouTube Live à m'interrompre ou après une question à demander des précisions ou autres. Alors la première question qu'on avait, c'était si les plateformes AMP ou PWWA, donc Accelerated Mobile Pages et Progressive Web Apps ne sont aujourd'hui pas des critères SEO, à proprement parler, avec l'index mobile first, cela peut-il changer ? Alors cette question-là vient du fait que AMP et PWWA sont vraiment faits avec le mobile à l'esprit. Ce sont des plateformes qui sont pour accélérer la vitesse parce que beaucoup d'utilisateurs ont des problèmes de connexion lente sur leurs téléphones mobiles. Ce sont deux plateformes qui se concentrent énormément à la fois la vitesse et l'expérience utilisateur, UX. Et actuellement, nous ne donnons pas un avantage direct à une URL parce qu'elle est AMP ou PWWA. Donc il n'y a pas de logique de dire est-ce que PWWA ou est-ce que AMP, PWWA, si oui, hop, on met une petite coche et on donne un poids plus important dans l'algorithme ou autre. Ce n'est pas du tout la logique qui est en place. En revanche, il peut y avoir clairement des effets de bord, donc une influence indirecte. Le moteur de recherche organique, les algorithmes se concentrent de manière générale sur l'expérience utilisateur, faire en sorte que l'utilisateur trouve ses réponses de manière rapide, de manière utile, de manière efficace, etc. Et ce sont des choses qui comprennent la vitesse et l'expérience utilisateur. Donc une page AMP forcément se charge très rapidement et est vue positivement par la partie des algorithmes Google qui se concentrent sur la vitesse. De manière plus générale, on peut aussi noter que même s'il n'y a pas d'impact que ce soit direct ou indirect sur l'algorithme, ça aura de toute manière un avantage sur les utilisateurs de manière plus générale. Donc même si ça n'aide pas exactement parfaitement avec l'algorithme de Google, ça aidera avec les utilisateurs de manière générale. Donc ce sont des solutions intéressantes à l'exploit. Est-ce qu'il y a des questions supplémentaires sur AMP et PWA en tant que critères d'un moteur de recherche ? Non. Alors passons à la question numéro 2. Alors la question numéro 2, c'est un ensemble de questions. Alors j'ai une question par écrit. Est-ce que l'on a intérêt à faire tout un site en AMP ? Ça va dépendre des utilisations qu'on veut en faire. Un site actuellement AMP et surtout ce sont surtout les sites d'actualité et on commence à voir aussi depuis quelques mois, une demi-année, on peut plus pas mal de sites e-de-commerce qui passent aussi, certains autres mais c'est beaucoup plus des cas isolés. Donc tout un site en AMP, pas forcément. Ça va dépendre un peu de la thématique. Si la question est de savoir est-ce qu'on peut faire tout un site uniquement en AMP ? Oui, ça peut avoir clairement un intérêt si on est sur un site principalement contenu par exemple avec des fonctionnalités limitées. AMP en fait, ça va être un moyen un peu différent d'écrire de l'HTML et du coup il y aura des limitations, un certain nombre de limitations. Donc si on est sur un site de type blog, un site de type uniquement contenu, avec pas forcément de besoin avancé d'input utilisateur ou autre, on peut tout à fait penser à un site 100% AMP uniquement. Question qui est des cheats AMP, donc des tricheries AMP qui consiste à montrer un extrait pour l'internaute suivi d'un bouton, lire l'article en entier. Donc oui, ça c'est une situation que j'ai vue déjà qui est loin d'être idéal mais qui actuellement n'est pas forcément pénalisé activement par Google. Donc ce qui se passe c'est qu'il y a certains sites qui essaient de mettre en place une partie uniquement du contenu sur leur site AMP pour charger plus rapidement, pour avoir plus d'interactions avec l'utilisateur, plus d'input de trafic avec leur page AMP, puis ensuite de retourner les utilisateurs sur une version complète ou dite classique. Pas forcément actuellement contre nos consignes, même si je peux imaginer que ça pourrait changer à l'avenir. De manière plus générale, l'interaction entre AMP et le reste d'un site web est quelque chose qui peut de manière générale être vraiment optimisé et qui peut fonctionner très bien. On remarque notamment une interaction entre AMP et les PWA, où il existe des articles très intéressants écrits sur Smash Magazine, notamment que je pourrais partager à l'issue de ce YouTube live, qui expliquent comment mettre en place un peu ce système pour avoir des pages AMP qui font de l'intake de l'aspiration de l'utilisateur. De manière générale, si on se concentre sur l'utilisateur et lui donner un contenu qui répond à ces questions, ce n'est pas la pire chose qu'on puisse faire aux yeux de Google. Je ne sais pas si ça répond à la question. On va passer ensuite à la deuxième question, deuxième série de questions qui est une question sur l'immigration HTTP vers HTTPS. J'avais pris trois questions qui sont remontées. La première c'est HTTPS devenant obligatoire et je cite en SEO. Est-il possible dans la search console de fusionner les propriétés en HTTP et en HTTPS pour éviter de jouer avec les ensembles de propriété ? Les ensembles de propriété sont ces ensembles qui permettent de regrouper plusieurs sites web ou plusieurs versions de sites web sous un même ensemble pour voir les données mises... Oui, les données sont consolidées sur un seul tableau. Deuxième question qui était, je sais que Google comprend les 300 de HTTPS, mais à long terme, il faut aussi les laisser ou les enlever. Dans la search console, une fois la propriété HTTPS créée, quand doit-on supprimer la version HTTPS ? Ces trois questions parlent vraiment de quelles sont les process pour faire en sorte que Google comprenne bien une immigration HTTPS et comment faire ensuite intégrer ça dans la search console et comment gérer ça avec différentes propriétés etc. Donc je vais repartir sur des recommandations un peu générales pour remettre ça en contexte sur l'immigration HTTPS. Le premier point est qu'il y a des ressources assez poussées qui sont disponibles sur notre ensemble de support, donc une recherche devrait vous permettre de trouver ça, donc déjà à lire pour toute personne qui envisage l'immigration HTTPS. La première chose à faire longtemps, dès que possible, c'est de créer la propriété HTTPS dans la search console, ainsi que de créer la propriété. Pour répondre à une des trois questions explicites, il n'est pas prévu actuellement de se passer de la distinction HTTPS dans la search console. Donc il faut toujours créer l'ensemble le plus vite possible. La raison pour laquelle il faut le créer le plus vite possible, c'est que les données dans les propriétés, pardon, les ensembles de propriété ne sont pas rétroactifs. C'est-à-dire que si je fais une migration en début janvier et que je crée l'ensemble de propriété en début avril, je n'aurai les informations, les données pour l'ensemble de propriété qu'à partir de mai avril. Donc même si pas besoin actuellement tout de suite, il vaut mieux le mettre en place, quand on a besoin, elles sont disponibles. Deuxième point, lors d'une migration HTTPS, comme pour toute migration de sites, il faut tester. On peut soit tester sur ce domaine en particulier, soit avoir testé déjà par le passé sur d'autres domaines pour bien comprendre comment s'effectue une migration. Ça peut se faire aussi sur une toute petite partie du site, sur un sous-domaine peu important, ou même créer uniquement pour l'occasion, ou quelques mois avant. C'est important d'avoir ce réflexe-là. Testé, contrôlé, donc avec Search Console et avec Search Analytics, avec tous les outils de tracking habituel que vous avez, contrôlé vraiment que la migration se passe bien. Et une fois qu'on est sûr d'être à l'aise avec la façon dont la migration se passe, passez sur une généralisation à tous les sites. Ensuite, bien réfléchir, lorsqu'on passe à la migration générale, quelles pages seront en code serveur 301 en général pour des migrations finalisées, et quelles parties du site pourra passer en code 404, 410, etc. Ça va permettre à la fois de s'assurer qu'on fait bien les transitions page-à-page pour les pages importants du site. Ça permet aussi de faire un certain nettoyage si on a des pages indexées qui ne devraient plus être dans la nouvelle version, qui se sont indexées au fur et à mesure des années, ou qui étaient importantes il y a plusieurs années, mais qui ne sont plus aujourd'hui. En faisant cette séparation entre les 400 et quelques, et les 300 et quelques, on permet de faire un nettoyage. Dernier point important à prendre en compte, pour mesurer l'efficacité d'un passage de HTTP à HTTPS, c'est une bonne idée de créer un site-map spécifique avec les URLs HTTPS pour pouvoir suivre le nombre de pages indexées pour les pages HTTPS uniquement au fur et à mesure du temps. Personnellement, j'aime bien voir ce tableau-là pour vérifier que tout se passe bien avec le temps. C'est vraiment très high-level, très haut niveau sur la migration HTTPS, ce sont des points importants à garder à l'esprit. Une des questions était, à partir de quel moment puis-je ou dois-je supprimer la version HTTPS dans la search console ? Ma réponse est, pourquoi vouloir supprimer la version HTTPS ? Il n'y a pas vraiment de raison de vouloir la supprimer. La seule raison à laquelle je peux penser maintenant, c'est de se dire qu'il y a une limite de 1000 propriétés par compte dans Search Console, et qu'on peut éventuellement arriver si on a trop de versions d'un même site à ce chiffre de 1000. A ça, je répondrai que si on a ce genre de problématique-là, c'est sûrement qu'on est dans une logique agence où on a une gestion de beaucoup de sites web, etc. Et à ce moment-là, il faudrait mettre en place, pas uniquement pour les HTTPS, mais il faudrait mettre en place un système de compte Gmail créé spécifiquement pour un certain nombre de clients que l'on divise en fonction qui est l'account manager de Camsit, etc. Il faudrait avoir une stratégie pour réfléchir quelle site web est sur le compte Search Console et sur quel ce compte Search Console pour garder un peu à l'esprit, permettre plus facilement des transitions si quelqu'un quitte l'agence, ce genre de choses-là. Autre point, quand supprimer les redirections 301 de HTTP vers HTTPS ? Un peu même réponse que la question précédente, pourquoi vouloir supprimer les redirections 301 ? Au fur et à mesure du temps, avec les redirections 301 et les 404 sur certaines des pages HTTP qui ne sont plus utiles, Google va comprendre que le contenu soit disparu, n'existe plus, soit à migrer. Et donc les pages HTTP qui sont en erreur 400 et quelques devraient être dropées de l'index de manière générale et les pages en 300 et quelques devraient migrer, Google comprendrait qu'elles migreront. Donc, c'est mis en place au niveau serveur et on sait jamais, c'est une façon assez générale de gérer la migration HTTPS. Il peut y avoir un petit coup serveur à garder en fait la 301, mais qui est relativement négligeable dans l'immense majorité des cas. Mais en fait, il n'y a pas besoin de les couper au niveau SEO, les laisser habitables ne changent absolument rien. Si vous voulez tout de même les supprimer pour une raison qui m'échappe ou pour simplement parce que il n'y a plus de trafic qui vient depuis les pages HTTP ou bien il n'y a plus du tout de lien qui mène vers les pages HTTP non plus, à ce moment-là, vous pouvez supprimer au bout d'un certain temps quand un certain temps assez long je dirais, on est sûrement plusieurs années. Mais une nouvelle fois, il n'y a pas vraiment de résumé particulière de vouloir supprimer les 301 lors d'une migration. Est-ce qu'il y a des questions par rapport à ça ? Donc, on va enchaîner. Alors, troisième question, et je vous la lis, lors d'un changement de nombre d'omènes, les pages non reprises sont supprimées. On laisse Googlebots trouver des erreurs 410 ou alors est-ce qu'il faut bloquer le crawl dans le robot HTTPS. Donc, migration, certaines pages ne sont plus utiles. Comment faire en sorte que Google comprenne qu'elles ne sont plus d'actualité ? Et deuxième partie de la question, le but étant de reporter du crawl budget pour une prise en compte plus rapide des 301 depuis l'ancien nombre d'omènes. Alors, à ça je répondrais qu'il vaut mieux de manière générale éviter de bloquer par le robot HTT des pages qui sont déjà indexées. La raison principale est que Google doit pour comprendre qu'une page par exemple n'existe plus et renvoie un code server 410 par exemple ou 404, Google doit pouvoir explorer la page, doit pouvoir faire un call au serveur et se rendre compte effectivement que la page n'est plus là. Si vous empêchez le crawl de ces pages par le robot HTT, vous repousser à plus tard le moment où Google pourra potentiellement se rendre compte que le contenu n'existe plus. C'est la première raison. La deuxième raison, c'est que ça peut créer des problèmes que l'on n'avait pas vu venir au niveau de certaines ressources qui ne peuvent éventuellement plus être crawlés si on les a hostés sur une certaine partie du site et que l'on a oublié qu'elles étaient là, etc. Donc de manière générale, le robot HTT a utilisé avec persimmonie pour l'immigration de sites avec disparition de pages. Sur la partie sur le crawl budget, le crawl budget pour un rappel rapide, c'est en gros un concept qui n'est pas forcément complètement transparent, communiqué de manière très transparente par Google, mais avec des suppositions, ce n'est pas très clair. Le crawl budget est appelé par l'écosystème SEO et Webmaster en fait cette allocation de visite de la part du Googlebot sur un site. C'est-à-dire qu'on peut se dire qu'un site, un domaine A, possède un crawl budget de 10 000 explorations par jour, donc 10 000 URL peuvent être explorées par jour et c'est le budget de crawl actuel de ce domaine-là. Et donc si je suis limité dans mon monde d'URL crawlés par jour, autant faire en sorte que le robot crawl les pages qui sont en 301 lors d'un transfert de domaines pour qu'il repère ces pages qui ont bougé plutôt que les pages qui l'ont disparu. Donc ça, c'est un peu l'exposition. Ma réponse à ça, c'est de dire il vaut mieux laisser les problématiques de quel page explorer ou quel page ne pas explorer à Google. Vouloir essayer de contrôler le crawl budget, c'est un peu aléatoire. Google devrait se rendre compte naturellement assez rapidement de quel parti du site n'existe plus, quel parti du site est en redirection vers d'autres URL et donc c'est quelque chose qui se gère un peu tout seul. Donc vraiment là-dessus, ce n'est pas forcément une chose à prendre en compte. De manière naturelle, le crawl de pages qui ont disparu en 410 par exemple devrait assez rapidement diminuer et disparaître. Si on prend encore un peu plus de hauteur, je dirais aussi que ce n'est pas forcément un problème d'avoir des erreurs 410. C'est-à-dire que des 410 ou 440. Ces erreurs-là existent pour que Google comprenne que le contenu a disparu et Google se rendra compte tout seul d'une situation sur la page. Si les 404 par exemple, les 410 augmentent, il y a des notifications dans Search Console qui permettent d'identifier des situations non voulues. Donc si on n'a pas mis en place de 410 ou de 440 récemment, mais si on sait qu'elles sont là, le fait qu'elles apparaissent dans le Search Console n'est pas un problème en soi. Ne pas trop se concentrer sur les 404 par exemple lors d'une migration de sites. C'est mon conseil principal pour la cette question. Est-ce qu'il y a des questions sur les questions ? Toujours pas. Alors on continue. La question suivante est une question assez large qui est est-ce qu'il est possible pour toi de nous donner ton avis sur l'indexation de Twitter ? Une question super large et je ne sais pas exactement ce qu'il y a derrière cette question-là. Donc je ne veux pas forcément pouvoir commenter sur le nombre de pages indexés, la fraîcheur, etc. C'est vraiment sur un site en particulier. C'est un peu difficile de voir la plus value que je pourrais ajouter. Ce que j'aimerais mettre en avant tout de même, c'est en parler de Progressive Web App tout à l'heure. Twitter est passé en version Progressive Web App pour son site mobile. Il y a maintenant pas mal de temps. Il y a au moins 4 à 6 mois, il me semble. Et ils ont observé des améliorations significatives de leurs métriques avec leurs utilisateurs. Donc il y a une étude de cas qui a été publiée par Google il y a quelques mois là-dessus particulièrement en collaboration avec Twitter. Les chiffres qui sont donnés dans cette étude de cas que je vous recommande de lire sont plus 65% de pages vues par session plus 75% de tweets envoyés après la migration et moins 20% de burn trades. Donc le fait d'être passé sur une Progressive Web App avec un chargement beaucoup plus rapide avec des fonctionnalités modernes des possibilités d'interressions utilisateurs a eu vraiment des effets très positifs pour Twitter sur leur site mobile. Donc je vous encourage à aller lire un peu là-dessus. Je pense que ça ne répond pas à la question générale sur Twitter et sur son indexation mais c'est trop compliqué pour moi de donner un point de vue qui ajoute de la Pévalu. Question suivante Ensemble de questions une nouvelle fois plusieurs questions sur un même thème Le thème étant la taille des sites, le nombre de pages etc. La première question était au niveau de mon point de vue personnel je remarque de meilleurs résultats avec des sites qui ont des paliers de N fois 100 pages indexables plutôt que sur des plus petits sites avec moins de pages quel est ton avis ? Deuxième question, pourquoi les gros sites avec des fiches produits dupliqués pour les couleurs etc. donc plusieurs pages pour différentes couleurs tout ce qu'on veut Reinc devant les petits avec du contenu qui eux ont pourtant du contenu vraiment unique un vrai site vraiment intéressant avec deux pages a-t-il autant de chance de se placer qu'un site qui a 100 pages mais ces pages sont inintéressants Donc, question assez assez similaire mais qui me font repérer un peu une tendance que j'observe chez beaucoup de SEO et que j'appellerais de manière un peu humoristique le symptôme SEO c'est une concentration sur des micro points qui sont hyper techniques souvent et qui sont assez éloignés de la problématique utilisateur un utilisateur qui arrive sur une page qui doit répondre à la question qu'il se posait en tapant une requête sur Google il s'en fout un peu qu'il y ait 76 ou 83 ou 88 pages sur le site en fait, c'est pas important Google se concentrant sur apporter une réponse pertinente avec une page en particulier c'est pas important le nombre de pages qu'il y a en soi Google va toujours chercher l'expertise, le contenu la présence de contenu etc Il y a aussi des signaux au niveau du site c'est à dire qu'un site lui-même ayant beaucoup de contenu de contenu qualitatif sur beaucoup de requêtes etc aura souvent tendance à donner des signaux positifs à un peu toutes les pages qui sont sur ce site là indépendamment non en plus de la réalité du contenu qui est réellement présente sur la page la page donnée mais de manière générale, pensez à des questions du type, est-ce que je dois faire des paliers de x fois 100 pages combien de pages je dois avoir comment je me compare par rapport à un site qui a 2 fois plus de pages que moi et aussi par rapport à un autre qui a 2 fois moins de pages que moi sur un thématique donnée etc, on rentre vraiment dans des optimisations qui n'ont pas forcément complètement de sens pour qu'on cherche une réponse et on cherche une expertise par rapport à une question utilisateur quelle que soit le nombre de pages l'expertise concept qui est souvent souvent discuté, l'expertise elle se mesure par est-ce que le contenu est travaillé est-ce que le contenu est en profondeur est-ce qu'il est qualitatif, est-ce que la personne qui l'a écrite connaît son sujet et apporte une plus-value que les restes les autres pages sur le web n'apporte pas est-ce que la page en elle-même a une fonctionnalité qui permet à l'utilisateur de faire quelque chose qu'il ne peut pas faire ailleurs par exemple sur une requête trouvé une association pour volontariat dans ma ville une page qui a beaucoup de contenus très calis qui décrit à peu près toutes les pages toutes les associations caritatives d'une ville sera peut-être moins bien classé qu'une page qui en décrirait peut-être moins mais qui indiquerait comment rentrer en contact avec chacune de ces associations indiquerait des numéros de téléphone indiquerait des liens vers les formuleurs de contact de ces associations etc donc Calis c'est pas forcément avoir X mot par article et avoir un grand professeur qui va parler d'une domaine etc c'est est-ce qu'on apporte vraiment une plus-value est-ce qu'on permet à l'utilisateur de remplir la tâche qu'il voulait effectuer en arrivant sur le site web également à un point donné à l'originalité d'un contenu est-ce qu'il est nouveau différent par rapport à ce qu'on trouve sur le web c'est pas un critère cinéquanone mais c'est un critère qui peut être important voilà donc question suivante à moins qu'il ait des questions là-dessus en particulier celle-là c'est j'ai trouvé des slides qui ont été mis en ligne par Rémi Perrona qui s'intitule pourquoi je m'en fous de page speed et vous devriez aussi alors pour mettre ça en contexte ça m'a beaucoup fait rigoler quand j'ai vu ce titre on parle de page speed inside qui est un outil qui permet à n'importe quelle personne de rentrer une URL et ensuite d'avoir une note qui est donnée à la fois pour la version desktop et la version mobile de l'URL et une note qui est basée sur à la fois la vitesse de chargement, la rapidité des critères liés à la vitesse d'une page et à la fois à l'UX à la façon dont la page est designée et est-ce qu'elle permet une navigation confortable donc dans une certaine mesure moi aussi je m'en fous de page speed inside en fait je précise mon propos, je m'en fous du score final en soi que j'ai 90 ou 95 ou 80 en fait c'est pas important ce qui est important c'est d'où je viens et où je suis aujourd'hui le score page speed inside c'est important en absolu pas forcément vouloir atteindre 100 sur 100 à ce test ne doit pas être un graal vers lequel on se consacre absolument toutes ses ressources, toute son énergie, tout son temps l'outil page speed inside c'est un outil que je qualifierai avec des énormes guillemets bet, c'est un outil il y a un certain nombre de critères et qui donne en output si oui ou non une URL respecte ces critères ou non donc ces technologies peuvent être l'optimisation d'images, est-ce que les images sont optimisées ça a un impact sur la vitesse est-ce que ça utilise le cache du navigateur forcément si une page utilise le cache navigateur elle se chargera plus vite à l'avenir les scripts sont laudés de manière asynchrone donc les scripts pas essentiels pour la consultation de la page par exemple tout ce qu'il y a les médias sociaux etc est-ce qu'il se charge après que le contenu général de la page était chargé ce genre de détails qui se permettent de dire si oui ou non il y a une concentration, un focus sur la vitesse et sur l'expérience utilisateur lorsque cette page est chargée donc c'est tout ce que nous dit l'outil page speed insight ensuite c'est une question d'arbitrage vouloir absolument progresser de 80 à 85 sur page speed insight n'a pas forcément de logique si ça doit représenter trop d'efforts, trop d'investissement trop de modifications du fitwell et casser d'autres parties du site web etc il faut toujours faire des arbitrages donc les arbitrages ce sont quel est mon gain de fonctionnalité par rapport aux efforts mis en place et par rapport à ce que ça a comme conséquence sur le reste du site web pourquoi je m'en fous de page speed et pourquoi vous devriez aussi je modifierai ça pourquoi je m'en fous du score absolu de page speed insight et pourquoi je devrais me concentrer sur le score relatif il y avait également une question subsidiaire qui est la question suivante l'évaluation de la rapidité d'une page est basée sur des mesures réelles ou bien sur la présence de point d'optimisation donc là on parle dans l'algorithme et deuxième partie de la question les critères utilisés pour calculer le score page speed sont-ils plus ou moins les mêmes utilisés par le moteur pour répondre à cette question je dirais que l'outil page speed en fait n'a pas de relation directe avec l'algorithme de Google c'est un lien indirect forcément si une page est plutôt dans le haut du panier sur page speed insight ça veut dire que l'utilisateur s'est concentré sur la vitesse et sur l'expérience utilisateur qui sont deux des critères utilisés dans l'algorithme et donc forcément par conséquence le site devrait être mieux vu par l'algorithme de Google ou vu en tout cas comme plus utilisable et répondant au mieux aux requêtes des internautes sur quel critère se concentrer vraiment lorsque l'on développe un site web au niveau algorithmique je serais beaucoup plus tenté de dire qu'on est sur tout ce qui est DevTools les indicateurs du type first time to paint donc à partir de quel moment les premiers éléments graphiques s'affichent au moment du chargement de la page, on est sur la rapidité de la communication server vraiment sur ce genre de choses beaucoup plus techniques pour les gérer il y a un de nombreux outils qui existent pour voir ce qui existe ou tout simplement quel est l'état de la vitesse je conseillerai évidemment les DevTools dans Chrome qui sont dans la console qui permettent d'analyser vraiment très en profondeur toutes ces problématiques de rapidité de chargement et également l'outil Lighthouse donc l'infar en anglais qui permet d'avoir des recommandations qui sont données au niveau performance mais aussi au niveau progressive web apps et avec d'autres audites donc je recommande ces outils là pour regarder tout ce qui est vitesse est-ce qu'il y a des questions sur la vitesse d'un site ou sur page speed in size ok donc on va passer à la suite j'espère qu'il n'y a pas de question parce que je suis très clair parce qu'il n'y a pas d'intérêt donc n'hésitez pas tous à poser des questions vraiment si vous en avez je suis là pour répondre question suivante les URL d'un site peuvent-elles être découvertes par des citations dans un texte par leur présence dans le code source ou leur présence dans du flash par exemple alors je réponds à cette question là en disant s'il vous plaît n'utilisez pas flash flash est une technologie qui sera complètement abandonnée par Adobe en 2020 par Chrome en même temps on est vraiment sur une technologie ancienne qui n'est plus adaptée au web moderne donc je ne répondrai pas à cette question sur une URL dans flash ou non flash c'est le passé ensuite répondre est-ce que les URL peuvent être découvertes par des citations dans le texte ou par la présence dans le code source présence dans le code source j'imagine qu'on parle de présence en cachée par exemple avec CSS ou alors dans le citation texte c'est à dire une URL en clair mais sans sans lien hypertexte la réponse est dans les deux cas oui le crawler le Googlebot va avoir tendance à être très gourmand et à vouloir tenter d'explorer une page web même s'il n'y a rien plutôt que de laisser tomber et de ne pas aller voir ce qui se passe sur une URL alors qu'il peut potentiellement y avoir du contenu donc toute URL qui peut être interprétée par le robot d'exploration pourra être explorée pour vérifier si c'est le cas d'une URL qui sont dans le code source mais pas affichée à l'utilisateur je vous conseille d'utiliser explorer comme Google qui permet un outil dans la search console qui permet de voir le code tel que compris par le Googlebot pour voir si l'URL c'est trop voulant question suivante la notion de profondeur de site existe tel pour Google et si oui, sur un site avec de nombreux liens profonds la profondeur se calcule tel toujours par rapport à la homepage à la page d'accueil donc pas vraiment, c'est pas vraiment un concept qui est très important évidemment Google, lorsqu'il indexe ces pages fera sans doute une distinction entre une homepage et une page plus loin dans l'architecture dans l'arborécence mais c'est pas un concept important dans le sens où on ne donnera pas de manière automatique un poids plus important à une page se trouvant plus proche de la homepage, qu'à une page se trouvant plus loin de la homepage ce qui va compter, c'est une nouvelle fois le contenu qui se trouve sur cette page quand on parle de profondeur d'une page web ça me fait penser beaucoup plus à la navigation on retrouve encore énormément de sites où plus on s'enfonce dans la profondeur d'un site web, plus on est loin dans le fil d'Ariane et plus la navigation devient compliqué, parce qu'on arrive sur des parties peut-être un peu plus lointaines un peu moins souvent mises à jour et donc ce qui rentre en ligne de compte c'est si une personne arrive à consulter cette page une page qui est très loin dans l'arborécence depuis le moteur de recherche par exemple elle pourrait être intéressée par la consultation d'autres pages du site web mais si la navigation est trop compliquée ça devient un problème et c'est également un problème pour les robots d'exploration puisque le robot d'exploration essaye aussi quand ils arrivent sur une page de trouver tous les liens qui existent, de comprendre la structure d'une page web et d'un site web de manière générale donc se concentrer sur la profondeur d'une page web soit pas forcément très important se concentrer sur la navigation depuis une page profonde ça peut être une bonne idée, s'assurer que ce n'est pas une page qui est mise en ligne avec un contenu qui peut être super intéressant mais qui ne permet pas à l'utilisateur de continuer son cheminement d'utilisateur donc question suivante j'en ai encore 3 et puis après on pourra soit passer à des questions des personnes présentes soit passer enfin je vais dire au revoir que c'est important donc 10ème question existe-t-il des actions manuelles qui ne sont pas listées dans Search Console donc pour donner du contexte à ceux qui l'ignoreraient la Search Console permet de voir les actions manuelles qui sont prises pour cause de spam sur des sites web en particulier ou sur des parties de sites web en particulier dans un outil qui s'appelle action manuelle la réponse est non il n'y a pas de messages pardon il n'y a pas d'actions manuelles prises pour cause de spam sans messages envoyés dans la Search Console lorsqu'il y a des actions pour cause de spam qui sont effectuées sur un site web et qu'il n'y a pas de notification utilisateur on est sur un cas d'action algorithmique par rapport à l'action manuelle la raison pour cela c'est que nous estimons que lorsque nous prenons une action pour cause de spam nous voulons donner la possibilité à une personne, à la personne qui gère le site web de nous signaler que ce spam n'est plus là n'est plus présent parce que ça peut être aussi souvent des choses un peu plus ponctuelles donc nous donnons cette possibilité le cas algorithmique est différent les idérations successives des algorithmes en fait c'est toujours à une page de rentrer dans une pénalité ou de sortir dans une pénalité question suivante numéro 11 le cpc adwords ou le cost per click le coût par click d'une requête individuelle est-il un facteur pour le moteur de recherche naturelle donc la question c'est de dire si une requête en particulier est chère dans la partie de Google, au niveau adwords est-ce que Google va plus travailler sur les résultats naturels qui se montrent pour cette page là en particulier la réponse c'est non il n'y a pas de lien entre les deux c'est quelque chose de très important à noter ce n'est pas parce qu'il y a un paysage particulier au niveau payant que cela ont un impact sur la partie naturelle des résultats du moteur de recherche de la même manière ce n'est pas parce qu'un client de Google dépense 100 000€ par an ou 10 000€ par an ou tout ce qu'on veut qu'ils auront des priorités dans la recherche organique ou qu'ils auront des accès particuliers à des personnes qui pourront les aider avec le récit haut etc on est vraiment sur une séparation des deux choses la façon dont on peut se poser la question aussi c'est de se demander si ok mais donc j'ai des requêtes qui sont chères de se positionner en payant sur des requêtes de un investissement vraiment important et du coup ça pourrait donner aux ingénieurs l'envie de faire en sorte que les résultats naturels soient vraiment aussi de bonne qualité pour aller de pair c'est pas vraiment le cas quand les équipes d'ingénieurs qui s'occupent du moteur de recherche sélectionnent leurs projets les modifications à apporter dans les futures iterations des algorithmes ce qui est pris en compte c'est l'impact du utilisateur donc il peut y avoir pas mal de facteurs mais ce n'est pas l'impact des annonceurs donc les personnes qui payent pour être dans la droite très important à préciser voilà toujours pas de question donc je prends la dernière question que j'ai préparée pour aujourd'hui et on n'est pas trop mal au niveau timing il nous restera quelques minutes la question est que peux-tu nous dire de fred donc de Google fred alors pour ceux qui ne sauraient pas Google fred c'est un nom qui a été donné à des changements algorithmiques qui se passent au niveau naturel depuis quelques mois, quelques trimestres maintenant pour Google l'origine d'une nom fred n'est pas interne à Google c'est à dire que à l'époque les algorithmes pandas et pingouins des noms de code un peu qui étaient approuvés par Google etc fred, l'historique de ce nom c'est qu'un collègue qui travaille à Zurich dans l'équipe des webmaster friends analystes Gary Villiers avait appris l'habitude de poster sur Twitter des photos de poissons et de fruits de mer vivants il fait de la congé et quelqu'un a demandé comment s'appelait le poisson en particulier sur une photo Gary a répondu fred et du coup la blogosphère américaine s'est remparée de la chose et a donné le nom fred à un peu tous les nouveaux changements algorithmiques les modifications algorithmiques qui se passent depuis le début l'année et même un peu avant donc l'algo fred ou le filtre fred ou le changement fred pour Google ça veut pas vraiment dire grand chose mais c'était beaucoup plus une blague à l'origine fred c'est toutes les modifications qui peuvent être apportées à l'algorithme des modifications algorithmiques on en fait des milliers, des centaines ou des milliers tous les ans il me semble qu'en 2016 il y a eu pas loin de 1600 changements aux algorithmes naturels de recherche Google donc on est sur une base énorme il se passe en permanence des changements de manière générale la philosophie de Google actuellement par rapport au passé et d'essayer de minimiser l'impact sur les créateurs de Citroën il y avait eu énormément de retour de la part des SEO des webmasters par le passé disons que à nous Googleur quand on allait en conférence sur internet etc qu'il n'y avait pas assez de communication sur les modifications algorithmiques et qu'il fallait donner un peu plus de billes pour comprendre et donc c'est quelque chose que nous avons pris en ligne de compte la première fois que nous avions annoncé une modification algorithmique majeure c'était en 2015 lorsqu'il y a eu Mobile Freddy il me semble que c'était 2015 le fait que les pages n'étant pas adaptées au mobile ne seraient pas aussi bien classées ou en tout cas auraient des critères négatifs pour le classement sur mobile et ça on l'avait annoncé 4 mois avant et il y avait eu un très bon retour de ça de la communauté par rapport à ça et ce qui s'est passé ensuite c'est qu'on essaye d'être de continuer dans cette direction par exemple avec le changement d'évolution mobile first indexing on a communiqué sur le fait que nous pensions faire ça alors même que nous n'avons pas de date et qu'on est encore vraiment en période de test on est plus vraiment dans les tests initiaux initiaux mais on n'est vraiment pas dans les tests finaux donc c'est du temps au webmaster pour comprendre ce qui se passe est important un autre exemple c'est le fait que ça ne consomme pas directement le moteur de recherche organique mais c'est une thématique qui est aussi importante pour le référence naturelle c'est le HTTPS l'équipe Chrome notifie désormais maintenant de toutes les modifications qu'il y aura au niveau HTTPS c'est le futur version de Chrome et donc par rapport par exemple dans la version Chrome 64 il me semble commencera à montrer aux internautes dans la barre d'adresse de Chrome une notification non sécurisée lorsqu'ils rentreront n'importe quelle information dans un champ sur un site qui n'est pas en HTTPS donc actuellement sur un champ mode pass sur des champs qui demandent de rentrer des informations personnelles à l'avenir ce sera pour n'importe quel champ sur un site web et pour ça on donne Google donne maintenant et essaie de donner le plus de temps possible au webmaster pour mettre ça en place par exemple ça a été annoncé en début d'été il me semble pour octobre au novembre voilà donc des changements il s'en passe tout le temps Fred c'est pas vraiment un onquet c'est vraiment une réalité des modifications c'est vraiment en permanence voilà donc les 12 questions que j'avais préparées au niveau timing pas trop mal du tout parce qu'il est moins 4 est-ce qu'il y a des dernières questions que je peux prendre des quelques personnes qui sont présentes oui moi j'ai une question vas-y pourquoi est-ce qu'il y a qu'il y a moins de 404 qui remontent dans la console que ce qu'on peut observer dans les logs server avec le user agent googlebot d'accord les outils de search console de manière générale la majorité d'entre eux sont vraiment utiles pour voir les tendances et pas les chiffres exacts c'est-à-dire que ce qui est important c'est de monitorer les évolutions par rapport à précédemment par exemple on parait 404 l'important et sans doute d'être notifié par la search console qu'il y a actuellement depuis une semaine par exemple une recrudescence d'une erreur 404 et ensuite pour comprendre vraiment ce qui se passe utiliser l'outil d'erreur d'exploration de la search console devient assez vite limité en fait notamment parce que l'information n'est pas toujours complète mais aussi parce qu'on n'a pas accès à toutes les informations qui sont nécessaires pour débugger et là effectivement une analyse des logs pour comprendre vraiment ce qui se passe ça va comment ta question ? très bien merci de l'avoir posé et est-ce qu'il y en a d'autres de nos autres participants ? écoute tu m'entends Vincent ? oui ok je m'entends j'avais juste une question pour revenir sur le page page speed oui on a trouvé en fait c'est moi qui ai parlé du mot hack tout à l'heure ou c'est plus trop quoi mais en tout cas on a un concurrent qui s'amuse à voir le first beat load là tu me parles du first paint tout à l'heure en fait c'est effectivement un concurrent qui met son site en load donc je ne sais pas il doit mettre une seconde et demi et en fait le temps de réponse sur son first beat est à 0,05 quelque chose qui normalement sous WordPress ne se fait pas donc il n'est pas sous WordPress et on a l'impression de la volumétrie dans la thématique que ça vous porte vraiment haut et on voulait savoir qu'est ce que tu en penses c'est un facteur clé est ce que Google se laisse avoir dans le sens où le site est en fait long à charger derrière mais il se fait avoir par ce first beat ou est ce que c'est c'est une question un peu complexe évidemment sans voir le site en lui-même ce que je peux te répondre là dessus c'est que même si ça rentre en ligne de compte ce qui est difficile de confirmer c'est que ce n'est pas la seule chose qui entre en ligne si tu me dis que on a un peu un echo je viens de couper mon micro c'est bon j'ai coupé la personne responsable donc oui pardon je reprends mon fil de ma pensée je ne peux pas te confirmer si oui ou non c'est hyper important etc mais si ça rentre en ligne de compte c'est à dire si ça les aide de flouter Google si effectivement c'est le cas ça doit sans doute être très loin d'être le seul critère et pareil au niveau de leur utilisateur un site qui qui se charge lentement aura toujours des utilisateurs qui partent de ce site web donc le chiffre qu'on donne d'habitude c'est un site qui met plus de 3 secondes à se charger par x% de ses utilisateurs je me souviens plus exactement de la donnée donc en fait un site qui se charge hyper hyper rapidement pour avoir le first beat ou le time to first paint etc mais qui ensuite mettra 20 secondes à montrer le contenu général l'utilisateur il partira ou en tout cas la majorité des utilisateurs donc si les gens attendent et consomment le contenu et que finalement c'est un site cali etc c'est qu'il a aussi beaucoup d'autres choses qui rentrent en ligne de compte ok ça marche merci j'en prie on a le temps peut-être pour une ou deux dernières questions de la part des personnes qui viennent de nous rejoindre qui viennent de nos quitter ok bon bah on va dire que c'est bon alors je vous remercie à tous d'être venus d'avoir posé des questions aux préalables et des questions pendant le youtube live n'hésitez pas à laisser des commentaires pour me dire si ça fonctionne si c'est un format qui est intéressant si ça répond aux questions et si c'est le cas on essaiera d'en réorganiser dans les semaines qui viennent et avec je l'espère un peu plus de régularité que ce qu'on a pu faire par le passé merci à tous et bonne fin de journée merci