SEOオフィスアワー、2022年2月18日

公開: 2022-02-28

これは、2022年2月18日のジョンミューラーGoogleSEOオフィスアワーからの最も興味深い質問と回答の要約です

内容を隠す
1製品レビューの更新の影響を受けるWebサイトの種類
2インデックスAPIの使用
3EATとGoogleのアルゴリズム
4リンクされていないブランドの言及とユーザー生成コンテンツ
5Googlebotと無限スクロール
6クロール統計レポートのデータの更新と検出
7Webサイトのクロールの削減
8Googleがページの対象となる国を特定する方法
9検出済みとしてマークされた多数のURL–現在インデックス付けされていません

製品レビューの更新の影響を受けるWebサイトの種類

4:03 「[…]私の質問は製品レビューの更新についてです[…]。 ページまたはサイトが商品レビューに関連しているかどうかをGoogleがどのように識別するかを理解したかったのです。 […]たとえば、eコマースサイト[…]があり、彼らは自分の製品をレビューするブログも持っています。 彼らは彼らの製品の賛否両論について書き、異なる製品を比較します。 […]Googleは、[…]これも製品レビューであり、製品レビューの更新によって分析できると言いますか? […]」

ジョンが説明したように、「[…]製品レビューに関する推奨事項[…]は、あらゆる種類の製品レビューに関連します。 だから私は必ずしも見ようとはしません、グーグルは私のサイトが製品レビューサイトであるかどうかを考えますか[…]。 むしろ、これらのグッドプラクティスがコンテンツに当てはまると思われる場合は、それらのグッドプラクティスを実行してください[…]」。

IndexingAPIの使用

6:53 「[…][Googleのドキュメント]には、求人情報やイベントのブロードキャストなどのページにIndexingAPIを使用する必要があると記載されています。 ニュース記事やブログコンテンツなど、さまざまな種類のコンテンツに対してこのAPIを試すことは可能ですか?」

ジョンは次のように答えました。 しかし、基本的に、私たちが文書化したのは、APIを使用する目的です。 これらのカテゴリに分類されるコンテンツがない場合、APIはそこで役立ちません。」

EATとGoogleのアルゴリズム

10:54 「[…] EATは[品質評価者ガイドライン]で言及されていますが、実際のアルゴリズムにも著者の専門知識などのEAT要素が[含まれている]かどうか知りたいですか?」

ジョンは次のように述べています。「同様のことをしようとするために、いくつかの間接的な作業が行われていると思います。 […]これをガイドラインに入れて、品質テスターがこれらのことを再確認できるようにします。 そして、それが重要だと考えるなら、検索品質の側の人々も、よりアルゴリズム的な方法でそれを理解しようと努力していると思います。

しかし、私は[…][あるだろう]EATスコアを見ることはできません、そしてあなたはそれに5かそのようなものを取得しなければなりません。 Web上のコンテンツのコンテキストを理解しようとしているのです。」

リンクされていないブランドの言及とユーザー生成コンテンツ

12:01 「[…]人々がリンクされていないブランドの言及について話しているのを見る[…]。 [Googleの]アルゴリズム[…]にとっても重要だと思いますか?」

リンクされていないブランドの言及とは、他のサイトがあなたのブランドについて言及しているが、あなたのWebサイトへのリンクが含まれていない状況を指していることです。

ジョンは次のように述べています。「[…]コンテキストが何であるかがよくわからないため、これはちょっと注意が必要です。 それはユーザーにとって悪いことではないと思います[…]その言及を通してあなたのウェブサイトを見つけることができれば、それは常に良いことです。 しかし、誰かがあなたのウェブサイトの名前に言及している場所を見つけようとしている[…]SEO要因があるとは思いません。」

12:58 「[…]ユーザーのレビューやコメントはどうですか? 記事や製品のランキング要素でもあると思いますか?」

ジョンは次のように答えました。「[…]多くの場合、人々は自分の言葉でページについて書きます。これにより、検索結果にこのページを表示する方法についてもう少し情報が得られます。 その観点から、コメントはページ上で良いことだと思います。 明らかに、人々がそれらのコメントをスパムするので、合理的な方法でそれらを維持する方法を見つけることは時々トリッキーです[…]。 Webページでコメントを維持する方法を見つけることができれば、それはあなたにもう少しコンテキストを与え、あなたのコンテンツを見つけるためにさまざまな方法で検索している人々を助けます。

Googlebotと無限スクロール

24:00 「[…] Googlebotがまだ無限スクロールを処理できるほど高度であるかどうか、または少なくともコンテンツが何かの上に構築され続ける何かを知っていますか?」

ジョンは次のように述べています。

ページをレンダリングすると、画面が非常に長い場合のように、かなり高いビューポートを使用し、ページをレンダリングして、ページにが表示されるかを確認します。 通常、これにより、無限スクロールをトリガーするために使用しているJavaScriptメソッドが何であれ、ある程度の無限スクロールがトリガーされます。 そこにロードされることになったものは何でも、それがインデックス付けできるものになります。

[…]無限スクロールの実装方法によっては、インデックスにこの長いページがある場合があります。 そのページに収まるすべてのものがあるわけではないかもしれません。 無限スクロールをトリガーする方法によっては、次のページを読み込んでいるだけの場合もあります。 次に、これらのページのうち2つまたは3つを、すべてではなく、無限スクロールで1ページにロードする場合があります。 […] [URL]検査ツールを使用してテストし、Googleがどれだけ取得するかを確認することをお勧めします。」

クロール統計レポートのデータの更新と検出

33:32 「検索コンソール[クロール統計]レポートでは、クローラー要求の97%が更新され、検出は3%のみです。 これを最適化して、Googleにさらに多くのページを検出させるにはどうすればよいですか?」

ジョンは次のように答えました。「[…]古い、より確立されたWebサイトでは、時間の経過とともに増加することがわかっているページの量を調べるため、多くの更新クロールが行われるのが普通です。 そして、入ってくる新しいページの量はかなり安定している傾向があります。 特に、確立されてゆっくりと成長しているWebサイトの場合、このようなバランスをとることはかなり一般的です。クロールのほとんどは更新クロールで行われ、検出クロールではあまり行われません。

新しい記事がたくさん入ってくるウェブサイト[…]があったら、それは違うと思います。古いコンテンツはすぐに無関係になります。 そうすれば、私たちは発見にもっと焦点を合わせる傾向があると思います。 […]eコマースサイトのように、ゆっくりとコンテンツの量を増やしていて、古いコンテンツのほとんどが有効なままである場合、[…]更新クロールの量はおそらく次のようになります。少し高くなります」。

Webサイトのクロールを減らしました

35:09 「ここ数週間、クロール統計が1日あたり700から50に大幅に低下していることに気づきました。 検索コンソールレポートから、この低下の原因が何であるかを理解する方法はありますか? ソースページの読み込みでしょうか? クロールリクエストの内訳を正しく読み取るにはどうすればよいですか?」

ジョンは、 Googleがウェブサイトをクロールする方法とクロールに影響を与える要因について詳細に説明しました。 「[…]私たちが行うクロールの量にはいくつかのことが関係しています。

[…]検索結果で物事を新鮮で有用なものに保つために、Webサイトからクロールする必要がある量を把握しようとしています。 そしてそれはあなたのウェブサイトの質、あなたのウェブサイトで物事がどのように変化するかを理解することに依存しています。 それをクロールデマンドと呼びます

一方、ウェブサイトでクロールできる量に関しては、サーバー、ウェブサイト、ネットワークインフラストラクチャから見た制限があります。 この2つのバランスをとろうとしています。

そして、制限は2つの主要なものに結びつく傾向があります:[…]リクエストへの全体的な応答時間

Webサイトにアクセスし、[…]クロール中に表示される[…]サーバーエラーの数。 サーバーエラーが多数発生する場合は、クロールが遅くなります[…]。 サーバーの速度が低下していることがわかった場合は、クロールも遅くなります[…]。

速度の面での難しさは、速度を見る2つの[…]異なる方法があることです。 クロール速度を見ると、混乱することがあります。 特にクロールレートについては、サーバーからURLをどのくらいの速さでリクエストできるかを見ていきます。

そして、おそらく遭遇する速度の他の側面は、 Core Web Vitalsの周りのすべてと、ページがブラウザーに読み込まれる速度です。 ブラウザでの速度は、Webサイトで個々のURLを取得するのにかかる速度とは直接関係がない傾向があります。 ブラウザでは、JavaScriptを処理し、これらすべての外部ファイルをプルし、コンテンツをレンダリングし、ページ上のすべての要素の位置を再計算する必要があるためです。 そして、それは単にそのURLをフェッチするのとは異なる時間を要します。

[…]クロール速度の変化を診断しようとしている場合は、ページのレンダリングにかかる​​時間を調べないでください。 […]サーバーからそのURLをフェッチするのにかかる時間を純粋に見てください。

もう1つ[…]は、[…] Webサイトがホストされている場所を理解しようとしていることです[…]。 ウェブサイトがホスティングをあるサーバーから別のサーバーに変更していることを認識した場合(別のホスティングプロバイダーに変更されている可能性があります)、[…] CDNに移動している、またはCDNを変更している[…]問題が発生しないことがわかっている場合の安全率は、段階的に再び増加します。

あなたがあなたのウェブサイトのホスティングに大きな変更を加えるときはいつでも、私はクロール率が下がると思います。 そして、次の数週間で、ウェブサイトを安全にクロールできると思われるものに戻ります。 それはあなたがここで見ているものかもしれません。

もう1つは、 Webサイトとサーバーの分類方法を決定するアルゴリズム[…]も更新できる場合があるということです。 […]ホスティングインフラストラクチャで何も変更しなくても、アルゴリズムは、このWebサイトがこのサーバーでホストされており、このサーバーが頻繁に過負荷になっていることを認識しようとします。 問題が発生しないように、このWebサイトのクロールにはさらに注意する必要があります。 これも時間の経過とともに、通常は数週間で自動的に落ち着くものです[…]。

[…][Google]検索コンソールでは、クロール速度を指定できます[…]。これにより、Webサイトに特定の設定[…]があることを理解でき、それを考慮に入れます。 クロール速度設定の難しさは、それが最大設定であるということです。 それは、私たちがそれだけクロールする必要があるという兆候ではなく、あなたがそこで指定したものをせいぜいクロールする必要があるということです。 通常、この設定は、クロールの量を増やしたい場合ではなく、クロールの量を減らす必要がある場合に役立ちます。

[…]検索コンソールのヘルプセンターに、Googlebotの問題を報告するためのリンクがあります。 ウェブサイトのクロールが期待する範囲から大きく外れていることに気付いた場合は、そのリンクからGooglebotの問題を報告できます[…]」。

Googleがページの対象となる国を特定する方法

56:25 「[…]ジオターゲティングに関しては、hreflangを使用する以外に、Googleは、この特定のWebサイトまたは特定のサブディレクトリでターゲットにしている[国]をどのように把握しますか?」

Johnの回答は次のとおりです。「たとえば、サブドメインやサブディレクトリなど、認識できる明確なパターンでURLをグループ化しようとしています。 サブディレクトリのパスの上位に国がある場合、このパスの下にあるものはすべてこの国のものであり、この別のパスの下にあるものはすべて別の国のものであると言うのははるかに簡単です。

Search Console […]で個々のパスを確認することもできます。これにより、少し簡単になります。 実際には、これが大きな違いを生むという人々からのフィードバックはあまりありません。

[…]どの国が個々のURLに関連しているかをできるだけ明確にし、URLに明確なパスを含めるようにします。 最後にURLパラメータとして国を使うことについても誰かが提出した質問があったと思います。 理論的には、それを行うことができます[…]。 私たちのシステムでは、どのURLがどの国に属しているかを認識するのが非常に難しくなります[…]。 hreflangを使用している場合は、URLごとに実行できるため、それほど問題にはなりません。」

検出済みとしてマークされた多数のURL–現在インデックスに登録されていません

58:25 「[…]私たちは巨大なeコマースサイトであり、クロールレポートを確認したところ、[検出済み–現在インデックスに登録されていないセクション][…]に大量のURLがあることがわかりました。 これは[a]問題[当サイト][…]の兆候ですか?」

ジョンは次のように述べています。「それは、それらのページが何であるか、そしてWebサイト内でそれらをどのように使用するかによると思います。 […]ウェブ全体であらゆる種類のURLが見つかり、それらのURLの多くは、クロールしてインデックスに登録する必要がありません。これは、それらがすでに知っているURLのバリエーションであるか、[…]ランダムなフォーラムやスクレーパーである可能性があるためです。スクリプトはあなたのウェブサイトからURLをコピーし、壊れた方法でそれらを含めました。 […]これらのURLの多くが、クロールされてインデックスに登録されていないか、検出されてクロールされていないのはごく普通のことです。これは、Web全体にさまざまなURLソースがあるからです。

[…]それらのサンプルをダウンロードしてみてください[…]個々の例を見ることができます。[…]これらのURLのどれが気になるもので、どれが[…]無視できるものかを分類してください。

[…]あなたが気にかけているもの、それは私があなたが内部リンクのようなものに関してあなたのウェブサイトでこれらをより良く結びつけるためにあなたが何ができるかを理解しようとするものです。 したがって、これらが見つからない個々の製品またはカテゴリである場合は、体系的な方法で何ができるかを考えて、これらのURLがすべて相互に適切にリンクされていることを確認してください。 […]特に大規模なeコマースサイトでは、すべてのURLを常に個別に確認できるわけではないため、注意が必要です。

しかし、時々、あなたが言うところにあなたがすることができるトリックがあります:最初のレベルのカテゴリーであるものは何でも、私は私のホームページからそれにリンクします。 そして、私の最初のレベルのカテゴリには、最大で[…]おそらく100アイテムまたは200アイテムがあることを確認します。これにより、 Googleにクロールとインデックス作成を提供するという点で、少し強制的な機能があります。 これに基づいて、もう少し体系的に構築することができます。

[…]ある程度、Googleがすべてをクロールしてインデックスに登録することはできないことを認めます。 […]たとえば、[…]個々の製品がクロールされてインデックスに登録されていないことに気付いた場合は、少なくともそれらの製品のカテゴリページがクロールされてインデックスに登録されていることを確認してください。 そうすれば、人々はまだあなたのウェブサイトでそれらの個々の製品のいくつかのコンテンツを見つけることができます[…]。

自分でWebサイトをクロールできるかどうかを確認して、自分のようなWebサイトをクロールする方法についてもう少し直接的なデータを入手できるようにします。 そこにはさまざまなクロールツールがあります。 […]自分でWebサイトをクロールすることにより、これらのURLのどれがホームページから非常に離れてリンクされているか、そしてこれらのどれがあなたのホームページの近くにリンクされているかを確認できます。 そして、それに基づいて、サイトの構造を少し調整して、ホームページからの距離に関して、物事が適度に近いか、適度に安定していることを確認できる場合があります。」