トラフィックの突然の低下

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!

「いいね!」 2

Discourse の最新バージョンを使用していますか?

「いいね!」 3

現在 2.8.0.beta11 がインストールされており、2.9.0.beta4 をインストールする必要があるようです。

「いいね!」 3

.beta6になりました。アップグレードが必要なことを思い出しました! :wink:

「いいね!」 2

プラグインでサイトマップを使ったことがないのですが、ネイティブになり、最新バージョンでさまざまな修正が行われたことで、約1か月間、インデックス作成に目に見える変化がありました。一部はほぼ即時でしたが、トラフィックに役立っているかはわかりませんが、インデックス作成のアクティビティがあることは歓迎すべきことです。

「いいね!」 2

2.x の初期バージョンから最新の 2.9 にアップグレードして以来、カバレッジは以下のようになりました。この上昇トレンドが始まるまで約 12 日かかりました。「2」は最新バージョンが達成されたおおよその時期を示しています。

履歴トレンドは有効なリンクのインデックス作成が減少していましたが、トレンドは逆転しており、少なくとも全体的なインデックス作成アクティビティを増加させる効果があったことがわかります。

有効なリンクの純増加数は約 15,000 です。

上記のグラフィックでは完全には明らかではありませんが、無効なリンクはアップグレード後にわずかに増加しましたが、その後減少し始めています。

ゆっくりと、リダイレクトされた無効なページは、無効なグループの中で最も大きく主要なものでしたが、過去 1 か月間はゆっくりではあるものの減少傾向を示しています。

クロールが減り、サイトマップから直接取得されるものが増えました。サイトマップの効果を明確に比較できます。

もう 1 つのビフォーアフターです。パンくずリスト(サイトリンクも同様の採用率でした)

正直なところ、バージョンからの大きなジャンプであり、数年間サイトマップがなかった状態からサイトマップを使用するようになったため、全体像を把握するために少なくとも 3 か月は様子を見るつもりです。それまでの間、アップグレードのペースを維持するように努めます。

ここでも明らかな改善が見られます。一時的に奇妙な状態になりましたが、現在の状態はより重要な指標全体で改善されたように見えます。


スピードに役立っている可能性のある技術的な改善(PG13 DB と Discourse コードベースによるプログラム的な改善に加えて)は、HD が nVME であり、Docker も非常に更新されていることです。全体的なパフォーマンスの大幅な改善を実感しており、Google のページスピードを使用したスピードテストも現在非常に良好です。

全体として、Google コンソールでのネガティブトレンドに関する一般的な懸念は、バージョン 2.9.beta4-6 により、ゆっくりではありますが、好転し始めています。

「いいね!」 4

また、最近追加されたこともお知らせします

これにより、これが役立ちます :+1:

「いいね!」 6

Googleページで検索タームリンクをクリックした人は、分析中のDiscourseフォーラムでの議論で求めているものを見つけられなかった可能性が高いです:slight_smile:

何が変わったのか分かりません。アップデートかもしれませんが、10月上旬頃から、突然デスクトップ向けにGoogleが良いURLをインデックスするようになりました。

Discoveryは10月1日から3日にかけて始まり、10月25日頃の急激な増加は、上記のインデックスの改善と一致しますが、Googleが正しく認識しているのか、それともインデックス可能性を向上させるアップデートなのかは分かりません。

モバイル向けにはまだインデックスされていません。

このデプロイは、完全に最新の状態にするためにあと数コミットです。2.9.0.beta10 [f7a4fd1f49]

「いいね!」 1

はい、されています。「URLが不適切」は、インデックスに登録されていないこととは全く別のことです。

「いいね!」 1

これが起こった:Discourse Splashの紹介 - サイトアセットの読み込み中に表示されるビジュアルプリローダー

それは良い指摘です。「インデックス作成」とGoogleの「良い/中程度/悪い」Web Vitalsのスコアリングを混同していますが、それらは全く同じものではありません。後者はランキングに影響を与える可能性がありますが。

「いいね!」 3

「良いURL」がゼロです。心配すべきでしょうか?(笑):upside_down_face:

「いいね!」 1

まあ、それを厳密に指摘するのは面白いですが、それは本質的な全体像を見失っています。なぜなら、言語によっては、実際には(投稿していない)インデックス作成活動の増加と一致することがあるからです。ですから、私は派生的なものについて話しているのです。なぜなら、すべてはインデックス作成サービスから派生しているからです…

「いいね!」 1

さて、それは7月頃だったので、上記のスクリーンショットにあるように、Googleが「GOOD」URLを確認するまで3か月後ということになります。最初のリリースから数日後にスプラッシュスクリーンのコミットがあったことを考えると、もっと早く展開できたはずです。

バナー(CSS/HTML)用の非常にシンプルですが古いカスタムモッドを削除し、代わりに汎用バナーコンポーネントを使用するように戻したときに、すべてが正しく機能したと推測していますが、10月初旬に「GOOD」URLが表示され始めたことを説明するものではありません。しかし、10月の急増を説明する可能性があります。

CLSの問題を減らすことを目指していたので、ページがより良くレンダリングされ、表示されるようになったと推測しています。おそらく、ここでより深い問題を解決したのかもしれません。記憶が正しければ、汎用バナーはモバイルビューでは使用されていません。

「いいね!」 1

また、私が最初に再び注意深く調べるきっかけとなったのは、インデックスに登録されていないページの検出が増加し始め、インデックスも減少したことです。すべて10月末頃に同時に発生したようです。

インデックスに登録されていない/404のエラーを確認したところ、最近のインデックス未登録の増加の主な原因となっているようで、現在10,000件近くになっています。例として以下のように表示されます。

Login | HSTS Redirection Community
Login | HSTS Redirection Community

?page=123 を削除するとURLは正しく解決されるため、ページは存在します。Googleはなぜこの不正確なリンク形式を検出しているのでしょうか? :thinking:

phpBBのインポートエラーや、その他のパーマリンクのアーティファクト/設定ミス、あるいは何か別の原因かと思っていました。

「いいね!」 2

デスクトップのページエクスペリエンスは正常に機能しており、サーチコンソールは統計情報を出力しています。

モバイルのページエクスペリエンスは何も表示されず、インプレッションがゼロです。

どうしたのでしょうか?

「いいね!」 1

私も同じ状況です。9月に始まり、何も変更したりプラグインをインストールしたりしていません。
Discourseは必要に応じて更新しただけです。

原因はCLSの問題だと思います。

AdSenseバナーとフローティングGoogle GDPR同意バナーをすべて削除しましたが、しばらく経っても何も変わりませんでした。

「いいね!」 1

CLSは検索結果とは全く関係ありません。

なぜ検索エンジンの結果とは全く関係のない、完全に二次的な指標を見ているのか理解できません。

「いいね!」 1

これを理解しようとしているからです。

しかし、明らかに私は間違っており、これら2つのことは関係ありません。

「いいね!」 2

meta で、Core Web Vitals が Google のランキングにどのように影響するかについて、Google May 4th Core Update impact on Discourse forums のような議論があります。ローディング時のスプラッシュスクリーン Introducing Discourse Splash - A visual preloader displayed while site assets load の主な理由は、Discourse サイトの初期ロード時の FCP (First Contentful Paint) の測定値が悪いことを回避するためでした (そのアップデートについては Discourse チームに感謝します)。

検索ランキングの多くは不明瞭ですが、CLS のような Vitals が実際に重要であることは明らかです。CLS は、このトピックの Sudden drop in traffic - #35 by piffy で私が抱えていた問題であり、その後修正しました。

基本的な Discourse サイトには CLS の問題はないようです。meta サイトでも https://pagespeed.web.dev/report?url=https%3A%2F%2Fmeta.discourse.org%2F で確認できます。この pagespeed サイトは、サイトの実際のユーザー統計を表示するのに役立ちますが、「パフォーマンスの問題を診断する」セクションは、クローラー版のウェブページを使用するため、あまり役に立ちません。CLS の問題を調査する際に、このサイト https://gtmetrix.com/ が役立ちました。

meta でも CLS の問題は示されていません。

私の問題は、カスタムバナープラグインで、すべてのページの上部に表示され、事前に高さを指定していなかったため、一貫したレイアウトシフトが発生していました (ただし、非常に速いため、ほとんど気づきませんでした)。事前に高さを指定することで解決しました。これにより、ブラウザは画像がフェッチされる前に高さを確保できます。

私が得た洞察は、修正が認識されるまでに非常に長い時間がかかるということです。これは、実際のユーザー訪問によって収集された統計に基づいています。私の場合、1 か月以上かかりました。検索コンソールで「修正を検証」オプションを実行すると、28 日以内に通知されます。修正をテストしてからフィードバックを得るまでに 1 か月近くかかるため、少しイライラします。

とにかく、これらの情報が役に立つかどうかはわかりませんが、私の経験を共有したいと思います。

「いいね!」 6