That’s right, all the discussions in my case were reworked by google and disappeared from the search.
I have no idea, for now on my sites I still have:
Not enough usage data in the last 90 days for this device type.
The decline continues despite there is always new content and updated discussions.
No errors are reported, it is clear that something has happened!
Êtes-vous sur la dernière version de Discourse ?
Nous avons maintenant la version 2.8.0.beta11 installée, il semble que nous devions installer la version 2.9.0.beta4.
.beta6 maintenant.. ça me rappelle que je dois mettre à niveau ! 
Jamais eu de sitemap via un plugin, maintenant qu’il est natif et avec diverses corrections dans la dernière version depuis environ un mois, un changement notable dans l’indexation, certains étaient presque instantanés, je ne suis pas sûr que cela aide le trafic, mais une certaine activité d’indexation doit être la bienvenue.
Depuis la mise à niveau d’une très ancienne version 2.x vers la dernière version 2.9, voici à quoi ressemble la couverture, il a fallu environ 12 jours pour que cette augmentation commence. « 2 » indique approximativement quand la dernière version a été atteinte.
La tendance historique était une indexation décroissante des liens valides, mais vous pouvez voir que la tendance est inversée, c’est-à-dire qu’elle a eu pour effet d’augmenter l’activité d’indexation dans l’ensemble, du moins.
Il y a environ une augmentation nette de 15 000 liens valides.
Bien que ce ne soit pas totalement clair dans le graphique ci-dessus, les liens invalides ont légèrement augmenté après la mise à niveau, mais ont depuis commencé à redescendre.
Lentement, et les pages invalides avec une redirection, constituaient le groupe invalide principal et le plus important, et il montre maintenant une tendance lente mais à la baisse au cours du dernier mois.
Moins de crawling et plus est maintenant directement sourcé via le sitemap, un effet très clair avant vs après sitemap :
Encore un avant et après, les fil d’Ariane (et les sitelinks ont eu une adoption similaire)
Franchement, je vais lui laisser plus de temps, au moins 3 mois pour voir comment tout cela se déroule, car c’était un grand saut de version et passer de l’absence de sitemap après quelques années à un sitemap - en attendant, j’essaierai de suivre le rythme de la mise à niveau.
Quelques améliorations évidentes ici aussi, les choses sont devenues bizarres pendant un moment, l’état actuel semble globalement amélioré pour plus de données vitales :
Les seules améliorations techniques qui pourraient aider à la vitesse (en plus de toute amélioration programmatique avec la base de données PG13 et le code de Discourse) sont que le HD serait nVME, et un docker très mis à jour aussi - on remarque définitivement une grande amélioration des performances globales et les tests de vitesse sont très bons maintenant en utilisant Google Pagespeed.
Dans l’ensemble, les préoccupations générales concernant les tendances négatives dans la console Google semblent s’inverser avec la version 2.9.beta4-6, bien que lentement.
Veuillez noter également que nous avons récemment ajouté
ce qui aidera à cela 
Il est probable que la personne qui a cliqué sur le lien du terme de recherche sur la page Google n’ait pas trouvé ce qu’elle cherchait dans la discussion sur le forum Discourse que nous analysons 
Je ne sais pas ce qui a changé. Peut-être une mise à jour, mais début octobre, Google indexe soudainement de BONNES URLs pour le bureau.
La découverte a soudainement commencé le 1er-3 octobre et la hausse soudaine autour du 25 octobre dans la courbe coïncide avec le basculement ci-dessus, je ne sais pas si c’est Google qui voit les choses correctement ou une mise à jour qui améliore l’indexabilité.
Cela n’indexe toujours pas pour mobile.
Ce déploiement n’est qu’à quelques commits de la mise à jour complète - 2.9.0.beta10 [f7a4fd1f49]
Oui, c’est le cas. Les URL médiocres sont une chose totalement différente de la non-indexation.
Ceci est arrivé : Introducing Discourse Splash - A visual preloader displayed while site assets load
C’est un bon point. @agemo utilise l’“indexation” et le classement par Google des Web Vitals “bons/moyens/mauvais” de manière interchangeable, alors qu’ils ne sont absolument pas la même chose, même si ce dernier peut affecter le classement.
Eh bien, c’est drôle que vous le souligniez de manière pédante, et c’est un point technique, mais cela manque le point général substantiel, car parfois le langage - cela coïncide en fait avec une augmentation de l’activité d’indexation, que je n’ai pas publiée. Donc, je m’étends sur le dérivé, car tout est dérivé du service d’indexation…
Eh bien, je ne comprends pas car c’était vers juillet et donc 3 mois plus tard avant que de BONNES URL ne soient vues par Google, comme dans les captures d’écran ci-dessus. J’aurais espéré plus tôt pour ce déploiement, car il y a eu le commit de l’écran de démarrage quelques jours après sa sortie initiale.
Je soupçonne que lorsque j’ai supprimé un mod personnalisé très simple mais ancien pour une bannière (CSS/HTML) et que je suis revenu à l’utilisation du composant de bannière polyvalent à la place, les choses se sont mises en place correctement, bien que cela n’explique pas l’apparition de BONNES URL début octobre, mais cela pourrait expliquer la montée en puissance d’octobre.
Je visais à réduire les problèmes de CLS, donc je suppose que les pages se rendent mieux et apparaissent mieux. Peut-être ai-je résolu un problème plus profond ici. Si je me souviens bien, la bannière polyvalente n’est pas utilisée sur les vues mobiles.
Une autre chose qui s’est également produite, et qui m’a amené à réexaminer attentivement la situation, est que la découverte de pages non indexées a commencé à augmenter avec une baisse de l’indexation également, hmm… tout cela s’est produit environ la dernière semaine d’octobre, quand toutes ces choses semblent se déclencher en même temps.
J’ai examiné les pages non indexées / 404, elles semblent être une source principale de l’augmentation récente des pages non indexées, et sont maintenant proches de 10 000, elles apparaissent comme ci-dessous par exemple :
Login | HSTS Redirection Community
Login | HSTS Redirection Community
Si je supprime le ?page=123, l’URL se résout correctement, donc la page est là - où Google pêche-t-il ce formatage de lien incorrect ? 
Je pensais que c’était une erreur d’importation phpBB ou un autre artefact de permalien / configuration incorrecte, ou quelque chose d’autre.
L’expérience de page pour ordinateur fonctionne bien et la console de recherche affiche des statistiques.
L’expérience de page pour mobile : nada, zilch, zéro impressions.
Qu’est-ce qui se passe ?
Je suis dans la même situation, tout a commencé en septembre et je n’ai apporté aucune modification ni installé de plugins.
J’ai seulement mis à jour Discourse lorsque nécessaire.
La raison pour laquelle je pense qu’il s’agit d’un problème avec le CLS
J’ai également supprimé toutes les bannières AdSense et la bannière flottante de consentement RGPD de Google, mais après un long moment, rien n’a changé.
CLS n’a absolument rien à voir avec les résultats de recherche.
Je ne comprends tout simplement pas. Pourquoi regardez-vous des métriques totalement secondaires qui n’ont rien à voir avec les résultats des moteurs de recherche ?
Parce que j’essaie de comprendre ceci
Mais évidemment j’ai tort et les deux choses ne sont pas liées.
Il y a des discussions sur meta comme celle-ci Google May 4th Core Update impact on Discourse forums qui parlent de l’impact de Core Web Vitals sur les classements Google. La raison principale de l’écran de chargement Introducing Discourse Splash - A visual preloader displayed while site assets load était de contourner la mauvaise mesure FCP lors du chargement initial d’un site Discourse (merci à l’équipe Discourse pour cette mise à jour au passage).
Tant de choses concernant le classement de recherche sont obscures, mais il semble clair que les Vitals comme CLS sont effectivement importants. CLS était le problème que j’avais ci-dessus Sudden drop in traffic - #35 by piffy dans ce même sujet que j’ai depuis résolu.
Un site Discourse minimaliste ne semble pas avoir de problèmes de CLS. Vous pouvez le confirmer avec le site meta aussi https://pagespeed.web.dev/report?url=https%3A%2F%2Fmeta.discourse.org%2F Ce site pagespeed est utile pour montrer les statistiques des utilisateurs réels de votre site, mais la section “Diagnostiquer les problèmes de performance” qui donne une vue en direct du site n’est pas utile car elle utilise la version crawler de la page Web. J’ai trouvé ce site utile lors de l’investigation de mon problème de CLS : https://gtmetrix.com/
Il ne montre également aucun problème de CLS pour meta.
Mon problème était un plugin de bannière personnalisé que j’avais écrit et qui apparaissait en haut de chaque page et ne spécifiait pas la hauteur à l’avance, causant des changements de mise en page constants (mais qui se produisaient si rapidement que vous ne le remarqueriez même pas). Je l’ai résolu en spécifiant simplement la hauteur à l’avance afin que le navigateur puisse ajuster la hauteur avant que l’image ne soit chargée.
La seule chose que j’ai comprise, c’est qu’il faut beaucoup de temps pour que la correction soit reconnue. Elle est basée sur des statistiques recueillies auprès de visites d’utilisateurs réels. Cela m’a pris plus d’un mois. Vous pouvez utiliser l’option “valider la correction” dans la console de recherche et elle vous notifiera dans les 28 jours. C’est un peu frustrant car il y a essentiellement un mois d’écart entre le test d’une correction et l’obtention des commentaires.
Quoi qu’il en soit, je ne sais pas si tout cela est utile, mais j’ai pensé partager mon expérience.
