SEOオフィスアワー、2021年11月12日

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

Google検索コンソールのインデックスなしページ

8:16 「 [一部のページ]が誤ってnoindexに設定されていました。 これは数ヶ月前に修正されました。 […]検索コンソールを介してインデックスをリクエストしようとしました[そして]サイトマップを再送信しましたが、それでもこれらのページはインデックスに登録されません。 Googlebotがインデックスリクエストをリッスンしない原因や、検索コンソールにインデックスに関する既知の問題があるかどうかについて、何かアイデアはありますか？」

ジョン：「その点で既知の問題はないと思いますが、インデックス作成リクエストの送信に関しては少し保守的である場合があります。これはおそらく部分的にはそこで見られることです。 […]一方で、ページが長期間noindexであることがわかった場合、通常はそのクロールで速度が低下します。 […]また、ページがインデックス可能になると、再びクロールを開始することを意味します。したがって、基本的には、その1種類のプッシュを実行する必要があります。

もう1つのことは、検索コンソールは基本的にWebサイトで認識されているURLを報告するため、画像が実際よりも悪く見える可能性があることです。 これは、たとえば、パフォーマンスレポートを調べて、Webサイトのそのセクション、またはそれらのURLパターンをフィルタリングして、検索コンソールの高noindexページの数が次のページでレポートしているかどうかを確認することで確認できます。それほど重要ではなく、それらのセクションの重要なページは実際に索引付けされています。」

Johnはまた、次のように述べています。「[…]サイトマップは基本的に良いスタートですが、内部リンクを使用して、これらのページがWebサイトにとって非常に重要であることを明確にし、クロールを少し速くすることもできます。 これは、一時的な内部リンクである可能性があります。数週間、ホームページから個々の製品にリンクします。 […]基本的に、内部リンクが大幅に変更されていることがわかった場合は、通常、それらのページも確認します。 したがって、これは、物事を再びインデックスにプッシュするための一時的なアプローチになる可能性があります。 内部リンクを使用すると、これらがWeb全体の重要なページであると言っているのではなく、Webサイトに関連する重要なページであると言っているのではありません。 したがって、内部リンクを大幅に変更すると、Webサイトの他の部分（インデックスがほとんど作成されていない可能性があります）が、ある時点でドロップアウトする可能性があります。 そのため、一時的なレベルでこれを行い、これらをシステムにプッシュして、通常の速度で再クロールされるようにします。次に、内部リンクを変更して、すべてが再び正常になるようにします。 。」

フッターへのリンクの追加に関して、ジョンは次のように付け加えました。 通常、ホームページのように、ウェブサイトの非常に重要なページで見つけることができれば、それは良いことです。[…]これはあなたにとって重要だと言っているので、そのページを再確認します。 」

正規タグと代替タグ

14:25 「WordPressのWebサイトを使用しており、2つのプラグインを使用しています。 [そのうちの]1つは、すべてのページにrel =” canonical”リンクを自動的に追加します。 […][もう1つは翻訳プラグインです]すべてのページにrel=”代替”リンクを追加します。 それはそれが言うことを論理的にしますか：そのURLについては、それは標準的ですが、それは代替でもありますか？ クローラーのどこかで競合しますか？」

ジョンは次のように述べています。 つまり、これら2つのプラグインが何をするのか正確にはわかりません。 全体的な観点から、rel = canonicalが含まれているページがある場合、基本的には標準的な言い回しになります。言及されているリンクには、必要な優先URLがあります。 同じページの場合は、このページがインデックスに登録したいページであることを確認できるので、完璧です。

rel =” Alternative”は基本的に、このページの代替バージョンもあることを意味します。 したがって、異なる言語では、たとえば、英語で1ページ、フランス語で1ページある場合、これら2つの言語バージョン間にrel =” Alternative”リンクがあります。 そして、そのリンクが掲載されているページが代替であると言っているのではなく、これらは2つの異なるバージョンであり、1つは英語で、もう1つはフランス語であるようです。 それらは両方とも標準的である可能性があるので、その組み合わせを持つことは通常問題ありません。

少し注意する必要があるのは、正規の言語が言語を超えてはならないということです。 したがって、フランス語のページでは、基本的に異なるページであるため、英語バージョンに正規に設定されている必要はありません。 しかし、フランス語のページは標準的なものにすることができ、英語のページは標準的なものにすることができ、2つの間に代替リンクがあり、それは本質的に良いセットです。」

正規化またはnoindexタグ

16:49 「コンテンツが薄いか重複している製品バリエーションがたくさんあるeコマースストアのあるWebサイトがあります。 インデックスを作成したいすべてのURLのリストを作成しました[…]。インデックスを作成したくありません。 […]何が良いかわかりません：正規化またはnoindex？」

ジョンは、「別のページにnoindexまたはrel =” canonical”を使用すべきかという一般的な質問は、おそらく絶対的な答えがないものだと思います。 […]もしあなたがそれに苦労しているのなら、あなただけが好きな人ではありません、ああ、私はどちらを使うべきですか？ これは通常、これらのオプションの両方が問題ない可能性があることも意味します。 だから通常、私がそこに見るのはあなたの本当に強い好みが何であるかです。 このコンテンツを検索にまったく表示したくないという強い好みがある場合は、noindexを使用します。 あなたの好みがもっと好きなら、私は本当にすべてを1ページにまとめたい[…]、それなら私はrel =” canonical”を使うでしょう。 最終的には、見ているページが検索に表示されない可能性が高いという点で効果は似ていますが、noindexを使用すると（確実に表示されず、rel =” canonical”を使用すると）表示されない可能性が高くなります。 」

ジョンは次のように要約しています。 たとえば、外部リンクがこのページを指している場合、両方をそこに置くと、このページにインデックスを付けたくないが、別のページも指定したので、いくつかのシグナルが可能であることがわかります。ただ前進してください。」

モバイルファーストのインデックス作成とクロール

28:26 「[…]それに応じてサイトを最適化します[モバイルファーストのインデックス作成用]。 構成に関しては、Googleはそれを行う2つの方法をお勧めします。 1つ目はレスポンシブWebデザインで、2つ目は動的な配信です。 最初の方法は、技術環境を通じて達成するのが少し難しいため、2番目の方法を使用します。 しかし、今日でも、モバイルドメインに向けて毎日20万を超えるクロールが行われていることがわかります。 これは普通のことですか？ […]m-dotドメインがあり、それをメインドメインにリダイレクトしました。」

ジョンは答えました。「そのようなクロールの量は正常です。 リダイレクトされた後でも、システムがドメインのクロールを完全に停止するまでには非常に長い時間がかかるため、それは問題とは見なされません。 私たちのシステムには、このようなことのために非常に長いメモリがある場合があります。サイトをあるドメインから別のドメインに移動したり、サブドメインでこのモバイルを変更したりすると、クロールが完全に停止するまでに何年もかかることがあります。」

Webテクノロジーとランキング

36:00 「通常のHTML、CSS、JS、および別のWebサイト（PWA）で作成されたWebサイトのランキングに関係や影響はありますか？ […]私たちの主要な競合他社の1つが最近それを採用し、SERPランキングが大幅に上昇していることに気づきました。」

ジョンは次のように述べています。「これらは本質的に異なるWebサイトの作成方法であり、さまざまなフレームワークと形式でWebサイトを作成できます。 ほとんどの場合、これらは通常のHTMLページと見なされます。 したがって、JavaScriptベースのWebサイトの場合は、レンダリングしてから、通常のHTMLページのように処理します。 すでに最初にHTMLである場合は、それを行うことができます。 [そこには]さまざまなフレームワークとその背後にあるCMSがあります。 通常、私たちは基本的にそれを無視し、まあ、ここにHTMLページがあり、それを処理することができます。

したがって、競合他社の1つが1つのフレームワークから別のフレームワークに移動し、検索が改善されたという事実だけで、私の観点からは、そのフレームワークの変更はその責任を負わないでしょう。 むしろ、フレームワークの変更に伴い、新しいWebサイトができたのかもしれません。 たぶん、新しいウェブサイトは異なる内部リンク、異なるコンテンツを内部的に持っている、[それは]かなり速いかかなり遅い、ユーザーはそれを本当に気に入っている、あるいは彼らはウェブサイトの立ち上げと一緒にマーケティングキャンペーンを行った。 これらはすべてそこで機能します。これらはすべて、使用しているフレームワークに限定されないものです。」

GooglePageSpeedInsightsとLighthouse

37:39 「GooglePageSpeedInsightsのラボデータの結果は、ChromeブラウザのLighthouseの結果と同じですか？ 彼らは同じ式を使用していますか？」

ジョンは、次のように述べています。 […]通常のコンピューターのように動作しようとする基本的にエミュレートされたデバイスを備えたデータセンターで実行されるPageSpeedInsightsを使用する場合、少し遅くなる制限があります。 […]Lighthouseでは、基本的にインターネットに接続されたコンピューターで実行されます。 Chrome内のLighthouseにもいくつかの制限があり、比較可能であることを確認するためだけにコンピューターで実行できるよりも少し遅く見えるようにするために適用されると思います。

しかし、基本的に、これらは完全に異なる環境で実行されるため、そこでは異なる数値が表示されることがよくあります。 […]オンラインで実行される他のスピードツールでテストすると、[また]異なる数値が表示される場合があります。 また、検索コンソールに表示される検索ランキングに使用するフィールドデータも、ユーザーが平均して異なる種類のデバイスまたは異なる種類のインターネット接続を使用している可能性があるという理由だけで、完全に異なる数値になる可能性があります。 したがって、式が同じであっても、これらのシステムを取り巻く環境全体は大きく異なります。」

Google Discover

47:09 「GoogleDiscoverのウェブサイトに大きな問題があることに気づきました。 2日間で、トラフィックは70％減少しました。 […]それで、私たちは何か間違ったことをしたのだろうか？ […]これほど劇的な引き分けだったので、正確に何が起こったのかを明確にできますか？ […]技術的なエラーでしょうか？」

ジョンは次のように述べています。「あなたのウェブサイトについて具体的にはわかりませんが、多くの人から、Discoverトラフィックがオンまたはオフになっているという報告があります。これは、アルゴリズムによって判断された場合、その間にスペースがほとんどないという意味です。現時点では、DiscoverでこのWebサイトのコンテンツをあまり表示しないため、基本的にそのトラフィックはすべて消えます。 逆に言えば、Discoverであなたのウェブサイトから何かを表示した場合、突然トラフィックが再び急増するのと同じことです。

それが技術的な問題である場合は、Web検索でもそれが表示され、クロールの問題が表示されます。 Discoverで正確に何が起こっているのかについて完全な洞察はありませんが、通常、人々が話している問題は、一方では、おそらくWebサイトの品質がそれほど良くない品質の問題であり、 Discoverの個々のポリシー。 特に、 Discoverについては、ウェブ検索とは異なるポリシーや、アダルトコンテンツ、クリックベイトコンテンツに関して少し異なる推奨事項があります。 […] Discoverのヘルプセンターページにすべて記載されています。 多くのウェブサイトにはこれらすべてが少し混ざっていると思いますが、アルゴリズムが少し多すぎるのではないかと思うことがあります。そうすると、このウェブサイトには注意が必要だと言われます。 だから、あなたのウェブサイトを知らずに、そしてディスカバーがそこで何を拾っているのかについての詳細を知らなくても、それは私がそこに向かう方向です。 […]

私たちの観点からは、Discoverは人々に情報の流れを見せようとする場所であり、そのため、本当にうまく機能するためにそこに提供する必要があるものについての詳細な情報があまりない傾向があります。 そのため、他の人が理解していることを確認することが理にかなっている場合があります。」

反応時間

50:41 「新しいニュースメディアサイトの適切な応答時間はどれくらいですか？」

ジョンによると、「応答時間は、サーバーのクロールにかかる時間を把握する能力に影響を与えるものです。 通常、応答時間は、実用的な観点から、クロールに必要な並列接続の数を制限または制限します。 したがって、Webサイトから1,000個のURLをクロールする場合、それを1日で分散させるための応答時間はかなり長くなる可能性があります。 一方、Webサイトから100万のURLをクロールする必要があり、応答時間が長い場合は、サーバーへの並列接続が多数発生することになります。 サーバーで問題を引き起こしたくないという点で、いくつかの制限があると思います。そのため、応答時間はクロール速度に直接関係しています。

ニュースWebサイトの場合、ニュースであるかどうかではなく、1日にクロールする必要のあるURLの数が問題になります。 それが私がそこで見る角度です。 ニュースのウェブサイトでは、1日に1万ページをクロールしている可能性があり、それらはすべて取り上げられている重要なニュース記事です。 常にアーカイブを更新する必要があるため、1日に何百万もの記事をクロールする必要があるかもしれません[…]。そうすると、明らかに応答時間、クロール速度が異なって見えます。」