8 mars 2019 – Notes de Hangout de l'aide Google

Cette semaine, John répond à quelques bonnes questions concernant la vitesse de la page, le texte d'ancrage, Java Script. Comme toujours, la vidéo complète et la transcription peuvent être trouvées ci-dessous!

Comment le contenu traduit est-il traité ?

0:33

Je pense que c'est bien d'avoir un site Web combiné comme celui-là. Je pense que pour les utilisateurs, il est logique de faire en sorte qu'il reste facile à lire, de sorte que si vous êtes anglophone et que vous visitez votre site Web, ce n'est pas comme un mélange de contenu russe, ukrainien et anglais, mais c'est plutôt tout le contenu en anglais. Ce n'est peut-être pas tout le contenu que vous avez dans différentes langues, mais ça va. Du point de vue du référencement, il est logique de transformer les traductions en contenu de haute qualité. Donc, pas seulement en utilisant Google Translate pour cela. Les outils de traduction s'améliorent encore et encore pour cela, mais c'est quand même si vous le traduisez à la main ou prenez la version google translate et que vous nettoyez cela et le rendez plus lisible, alors c'est mieux. C'est quelque chose que les utilisateurs remarquent et c'est aussi quelque chose que nous remarquons d'un point de vue algorithmique. Si nous pouvons dire qu'il s'agit d'un contenu de très haute qualité, nous le traiterons mieux dans les résultats de recherche.

Résumé : Assurez-vous que votre contenu traduit est lisible dans d'autres langues et pas seulement traduit automatiquement avec Google Traduction. Assurez-vous également que les traductions sont de haute qualité et ont de la valeur pour les utilisateurs.

Si mon site fonctionne sur Javascript et que le temps d'indexation est critique pour le contenu, comment puis-je savoir qu'il faudra attendre pour être indexé ?

3:10

Donc, en général, la première partie est correcte. C'est le cas où nous essayons d'indexer le contenu le plus rapidement possible, ce que nous pouvons si nous avons une version HTML statique, puis l'étape suivante consiste à essayer de rendre la page comme le ferait un navigateur et nous sélectionnons également ce contenu et utilisez-le pour l'indexation. Ces deux éléments combinés fonctionnent généralement ensemble, mais il n'est pas vrai que la version HTML statique soit retardée (artificiellement) jusqu'à ce que la version javascript soit prête. Donc, de ce point de vue, pour la plupart des sites, il n'est pas critique qu'il y ait cette différence et nous n'avons pas de temps explicite qui s'applique au temps qu'il faut pour commencer à rendre une page. Cela peut différer selon le type de page, quand nous l'avons trouvée, comment nous l'avons trouvée, ce qui se passe autour de cette page. Par exemple, si nous pensons que c'est quelque chose qui s'affiche très rapidement dans la recherche, nous essaierons de le rendre immédiatement. C'est donc assez difficile à prendre en compte. Il n'y a pas de numéro fixe là-bas. En général, j'utiliserais cela comme une ligne directrice approximative pour déterminer si vous devez faire quelque chose avec le contenu javascript côté client. Par exemple, si vous avez du contenu d'actualités qui doit être indexé rapidement, je m'assurerais que Google puisse récupérer ce contenu le plus rapidement possible sans avoir à le rendre séparément. Pour les sites d'actualités, en particulier sur les pages sur les sites d'actualités où vous créez un lien vers tous les nouveaux articles, je m'assurerais vraiment que ces pages fonctionnent bien uniquement avec le HTML statique servi aux moteurs de recherche. C'est en quelque sorte la façon dont j'y penserais, pensez à quel point il est essentiel que mon contenu soit indexé immédiatement et non en termes de combien de minutes cela prend-il parce qu'il n'y a pas de temps fixe pour combien de temps cela peut prendre.

Résumé : Pour les sites javascript Google Firsts indexe la page et a ensuite besoin de temps pour traiter le javascript. Il n'y a pas de temps fixe quant au temps que cela prend. Donc, si votre contenu a besoin d'être fréquemment mis à jour, il est préférable de proposer une version HTML statique de la page.

Quelles sont les principales différences entre l'outil d'inspection d'URL et le test adapté aux mobiles, s'ils récupèrent tous les deux des pages du serveur en direct ?

9:16

Donc, l'idée avec le test adapté aux mobiles est simplement de tester si cette version est un ami mobile, c'est donc en quelque sorte l'objectif principal. Et l'outil d'inspection d'URL, l'outil de test en direct, est davantage destiné à voir "comment cette page se comporterait-elle en indexation ?", Il vérifie des choses, je pense, comme le code de réponse sans index, le genre de choses habituelles qui s'appliqueraient pour savoir si nous prenons cette page et la mettons dans notre index ou non. Le test adapté aux mobiles est principalement axé sur le côté mobile et l'outil d'inspection d'URL est comme ce grand couteau de poche avec différentes fonctionnalités que vous pouvez utiliser pour différentes choses.

Résumé : Le test adapté aux mobiles consiste à voir dans quelle mesure le site fonctionnerait sur mobile tandis que l'outil d'inspection d'url vérifie si l'indexation fonctionne comme il se doit, comme aucun code de réponse d'index.

Je pense diviser mes pages de produits sur mon site de commerce électronique. Actuellement, ils sont configurables sur une seule page avec plusieurs variantes affichées. Quelles sont vos recommandations ?

18:00

Je pense que l'aspect que j'examinerais davantage est de savoir s'il est vraiment logique de diviser ces produits en pages distinctes, car ce que vous négociez est une page de produit assez forte pour ce produit et toutes les variations, par rapport à plusieurs pages qui doivent en quelque sorte travailler par eux-mêmes et être soutenus par eux-mêmes. Ainsi, au lieu d'avoir une page vraiment forte pour les "chaussures de course", vous avez plusieurs pages qui doivent se battre pour des "chaussures de course bleues", "chaussures de course rouges", "chaussures de course vertes". Donc, si quelqu'un recherche des "chaussures de course", ces petites pages ne sont vraiment pas aussi solides que la page de produit que vous avez pour ce produit principal. Donc, mon conseil général est de dire, si vous pensez que ces variations ne sont que des attributs des produits principaux, dans la mesure où les gens ont tendance à rechercher le contenu principal, puis à dire "oh, quelle couleur est-ce que je veux, c'est comme si j'avais trouvé le produit Je veux, mais je dois juste choisir la couleur que je veux. alors je les mettrais sur une page partagée. Alors que si les gens recherchent explicitement cette variation et que cette variation est vraiment unique et se démarque d'elle-même et que les gens ne viennent pas sur votre site en disant simplement "Je veux des chaussures de course" mais plutôt "Je veux ce type spécifique de chaussures de course chaussures de cette couleur », alors c'est peut-être quelque chose qui vaut la peine d'être retiré en tant que produit séparé.

Résumé : À moins que les variantes du produit ne se démarquent d'elles-mêmes et que les internautes recherchent cette variante spécifique, il est préférable de les conserver toutes sur une seule et même page. De cette façon, les différentes variantes des pages de produits ne se font pas concurrence.

La vitesse est-elle importante pour la version mobile de votre site ?

21:00

Donc, la bonne partie est que nous avons beaucoup de facteurs de classement, vous n'avez donc pas toujours à tout faire parfaitement. Mais cela signifie également que vous rencontrez des situations comme celle-ci où vous dites "Google dit que la vitesse est importante, mais les meilleurs sites ici ne sont pas si rapides, donc cela ne doit pas être important". Pour nous, c'est certainement important, mais cela ne signifie pas qu'il remplace tout le reste. Vous pouvez imaginer que la page la plus rapide à laquelle vous pourriez penser est probablement une page vide. Mais une page vide serait un résultat de recherche vraiment terrible si vous recherchiez quelque chose de vraiment spécifique. C'est vraiment rapide mais il n'y a pas de contenu là-bas, donc l'utilisateur ne serait pas content. Nous devons donc équilibrer tous ces facteurs, le contenu, les liens et tous ces signaux et essayer de comprendre comment faire le classement en fonction de ce mélange de différents facteurs que nous avons. Et ça change aussi avec le temps, ça peut changer assez rapidement. Par exemple, si quelque chose est vraiment intéressant pour le moment, nous pouvons choisir de montrer à des sites légèrement différents quelque chose qui relève davantage d'un sujet de recherche à feuilles persistantes.

Résumé : La vitesse n'est qu'un des facteurs de classement utilisés par Google. Ce n'est pas parce que les meilleurs sites ne sont pas rapides que cela n'est pas important pour votre site.

Quel type de balisage de schéma est préférable pour Google, devrions-nous utiliser JSON ou des micro-données, des formats micr. Lequel est préférable ?

22:30

Nous préférons actuellement le balisage JSON-LD. Je pense que la plupart des nouveaux types de données structurées sortent d'abord pour JSON-LD, c'est donc ce que nous préférons.

Résumé : JSON-LD est préféré par Google.

Quelle est l'importance du texte d'ancrage ?

25:10

Donc, je pense que tout d'abord, je ne m'inquiéterais pas trop des brevets de Google, nous brevetons beaucoup de choses qui ne s'appliquent pas nécessairement à ce que les maîtres de sites Web doivent faire. Je pense donc qu'il est intéressant de voir sur quoi nos ingénieurs travaillent, mais cela ne signifie pas nécessairement que nous serons immédiatement affectés par cela. En ce qui concerne le texte d'ancrage en général, nous l'utilisons pour le texte. C'est quelque chose que nous captons. C'est un excellent moyen de nous donner le contexte d'un lien. En particulier sur votre site Web, si vous avez un lien qui dit simplement "cliquez ici pour plus d'informations", cela ne nous est pas très utile. Là où vous avez un lien qui dit "vous pouvez trouver plus d'informations sur cette page de produit" et un lien avec ce nom de produit vers cette page, cela nous dit que cette page concerne peut-être vraiment ce produit. Je continuerais donc certainement à regarder votre texte d'ancrage que vous utilisez, en particulier en interne sur votre site Web, et j'essaierais de m'assurer que vous fournissez un texte d'ancrage qui est vraiment utile et fournit un contexte à ce qui est lié sur la page.

Résumé : Le texte d'ancrage est très important car il fournit à Google un contexte sur le sujet de la page. Un texte d'ancrage tel que "Cliquez ici pour plus d'informations" ne fournit pas beaucoup d'informations à Google, mais un texte d'ancrage tel que "Vous pouvez trouver plus d'informations sur cette page de produit" indique à Google que cette page concerne cette page de produit.

Notre note : si vous créez vos propres liens, le fait d'avoir trop de liens de mots-clés peut éventuellement alerter l'équipe anti-spam si vous faites l'objet d'un examen manuel.

Comment Google voit-il visuellement votre page ?

39:00

Nous essayons de regarder la page visuellement, mais surtout en ce qui concerne le contenu réel au-dessus du pli ou l'espace au-dessus du pli juste une publicité géante. C'est un peu ce sur quoi nous nous concentrons, également en ce qui concerne la convivialité mobile, nous essayons de cartographier visuellement une page et de voir, est-ce une page qui fonctionnerait bien sur un appareil mobile. Et pour cela, nous devons en quelque sorte tracer la page, ce n'est pas grave si certains éléments sont illisibles tant qu'ils fonctionnent sur un appareil mobile. Si ces liens sont là, qu'ils ont la bonne taille et que les gens peuvent cliquer dessus, alors c'est parfaitement bien. Si vous faites une transformation CSS sophistiquée pour transformer cela en texte 3D, cela dépend entièrement de vous. L'important est que le texte lui-même soit visible sur la page et que vous ne fassiez pas trop de balisage fantaisiste pour diviser ce texte. Donc, à titre d'exemple, si vous avez un titre dans l'ancien système où vous avez une mise en page basée sur un tableau et que vous vouliez diviser la guérison en haut, il semble que les gens mettent des lettres individuelles dans des cellules de tableau individuelles et de notre point de vue, cela fait il est pratiquement impossible de voir qu'il s'agit en fait d'un mot car vous utilisez le balisage pour le diviser en morceaux déconnectés. Du point de vue de l'analyse de la page, c'est vraiment délicat.

Résumé : Google essaie principalement de voir si le contenu réel est au-dessus du pli et pas seulement une publicité géante. En termes de convivialité mobile, Google essaie de comprendre si les mêmes liens sont là, si tout est de la bonne taille et si les gens peuvent cliquer sur ces liens. Le plus important est de savoir si le texte lui-même est visible sur la page.

Pouvez-vous échanger une URL avec Javascript ?

43:00

Oui, nous pouvons le récupérer. La partie importante, je pense, est que l'URL doit être échangée après le chargement de la page. Il ne doit pas être échangé lorsqu'un utilisateur effectue une action spécifique. Ainsi, par exemple, si un utilisateur survole un lien et que vous utilisez JavaScript pour échanger l'URL, cela ne serait pas quelque chose que nous remarquerions ou si un utilisateur clique sur un lien et que vous utilisez ensuite JavaScript pour échanger l'URL, alors cela ne serait pas non plus quelque chose que nous remarquerions. Mais si la page se charge et que vous exécutez du JavaScript qui nettoie l'URL afin qu'elle soit liée aux versions canoniques appropriées, c'est parfaitement bien et un peu comme nous en avons parlé au début en ce qui concerne le rendu, parfois cela prend un peu de temps. Ce n'est donc pas une chose immédiate que nous pourrions prendre ou il est probable que nous prendrions ces deux versions à la fois le lien original que vous aviez là-bas ainsi que la version JavaScript. Il ne serait donc pas possible que les anciennes versions disparaissent complètement.

Résumé : Google peut détecter si une URL a été échangée après le chargement d'une page. La seule chose à savoir est de s'assurer que l'URL n'est pas échangée lorsqu'un utilisateur effectue une action spécifique.

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.

Question 0:33 - Question sur la traduction. Je sais que si je traduis du contenu anglais en russe ou en ukrainien, la plupart des gens n'utilisent que la traduction de Google et insèrent simplement le contenu. Mais c'est comme si 90% de celui-ci avait besoin d'être corrigé si vous le lisiez en tant que locuteur natif. Je suis intéressé par deux points. Si je veux créer une autre version ou une autre langue de mon site Web, comme l'anglais, le russe ou l'ukrainien, est-ce que ça va ? Deuxième, si je trouve un article intéressant sur ma niche et que je veux le traduire, est-ce bien ou pas ? Dois-je le rendre adaptatif pour les lecteurs nationaux ?

Réponse 1:38 - Je pense que c'est bien d'avoir un site Web combiné comme celui-là. Je pense que pour les utilisateurs, il est logique de faire en sorte qu'il reste facile à lire, de sorte que si vous êtes anglophone et que vous visitez votre site Web, ce n'est pas comme un mélange de contenu russe, ukrainien et anglais, mais c'est plutôt tout le contenu en anglais. Ce n'est peut-être pas tout le contenu que vous avez dans différentes langues, mais ça va. Du point de vue du référencement, il est logique de transformer les traductions en contenu de haute qualité. Donc, pas seulement en utilisant Google Translate pour cela. Les outils de traduction s'améliorent encore et encore pour cela, mais c'est quand même si vous le traduisez à la main ou prenez la version google translate et que vous nettoyez cela et le rendez plus lisible, alors c'est mieux. C'est quelque chose que les utilisateurs remarquent et c'est aussi quelque chose que nous remarquons d'un point de vue algorithmique. Si nous pouvons dire qu'il s'agit d'un contenu de très haute qualité, nous le traiterons mieux dans les résultats de recherche.

Question 3:10 - Google explore et indexe le contenu en deux étapes. Le premier est le rendu côté serveur et le second est le rendu côté client, selon les déclarations précédentes, cela peut prendre des jours ou des semaines pour que ce processus soit terminé. Pour les sites utilisant Javascript, ils peuvent rencontrer de sérieux problèmes si l'indexation est urgente. Comment puis-je savoir combien de temps cela va prendre?

Réponse 3:46 - Donc, en général, la première partie est correcte. C'est le cas où nous essayons d'indexer le contenu le plus rapidement possible, ce que nous pouvons si nous avons une version HTML statique, puis l'étape suivante consiste à essayer de rendre la page comme le ferait un navigateur et nous sélectionnons également ce contenu et utilisez-le pour l'indexation. Ces deux éléments combinés fonctionnent généralement ensemble, mais il n'est pas vrai que la version HTML statique soit retardée (artificiellement) jusqu'à ce que la version javascript soit prête. Donc, de ce point de vue, pour la plupart des sites, il n'est pas critique qu'il y ait cette différence et nous n'avons pas de temps explicite qui s'applique au temps qu'il faut pour commencer à rendre une page. Cela peut différer selon le type de page, quand nous l'avons trouvée, comment nous l'avons trouvée, ce qui se passe autour de cette page. Par exemple, si nous pensons que c'est quelque chose qui s'affiche très rapidement dans la recherche, nous essaierons de le rendre immédiatement. C'est donc assez difficile à prendre en compte. Il n'y a pas de numéro fixe là-bas. En général, j'utiliserais cela comme une ligne directrice approximative pour déterminer si vous devez faire quelque chose avec le contenu javascript côté client. Par exemple, si vous avez du contenu d'actualités qui doit être indexé rapidement, je m'assurerais que Google puisse récupérer ce contenu le plus rapidement possible sans avoir à le rendre séparément. Pour les sites d'actualités, en particulier sur les pages sur les sites d'actualités où vous créez un lien vers tous les nouveaux articles, je m'assurerais vraiment que ces pages fonctionnent bien uniquement avec le HTML statique servi aux moteurs de recherche. C'est en quelque sorte la façon dont j'y penserais, pensez à quel point il est essentiel que mon contenu soit indexé immédiatement et non en termes de combien de minutes cela prend-il parce qu'il n'y a pas de temps fixe pour combien de temps cela peut prendre.

Question 6:17 - Et maintenant, nous avons une longue question géante sur la compréhension du type de signalement dans la console de recherche, comme lorsque nous signalons quelque chose comme "Google en double choisit un canonique différent de celui de l'utilisateur" ou "URL soumise en double et non sélectionnée comme problèmes canoniques .

[L'utilisateur sonne] Il s'agit d'une page Javascript. Il est pré-rendu, tout le contenu est dans le HTML statique et pourtant Google essaie toujours d'exécuter la page. Et nous constatons dans cet environnement de commerce électronique que ces pages de produits uniques avec des descriptions uniques et un contenu significatif sont signalées comme Google en tant que contenu en double. Nous supposons que cela est dû à une sorte d'échec de rendu JavaScript, où Googlebot continue de voir la même page d'erreur ou quelque chose comme ça et pense donc qu'il s'agit de doublons - comment pouvons-nous comprendre ce que c'est que le service de rendu Web se retrouve avec ça peut entraîner un contenu en double pour Google bot.

Réponse 7:43 - Je devrais regarder quelques exemples réels, donc si vous pouviez m'envoyer des exemples qui seraient vraiment utiles.

Question 8:00 - Google est-il au courant d'un problème persistant ?

Réponse 8:00 - Non… J'ai entendu certains sites s'en plaindre plus que d'autres, donc si vous m'envoyez quelques exemples, ce serait utile.

Question 8:24 - Si une URL est signalée, est-il possible de voir quoi que ce soit sur le rendu qui s'est produit au moment de cette analyse. Existe-t-il un moyen de voir les erreurs de chargement des ressources qui se sont produites dans celle qui a été indexée ? Vous n'avez pas cette interface utilisateur dans la console de recherche, ou du moins je ne peux pas y accéder. Et ou y a-t-il un endroit où nous pouvons voir à quoi ressemble réellement le contenu au moment où l'indexeur et/ou le détecteur de doublons le regarde

Réponse 8:41 - Pas pour le moment. C'est quelque chose qui aurait beaucoup de sens. Pour la plupart des sites, ce n'est pas critique. Mais dans un cas comme celui-ci, ce serait utile d'avoir.

Question 9.16 - Question suivante. Test adapté aux mobiles. Vous y avez fait référence plusieurs fois pour comprendre comment l'indexeur verrait le contenu. Cependant, nous constatons qu'il existe de nombreuses autres erreurs étiquetées dans le chargement des ressources et la vitesse à laquelle ces erreurs se produisent semble varier d'un domaine à l'autre. Alors première question, les erreurs que l'on voit dans le test mobile friendly sont-elles représentatives des erreurs que le service rencontrerait lors de l'indexation ? Ou existe-t-il différentes allocations de ressources pour le test MF ?

Réponse 10:04 - Je pense donc que vous faites spécifiquement référence aux ressources intégrées qui sont utilisées pour le test, n'est-ce pas ? Comme les fichiers JS CSS différentes réponses ce genre de chose ? Je pense que l'un des aspects est un peu compliqué pour le moment dans le sens où nous avons des priorités différentes pour le test convivial mobile par rapport au bot Google normal. Nous essayons d'extraire les ressources le plus rapidement possible du serveur en direct et pendant l'indexation, nous mettons en cache une grande partie des ressources et prenons simplement la version en cache de la page. Donc, ce que vous pourriez voir dans le test adapté aux mobiles, c'est que nous essayons de rendre cette page aussi rapidement que possible et que nous pouvons obtenir beaucoup de ces ressources, mais pour certaines d'entre elles, nous expirons essentiellement avec essentiellement la capacité de tirer cela en direct de le serveur. C'est donc pour une grande partie certaines des erreurs que vous voyez avec le test adapté aux mobiles. Je crois aussi que dans l'outil d'inspection d'url si vous utilisez un test en direct, nous essayons de tout tirer en direct et parfois ce n'est tout simplement pas possible de le faire en direct. Et pour l'indexation, nous avons beaucoup plus, un peu plus de temps, dont nous disposons pour cela. Donc, si nous voyons que ces ressources sont nécessaires, nous les extrairons, nous les mettrons en cache et nous essaierons de les avoir à disposition lorsque nous essaierons de faire le rendu. C'est donc quelque chose que nous n'avons pas besoin de faire en direct, donc si cela prend un peu plus de temps pour le faire, nous serons patients et attendrons que tout cela se réunisse. Il y a toujours un aspect du temps qui passe, c'est que ces ressources sont toutes telles que nous ne pouvons pas les mettre en cache (par exemple, l'ID de session et toutes les URL JS), ce qui nous oblige vraiment à conserver une version en cache et réutilisez-le plus tard, alors ce sont ceux que nous pourrions, je ne sais pas, pour une raison quelconque, ne pas être en mesure de récupérer pour l'indexation. En bref, je pense qu'il est difficile de diagnostiquer des problèmes comme celui-ci, surtout si vous avez beaucoup de ressources intégrées. Les directives que je reçois généralement de l'équipe d'ingénierie sont que nous devrions simplement dire aux gens d'avoir moins de ressources intégrées et ils ont tendance à ne pas rencontrer ce problème. Ce n'est pas toujours aussi facile, donc, mais en général, ce que je ferais, c'est de prendre le test adapté aux mobiles comme un guide approximatif, donc si cela fonctionne dans le MTF, vous êtes définitivement du bon côté. Si vous voyez d'autres choses expirer avec cette autre erreur, nous pouvons toujours l'utiliser pour l'indexation.

Question 12:57 - Vous l'avez abordé, je suppose, tangentiellement, devrions-nous être conscients de tout délai d'attente dur ou arbitraire sur le rendu par le service de rendu Web. Y a-t-il une clarté sur le contenu réellement utilisé si une page prend beaucoup de temps à être rendue par Googlebot dans le service de rendu. Est-ce qu'il abandonne et utilise le contenu de la page html qui était là à l'origine ? Avons-nous des éclaircissements sur jusqu'où vous pouvez vous retrouver dans le processus de rendu ?

Réponse 13:45 - pour la plupart, si quelque chose se casse ou s'arrête, nous prenons juste un instantané sur-le-champ. Alors oui… Je pense que dans votre cas, si vous pré-rendez le contenu, il ne devrait pas y avoir de problème car le contenu est là. Ce que nous voyons parfois avec les sites de commerce électronique ou avec des sites qui utilisent un cadre très basé sur des modèles, c'est que nous nous heurtons à des situations où nous supposons qu'il y a du contenu en double avant de tester réellement les URL. Cela peut donc arriver si nous voyons, par exemple, un modèle d'URL. Si nous accédons à un tas d'urls avec des modèles différents ou des paramètres différents par exemple, et que nous voyons que toutes ces urls mènent au même contenu, alors notre système pourrait dire "ok eh bien ce paramètre n'est pas si pertinent pour le site Web après all » et nous avons alors tendance à supprimer ces URL et nous dirions « cet ensemble d'URL est probablement le même que cet autre ensemble d'URL que nous avons déjà exploré ». Donc, en particulier, si vous avez des choses quelque part, voyons, un exemple que j'ai vu un peu est si vous avez beaucoup de sites Web de commerce électronique différents et qu'ils vendent tous les mêmes produits - donc tout le chemin après la partie produit de les urls sont les mêmes sur un grand nombre de domaines - alors notre système dira "toutes ces urls sont les mêmes, elles mènent toutes au même produit" donc nous pourrions aussi bien indexer l'un de ces domaines au lieu de tous de ces domaines. Je ne sais pas si cela s'appliquerait à votre cas, donc je ne sais pas si cela est utile, mais c'est l'une de ces choses où nos systèmes essaient d'optimiser ce que nous trouvons sur le Web et nous supposons que d'autres personnes faire des erreurs aussi sur le web et nous essayons de contourner cela. Nous voyons "toutes ces personnes créent des doublons, mais nous n'avons pas besoin d'explorer tous ces doublons" afin que nous puissions nous concentrer sur ce que nous pensons être les URL réelles.

Question 16:22 - Pour reprendre le test convivial mobile et le test en direct sur l'outil d'inspection d'url. Lors d'un test adapté aux mobiles, Googlebot essaie de récupérer une page du serveur en direct, alors en quoi est-il différent de l'outil d'inspection d'URL avec cette fonctionnalité ? En quoi le rendu est-il différent ou la récupération des pages et des ressources

Réponse 17:04 - Donc, l'idée avec le test adapté aux mobiles est simplement de tester si cette version est un ami mobile, c'est donc en quelque sorte l'objectif principal. Et l'outil d'inspection d'URL, l'outil de test en direct, est davantage destiné à voir "comment cette page se comporterait-elle en indexation ?", Il vérifie des choses, je pense, comme le code de réponse sans index, le genre de choses habituelles qui s'appliqueraient pour savoir si nous prenons cette page et la mettons dans notre index ou non. Le test adapté aux mobiles est principalement axé sur le côté mobile et l'outil d'inspection d'URL est comme ce grand couteau de poche avec différentes fonctionnalités que vous pouvez utiliser pour différentes choses.

Question 18:00 - Sur le site de commerce électronique de nos clients, certains produits sont vendus comme configurables, ce qui signifie que plusieurs variantes différentes du produit sont affichées et gérées sur la même page. Nous envisageons de diviser ces pages afin qu'elles aient chacune leur propre page de produit distincte avec une toute nouvelle URL. Les avis des clients seraient alors déplacés de l'ancienne page vers les nouvelles plus simples. Le fait que l'ancienne revue ait une date plus ancienne que la nouvelle date de création pourrait-il être marqué comme un SEO black hat ?

Réponse 18:37 - Donc, je ne vois aucun problème avec les critiques, tant que vous pouvez continuer à ajouter de nouvelles critiques à ces pages de produits. Je pense que l'aspect que j'examinerais davantage est de savoir s'il est vraiment logique de diviser ces produits en pages distinctes, car ce que vous négociez est une page de produit assez forte pour ce produit et toutes les variations, par rapport à plusieurs pages qui doivent en quelque sorte travailler par eux-mêmes et être soutenus par eux-mêmes. Ainsi, au lieu d'avoir une page vraiment forte pour les "chaussures de course", vous avez plusieurs pages qui doivent se battre pour des "chaussures de course bleues", "chaussures de course rouges", "chaussures de course vertes". Donc, si quelqu'un recherche des "chaussures de course", ces petites pages ne sont vraiment pas aussi solides que la page de produit que vous avez pour ce produit principal. Donc, mon conseil général est de dire, si vous pensez que ces variations ne sont que des attributs des produits principaux, dans la mesure où les gens ont tendance à rechercher le contenu principal, puis à dire "oh, quelle couleur est-ce que je veux, c'est comme si j'avais trouvé le produit Je veux, mais je dois juste choisir la couleur que je veux. alors je les mettrais sur une page partagée. Alors que si les gens recherchent explicitement cette variation et que cette variation est vraiment unique et se démarque d'elle-même et que les gens ne viennent pas sur votre site en disant simplement "Je veux des chaussures de course" mais plutôt "Je veux ce type spécifique de chaussures de course chaussures de cette couleur », alors c'est peut-être quelque chose qui vaut la peine d'être retiré en tant que produit séparé. C'est donc la distinction dont je m'inquiéterais peut-être - je ne m'inquiéterais pas tellement de la partie des critiques.

Question 20:36 La fonctionnalité du nouveau schéma de balisage de la console de recherche est-elle restée la même que dans l'ancienne ?

Réponse 20:50 Je ne sais pas quels sont les plans exacts pour la nouvelle console de recherche en ce qui concerne les fonctionnalités de données structurées, mais nous prévoyons de prendre en charge toutes ces fonctionnalités de données structurées. Donc, ce qui pourrait arriver, c'est que ces fonctionnalités se retrouvent dans la console de recherche d'une manière légèrement différente.

Question 21:00 Qu'en est-il de la vitesse pour la version mobile, est-il crucial d'avoir une vitesse dans la zone verte et si oui, pourquoi beaucoup des meilleurs sites sont-ils encore si lents ?

Réponse 21:20 : Donc, la bonne partie est que nous avons beaucoup de facteurs de classement, donc vous n'avez pas toujours à tout faire parfaitement. Mais cela signifie également que vous rencontrez des situations comme celle-ci où vous dites "Google dit que la vitesse est importante, mais les meilleurs sites ici ne sont pas si rapides, donc cela ne doit pas être important". Pour nous, c'est certainement important, mais cela ne signifie pas qu'il remplace tout le reste. Vous pouvez imaginer que la page la plus rapide à laquelle vous pourriez penser est probablement une page vide. Mais une page vide serait un résultat de recherche vraiment terrible si vous recherchiez quelque chose de vraiment spécifique. C'est vraiment rapide mais il n'y a pas de contenu là-bas, donc l'utilisateur ne serait pas content. Nous devons donc équilibrer tous ces facteurs, le contenu, les liens et tous ces signaux et essayer de comprendre comment faire le classement en fonction de ce mélange de différents facteurs que nous avons. Et ça change aussi avec le temps, ça peut changer assez rapidement. Par exemple, si quelque chose est vraiment intéressant pour le moment, nous pouvons choisir de montrer à des sites légèrement différents quelque chose qui relève davantage d'un sujet de recherche à feuilles persistantes.

Question 22:30 Quel type de balisage de schéma est préférable pour Google, devrions-nous utiliser JSON ou des micro-données, des formats micr. Lequel est préférable ?

Réponse 22:48 Nous préférons actuellement le balisage JSON-LD. Je pense que la plupart des nouveaux types de données structurées sortent d'abord pour JSON-LD, c'est donc ce que nous préférons.

Question 23:00 Google a-t-il effectué des mises à jour importantes en février ou mars ?

Réponse : 23:15 Je ne sais pas, je veux dire que nous faisons des mises à jour tout le temps. Je ne sais pas ce que vous considérez comme lourd. Cela dépend probablement de votre site Web. Si votre site Web a été fortement affecté par l'une de ces mises à jour, vous pensez probablement qu'il est assez lourd. Si nous regardons le Web dans son ensemble, c'est peut-être comme si normalement les changements se produisaient toujours.

Question 23:24. Que signifie le contenu fin pour les sites Web affiliés ?

Réponse 23:34 Le contenu léger ne signifie rien de différent pour les sites affiliés par rapport à tout autre site Web. Ce que nous avons vu, en particulier avec les sites Web affiliés, il y a cette tendance à simplement prendre le contenu d'un flux parce que c'est vraiment facile à faire. Vous pouvez obtenir des scripts qui le font pour vous assez rapidement, c'est facile à faire, vous n'êtes pas deux pour faire beaucoup de travail, cela crée beaucoup d'URL. Mais bien sûr, pour les utilisateurs et pour nous, ce n'est pas vraiment intéressant parce que vous fournissez déjà la même chose que tout le monde.

Question 24:40 Le contenu caché dans les onglets est-il un problème pour l'indexation ?

Réponse 24:50 En général ce n'est pas un problème pour l'indexation. Cela peut être un problème pour les utilisateurs, donc s'il y a du contenu là-bas que vous pensez que les utilisateurs ont vraiment besoin de voir pour convertir, ce serait un peu problématique de votre point de vue. En ce qui concerne l'indexation, nous pouvons récupérer ce contenu et le montrer, donc c'est moins problématique.

Question 25:10 Le texte d'ancrage est-il toujours un facteur de classement important en 2019 ? Beaucoup d'entreprises ont fait des études qui indiquent qu'il n'y a pas de corrélation. Et puis il y a un lien vers un brevet de Google.

Réponse 25:30 Donc, je pense tout d'abord, que je ne m'inquiéterais pas trop des brevets de Google, nous brevetons beaucoup de choses qui ne s'appliquent pas nécessairement à ce que les webmestres doivent faire. Je pense donc qu'il est intéressant de voir sur quoi nos ingénieurs travaillent, mais cela ne signifie pas nécessairement que nous serons immédiatement affectés par cela. En ce qui concerne le texte d'ancrage en général, nous l'utilisons pour le texte. C'est quelque chose que nous captons. C'est un excellent moyen de nous donner le contexte d'un lien. En particulier sur votre site Web, si vous avez un lien qui dit simplement "cliquez ici pour plus d'informations", cela ne nous est pas très utile. Là où vous avez un lien qui dit "vous pouvez trouver plus d'informations sur cette page de produit" et un lien avec ce nom de produit vers cette page, cela nous dit que cette page concerne peut-être vraiment ce produit. Je continuerais donc certainement à regarder votre texte d'ancrage que vous utilisez, en particulier en interne sur votre site Web, et j'essaierais de m'assurer que vous fournissez un texte d'ancrage qui est vraiment utile et fournit un contexte à ce qui est lié sur la page.

Question 27:00 Pouvez-vous nous dire comment fonctionne le processus DMCA ?

Réponse 27:01 Je ne peux pas vous dire comment cela fonctionne car je ne connais pas les détails à ce sujet et c'est aussi un processus légal et je ne peux pas vous donner de conseils juridiques.

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

Réponse 47:54 - Ces deux méthodes fonctionnent. Ainsi, le fichier sitemap nous aide à mieux comprendre les pages nouvelles et modifiées sur un site Web. Ce n'est pas un facteur de classement, donc vous ne serez pas mieux classé simplement parce que vous avez un fichier de plan de site, cela nous aide à comprendre lesquelles de ces pages sont disponibles sur un site Web, mais pour la plupart, en particulier pour les petits sites, nous pouvons simplement les explorer normalement ainsi et il n'y a pas de grande différence en ce qui concerne la façon dont un site est affiché dans la recherche si nous pouvons l'explorer normalement ou si nous l'explorons avec un fichier sitemap. Donc, un fichier de plan de site n'est certainement pas critique pour les grands sites si vous modifiez des éléments de contenu qui sont parfois un peu plus bas dans le site, alors évidemment un fichier de plan de site nous aide à trouver ces changements beaucoup plus rapidement mais si vous venez de commencer un blog, vous n'avez pas nécessairement besoin d'avoir un fichier sitemap.

Question 48:50 - Nous revendons des hôtels en Grèce via notre site Web, nous avons développé une bonne section conviviale pour les hôtels, mais nous dupliquons également le contenu et les titres de ces hôtels car nous intégrons des vidéos YouTube de ces hôtels. Est-ce nocif pour nous ?

Réponse 49:10 - Eh bien, je pense que cela revient aux autres questions que nous avions sur le contenu dupliqué. Dupliquer le contenu où vous devez vraiment vous concentrer pour vous assurer que vous avez quelque chose d'unique sur votre site Web si vous fournissez vraiment la même chose sur de nombreux sites Web différents, alors il est très difficile pour nous de dire bien c'est en fait un site Web dont nous avons besoin pour afficher les résultats de la recherche. C'est donc quelque chose pour lequel je recommanderais de prendre du recul et de réfléchir à ce que vous pourriez faire pour vous assurer que votre site est vraiment unique et convaincant en soi plutôt que la même chose que tous ces autres sites Web.

Question 50:00 - Si une histoire a été redirigée parce qu'il s'agissait d'un contenu léger et qu'il datait de plusieurs années, les effets négatifs de l'article sont-ils en quelque sorte transmis avec la redirection ?

Réponse 50:12 - Non pas nécessairement. Donc, surtout en ce qui concerne le contenu, nous examinons le contenu que nous trouvons sur la page ultime sur laquelle nous atterrissons. Donc, si vous avez supprimé du contenu, si vous avez nettoyé quelque chose et je suppose que cela se produit automatiquement. si vous redirigez cette page et que l'ancien contenu n'est plus là et que nous n'avons que le nouveau contenu, c'est parfaitement bien. Ce ne serait donc pas quelque chose qui serait en quelque sorte poursuivi.

Question 50:45 - Est-il naturel que la console de recherche signale que des erreurs adaptées aux mobiles sont dans la sous-version de test d'une page lorsque nous avons associé la version adaptée aux mobiles d'une page avec le lien rel alternate' act

Réponse 50:57 - Cela signifie donc généralement que nous ne comprenons pas clairement lesquelles de ces pages vont ensemble. Donc, pour une raison ou une autre, nous indexions ces pages individuellement plutôt que comme une paire où nous savons que cette page de bureau appartient à cette page mobile. Cela indiquerait peut-être une incompatibilité avec la façon dont vous avez configuré le lien alternatif ou le lien canonique rel sur ces pages. Donc, j'examine cela aussi et l'autre chose bien sûr est que j'examinerais également ce qu'il faudrait pour passer à une conception réactive, car en particulier avec un premier index mobile, tous ces types de problèmes où nous avons un mobile séparé Les URL rendent tout inutilement compliqué. Alors que si vous pouvez passer à une conception réactive ou à une conception qui utilise simplement les mêmes URL pour les versions de bureau et mobiles. Que vous vous épargnez tellement de problèmes, alors au lieu de suivre ce genre de problème, prenez peut-être le temps de dire, d'accord, je devrais investir dans un plan pour passer à une conception réactive afin que je n'aie pas à me concentrer sur ceux-ci plus de problèmes à l'avenir.

Question 1:01:01- Est-ce une bonne idée d'ajouter un lien nofollow au lien wikipedia et aux articles d'aide de google comme les autres liens externes ? Et combien de temps prend un bon surligneur de données pour prendre effet dans une recherche ?

Réponse 1:01:16 - Skay ajoute donc du nofollow aux liens Wikipédia. Je ne pense pas que cela ait beaucoup de sens à moins que Wikipedia ne vous paie pour placer ces liens. Donc, j'ajouterais un nofollow aux liens que vous ne voulez pas associer à votre site Web. Mais sinon, s'il s'agit d'un lien normal dans le contenu et que je regarderais normalement, à moins que Wikipedia ne vous paie pour ces liens, je penserais simplement normalement, je suppose. Et pour le surligneur de données, ce qui se passe est une sorte de processus algorithmique qui peut prendre un peu de temps car il est basé sur les pages de cache qu'il apprend à partir des pages d'index de votre site Web et sur la base évidemment du balisage que vous faites les données surligneur, puis il prend cela et l'applique aux nouvelles pages au fur et à mesure que nous les réexplorons et les réindexons sur votre site Web. C'est donc quelque chose qui prend un certain temps pour s'appliquer au contenu lorsque nous le réexplorons et le réindexons sur votre site Web. Il n'y a donc pas de calendrier fixe, parfois c'est assez rapide pour beaucoup de pages et parfois cela peut prendre quelques mois pour être visible. Il n'y a donc pas de bouton instantané pour cela, cela prend du temps comme toutes les autres données structurées que vous ajouteriez manuellement à vos pages.

Question 1:02:58 - Google est-il au courant et annonce-t-il un changement substantiel dans la manière dont le contenu dupliqué a commencé à être traité fin novembre début décembre de l'année dernière ? Ou y a-t-il eu un changement substantiel dans la façon dont le service de rendu Web gère ses activités ou la relation entre le rendu Web et l'indexation par rapport à l'indexation crawlée autour de cette période parce que rien n'a changé dans notre système et nous avons vu comme je l'ai dit des problèmes substantiels à partir de là en particulier pas seulement pour nous-mêmes, mais nous avons également remarqué un certain nombre d'autres observations de cette classe de problèmes autour de la même période ?

Réponse - 1:03:47 - Où quelque chose de substantiel a changé là-bas. La seule chose qui, je pense, s'est en quelque sorte produite vers l'automne, c'est que nous avons commencé à ajouter cette fonctionnalité à la console de recherche pour mettre en évidence ces problèmes et c'est aussi, je pense, là où j'ai commencé à voir plus de ces rapports une fois que nous l'avons mis en évidence pour les utilisateurs qui, hé, nous supprimons ces URL et comme il y en a un graphique parce que nous pensons qu'ils sont tous en double, et bien sûr tout le monde est comme, oh c'est un nouveau problème, mais pour une grande partie ça a toujours été comme que nous n'en avons jamais parlé dans la console de recherche. Donc, je ne sais pas exactement quand nous avons commencé à déployer cette fonctionnalité dans la console de recherche, mais probablement dans la seconde moitié de l'année dernière, quelque chose à cette époque.