22 janvier 2019 – Notes du Hangout de l'aide Google

Cette semaine, John est dans la Big Apple, NYC. Rejoint IRL, de gauche à droite, par Martin Splitt de l'équipe Java Script de Google, Chris Love, Lily Ray, Marie Haynes, Dave Minchala et Quason Carter. Cette semaine, il y avait de bonnes questions sur Cloudfare, The QRG et The New Page Speed ​​Tool. Le lien vers la vidéo et la transcription complète se trouvent ci-dessous !

Cloudflare bloque-t-il parfois Googlebot ?

7:58

"Ouais, je ne sais pas comment c'est configuré avec Cloudflare pour le moment, mais je sais que dans le passé, ils bloquaient les gens qui simulaient Googlebot. Donc, si vous utilisez, par exemple, le vôtre, je ne sais pas, Screaming Grenouille ou quelque chose du genre-- vous dites, j'utilise l'agent utilisateur Googlebot, alors ils bloqueraient cela parce qu'ils pourraient dire, par exemple, que ce n'est pas un Googlebot légitime. Nous pouvons bloquer cela. Mais pour la plupart, je pense qu'ils ont assez de pratique pour reconnaître les Googlebots normaux et les laisser ramper normalement."

Résumé : Parfois, lors des tests, il peut sembler que Cloudflare bloque Googlebot. Ce qui se passe probablement ici, c'est que Cloudflare bloque les personnes qui prétendent être Googlebot. Ainsi, si vous utilisez un outil comme Screaming Frog et choisissez Googlebot comme agent utilisateur, vous ne pourrez peut-être pas explorer les sites à l'aide de Cloudflare .

Les liens non naturels peuvent-ils encore nuire à un site de manière algorithmique ? Si oui, l'utilisation de l'outil de désaveu peut-elle aider ?

14:01

"Je pense que c'était une bonne question. Donc, de mon point de vue, ce que je regarderais là-bas, c'est, d'une part, certainement le cas où il y a une action manuelle. Mais aussi, les cas où vous voulez aussi voir beaucoup d'actions manuelles dirait, eh bien, si l'équipe de spam Web examinait cela maintenant, elle vous donnerait une action manuelle. Genre des cas où vous diriez, eh bien, l'action manuelle est plus une question de temps et pas un peu comme si c'était basé sur quelque chose qui a été fait - je ne sais pas - où c'est clairement fait il y a quelques années, et c'était un peu limite non. Mais le genre de choses où vous le regardez et dire, si quelqu'un de l'équipe de spam Web recevait cela comme un conseil, il prendrait une action manuelle, et c'est certainement le genre de chose où je nettoierais ça et ferais comme un désaveu pour ça. il est difficile de dire s'il y a une chronologie spécifique. Mais en général, si l'équipe de lutte contre le spam a regardé cela et a dit, comme, les choses ont évolué. C'était clairement d un il y a quelques années. Ce n'était pas totalement malveillant. Ensuite, ils ne prendraient probablement pas d'action manuelle pour cela. "

Et je suppose que vous ne pouvez probablement pas répondre à cela, mais y a-t-il un moyen que - comme, disons que nous n'avons pas obtenu d'action manuelle, ou qu'ils n'ont pas obtenu d'action manuelle. Ces liens peuvent-ils les blesser algorithmiquement ? Parce que nous avons l'impression de voir des améliorations sur certains sites, vous savez, après avoir désavoué. Donc, encore une fois, je sais que c'est toujours-- ce n'est jamais en noir et blanc.

Cela peut certainement être le cas. C'est donc quelque chose où nos algorithmes, quand nous regardons cela et qu'ils voient, oh, ils sont un tas de liens vraiment mauvais ici, alors peut-être qu'ils seront un peu plus prudents en ce qui concerne les liens en général pour le site Web. Donc, si vous nettoyez cela, alors les algorithmes l'examinent et disent, oh, il y a... il y a en quelque sorte... c'est OK. Ce n'est pas mauvais.

Résumé : Si vous avez des liens spécialement conçus pour le référencement, et que vous en avez beaucoup, ils peuvent amener les algorithmes de Google à se méfier de tous vos liens. Mieux vaut désavouer pour des cas comme celui-ci.

Comment les algorithmes de Google mesurent-ils l'EAT des éditeurs ?

33:40

"Je ne sais pas. Je pense que c'est probablement difficile à comprendre de manière algorithmique. Et s'il y avait des choses techniques que vous devriez faire, alors nous vous le ferions savoir. Donc, s'il y a des choses comme le balisage d'auteur que nous avait à certains moments que nous pensons être utile pour quelque chose comme ça, nous apporterions certainement cela là-bas. Mais beaucoup de choses sont vraiment plus des facteurs de qualité souples que nous essayons de comprendre, et ce n'est pas quelque chose de technique que vous Je fais ou je ne fais pas. Il s'agit plutôt d'essayer de comprendre comment un utilisateur pourrait voir cela. Donc, rien de spécifique que je puisse pointer. "

Résumé : Il existe de nombreux "facteurs de qualité souples" que Google examine. Regardez les choses du point de vue de l'utilisateur. De plus, le balisage d'auteur peut aider Google à mieux comprendre les choses.

Si quelque chose figure dans les directives des évaluateurs de qualité, est-il raisonnable de supposer que Google souhaite que cela se reflète dans ses algorithmes ?

34:44

Je pense qu'en général, c'est probablement une bonne pratique de viser cela. J'évite d'essayer de trop me concentrer sur ce que Google pourrait utiliser comme facteur algorithmique et de le considérer davantage comme-- nous pensons que c'est bon pour le Web, et, par conséquent, nous essaierons d'aller dans cette direction et de faire ces genre de choses. Donc, ce n'est pas tellement comme si je faisais un bon site Web juste pour pouvoir mieux me classer, mais je fais un bon site Web parce que quand j'apparais dans la recherche, je veux que les gens aient une bonne expérience. Et puis ils reviendront sur mon site Web, et peut-être qu'ils achèteront quelque chose. C'est donc un peu la direction que je verrais, non pas comme faire ça pour se classer, mais pour avoir une relation saine et à long terme sur le web.

Résumé : pensez à ce qui est le mieux pour les utilisateurs. Même si tout ce qui se trouve dans le QRG n'est pas actuellement reflété dans les algorithmes de Google, ce sont tous de grands pas vers l'amélioration de la qualité globale.

Existe-t-il un schéma pour aider les sites à apparaître plus haut dans les résultats de recherche vocale ?

36:10

Je ne sais pas. Je ne peux penser à rien de désinvolte. Il y a donc le balisage prononçable que vous pouvez utiliser, ce qui est probablement raisonnable à - en quelque sorte examiner pour voir où cela pourrait avoir un sens sur une page. Je ne pense pas que nous l'utiliserons encore dans tous les endroits.

Résumé : Le balisage vocable n'est pas encore utilisé dans toutes les zones géographiques. Mais, c'est un bon point de départ.

Quelques conseils pour gagner des extraits optimisés

38:03

Mais les extraits de code, en particulier, je ne pense pas que nous ayons un type de balisage spécifique à cela. C'est donc quelque chose où si vous avez une structure claire sur la page, cela nous aide beaucoup. Si nous pouvons reconnaître des tableaux similaires sur une page, nous pouvons les extraire beaucoup plus facilement. Alors que si vous utilisez du HTML et du CSS sophistiqués pour le faire ressembler à un tableau, mais que ce n'est pas vraiment un tableau, alors c'est beaucoup plus difficile à extraire pour nous.

Résumé : Il n'y a pas de balisage que vous pouvez ajouter pour gagner un extrait optimisé. Mais, une bonne utilisation des balises h et des tableaux HTML normaux peut vraiment aider.

Le schéma d'emplacement doit-il être ajouté à toutes les pages ?

50:47

Réponse 51:42 - Pour autant que je sache, c'est juste la page d'accueil. Je ne sais pas. Est-ce que vous connaissez quelqu'un?

Réponse de Liz 51:4 7 - C'est censé n'être qu'une seule page généralement avec organisationnel et corporatif. C'est généralement la recommandation.

MARTIN SPLITT 52:00 - Je suppose que peu importe quelles pages, tout comme ne pas le mettre sur chaque page que vous avez, je suppose, est la partie la plus importante. Je pense que cela dépend de-- si vous êtes un site d'actualités, il est probablement logique de le mettre dans la page de contact, ou la page à propos, ou quelque chose comme ça. Alors que dans le site Web d'un magasin ou d'un restaurant, il est probablement acceptable de le mettre sur la page d'accueil.

JOHN 52:20 - Je pense aussi, dans ce cas, cela n'a pas autant d'importance pour nous car nous devons pouvoir le trouver quelque part comme la page d'accueil ou la page de contact. Mais si nous l'avons ailleurs, cela ne change rien pour nous. Donc, la grande chose à ne pas comparer est le balisage des avis où nous voyons parfois des gens mettre comme avis d'entreprise sur toutes les pages du site Web dans l'espoir d'obtenir les étoiles et les résultats de recherche pour chaque page de leur site. Et ce serait mauvais pour nous. Mais les informations de contact, si vous les avez annotées, c'est-- Je n'y vois pas de problème.

Résumé : Cela n'a pas vraiment d'importance. Cela devrait être sur la page de contact et probablement sur votre page à propos et votre page d'accueil. Avoir un schéma d'emplacement sur le site n'est pas un problème, mais n'est probablement pas nécessaire non plus.

Pourquoi le nouvel outil PageSpeed ​​Insights, basé sur Lighthouse, est-il tellement plus sévère lors de la notation des sites Web ?

53:05

Marie Haynes : Ce n'est pas ma question, mais pour donner un peu de contexte, les nouvelles données de Lighthouse pour la vitesse des pages sont bien plus dures que l'étaient les Page Speed ​​Insights. Donc, quelque chose qui avait un score de 80 sur Page Speed ​​​​Insights pourrait être un 29 rouge sur Lighthouse. C'est donc une bonne question. Est-ce que cela est susceptible de causer-- parce que nous savons que dans les mobiles, les sites très lents pourraient être rétrogradés. Alors est-ce bien si nous disons, vous savez, si vous êtes dans le rouge au test Lighthouse, que nous devrions vraiment améliorer les choses parce que cela pourrait entraîner une rétrogradation, ou y a-t-il une coupure ?

Réponse 54:07 - Nous n'avons donc pas de cartographie individuelle des outils externes et de tout ce que nous utilisons pour les réseaux sociaux. Oui, c'est vraiment difficile à dire, mais dans la recherche, nous essayons d'utiliser un mélange de données réelles, qu'est-ce que c'est, des données de test de laboratoire, qui ressemblent un peu au test Lighthouse, et aux données du rapport Chrome UX, où essentiellement quoi nous mesurons ce que les utilisateurs du site Web verraient.

MARTIN SPLITT 55:37 - Il est également important de voir que Lighthouse, par exemple, mesure spécifiquement une connexion 3G à l'extrémité médiane - ou comme un téléphone à performances moyennes, oui. Donc, fondamentalement, si vous utilisez un Apple McIntosh récent ou un ordinateur Windows rapide récent avec une très bonne connexion filaire ou une très bonne connexion Wi-Fi dans votre bureau, bien sûr, vous voyez un temps de chargement de deux secondes, mais un vrai utilisateur avec son téléphone dans la nature ne le voit probablement pas. C'est donc l'un de ces cas comme si cela ne faisait jamais de mal de rendre votre site Web plus rapide, mais c'est vraiment, vraiment difficile de dire à quoi cela ressemblerait du point de vue de l'intérieur, car nous utilisons des métriques très spécifiques qui ne correspondent pas nécessairement à un à ce que les outils exposent ... bien sûr, il est important de résoudre ce problème, car vous ne voulez pas que vos utilisateurs attendent indéfiniment sur votre site Web. Ça va te faire mal. Cela va nuire à vos utilisateurs. Cela va juste vous blesser dans la recherche. Mais je ne paie pas - je dirais qu'il suffit de regarder les outils. Si les outils vous disent que vous vous débrouillez bien, vous ne devriez pas trop vous en soucier. Si les outils vous disent que vous ne faites vraiment pas bien, alors je pense que le temps passé à comprendre pourquoi cela dit - comme, si ce qu'il dit est pertinent, c'est perdu. Vous devriez plutôt chercher à rendre le site plus rapide.

Les performances mobiles sont un facteur très important pour vos utilisateurs, ainsi que tout le reste. Je dirais donc assurez-vous que votre site Web fonctionne bien dans des conditions réelles. Peut-être même acheter un téléphone bon marché et essayer le site Web de temps en temps, et si... c'est quelque chose que j'aime faire, et que je faisais avant de rejoindre Google avec l'équipe de développement avec laquelle je travaillais. J'étais genre, écoutez, voulez-vous utiliser ce site Web sur ce téléphone ? C'était comme, oh, c'est horrible. Je me dis, mhm, ouais, alors peut-être qu'on devrait faire quelque chose à ce sujet.

JOHN - Dans Chrome, vous pouvez le configurer et essayer différentes vitesses de connexion. Émulateur mobile. Je pense que ce sont de très bonnes choses à regarder, et aussi, comme, regardez votre base d'utilisateurs. Regardez vos données d'analyse si vous voyez que les gens n'utilisent votre site Web qu'avec un iPhone haut de gamme, alors c'est peut-être moins un problème que si vous voyez que les gens se connectent à votre site à partir de connexions rurales aléatoires, qui sont lent, et ils ont des appareils bas de gamme, alors c'est peut-être plus.

Résumé : Lighthouse mesure les vitesses d'une connexion 3G, de sorte que la plupart des sites fonctionneront beaucoup plus rapidement que ce qui est affiché ici pour la majorité des sessions. Remarque : Une fois ce Hangout terminé, Martin a poursuivi en disant que c'est la "première peinture de contenu" qui est la plus importante en ce qui concerne les rétrogradations potentielles de classement.

Si vous aimez ce genre de choses, vous allez adorer ma newsletter !

Mon équipe et moi rendons compte chaque semaine des dernières mises à jour de l'algorithme Google, des actualités et des conseils SEO.

Vidéo et transcription complète

Question 1:32 - Je me demandais si vous aviez d'autres conseils ou un autre point de vue sur les tests d'une manière que les référenceurs pourraient utiliser pour être plus précis et avoir plus confiance en leurs rapports avec l'entreprise. Nous avons essayé cette chose, et elle a fait son effet. Et nous l'avons fait d'une manière infaillible, un peu comme Google le recommanderait.

Réponse 3:20 - Donc, de mon point de vue, j'essaie de séparer les choses de type plus technique des types de changements de type qualité. Donc, tout ce qui est vraiment une chose technique claire, vous pouvez à peu près tester si cela fonctionne ou si cela ne fonctionne pas. Il ne s'agit pas de savoir si cela fonctionne ou si cela ne fonctionne pas, mais beaucoup de ces choses techniques, en particulier lorsque vous regardez le rendu, ou lorsque vous regardez si Google peut effectivement indexer ce contenu, c'est quelque chose qui fonctionne ou qui ne fonctionne pas. Là où ça devient délicat, c'est tout ce dont il s'agit - c'est indexé, mais comment cela apparaît-il dans les classements ? Et je pense que pour beaucoup de cela, il n'y a pas de moyen absolu de vraiment tester cela. Parce que si vous testez cela dans une situation isolée, comme vous créez un site de test, et que vous le configurez avec toutes les recommandations que vous avez, vous ne pouvez pas vraiment supposer qu'un site de test fonctionnera de la même manière qu'un site Web normal. Il y a parfois des choses simples, comme s'il s'agit d'un site de test, alors peut-être que nous ne ferons pas de rendu complet parce que nous pensons que cela n'a pas de sens de passer autant de temps sur ceci et cela, parce que, par exemple, personne ne le regarde. Il n'apparaît jamais dans les résultats de recherche, pourquoi devrions-nous mettre autant de ressources derrière cela ? Alors que si vous faisiez cela sur un site Web normal, cela fonctionnerait très différemment. C'est donc quelque chose pour lequel je n'ai pas vraiment d'indications claires sur ce que vous devriez faire ou ce que vous ne devriez pas faire. Cela ressemble plus au genre de chose où vous regardez les tendances générales où vous voyez que le site Web apparaît, le genre de changements dans les classements que vous voyez pour ces requêtes, et essayez d'y appliquer les meilleures pratiques.

Question 5:21 - Alors peut-être que si-- un exemple concret peut-être pourriez-vous l'utiliser pour-- peut-être que cela serait utile, donc quelque chose comme un test de balise de titre, n'est-ce pas ? Si vous faisiez cela... que devrions-nous rechercher, le cas échéant ? Ou y a-t-il quelque chose à regarder pour démêler - est-ce dû à notre test ou est-ce dû à quelque chose qui change sur le serveur, l'algo, la dynamique concurrentielle ? [RIRES] En supposant que nous fassions d'autres choses pour examiner ces externalités.

Réponse 5:56 - Je pense qu'un changement de balise de titre est en fait assez complexe de notre côté dans la mesure où il y a une sorte d'interaction entre Google utilise-t-il une balise de titre que vous fournissez réellement, d'une part, pour le classement, d'autre part d'autre part, pour apparaître dans les résultats de recherche. Comme pour les ordinateurs de bureau et mobiles, nous avons une quantité d'espace différente, nous pouvons donc afficher des balises de titre légèrement différentes. Les utilisateurs peuvent y répondre de différentes manières. Vous pourriez donc vous classer de la même manière, mais les utilisateurs pourraient penser, oh, c'est une excellente page. Je vais le montrer plus haut - ou je vais cliquer dessus dans les résultats de recherche car il ressemble à une grande page. Et puis vous avez plus de trafic. Mais le classement est en fait le même. Alors est-ce que c'est une bonne chose ? Probablement, je suppose. Si vous regardez simplement le classement, cela ressemblerait à, eh bien, vous n'avez rien changé à quoi que ce soit, et nous avons juste eu plus de trafic.

Mais c'est quelque chose où il y a beaucoup d'aspects différents qui circulent là-dedans. C'est donc quelque chose où je pense qu'en tant que référenceur, il est utile, d'une part, d'avoir une compréhension technique de ce qui s'est passé, mais aussi d'avoir une sorte de compréhension plus marketing et de qualité de la façon dont les utilisateurs réagissent au changement, ce sont des changements à long terme que nous pourrions affecter aux utilisateurs, comment pouvez-vous piloter cela pour vous assurer que notre site est considéré comme le site le plus pertinent dans les situations où les gens recherchent quelque chose en rapport avec cela. Et je pense que c'est quelque chose qui est vraiment difficile à tester. C'est, comme, même dans le marketing traditionnel où ils ont eu des années et des années de pratique, c'est vraiment difficile à tester, comme, est-ce que cela a vraiment un grand impact ou pas ? C'est quelque chose où ils finissent par avoir une vue d'ensemble ou faire des études d'utilisateurs, ce que vous pouvez également faire en tant que SEO. Pardon. [RIRE]

Question 7:58 - J'ai une question plus directe. Donc, un certain nombre de nos sites, vous savez, utilisent Cloudflare, et nous avons remarqué qu'ils bloquent directement Googlebot, n'est-ce pas ? Mais cela n'a pas eu beaucoup d'impact sur nos classements, sur notre visibilité, etc. Donc, en quelque sorte, essayez de comprendre comment, par exemple, vous utilisez un autre bot pour explorer directement un index en dehors du Googlebot, et comment devrions-nous y penser lorsque les CDN font tout leur possible pour bloquer le bot ?

Réponse 8:33 - Oui, je ne sais pas comment cela se passe avec Cloudflare pour le moment, mais je sais que dans le passé, ils bloquaient les personnes qui simulaient Googlebot. Donc, si vous utilisez, par exemple, votre propre, je ne sais pas, Screaming Frog ou quelque chose du genre-- vous dites, j'utilise l'agent utilisateur de Googlebot, alors ils bloqueraient cela parce qu'ils pourraient dire, par exemple, que ce n'est pas un légitime Googlebot. Nous pouvons bloquer cela. Mais pour la plupart, je pense qu'ils ont suffisamment de pratique pour reconnaître les Googlebots normaux et les laisser ramper normalement.

Question 9:02 - Ouais, c'était intéressant. Parce que j'ai contacté un groupe de collègues d'autres agences, et ils reproduisaient des situations similaires même sur leur propre site. Par exemple, il y avait un ticket d'assistance dans Cloudflare, et celui-ci était également bloqué lorsque j'essayais simplement de rendre directement à partir de Googlebot ou d'un smartphone Googlebot.

Réponse 9:21 - OK, ouais. Eh bien, nous n'avons pas de solution de contournement. Par exemple, si les sites Web nous bloquent, nous sommes en quelque sorte bloqués. Mais généralement, si un service comme Cloudflare nous bloquait par défaut, cela affecterait de nombreux sites Web. Et nous le remarquerions. Nous contacterions probablement Cloudflare à propos de quelque chose comme ça. Il se peut qu'ils aient différents niveaux de service. C'est comme si vous étiez au niveau inférieur, alors c'est comme un service gratuit, mais nous avons une limite avec la quantité de trafic. Je ne sais pas s'ils ont quelque chose comme ça. C'est quelque chose que j'ai vu avec d'autres hébergeurs, où si vous avez une sorte d'hébergement gratuit par défaut, alors parfois ils ont juste un plafond de trafic, et ils bloquent les choses.

MARTIN SPLITT : Vous ne le verrez peut-être pas immédiatement dans les statistiques de votre classement, etc. Parce que fondamentalement, si nous avons du contenu de votre part, et fondamentalement, le site Web n'est pas - selon ce que bloqué, dans ce cas, signifie parce que je n'ai pas vu cela. Et je gère quelques sites Web derrière Cloudflare, et je n'ai eu aucun problème. Mais encore une fois, je n'ai pas un site Web gigantesque ou j'aime beaucoup de trafic parce que je suis sur le plan gratuit. C'est... mais si vous n'obtenez pas d'erreur de notre côté, il se peut que nous conservions le contenu que nous avons vu la dernière fois. Et cela se classe bien, et c'est OK.

Réponse 12:09 - Oui, donc je pense que ce qui se passerait dans un cas comme le vôtre, c'est que nous ralentirions l'exploration. Et nous essaierions de garder le contenu que nous pouvons récupérer davantage sur l'index, et nous réexplorerions juste un peu plus longtemps. Mais cela signifie également que si vous apportez des modifications à votre site Web, il nous faudra plus de temps pour les récupérer. Si nous devons réexplorer des choses de manière significative, comme, je ne sais pas, AMP, ou si vous ajoutez tel ou tel élément sur l'ensemble du site, cela prendra beaucoup plus de temps. Donc, si vous voyez vraiment régulièrement que nous ne pouvons pas explorer avec un Googlebot normal, alors c'est quelque chose que j'aborde avec l'hôte pour que nous puissions voir.

Question 14:01 - Parfait. J'ai donc une question sur l'outil de désaveu. Nous recevons donc tout le temps des gens qui veulent que nous fassions des audits de liens. Et depuis Penguin 4.0, donc septembre 2016, où Gary Illyes a dit, et je pense que vous l'avez dit aussi, comme, Google est assez doué pour ignorer les liens non naturels. Donc, ma pensée à ce moment-là était, eh bien, nous ne devrions pas avoir à utiliser l'outil de désaveu pour demander à Google d'ignorer les liens qu'ils ignorent déjà, à moins que vous n'ayez une action manuelle pour les liens non naturels. Nous ne l'avons donc recommandé qu'aux sites qui ont activement, vous savez, créé des liens, essayé de manipuler des choses, des choses qui ne sont pas des liens naturels. Mais je pense qu'il y a tellement de confusion parmi les webmasters parce que je vois tout le temps des gens, vous savez, facturer des tonnes d'argent pour auditer - pour désavouer des liens qui sont juste - je sais qu'ils sont ignorés. J'aimerais donc que nous puissions avoir un peu plus de précisions. Alors peut-être que si je peux vous donner un exemple, comme s'il y avait un propriétaire d'entreprise qui, il y a quelques années, avait embauché une société de référencement, et que cette société de référencement avait fait un tas de publications d'invités juste pour les liens et, vous savez, des trucs qui était plutôt de qualité moyenne, si vous voyez ce que je veux dire, pas ultra spam, pouvons-nous être sûrs que Google ignore ces liens ? Ou devrions-nous entrer et désavouer?

Réponse 15:22 - Je pense que c'était une bonne question. Donc, de mon point de vue, ce que je regarderais là-bas, c'est, d'une part, définitivement le cas où il y a une action manuelle. Mais aussi, les cas où vous voulez également voir beaucoup d'actions manuelles diraient, eh bien, si l'équipe de spam Web examinait cela maintenant, elle vous donnerait une action manuelle. Le genre de cas où vous diriez, eh bien, l'action manuelle est plus une question de temps et pas un peu comme si elle était basée sur quelque chose qui a été fait - je ne sais pas - où c'est clairement fait quelques années il y a, et c'était un peu limite pas. Mais le genre de choses où vous regardez et dites, si quelqu'un de l'équipe de spam Web recevait cela comme un conseil, il prendrait une action manuelle, et c'est certainement le genre de chose que je nettoierais et ferais comme un désaveu pour ça. Oui, je pense qu'il est difficile de dire s'il y a une chronologie spécifique. Mais en général, si l'équipe webspam regardait cela et disait, comme, les choses ont évolué. Cela a clairement été fait il y a quelques années. Ce n'était pas totalement malveillant. Ensuite, ils ne prendraient probablement pas d'action manuelle pour cela.

Question 16:43 - Et je suppose que vous ne pouvez probablement pas répondre à cela, mais y a-t-il un moyen que - comme, disons que nous n'avons pas obtenu d'action manuelle, ou qu'ils n'ont pas obtenu d'action manuelle. Ces liens peuvent-ils les blesser algorithmiquement ? Parce que nous avons l'impression de voir des améliorations sur certains sites, vous savez, après avoir désavoué. Donc, encore une fois, je sais que c'est toujours-- ce n'est jamais en noir et blanc.

Réponse 17:03 - Cela peut certainement être le cas. C'est donc quelque chose où nos algorithmes, quand nous regardons cela et qu'ils voient, oh, ils sont un tas de liens vraiment mauvais ici, alors peut-être qu'ils seront un peu plus prudents en ce qui concerne les liens en général pour le site Web. Donc, si vous nettoyez cela, alors les algorithmes l'examinent et disent, oh, il y a... il y a en quelque sorte... c'est OK. Ce n'est pas mauvais.

Question 17:24 - Il est toujours bon de désavouer simplement pour empêcher une action manuelle, n'est-ce pas ?

Réponse 17:29 - Je pense que si vous êtes dans un cas où il est vraiment clair que l'équipe de spam Web vous donnerait une action manuelle basée sur la situation actuelle, alors c'est ce que je désavouerais.

Question 17:37 - Donc c'est bien de penser comme chez Google -- comme quelqu'un dans l'équipe anti-spam de Google pense juste, comme, vous savez, s'ils regardent ça, que feraient-ils s'ils le faisaient ?

Réponse 17:47 - Ouais.

Question 17:48 - Le problème est, cependant, que la plupart des gens ne le savent pas. Je veux dire, le propriétaire d'entreprise moyen ne sait pas quels liens l'équipe anti-spam sur le Web pourrait... Je veux dire, il y a des directives, mais c'est très... vous savez, c'est difficile de les interpréter. Donc je pense... Je veux dire, j'ai quelques inquiétudes, mais ma principale inquiétude est qu'il y a des gens qui dépensent des tonnes d'argent pour des audits de liens qui, je pense, n'en valent pas la peine. D'un autre côté, nous pouvons ne pas faire d'audits de liens et désavouer certains sites qui pourraient en bénéficier. Donc j'aimerais, vous savez, je pense que ce que vous avez dit a beaucoup aidé pour que nous... vous savez, c'est bien.

Réponse 18:22 - Oui, je pense que pour la grande majorité des sites, ce genre de mélange normal de choses où c'est comme si vous aviez suivi de mauvais conseils dans le passé, et c'est comme si vous aviez évolué, et les choses sont assez naturelles maintenant, alors ils n'ont vraiment pas à le faire. C'est en quelque sorte l'objectif de tout cela, et c'est pourquoi l'outil de désaveu n'est pas comme une fonctionnalité principale de la Search Console. Vous le cherchez explicitement. Tout cela est fait exprès, car pour la plupart des sites, vous n'avez vraiment pas besoin de vous concentrer autant sur les liens. Ce que j'aime un peu à propos de l'outil de désaveu, cependant, c'est que si cela vous inquiète, vous pouvez toujours y aller et dire, OK, je sais qu'il y a comme ces quelques choses que nous avons faites quelques années il y a, et je suis vraiment inquiet à ce sujet. Alors les renier, de mon point de vue, n'est pas un problème. Je n'irais pas chercher spécifiquement tous ces trucs. Mais si vous le savez et que cela vous inquiète vraiment, alors vous pouvez en quelque sorte vous en occuper.

Question 19:27 - J'ai une question concernant l'un de nos sites Web clients. Alors ils ont un club... ils ont un club dans trois villes de la Nouvelle-Galles du Sud. Et chaque club a un sous-domaine sur le site Web. Désormais, lorsqu'ils ajoutent une page à leur site Web, ils créent la page pour chaque sous-domaine. Ainsi, récemment, ils ont ajouté une page, qui concerne les activités de leur club, et ils ont ajouté cette page à leurs - tous les sous-domaines. Cela signifie donc que tous les sous-domaines ont le même contenu, sauf que le titre de la page est différent. Parce que quand ils ajoutent au-- pour Sydney, ils ajoutent leur nom de lieu dans la balise de titre. Lorsqu'ils l'ajoutent pour Newcastle, ils ajoutent Newcastle dans la balise de titre, mais le reste du contenu de la page est le même. Sera-ce donc un problème parce qu'ils ont 50 sous-domaines et qu'ils ont créé 50 pages, qui ont le même contenu sauf le titre ?

Réponse 20:36 - Cela ressemble à quelque chose d'un peu inefficace, je suppose. Donc, je veux dire, vous en parlez déjà et un peu comme dire, cela semble être quelque chose qui pourrait être fait différemment. Je pense que si vous êtes dans le cas où vous avez 50 sous-domaines qui ont tous le même contenu, et que vous changez simplement la balise de titre, alors vous ne nous fournissez probablement pas beaucoup de contenu vraiment utile. C'est donc la situation où je dirais qu'il est plus logique de combiner les choses et de créer des pages vraiment solides plutôt que de diluer les choses dans encore plus de sous-domaines.

Question 21:44 - Qu'en est-il de la création d'une page, puis de l'utilisation d'une URL canonique vers d'autres pages de localisation. Je veux juste créer une page, sur laquelle nous parlerons de leurs activités, et j'utiliserai le lien comme URL canonique vers d'autres pages de localisation.

Réponse 22:10 - Emplacement-- ouais. Je pense que cela pourrait avoir du sens parce qu'alors vous combinez à nouveau les choses. Ensuite, vous créez une page solide plutôt qu'un tas de pages diluées.

Question 22:20 - Parce que ce qui se passe lorsqu'une personne visite le site Web et choisit son emplacement, elle redirige automatiquement cette personne vers le sous-domaine pour lequel elle a indiqué son emplacement. C'est donc la raison pour laquelle ils ont besoin de la page sur ce sous-domaine. Donc je pense que c'est pourquoi si nous gardons une page et ajoutons l'URL canonique, c'est la seule option que nous ayons pour le moment.

Réponse 23:08 - OK, mais je pense que si vous avez des pages séparées dont vous avez besoin pour des raisons techniques sur le site, et que vous mettez canonique, c'est une bonne approche.

Question 23:21 - Serait-ce comme-- comme une entreprise qui a plusieurs franchises dans différents endroits qui auraient essentiellement le même contenu pour chaque franchise serait dans une ville ou un canton différent, ou autre, et une sorte d'entonnoir qui de votre point de vue sur une seule page ?

Réponse 23:34 - Je pense que c'est toujours un peu délicat parce que vous équilibrez les personnes à la recherche de ce type d'entreprise dans un endroit spécifique avec une sorte de page d'information autour de cette entreprise directement. C'est donc quelque chose où il est parfois logique d'avoir cela séparé pour une entreprise. Parfois, il est logique d'avoir une sorte d'informations générales dans un endroit central et d'avoir juste comme des pages de destination de localisation qui sont plus axées sur l'adresse, les heures d'ouverture, ce genre de choses.

Question 24:12 - Oui, j'ai - j'ai une question connexe concernant le point canonique que vous soulevez. C'est une question que mon équipe et moi nous posons depuis plusieurs années. Et nous ne connaissons toujours pas exactement la solution. Donc, si vous gérez un grand site de commerce électronique avec de très nombreux produits et de très nombreuses catégories. Disons que vous êtes sur une page de catégorie qui a beaucoup de filtres et de facettes différents et des choses de cette nature qui modifient légèrement le contenu de la page, mais peut-être pas assez pour justifier d'avoir sa propre URL. Mais peut-être que dans certains cas avec certains filtres, cela justifie d'avoir une URL de site. Alors, comment gérez-vous l'exploration dans cette situation? Par exemple, une balise canonique fonctionne-t-elle ? Est-ce une solution globale pour créer une seule page indexée ? Ou devriez-vous envisager, vous savez, de ne pas indexer certaines facettes et certains filtres, ou d'utiliser des robots, ou comment contrôlez-vous cela pour les grands sites de commerce électronique ?

Réponse 24:57 - C'est délicat. Je ne pense pas que nous ayons des indications vraiment claires à ce sujet pour le moment. C'est donc quelque chose où tous ces différents types de méthodes peuvent avoir un sens. En général, j'essaie d'éviter d'utiliser robots.txt pour cela car ce qui peut arriver, c'est que nous trouvons les URL. Nous ne savons tout simplement pas ce qu'il y a là-bas. Donc, à moins que vous ne voyiez vraiment des problèmes qui causaient trop de charge sur le serveur, j'essaie d'utiliser des choses comme le no index, utilisez le rel canonique. Peut-être que vous utilisez rel no-follow avec des liens internes vers des types d'entonnoirs pour clarifier un peu ce que nous devrions explorer un index plutôt que d'utiliser robots.txt. Mais le genre de décision sur le moment de combiner les choses dans une page au niveau de l'index et quand la bloquer de l'indexation, quand la guider doucement vers une URL canonique, c'est-- c'est parfois très délicat.

Question 25:53 - Parce que parfois les canoniques sont ignorés si le contenu de la page est trop différent.

Réponse 25:57 - Exactement. Si le contenu est différent, alors nous pourrions dire, eh bien, ce sont des pages différentes. Nous ne devrions pas utiliser le canonique. Alors que vous pourriez dire, eh bien, c'est vraiment quelque chose que je ne veux pas voir indexé. Peut-être qu'un sans index aurait plus de sens qu'un canonique. Vous pouvez également combiner les deux. Nous ne recommandons pas de les combiner car il est vraiment difficile pour nous de dire, eh bien, que voulez-vous dire ? Êtes-vous en train de dire que ce sont les mêmes, mais que l'un est indexable et l'autre non indexable, alors ce ne sont pas les mêmes. Mais c'est quelque chose où j'imagine qu'au cours de l'année, nous aurons des indications claires sur ce qui pourrait fonctionner là-bas. Mais surtout avec de très grands sites de commerce électronique, le côté de l'exploration peut être assez difficile.

Question 26:46 - Il y a donc un scénario que j'ai essayé de comprendre avec quelques-uns de mes clients ces derniers temps. Nous essayons de comprendre pourquoi nous ne sommes pas en mesure de jeter essentiellement un site qui utilise toujours HTTP et qui semble plus ou moins abandonné parce que la page n'a pas été mise à jour depuis un certain temps et que le contenu est ancien, obsolète et généralement genre de mince, et donc j'ai quelques théories à ce sujet. Une partie de cela est, je pense, que cela fait peut-être partie de l'index depuis si longtemps que vous avez tous en quelque sorte un facteur de confiance construit avec eux. And it's kind of hard to unseat them. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Question 42:29 - Il s'agissait des sites Web des agences de voyages pour voyager. Nous choisissons la recherche interne pour afficher un contenu dynamique, comme le top 10 des hôtels les moins chers dans la ville de recherche, d'accord ? Ainsi, le cadre de la page se charge en un instant. Mais les résultats des 10 meilleurs hôtels les moins chers se chargent dynamiquement en 30 secondes environ depuis que la recherche a été effectuée, car le site Web doit effectuer cette recherche dans le dos, puis compare et affine les résultats afin de répertorier, pour le chercheur, le top 10 bon marché. hôtels. Il faut donc un peu de temps pour les lister. Donc, pour le moment, Googlebot ne voit que l'arrière-plan de la page. Ensuite, ces 10 espaces réservés vides étaient là où les résultats se chargeront un peu plus tard après la recherche interne. Donc, comme il s'agit d'une tendance pour les sites Web de voyage à fournir des informations aussi fraîches que possible et aussi précises que possible, je pense à ce que Google fait à ce sujet. Bien sûr, nous pouvons répertorier du contenu statique sur ces pages comme tous les autres sites Web le font actuellement pour Google, si je puis dire. Mais ce genre de choses va à l'encontre de ce que la plupart des utilisateurs veulent voir maintenant, frais et bon marché.

Réponse 44:00 - Donc, s'il ne se charge pas ici, nous ne pouvons pas l'indexer. Mais généralement, il s'agit plutôt de ne pas pouvoir traiter le JavaScript ou peut-être d'être empêché d'accéder au contenu qui s'y trouve. C'est donc quelque chose que vous pouvez faire d'une manière qui fonctionnerait. Ce n'est pas par conception que cela ne fonctionnerait jamais. C'est donc quelque chose où vous pouvez creuser dans les détails en utilisant des choses comme le test adapté aux mobiles pour voir s'il y a des erreurs JavaScript impliquées, si des choses sont bloquées, et en quelque sorte l'affiner à partir de là. Ce n'est donc pas impossible, mais cela demande un peu de travail.

Question 44:42 - John, je creuse là-dessus pour m'assurer que rien n'est bloqué par Google. La seule chose que nous voulons que Google fasse, c'est d'attendre un peu que le contenu dynamique se charge sur les pages, vous savez ? C'est la prochaine étape, si je puis dire, car même si cette page n'est pas comme un défilement sans fin, disons Facebook, c'est une page limitée à 10 résultats. Donc c'est fini. C'est limité. Le fait est que Google devrait attendre un peu le contenu dynamique. Je ne vous donne qu'un exemple. Mais je suis sûr qu'il y a beaucoup d'autres exemples dans la nature. Et parce que c'est la tendance des gens à voir du contenu dynamique parce qu'ils trient les choses d'une manière ou d'une autre et qu'ils passent de moins en moins de temps-- les gens passent de moins en moins de temps sur les sites Web, et ils veulent trouver aussi vite que possible le des résultats parfaits, si je puis dire. Je me demandais si vous envisagez cette amélioration.

Réponse 45:55 - Nous attendons donc un peu le rendu. Mais si les gens sont impatients, c'est un signe que vous devriez être plus rapide de toute façon. C'est donc quelque chose que j'examinerais de toute façon. Mais je pense qu'en regardant la capture d'écran, tous les éléments y étaient bloqués dans des cases grises. Cela ressemble donc plus à un problème technique qu'à un simple temps mort.

MARTIN SPLITT : Ouais. J'étais sur le point de dire, comme, nous voyons beaucoup de contenu dynamique qui est indexé sans problème, même s'il utilise comme JavaScript et d'autres choses. Donc, si nous perdons du temps, vous pourriez avoir un problème en termes de durée des recherches, et cela pourrait également se refléter ailleurs. Nous attendons assez longtemps pour que le contenu se termine.

Question 46:48 - Pouvez-vous-- pouvez-vous me donner un délai ? Combien attends-tu ?

MARTIN SPLITT : C'est vraiment, vraiment délicat parce que fondamentalement -- donc le fait est que la raison pour laquelle nous ne pouvons pas vous donner de délai est parce que le temps -- et cela va sembler vraiment bizarre, et supportez-moi une seconde . Le temps passé dans le rendu Googlebots est spécial et ne suit pas nécessairement les principes d'Einstein. [RIRE] Donc je ne peux pas vraiment dire grand-chose. Ce que je peux dire, c'est que si le réseau est occupé et que le réseau est le goulot d'étranglement, nous attendons probablement, mais nous n'attendons que si longtemps. Donc, si vous prenez une minute ou 30 secondes, alors nous perdons probablement du temps entre les deux. Mais il n'y a pas de dur-- si je vous dis 10 secondes, ça peut marcher ou pas. Si je vous dis 30 secondes, cela pourrait ou non fonctionner. Donc je préfère ne pas dire de chiffre. Ce que je dirais, essayez de l'obtenir le plus rapidement possible. Et si vous ne pouvez pas l'obtenir rapidement, essayez quelque chose comme mettre en cache les résultats de la recherche afin que la recherche devienne plus ou moins in-- ou que la production des résultats sur la page devienne de plus en plus-- plus ou moins instantanée. Ou essayez le rendu dynamique de votre côté qui pourrait être une solution de contournement pour cela. Ce que vous pouvez également essayer, c'est que vous pouvez essayer de le placer côté serveur et essayer de générer autant de contenu que possible lors de la première passe. C'est quelque chose qui profite également à vos utilisateurs, surtout s'ils sont sur des réseaux lents. Donc voilà. Désolé, je n'ai pas de réponse simple, mais le temps passé dans Googlebot est génial.

Réponse 49:29 - Je pense que cela dépend probablement de ce que fait réellement le site Web. L'une des choses qui est délicate avec la vitesse de rendu est que nous pouvons mettre en cache beaucoup de choses qui sont envoyées depuis un serveur plus qu'elles ne le seraient dans un navigateur, car nous pouvons utiliser notre index pour beaucoup de ces choses. Donc, parfois, si JavaScript est mis en cache de notre côté, nous n'avons pas à le récupérer. Ensuite, si vous comparez à nouveau les heures, cela ne correspondra pas à ce que l'utilisateur voit. Cela ne correspondra pas à ce que vous voyez dans webpagetest.org. C'est donc vraiment délicat, et pour les parties où nous savons que cela prend plus de temps, nous serons un peu plus patients. Mais c'est compliqué à tester. C'est pourquoi nous avons maintenant tous ces outils de test qui affichent autant d'erreurs que possible pour permettre de comprendre, par exemple, si cela ne fonctionne pas du tout ? Est-ce que ça marche parfois et où sont parfois les problèmes qui surgissent ?

Question 50:29 - Pour les très grands sites Web, l'ordre des URL dans les sitemaps XML est-il important ?

Réponse 50:34 - Non. On s'en fout. C'est un fichier XML. Nous récupérons toutes les données. Nous traitons tout en même temps.

Question 50:44 - Alors qu'en est-il du paramètre de priorité dans les sitemaps ?

Réponse 50:47 - Nous ne l'utilisons pas du tout. C'est donc quelque chose qu'au début, nous avons pensé, oh, cela pourrait être utile pour déterminer la fréquence à laquelle nous devrions explorer les pages. Mais il s'avère que si vous demandez aux webmasters, ils se disent que tout est prioritaire. C'est le plus important. Et similaire aussi avec, je pense, la fréquence des changements dans les sitemaps, où nous remarquons également que, par exemple, les gens nous disent que les choses changent tout le temps, mais il a été mis à jour pour la dernière fois l'année dernière. Donc, si vous avez la fréquence des changements et la date, nous obtiendrons ces informations à partir de la date de toute façon. Nous ignorons donc la fréquence de changement.
Question 51:35 - Le schéma d'entreprise doit-il être ajouté uniquement à la page d'accueil, à la page de contact ou à toutes les pages ?

Réponse 51:42 - Pour autant que je sache, c'est juste la page d'accueil. Je ne sais pas. Est-ce que vous connaissez quelqu'un?

Réponse de Liz 51:4 7 - C'est censé n'être qu'une seule page généralement avec organisationnel et corporatif. C'est généralement la recommandation.

MARTIN SPLITT 52:00 - Je suppose que peu importe quelles pages, tout comme ne pas le mettre sur chaque page que vous avez, je suppose, est la partie la plus importante. Je pense que cela dépend de-- si vous êtes un site d'actualités, il est probablement logique de le mettre dans la page de contact, ou la page à propos, ou quelque chose comme ça. Alors que dans le site Web d'un magasin ou d'un restaurant, il est probablement acceptable de le mettre sur la page d'accueil.

JOHN 52:20 - Je pense aussi, dans ce cas, cela n'a pas autant d'importance pour nous car nous devons pouvoir le trouver quelque part comme la page d'accueil ou la page de contact. Mais si nous l'avons ailleurs, cela ne change rien pour nous. Donc, la grande chose à ne pas comparer est le balisage des avis où nous voyons parfois des gens mettre comme avis d'entreprise sur toutes les pages du site Web dans l'espoir d'obtenir les étoiles et les résultats de recherche pour chaque page de leur site. Et ce serait mauvais pour nous. Mais les informations de contact, si vous les avez annotées, c'est-- Je n'y vois pas de problème.
Question 53:05 - Le test de vitesse du site Web de Google que nous avons utilisé a enregistré des temps de chargement de page très lents, mais les tests indépendants que nous avons effectués avec des collègues à l'étranger ont affiché un temps de chargement de page très rapide. Ce faux enregistrement des mesures de Google affecte-t-il le classement de notre site dans l'algorithme de Google ?

Marie Haynes : Ce n'est pas ma question, mais pour donner un peu de contexte, les nouvelles données de Lighthouse pour la vitesse des pages sont bien plus dures que l'étaient les Page Speed ​​Insights. Donc, quelque chose qui avait un score de 80 sur Page Speed ​​​​Insights pourrait être un 29 rouge sur Lighthouse. C'est donc une bonne question. Est-ce que cela est susceptible de causer-- parce que nous savons que dans les mobiles, les sites très lents pourraient être rétrogradés. Alors est-ce bien si nous disons, vous savez, si vous êtes dans le rouge au test Lighthouse, que nous devrions vraiment améliorer les choses parce que cela pourrait entraîner une rétrogradation, ou y a-t-il une coupure ?

Réponse 54:07 - Nous n'avons donc pas de cartographie individuelle des outils externes et de tout ce que nous utilisons pour les réseaux sociaux. Oui, c'est vraiment difficile à dire, mais dans la recherche, nous essayons d'utiliser un mélange de données réelles, qu'est-ce que c'est, des données de test de laboratoire, qui ressemblent un peu au test Lighthouse, et aux données du rapport Chrome UX, où essentiellement quoi nous mesurons ce que les utilisateurs du site Web verraient.

MARTIN SPLITT 55:37 - Il est également important de voir que Lighthouse, par exemple, mesure spécifiquement une connexion 3G à l'extrémité médiane - ou comme un téléphone à performances moyennes, oui. Donc, fondamentalement, si vous utilisez un Apple McIntosh récent ou un ordinateur Windows rapide récent avec une très bonne connexion filaire ou une très bonne connexion Wi-Fi dans votre bureau, bien sûr, vous voyez un temps de chargement de deux secondes, mais un vrai utilisateur avec son téléphone dans la nature ne le voit probablement pas. C'est donc l'un de ces cas comme si cela ne faisait jamais de mal de rendre votre site Web plus rapide, mais c'est vraiment, vraiment difficile de dire à quoi cela ressemblerait du point de vue de l'intérieur, car nous utilisons des métriques très spécifiques qui ne correspondent pas nécessairement à un à ce que les outils exposent ... bien sûr, il est important de résoudre ce problème, car vous ne voulez pas que vos utilisateurs attendent indéfiniment sur votre site Web. Ça va te faire mal. Cela va nuire à vos utilisateurs. Cela va juste vous blesser dans la recherche. Mais je ne paie pas - je dirais qu'il suffit de regarder les outils. Si les outils vous disent que vous vous débrouillez bien, vous ne devriez pas trop vous en soucier. Si les outils vous disent que vous ne faites vraiment pas bien, alors je pense que le temps passé à comprendre pourquoi cela dit - comme, si ce qu'il dit est pertinent, c'est perdu. Vous devriez plutôt chercher à rendre le site plus rapide.

Les performances mobiles sont un facteur très important pour vos utilisateurs, ainsi que tout le reste. Je dirais donc assurez-vous que votre site Web fonctionne bien dans des conditions réelles. Peut-être même acheter un téléphone bon marché et essayer le site Web de temps en temps, et si... c'est quelque chose que j'aime faire, et que je faisais avant de rejoindre Google avec l'équipe de développement avec laquelle je travaillais. J'étais genre, écoutez, voulez-vous utiliser ce site Web sur ce téléphone ? C'était comme, oh, c'est horrible. Je me dis, mhm, ouais, alors peut-être qu'on devrait faire quelque chose à ce sujet.

JOHN - Dans Chrome, vous pouvez le configurer et essayer différentes vitesses de connexion. Émulateur mobile. Je pense que ce sont de très bonnes choses à regarder, et aussi, comme, regardez votre base d'utilisateurs. Regardez vos données d'analyse si vous voyez que les gens n'utilisent votre site Web qu'avec un iPhone haut de gamme, alors c'est peut-être moins un problème que si vous voyez que les gens se connectent à votre site à partir de connexions rurales aléatoires, qui sont lent, et ils ont des appareils bas de gamme, alors c'est peut-être plus.