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

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

schema.orgバリデーターとGoogle検索コンソールでのスキーママークアップのテスト

7:41 「ジョン、私の最初の質問は、Google検索コンソールが必要な構造化データ要素でエラー[…]をスローしているということです。 しかし、 validator.schema.orgで同じことを確認すると、警告やエラーは表示されません。 したがって、最初の質問は、WebページのAMP実装をチェックするのに適切なサイトですか？ […]「

ジョンは次のように答えました。「そうです。これらのテストツールの目的は少し異なります。 それがおそらくあなたがその違いを見ている理由です。 schema.orgのテストツールは、schema.orgの要件に基づいて、全体的なように、schema.orgマークアップを一般的に理解することを目的としています。 また、検索コンソールのテストツールは、構造化データから引き出して検索機能に表示するために使用できるものに純粋に焦点を当てています。 そのため、そのストーリーの検索部分に焦点を当てています。 また、検索内では、schema.orgマークアップのごく一部のみを使用します。 また、場合によっては、要件がわずかに異なるため、基本のschema.orgマークアップが必要とするよりも特定の要素が必要になることがあります。 そして、それがあなたがその違いを見る理由です。 また、schema.orgバリデーターは理論上のマークアップ用であり、Googleバリデーターは実際にはGoogle検索の実用的な側面用です。 「「

9:20 「[…]基本的に、それはエラーではありません。 検索コンソールでの警告です。 そして、検索コンソールで詳細を確認すると、正しく実行していないと表示されます。 それで、[問題を修正する]可能な方法はありますか、それとも私の開発チームはそれを理解する必要がありますか？

ジョンは次のように説明しました。「ええ、それが警告であれば、私はそれについて心配しません。 それは基本的にあなたが何か違うことをすることができたと言っているだけです。 […]。 違いを正確に知りたい場合は、 developers.google.comの検索用ドキュメントを再確認してください。ここには、すべての構造化データと、すべての必須フィールドと推奨フィールドがあります。 そして、おそらく推奨またはオプションのフィールドの1つが、この警告をトリガーしているものです。」

ページがクロールされてもインデックスに登録されない理由

14:11 「 […]特定のページが複数回クロールされたにもかかわらず、インデックスに登録されなかった理由として考えられるものは何ですか。 」

ジョンはこう答えました。 それほど頻繁ではないと思います。なぜなら、通常、何かをクロールすることを決定したときは、外に出てインデックスを作成することも非常に喜ばしいからです。 しかし、ページをクロールして、最終的に、実際にはインデックスを作成する必要がないと判断する場合があります。

[…]それが発生する可能性のあるいくつかの一般的な状況は、おそらくあなたの場合には当てはまりませんが、ページにエラーコードがある場合です。 最初にクロールする必要があり、次にエラーコードが表示されます。 ページにnoindexがある場合は、最初にそれもクロールする必要があり、次にnoindexが表示されます。 ページがすでに見た他の何かの完全な複製である場合、それをクロールし、複製であることがわかりますが、再びプライマリページに焦点を合わせます。 したがって、これらは、何かをクロールし、インデックスを作成しない通常の状況の一種です。 しかし、何かをクロールしてから、インデックスを作成するまでに、実際には、代わりにWebサイトから何かを取得したいと思うこともあります。 」

15:41 「[…][すでに述べたもの以外の]他のどのような要因がGooglebotに決定を下す可能性がありますか？最後にインデックスを作成したくないですか？」

ジョンは言いました。 全体的なWebサイトの品質が確かに重要な役割を果たしていると思いますが、通常、Webサイトの品質について確信が持てない場合は、そもそもページをクロールしないでしょう。 ですから、それはちょっとトリッキーな状況だと思います。 また、検索コンソールを見ると、ほとんどすべてのサイトで、検出されたがインデックス付けされていないグループと、クロールされてインデックス付けされていないグループが表示されると思います。 これは、サイト間でかなり一般的だと思います。」

質問をしている人は、ページの品質と技術的な問題以外に調べなければならないことが他にあるかどうかを知りたがっていました。 ジョンは、1つのページに集中しすぎないように勧めました。「その特定のページに集中しすぎないことも重要だと思います。 したがって、技術的な観点から、すべてが問題ないと確信している場合は、その特定のページの品質が問題であるとは思いませんが、Webサイトのその部分またはウェブサイト全体。 それは、物事を改善するためにあなたが何ができるかを見ようとする場所のようなものです。個々のページがインデックスに登録されなかっただけでなく、そのページの全体像はどのようなものですか。 」

eコマースサイトの商品リストを削除すると、不利になる可能性がありますか？

21:48 「 eコマースのウェブサイトを運営しており、カテゴリページを大幅に更新したい段階にあります。 […]1つのドラフトで、製品リストを削除したいと思います。 つまり、ファセット検索を使用した商品リストがあり、探している商品をフィルタリングできます。 […]カテゴリページの商品リスト全体を削除すると、最初に他のすべての競合他社がこの種の商品リストを持っているため、ランキングに不利になりますか？ そして第二に、これはeコマースページの確立された要素であり、ユーザーは[…]すべての製品の概要を把握し、フィルターを使用して必要な製品を検索できると期待しています。 」

ジョンは次のように答えました。「 SEOの観点からは問題はありません。 あなたが気をつけたいと思うさまざまなことがあると思います、[…]私たちがそこにきれいなリンクを持っている個々の製品のすべてをまだ見つけることができるように。 ただし、このカテゴリページを再設計して、情報ページのように見せたいだけの場合は、問題はないと思います。 また、とにかく検索でそのような種類のカテゴリページに特別なことをすることはないと思います。そのため、その観点からは、基本的にデザインを変更するだけです。  

商品ページの場合は違うと思いますが、商品ページを認識し、価格、在庫状況などを把握するため、完全に変更することになりました。 そして、あなたがそれを完全に異なって見えるようにしたなら[…]、それは私たちが製品ページを拾う方法とそれを製品検索結果に表示できるかどうかに影響を与えると想像できます。 しかし、私が知る限り、カテゴリーページには特別なことは何もしていません。 したがって、基本的にそれらを非表示にして、製品へのリンクを引き続き見つけることができることを確認してください[…]それを行うことができます。 しかし、それらについてより多くの情報を提供することによってそれらをより有用にしたいのであれば、それは良い考えだと思います。」

質問の最後に、ジョンは、ユーザーの観点から変更を確認することが重要であると付け加えました。「[…]あなたが言った「ユーザーは混乱するだろう」。 私はそれを再確認します。 つまり、SEOの観点からは、それはまったく問題ないと思いますが、ユーザーの観点からは、おそらく最初にテストしたいものです。」

内部リンク構造の重要性

25:18 「ブレッドクラム設定用の構造化データがある場合、内部リンクはSEOにとって依然として重要ですか？」

ジョンはこう答えました。 これは、SEOにとって内部リンクが非常に重要なものです。 これは、Googleをガイドし、訪問者を重要だと思うページに誘導するためにWebサイトで実行できる最大のことの1つだと思います。 そして、あなたが重要だと思うことは完全にあなた次第です。 あなたはあなたが最もお金を稼ぐところで物事を重要にすることを決めることができます、あるいはあなたが最も強い競争相手であるかあなたが最も弱い競争相手であるところで物事を重要にすることができます。 内部リンクを使用すると、サイトのそれらの方向とそれらの部分に焦点を当てることができます。 そして、それは構造化データに置き換えることができるものではありません。

したがって、ページのどこかに構造化データがあるからといって、それが通常の内部リンクの代わりになるとは思いません。 構造化データでURLも指定した場合でも、ページで通常の内部リンクを使用する場合と同じようにそれらのURLを使用することはありません。 したがって、hreflangアノテーションが国のバージョン間のリンクを置き換えたり、breadcrumbアノテーションがWebサイトの異なるレベル間のリンクを置き換えたりすることは絶対にありません。 あなたは本当にあなたのウェブサイトの異なる部分の間に通常のHTMLリンクを持っているべきです。 そして、理想的には、基本的なリンクのセットを用意するだけでなく、戦略的な方法でそれを見て、何を最も気にかけているのかを考え、内部リンクでそれをどのように強調できるでしょうか。 」

商品リストページの複数の商品スキーマ

29:50 「商品リストページの場合、商品リストページに複数の商品スキーマを実装できますか？ 」

ジョンは次のように述べています。「ポリシーの観点からは、そうするべきではないと思います。少なくとも前回、構造化データに関するポリシーを確認したときは、製品の構造化データについては、プライマリに適用する必要があるためです。ページの要素。 また、1つのページに複数の商品がある場合、そのうちの1つがページの主要な要素であるとは限りません。 したがって、その観点から、カテゴリページで複数の製品構造化データ要素を使用しないでください[…]。 」

混合言語のページを作成すると、ランキングが低下する可能性がありますか？

30:30 「混合言語が使用されているページのベストプラクティスはありますか？ たとえば、日本のインターナショナルスクールは日本人と外国人の家族を対象としていますが、ホームページのほとんどの情報は英語で保管しています。 日本語のページにもサポートを追加します。 […]私たちの実生活でのコミュニケーションは混合言語であるため、ホームページにそれを反映させると、より自然に感じられます。 ページが意図的に混合言語である場合、検索で罰せられますか？」

ジョンは、「そのような場合、ページが罰せられるとは必ずしも言えません。 しかし、私たちはページの主要言語が何であるかを理解しようとします。それは、このページを表示できるクエリの種類を理解するのに役立ちます。 ですから、このような場合はちょっとトリッキーだと思います。

1ページに複数の言語がある場合も理解できます。 誰かが英語で検索している場合、これが彼らに表示するのに適切なページであることを私たちが本当に明確にするのは非常に簡単です。 だから私はホームページのようなものを想像することができました、多分そのミックスまたはわずかなミックスを持つことは理にかなっています。 主要な英語として1つのホームページがある場合は、日本語の要素を含めることができます。 主に日本語で、英語の要素がいくつかある別のバージョンがある場合は、問題ありません。 しかし、ほとんどの場合、これは英語のページであることを本当に理解するのに役立ちます。 そして、誰かが日本の特定の種類のインターナショナルスクールを英語で検索している場合、私たちが言うのは理にかなっています。あなたのニーズに合っていて、あなたが私たちに与えた質問に一致することがわかっている英語のコンテンツがあります。 したがって、その観点から、ページが罰せられるとは限りませんが、システムがそのページを適切にランク付けする方法を理解するのは非常に困難です。

ここで考えることができることの1つは、検索コンソールで、Webサイトまたはホームページに送信されるクエリを確認することです。 そして、Googleが言語を正しく理解しなかった場合、これらのクエリのどれが影響を受ける可能性があるかを考えてください。 そして、ほとんどの人があなたの名前や学校のブランドを検索しているのであれば、基本的に、それはまったく影響を受けないでしょう。 一方、ほとんどの人がより広いクエリ、より一般的なクエリを検索している場合、ホームページの何かに一致する文のように、検索結果に表示するのが少し難しいと想像できます。 、あなたのホームページが実際にそのクエリのその言語であるかどうかわからないという理由だけで[…]。

また、[…]ホームページをこのバイリンガルバージョンのようなものにすることもできます[…]が、個々の言語用に個別のページを追加で作成して、誰かがインターナショナルスクールに関する長い情報を探している場合にこれで、彼らはまだそれらの純粋な英語またはほとんど英語のページを見つけることができ、そこからあなたのウェブサイトの残りの部分に移行します[…]。

モバイルバージョンとデスクトップバージョンのコンテンツの違い

34:20 「モバイル版とデスクトップ版のコンテンツに違いがある場合、それはGoogleがウェブサイトを罰してウェブサイトのランキングに影響を与えることを意味しますか、それとも単にGooglebotがモバイル版でそれを見つけることができるという意味ですか？ランク付けできませんか？ 」

ジョンは次のように述べています。「そのため、ほとんどの場合、インデックス作成のほとんどをモバイルファーストのインデックス作成に移行しました。つまり、そのような場合にのみ、モバイル版のウェブサイトを確認します。 したがって、基本的に、デスクトップバージョンのWebサイトでわずかに異なるものがある場合、ほとんどの場合、それを検索に使用することはありません。 つまり、違いのためにWebサイトを罰するのではなく、Webサイトの一方のバージョンを見るだけで、もう一方のバージョンが何であるかさえわからないということです。 。  

そして、まだデスクトップインデックスに登録されている少数のサイトの場合、それは逆に当てはまります。 もちろん、デスクトップバージョンではないモバイルバージョンに[…]何かがあり、デスクトップクローラーによってインデックスが作成されている場合、それは実際にはわかりません。 代替バージョンを時々クロールしますが、それをクロールして詳細情報を取得するのではなく、デスクトップURLとモバイルURLの間にこの接続があることを確認するだけです。 」

サイトマップをクラウドでホストできますか？

46:20 「何百万ものURLを含む非常に巨大なページがあり、[…]サイトマップは現在改装中です。 また、ITチームは、新しいサイトマップファイルをクラウドサービスに保存することを検討しています[…]。 つまり、example.com/sitemapsからcloud.com/sitemapsへ。 そして、私たちは疑問に思っています、それは私たちがサイトマップをクラウドに保存する場合の問題ですか？ それが問題ではない場合は、このexample.com/sitemapの古いURLの永続的なリダイレクトも作成する必要がありますか、それとも移動をどのように計画する必要がありますか？ 」

ジョンは次のように述べています。「サイトマップファイルを別の場所でホストすることは間違いなく可能です。 それを行うには2つの方法があります。 1つは、これらのドメインの両方を検索コンソールで確認した場合、それは機能します。 もう1つの方法は、robots.txtファイルを使用して送信する場合です。ここで、「sitemap：」を指定してから、サイトマップのURLを指定します。 別のドメインに移動することもできます。 […]クリーンにするために古いサイトマップファイルを新しい場所にリダイレクトしますが、おそらく古いサイトマップURLを削除して新しいサイトマップのURLを正しく送信したとしても、それでうまくいくはずです。  

少し注意が必要なのは、検索コンソールがUIに直接表示する方法がわからないことです。特に、サイトマップファイルが別の場所にある場合、検索コンソールがインデックスレポートにサイトマップ情報を表示する場合は、例えば。 しかし、それは報告の問題です。 これは、サイトマップファイルの機能に依存するものではありません。 検索コンソールに正しく表示されないだけです。 そして、繰り返しますが、多分そうです。 100％確信が持てません。 」

ドメインの履歴はあなたのウェブサイトに影響を与える可能性がありますか？

49:40 「[…]それで[前のSEOオフィスアワーの間に]私たちはエスコートサービスプロバイダーとしての歴史を持つドメインについてその質問を投げかけました。 […]そのウェブサイトの最初のスナップショットは1997年のものであるため、ドメインには長い歴史があります。[…]昨年6月にウェブサイトをリニューアルしました[…]。 そして、私たちが抱えている主な問題は、[…]まだ[アダルトコンテンツとして]フラグが立てられていることです。 さらに、この問題があります[…] –クロールされ、現在インデックスに登録されていません。 また、ドメインの履歴が、インデックス作成に問題があることに実際に影響を与える可能性があるかどうかを理解しようとしています。 […]私たちが公開しているコンテンツは高品質であると信じています。 内部的にリンクされており、質の高いサイトの構築に努めています。 現時点で苦労しているのはページのパフォーマンスであるため、そのために最適化することは現在進行中です。 ただし、 prerender.ioを使用しているため、Googleに表示されるのはすでに事前レンダリングされたバージョンです。 ですから、灯台のスコアに関しては、すべて良いです。 […]インデックスが作成されない理由を理解するために、何を改善または探すことができますか？ URLも共有できてうれしいです。 「「

ジョンは後でURLを確認できると提案し、次のように答えました。「通常、以前にウェブサイトにアダルトコンテンツがあった場合、インデックス作成の側面は関係ありません。

以前にそこにあったコンテンツが非常にスパムであった場合、インデックス作成側が影響を受ける可能性があります。 つまり、インデックス作成の観点から、この新しいWebサイトが実際にはまったくスパムではないことを理解するのに少し時間がかかる場合があります。

しかし、以前にアダルトコンテンツがあっただけの場合は、セーフサーチフィルターがそれを認識するのが少し遅いのではないかと想像できます。 私たちはそれをより速くするためにいくつかの措置を講じたことを知っています[…]、あるいはセーフサーチにある種のこだわりがある何か他のものがあるかもしれません。

セーフサーチ側は、サイトクエリを実行してからセーフサーチのオンとオフを切り替えるかどうかを確認できるものです。 セーフサーチから何かが起こっているかどうかを確認できるはずです。 ただし、インデックス作成に関してはわかりません。 しかし、後でこれを見ることができ、私があなたに知らせることができる非常に明白な何かがあるかどうかを見ることができます。 」