SEOオフィスアワー、2022年3月11日

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

1つのページがドメイン全体に影響を与える可能性はありますか？

6:50 「 […]最近、大量のトラフィックとエンゲージメントを一貫して促進しているページをサイトに追加しました[…]。 あなたへの私の質問は、非常に高いエンゲージメントとトラフィックを持つ単一のページがドメイン全体に影響を与えることができるかということです。 […] 」

ジョンは次のように答えました。「エンゲージメントを要因として使用することはないと思います。 しかし、通常、Webサイト内のページはWebサイトの他の部分と相互にリンクされている場合があります。 そして、ウェブサイト全体のこれらの内部リンクを通じて、いくつかのシグナルを転送します。 したがって、ページが非常に優れていることがわかり、検索で多く表示したい場合は、さまざまな外部リンクがそこにある可能性があります。これにより、そのページに関する多くの追加コンテキストが得られます。 そして、その一部をWebサイトの残りの部分に転送することができます。 だから通常、それは良いことです。

私が気をつけているのは、それがあなたが気にかけているようなものへのエンゲージメントを促進するかどうかです。 これは私が時々見たもので、特定のクエリでページが非常に目立つ場合がありますが、クエリを見ると、ランク付けしたくないような気がします。 私のトピックは別のものです。 ですから、それはメトリクスを注意深く見るためだけのものかもしれません。」

次に、その人は、ページの1つのセクションのコアWebバイタルスコアが低いと、ドメインの他の部分に影響を与える可能性があるかどうかを尋ねました。 彼女が言及したメトリクス（最大コンテンツペイント（LCP）と累積レイアウトシフト（CLS））に精通していない場合は、最大コンテンツペイントとは何かと累積レイアウトシフトとは何かに関するガイドを読むことをお勧めします。

8:28 「[…] CoreWeb Vitalsの場合、製品の改善のために検索数の多いページを優先します[…]。 LCPまたはCLSが不十分なページのサブセット、たとえば、サイトのメインまたはセカンダリ、さらにはターシャリの検索トラフィック駆動ページではないサイトのビデオページのみが、サイトの残りのコアWebバイタルに影響を与える可能性があります。スコア？ […] 「

ジョンはこう答えました。「通常、それは問題にはなりません。 ですから、そこには2つの側面があると思います。 一方では、Core Web Vitalsについて、これらのページへのトラフィックのサンプルを調べます。これは、 Chromeユーザーエクスペリエンスレポート機能を介して行われます。 それはChrome側のどこかに文書化されていると思います。 しかし、それは本質的にあなたのウェブサイトへのトラフィックの一部です。 つまり、ほとんどの場合、私たちが最もよく見るのは、実際に最も多くの訪問者を獲得したページであることを意味します。 したがって、誰も見たことがない側にランダムなページがあり、それらが本当に遅い場合、それらはあなたのサイトを下にドラッグしません。 また、その逆も同様です。これらのランダムなページが非常に高速である場合、サイトを引き上げることはありません。 ランダムなページがたくさんあるとしても、全体としてトラフィックがあまり多くない場合は、あまり気にしません。 […]人々が目にするものは、優れたユーザーエクスペリエンスを備えている必要があります。 したがって、ほとんどの人がサイトの特定の部分を見ている場合、それが私たちが焦点を当てたい部分です。

もう1つは、Page Experienceの更新により、Webサイトのデータ量に応じて、Webサイトをさまざまなセクションに分割する場合があることです。 そして、ウェブサイト全体のどのページが本質的に類似しているかを理解することによって、それを行おうとしています。 テンプレートの種類などによっても可能です。つまり、たとえばeコマースサイトの場合、すべての商品ページが非常に高速であり、商品ページを表示するのに十分なデータがある可能性があります。個別に、そのページのグループにそれ自体を処理させることができます。 また、サイト全体に別の種類のページがあり、十分なデータがあり、データが遅い場合は、この種類のページの方が遅いと言えます。 これが2番目の部分です。非常に遅い種類のページがあり、その種類のページを理解するのに十分なデータがある場合、これはWebサイトのその部分にすぎず、その部分だけがCoreWebVitalsとページエクスペリエンスの更新の影響を受けます。 」

内部リンクが多すぎると、Webサイトに悪影響を与える可能性がありますか？

12:50 「以前の営業時間で、同じページで内部リンクを多用するとその価値が薄れる可能性があり、Googleがサイトの構造を理解できない可能性があるとおっしゃっていました。 それで、あなたの意見では、eコマースサイトの1ページあたりの理想的な内部リンクの量はどれくらいですか？おそらく数百万ページですか？ 」

ジョンは、「最適な数はないと思います。 私が気をつけたいのは、Webサイトをクロールしても、構造があることを認識できるということです。 特に、まだ認識できるeコマースサイトの場合：ここにメインのホームページ、ここにトップレベルのカテゴリ、セカンドレベルのカテゴリがあります。個々のページのコンテキストがどのようになっているのかが明確になるように、その構造を認識できます。 。 […]すべてのページが他のすべてのページにリンクされていると、構造を認識するのが難しくなります。 また、Webサイトに数百万のページがある場合、すべてのページに数百万のリンクがあるとは限りません。 ですから、その観点からすると、eコマースサイトでは通常これに問題はありません。なぜなら、eコマースCMSはとにかくそのように設定される傾向があり、カテゴリのレベルが異なるからです。そして、ある時点で個々の製品ページ。 「「

小さなWebサイトのクロールの問題を診断する

25:47 「検索コンソールでクロール統計レポートを確認し、Googleがウェブサイトをクロールする際に技術的な問題があるかどうかを特定しようとしています。 グーグルが何かをクロールするのに苦労している場合、またはグーグルボットが無関係なファイルに気を取られている場合に私たちを指し示すシグナルまたは識別すべきもののいくつかは何ですか[…]？ 」

ジョンは、質問をしている人が比較的小さなWebサイトを管理していることを確認し、次のように答えました。統計レポート、あなたは本当にあなたのウェブサイトのクロールの全体像を見ています。 そして通常、それはあなたが数十万ページのようなものを持っているならもっと理にかなっています。 次に、それを見て、まあ、平均して、クロールが遅いと言うことができます。 あなたがウェブサイトを持っているなら、私にはわかりませんが、おそらく100ページ程度ですが、基本的に、クロールが本当に本当に遅い場合でも、それらの100ページは、一度のように、それを取得することができます日、最悪の場合、おそらく週に1回。 クロールに関しては技術的な問題にはなりません。

本質的には、Webサイトが、インデックスを作成する必要のあるユニークで価値のあるものを実際に提供していることを理解する必要があります。 したがって、クロール側の問題は少なく、インデックス側の問題が多くなります。 ここでの例外は、Webサイトに本当に大きな技術的な問題がある場合です。 しかし、おそらくこれらのURLの個々をチェックして、Googleがそれらをまったくクロールできないことに気付くので、それはすぐにわかるものです。 返されたエラーがあるか、返されたnoindex [tag]があります。 そして、それは非常に明白でしょう。 したがって、特に小規模なWebサイトの場合、GoogleがWebサイトの価値を理解し、可能な限りインデックスを作成することが理にかなっていることを確認することが重要であると考えています。 クロール側が制限要因になることはないからです。 それは本当にもっと似ています、まあ、あなたは最初にグーグルに実際にクロールしようとするべきだと説得しなければなりません。 」

同義語がランキングに違いをもたらす理由

39:34 「同義語に小さな違いがあり[…]ランキングの位置に大きな違いがあるのはなぜですか？」

その人は、同義語の次の例を提示しました：「ビデオの編集」と「ビデオエディタ」。

ジョンは次のように答えました。「つまり、私たちの観点からすると、これは完全に正常である可能性があります。これは、一方では、クエリ内の同義語などを理解しようとするものですが、クエリ。 特に同義語に関しては、何かがほとんど同義語であると想定するかもしれませんが、それは完全に同義語であるという意味ではありません。 特に、「ビデオの編集」と「ビデオエディタ」のようなものを見ている場合、ユーザー側からの期待は少し異なります。 一方では、ビデオを編集したいとします。 一方、ビデオエディタをダウンロードすることもできます。 非常に似ているように見えますが、ユーザーが望んでいるものの種類は少し異なります。 ですから、私の観点からすると、そこにさまざまなランキングを表示するのは理にかなっています。 また、単語のスペルがわずかに異なる場合も同じです。 イギリス語またはアメリカ語の英語の単語がある場合と同様に、アクセントのある単語または文字があり、アクセントがない場合、これらはほとんど同じであると理解していますが、それらが少し違います。 そして、そのようなことを考慮した検索結果を表示しようとしています。」

1ページに複数の豊富な結果タイプを組み合わせる

42:06 「私の国では、ほとんどのレシピWebサイトがあまり有用な情報を提供していないことがわかりました。より有用な情報を提供し、すべてのレシピにFAQを追加することで、それを変えようとしています。 これらのFAQを追加する最良の方法は何ですか？ 」

ジョンはこう答えました。「[…]私の観点からすると、それは完全にあなた次第です。 このような場合、ページに関連する可能性のあるリッチな結果タイプが複数ある場合に注意することの1つは、これらのタイプの一部は組み合わせることができ、一部は実際には組み合わせることができないということです。良い。 レシピに関しては、具体的にはわかりませんが、組み合わせることができるのか、基本的にどちらかを選択する必要があるのか​​はわかりません。 また、他のレシピWebサイトにレシピリッチスニペットと下部のFAQセクションがないことに気付いた場合は、おそらくそれらを組み合わせることができません。 そして、実際に表示したいリッチ結果タイプのタイプを選択し、純粋にそのタイプに焦点を当てた方がおそらく良いでしょう。 」

ペイウォールがクローキングペナルティを引き起こさないようにする方法

43:43 「 Googleは、サブスクリプションとペイウォールコンテンツのガイドラインで、ペイウォールコンテンツをインデックスに共有し、クローキングペナルティをトリガーしないようにするには、特定のスキーマをページに追加する必要があると説明しています。 しかし、これを実装した後、リッチリザルトテストはこれを特定していないようであり、不注意でクローキングペナルティのリスクを冒していませんか？」

ジョンは次のように述べています。「リッチリザルトテストではこれが表示されると思いますが、実際にはチェックしていません。リッチリザルトテストでは、ほとんどの場合、Googleがリッチリザルトタイプとして検索結果に実際に表示する内容に焦点を当てているためです。 。 そして本質的に、ペイウォールのコンテンツは、特定のリッチな結果タイプとして表示されるものの1つではない可能性があります。 したがって、そのテストではそれを示さない可能性があります。 これを行う簡単な方法の1つは、非常に単純なテストページを作成し、そのページを個別にテストすることです。 Googleが実際にマークアップを含む完全なコンテンツを表示していることを確認するために実行できるもう1つのテストは、通常のURL検査テストです。このテストでは、ページのライブスケッチを実行し、そのために生成されたHTMLを確認できます。ページ。 そして、それをエディターにコピーして再確認し、そこに表示したい構造化データが実際にそこに表示されていることを確認できます。 だから、それは私がそこに向かう方向のようなものです。」

ページの特定のセクション内のリンクはGoogleにとってより重要ですか？

45:11 「 […]サイトの特定のセクション内のリンクは異なって見られますか？ たとえば、ページがヘッダーまたはフッター内にリンクされているため、サイトのすべてのページに含まれている場合、Googleはそれらのリンクをページの本文内のリンクとは異なる方法で表示しますか？ 」

ジョンはこう答えました。 したがって、[ページ]がページのフッターにリンクされていて、それらがWebサイト全体からリンクされている場合、私たちの観点からは、Webサイト全体からのリンクがあります。 フッター内のリンクの重みが軽い、またはあまり役に立たないと言うわけではありません。無視します。 したがって、その観点から、リンクに関しては、基本的にはページ上のリンクとして表示されます。

そこにあるテキストに関しては、ページの主要なコンテンツが何であるかを理解しようとするという点で少し異なります。 そして、あなたのウェブサイトの他のコンテンツとの相対的なランキングに関しては、ページの主要なコンテンツセクションに焦点を当てようとします。 しかし、リンクは、私たちの観点からは、サイトの構造をよりよく理解するのに役立ちます。 そして、それらがヘッダー、フッター、サイドバー、またはメインコンテンツのいずれにあるかにかかわらず、それは私たちにとって実際には何も変わりません。 」

モバイルファーストのインデックス作成は、ランクを上げるのに役立ちますか？

46:33 「モバイルファーストのインデックス作成は検索ランキングに役立ちますか？ 私たちのウェブサイトはまだGooglebotデスクトップによってクロールされています。 そして、なぜそれがモバイルファーストに切り替わらないのか理解できません。 Googleのドキュメントとトラブルシューティングを確認しましたが、何も飛び出しません。 プログレッシブウェブアプリとオフラインサポートへの移行は役に立ちますか？ 」

ジョンは次のように答えました。「まず第一に、モバイルファーストのインデックス作成はランキングに何の変化もありません。 したがって、モバイルファーストのインデックス作成へのあらゆる種類の移行を強制する必要があるわけではありません。 それは純粋に、Webサイトで使用するコンテンツのインデックスを作成して選択することです。 したがって、その観点から、私はこれについて心配することはありません。 あなたのウェブサイトがモバイルでうまく機能するなら、ある時点で、それは切り替えられるでしょう。 まだ切り替えていないサイトが残っていると思います。 しかし、ほとんどの場合、ほとんどのサイトを切り替えました。 そして残っているものは、引き続き再確認します。 準備ができたら、準備ができたと思ったら、切り替えます。

ただし、モバイルバージョンがデスクトップバージョンと大幅に異なる場合を除いて、ランキングの変更に気付くとは限りません。 そして、それは私たちがモバイルファーストのインデックスに切り替えない理由でもあります。 また、モバイルバージョンが大幅に異なり、サイトにモバイルファーストインデックスを使用した場合、基本的にはモバイルバージョンに基づいてコンテンツにインデックスを付けるだけです。 また、デスクトップバージョンにさらに多くのコンテンツがある場合は、それを無視します。 したがって、その観点から、私はこれを強制しようとはしません。 プログレッシブウェブアプリへの移行はあなたにできることですが、モバイルファーストのインデックス作成があなたのウェブサイトをどのように見るかに影響を与えるとは思いません。 そして通常、プログレッシブWebアプリに関して言えば、それらはJavaScriptフレームワークWebサイトです。 JavaScriptは通常レンダリングして適切に処理できるものであるため、Googleが実際にコンテンツを表示できるようにする必要があるという点で、それに伴う他の一連の課題が発生しますが、純粋な静的なものほど簡単ではありません。 HTMLページ。 」