SEOオフィスアワー– 2021年12月24日

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

ペイウォールコンテンツとクローキング

00:49 「ペイウォールコンテンツを含むペイウォールデータに関して。 […]ウェブサイトがあります。 私たちはたくさんの記事を書きました、そしてすべてがグーグルにアクセス可能です。 そこにペイウォールを追加したいのですが、[…] […]のみ[…]あなたが持っている構造化データスニペットを使用してペイウォールコンテンツをGoogleに表示します。 クローキングと見なされますか？

そこで、それがGooglebotであるかどうかを確認し、[…]構造化データ– […]ペイウォールデータのみを表示します。 しかし、通常のユーザーには[…]、構造化データは表示しませんが、それで問題ありませんか？」

ジョンは、このソリューションの問題を認識していませんでした。 技術的には、それでもクローキングと見なされます。これは、別の何かを表示しているためですが、ポリシーからは許容できます。 ユーザーは、[…]ペイウォールを通過すると、[…] Googlebotに表示しているコンテンツが表示されるためです。」

潜在的なインデックスの問題

03:38 「高品質のコンテンツを公開し、サイトマップを送信し、Google検索コンソールからインデックス作成をリクエストすることもあります。 しかし、新しいコンテンツのインデックス作成にまだ問題があるか、[遅延して]インデックスが作成されています。 […]これはGoogleのバグですか、それとも新しいアルゴリズムの更新ですか？」

ジョンは次のように答えました。「その点で私たちの側にバグはありません。 […]すべてのコンテンツにインデックスを付けるわけではなく、一部のWebサイトは大量のコンテンツを生成します。 そして、すべてにインデックスを付けなければ[…]、それで問題ありません。 しかし、すべてにインデックスを付けたいと思うかもしれません。私たちは常にすべてを行うことはできません。

トリッキーな部分[…]は、過去には、[…]多くのWebサイトが技術的にそれほど優れていなかったことです。 どの種類のコンテンツがインデックスに登録されなかったかが少し明確になりました。 今日、ウェブサイトは技術的には問題ありません、そしてそれは[…]品質バーが少し高いようです[…]。 理論的には誰でもインデックスを作成できるものを公開できますが、[…]ユーザーにとって実際に有用で関連性のある正しいものをインデックスに登録していることを確認する必要があります。 そのため、インデックスを付けないままにしておく必要がある場合があります。」

製品レビューの更新–影響を受ける言語と国

14:01 「製品レビューの更新について。 […]アップデートが英語圏のWebサイトにのみ影響する場合でも、ドイツ語検索でもいくつかの動きが見られました。 この製品レビューの更新やその他の種類によって、他の言語のWebサイトにも影響があるのではないかと思っていました[…]？」

ジョンが言ったように、「私の仮定は、これはグローバルであり、すべての言語にまたがっていた[…]。 しかし、通常、私たちはエンジニアリングチームにそれについて決定を下すように促し、ブログ投稿に適切に文書化できるようにします。 それが製品レビューの更新で起こったかどうかはわかりません。 […]私たちが複数の言語で行うことができ、英語だけに縛られることはないようなもののようです。 また、最初は英語だったとしても、全体的に関連性のあるもののように感じます。時間の経過とともに、他の言語にも展開する方法を模索する必要があります。 ですから、ドイツで変化が見られても、特に驚くことではありません[…]。」

Googleのブログ投稿では、英語のWebサイトに影響する更新についてのみ言及されていることを知った後、ジョンはさらに詳しく説明しました。

「この種の更新では、1つの言語または1つの場所から始めて、何を調整する必要があるかを確認し、そこから拡張します。 […]よりコンテンツに関連するものでは、通常、さまざまな言語に拡張するのに少し時間がかかります[…]。」

英語圏の国向けのローカライズページ

17:53 「英語圏の異なる国で同じページのセットをローカライズする他の方法を知っていますか？ […]オーストラリアやニュージーランドのサブドメインなど、.joトップレベルドメインを持つサブドメインがいくつかあり、国をJSAバックエンドに設定し、ページレベルでもhreflangを使用しています。 […]これらのサブドメインをローカライズするのに役立つ他の方法を見つけることができませんでした。 改善できる良い方法や方法はありますか？」

ジョンがこのトピックについて話し合った方法は次のとおりです。

「あなたは主なものをカバーしたと思います。 これは、検索コンソールとhreflang設定でのジオターゲティングです。

ジオターゲティングはサブディレクトリまたはサブドメインレベルで機能し、そこにあるすべてのページです。

Hreflangはページごとにあります。 ある国のホームページと同じ国の異なる製品ページがある場合は、それらの各ページをhreflangと相互リンクする必要があります。

私がいつもお勧めするもう1つのことは、ある種のバックアップ計画を立てることです。[…]ユーザーが間違ったバージョンのサイトにアクセスしていることを認識したときに表示できるJavaScriptベースのバナーのようなものです。 たとえば、オーストラリアのユーザーがイギリスのページにアクセスした場合、「ねえ、このページのオーストラリア版がここにあります」というJavaScriptバナーを表示できます。 直接そこに行くことができます。」 JavaScriptベースのバナーの利点は、robots.txtでブロックできるため、インデックス作成の観点からバナーが表示されないことです。 また、自動的にリダイレクトしない場合、[…] [検索エンジン]はこれら2つのバージョンを個別に処理できます。

これらのページが本質的に同じである場合、これらのページの1つを正規バージョンとして扱う可能性があります。 たとえば、ニュージーランドとオーストラリアのページがあり、コンテンツ全体が同じである場合、わずかに異なるのはページの通貨だけです。[…]これらのページを折りたたんで、次のように選択します。正規であり、それを検索の基礎として使用します。

hreflangをお持ちの場合は、それらのページでも、hreflangを使用して正しいバージョンのURLを表示します。 ただし、インデックスに登録されたコンテンツは正規バージョンのものであり、検索コンソールのすべてのレポートは正規バージョンのものになります。 それは時々少しトリッキーになります、特にあなたが[…]異なる国のために同じコンテンツを持っているより大きなウェブサイトを持っているなら。」

ページへの動的コンテンツの追加

25：0 「私のウェブサイトには、カテゴリ、サブカテゴリ、製品、eコマース[…]ページなど、何百万ものページがあります。 […]数百万のページ[…] [難しい]個別のコンテンツまたは[…]各ページに固有のコンテンツを追加するのが難しいため、動的コンテンツを追加しました。 カテゴリページ、サブカテゴリページ、および製品ページに[…]テンプレートベースのコンテンツを追加しました。 […]それは私たちのウェブサイトのパフォーマンスに良いかどうか、または各ページのコンテンツを更新する必要がありますか？ […]」。

ジョンの反応は次のとおりです。

「関連するコンテンツをページに動的に追加することは理にかなっています。なぜなら、[…] [それ]は本質的に[…]データベースルックアップを実行し、それに基づいてコンテンツを追加するだけだからです。 […]それは本当にあなたがそれをどのように設定しているかに依存します。

私が避けたい主なことは、あなたが人為的に追加したキーワードに対してこのページがより良くランク付けされることを期待して、あなたが人為的にコンテンツをページに追加している状況に遭遇することです。 […]ユーザーがそこに行くと、「なぜこのページにこれらのランダムなキーワードがあるのですか？」のようになります。 […]これらの重要なキーワードに関連性の高い優れたコンテンツが実際にあることを確認してください。それが私が焦点を当てる内容です[…]。」

ジョンは、ページが価値を提供していると見なすために、Googleが各ページに関連するコンテンツを書く必要があるかどうかをさらに尋ねられたとき、次のように述べました。

「それは関連性のあるページ上の何かでなければなりません。 そして、それがカテゴリーページである場合、そこにリストした製品は非常に関連性があり[…]、通常、そのカテゴリーの説明があります。 […]これらすべての製品とそれらがどこから来たのかについて、下部にWikipediaの記事を書く必要があるわけではありませんが、[…]ページに関連する少しの情報が重要です。」

JavaScriptファイルのレンダリングとインデックス作成

28:28 「私のウェブサイト[…] [使用]クライアント側のレンダリングに反応します。[…] JavaScriptとブラウザをオフにすると、私のページは完全に空白になります。 それがランキングの低下の原因である可能性がありますか、それともWebページのパフォーマンスの低下の原因である可能性がありますか？」

ジョンの返答は次のとおりでした。 […]検索では、レンダリングを行い、ページでJavaScriptを処理します。 通常のブラウザで表示されていて、特に悪いことをしていない場合は、それらのページに通常どおりインデックスを付けることができます。 検索コンソールの[ URLの検査]ツールで再確認して、 Googlebotがページをレンダリングしようとしたときにコンテンツが実際に表示されているかどうかを確認できます。コンテンツが表示されている場合は、すべて設定されているはずです。」

Webサイト内の検索によって生成されたURLのインデックス作成

30:11 「私たちはすでに私たちのウェブサイトに検索ボックスを追加しているので、ユーザーは私たちのウェブサイトに来てそこで検索し、検索ごとに一意のURLを生成します。 これらのURLはインデックスに登録できるかどうか？」

ジョンが言ったように、「通常はそうではありません。 […]その主な理由は2つあります。

一方では、検索が異なるだけのURLがさらに100万個あり、それが何の価値ももたらさない状況に陥るのは非常に簡単です。 私たちはそれを無限の空間と呼んでいます[…]。 それは避けたいものです。

もう1つ避けたいのは、検索ボックスでスパム行為を行い、それらのインデックスを作成しようとすることです。これは、電話番号や[…]業種[…]の検索などです。 突然、あなたのウェブサイトの検索ページはその種のビジネスにランク付けされ、それらのクエリに一致するコンテンツがない場合でも、電話番号が表示されます。[…]検索結果に表示されるようにこれを行います。 この種の検索ページをrobots.txtでブロックします。 そうすれば、どのコンテンツにもインデックスを付けることができないことを確信できます。」

YMYLとしてのSEOサイト

31:55 「SEO会社はあなたのお金またはあなたの人生のウェブサイトとして分類されますか、それとも医療および財務アドバイスのウェブサイトにのみ関連していますか？」

ジョンによると、「[…] SEOのウェブサイトは人々の生活にとってそれほど重要ではないと思います。 明らかに、あなたがSEO会社で働いているなら、あなたはそれに縛られていますが、それはウェブサイト自体があなたのお金やあなたの人生のタイプのウェブサイトであるということではありません。 […]何かを販売するすべてのウェブサイトがこのカテゴリに分類されるわけではありません。

ここで私がお勧めするのは、「このタイプのWebサイトはこの特定のカテゴリに分類されますか？」を盲目的に見ようとするのではなく、[…]このカテゴリの由来、つまり品質評価者ガイドラインを読んで、もう少し理解することです。 Googleがこれらのさまざまなタイプのウェブサイトを理解するために何をしようとしているのか。 […]これにより、実際に何が起こっているかについて、もう少し背景情報が得られます[…]。」

ブレッドクラム構造化データの実装

39:56 「ブレッドクラムの構造化データに関しては、訪問者がページに表示するブレッドクラムとまったく同じである必要がありますか？ 構造化データが完全なブレッドクラムパスであるのに、ページにブレッドクラムの要約バージョンが表示されることがあります。 どちらも受け入れ可能なオプションですか？」

ジョンが言ったように、「[…]構造化データがページに表示されているかどうかを認識しようとしています。 そして、そうでない場合は、「検索結果にこれを表示することはまだ意味がありますか？」と理解する必要があります。 」

ページに短いバージョンのブレッドクラムを表示するようなことをしていて、それを一致させることができない場合、実際にそのブレッドクラムマークアップを取得して使用すると、少しヒットしてミスする可能性があります。

個々のパン粉または[…]パンくずリストの個々のアイテムを取得していて、それらのすべてではなく一部だけを表示している場合は、それらを取得しただけである可能性があります。 […]パンくずリストの一致がたくさんあるので、残りをまだ拾っている可能性があります。

他の種類の構造化データと同様に、ページに表示されていない場合に備えている完全なブレッドクラムマークアップを取得して使用できることは保証されていません。

主な例外は[…] FAQマークアップだと思います。ここでは、質問と回答があります。[…]重要な部分は、質問が実際に表示されることです。回答は、ページですが、[…]少なくとも表示されている必要があります。」

ウェブサイトの一部のページのみを翻訳する

44:00 「私たちは300ページ未満のインデックスページをすべて英語で掲載しているサイトを運営しています。 これらのページの約半分をスペイン語に翻訳することを検討しています。これらのページは、/ ESなどの同じドメインのサブディレクトリに配置され、英語コンテンツの代替言語バージョンとしてタグ付けされます。 ページのコンテンツの一部だけを翻訳しても大丈夫ですか、それとも英語のWebサイトを正確に反映し、他の場所でランク付けされる可能性が最も高いようにすべてを翻訳する必要がありますか？」

ジョンは次のように述べています。「ウェブサイトの一部のページを翻訳するだけでも問題ありません。 ページの言語を個別に調べます。 スペイン語のページがある場合は、誰かがスペイン語で検索しているときに、それらのスペイン語のページを確認します。 私たちが言うのはそうではありません： 'ここにはスペイン語のページよりもはるかに多くの英語のページがあります。 したがって、スペイン語のサイトはそれほど重要ではありません。 […]これらはスペイン語のページであり、スペイン語で上位にランク付けできます。 […]ユーザーにとっては、できるだけ多くのコンテンツを翻訳することが理にかなっている場合があります。 しかし、通常、これは時間の経過とともに段階的に改善されるものであり、いくつかのページから始めて、それらを適切にローカライズし、さらにページを追加します[…]。

hreflangアノテーションもページごとにあります。 英語とスペイン語のページがいくつかあり、それらをリンクしている場合、それはまったく問題ありません。 スペイン語だけのページがある場合は、それで問題ありません。hreflangは必要ありません。 英語だけのページもありますが、それでも構いません。 その観点からすると、これは開始するのに合理的な方法のように思えます。」

クロール予算と自動生成されたURL

46:12 「私が話しているウェブサイトはWordPressのウェブサイトです。 複数の不要なURLを自動的に生成します。 […]これらのURLを見つけるためにクローラーを停止する方法はありますか？ 私はそれを「noindex」できることを知っています、そしてそれらはすべてインデックス付きのURLではありません。 しかし、その後、検索コンソールの[除外]部分でそれらを確認できます。 […]これはニュースウェブサイトで、何千ものURLがあります。 […]それはクロール予算に影響を与えるでしょうか？」

ジョンはウェブサイトのサイズについて尋ねたところ、それは5,000から10,000のURLの間であると言われました。

それを踏まえて、ジョンは次のように述べています。 […]その数のページをかなり速く、通常は数日以内にクロールできます。 もう1つ[…]は、 「noindex」がページ上のメタタグです。 メタタグを表示するにはページをクロールする必要があります。つまり、「noindex」ページをチェックすることは避けられません。 […]ページに「noindex」があることがわかった場合、通常は時間の経過とともに、それらのページをクロールする頻度は低くなります。 それでも時々再確認しますが、他の方法で索引付けされている通常のページほどは確認しません。 もう1つのアプローチは、robots.txtを使用することです。 robots.txtファイルを使用すると、これらのページのクロールを完全にブロックできます。 欠点は、ページのコンテンツではなく、検索結果でURL自体にインデックスを付けることができる場合があることです[…]。」

ジョンはまた、次の例を示しました。

「[…]サッカーニュースのウェブサイトがあり、ブロックされている記事とクロールが許可されている記事がある場合、誰かがサッカーニュースを検索していると、インデックスに登録可能なバージョンのページが見つかります。 robots.txtによってブロックされている他のページがあるかどうかは関係ありません。 ただし、誰かがこれらのブロックされたページに対して明示的にサイトクエリを実行すると、検索でそれらのURLを確認できます[…]。 あなたのような状況では、[…]クロールの予算について心配する必要はありません。」

ジョンはまた、次のように付け加えました。「実用的な観点からは、「noindex」とrobots.txtはどちらも同等です。 […]このコンテンツはおそらく検索結果に表示されないでしょう。「noindex」がある場合はクロールする必要がありますが、数値が非常に小さいため、実際には問題になりません。 robots.txt […]」によってブロックされている場合でも、URLを使用してインデックスを作成する可能性があります。

推奨される方法について、ジョンは次のように述べています。 […] WordPressを使用していて、投稿に「このページのnoindex」というチェックボックスを付けることができる場合は、おそらくそれが最も簡単なアプローチです[…]。」

パラメータを使用したURLのクロール

54:25 「ログファイルを確認し、IEPを介したGooglebotであることを証明しました。これは、オーガニックボットからUTMパラメータURL、Googleディスプレイ、ユニバーサルアプリキャンペーンへの多くのクロールです。 […]これらのURLへのリンクはどこからも見られません。 […]これがどこで、またはなぜ起こっているのかについて何か考えがありますか？」

ジョンは次のように回答しました。「Googlebotで広告キャンペーンにリストされているページもクロールする場所[…]は、商品検索用です。 商品検索フィードまたはマーチャントセンターフィード[…]を設定している場合は、Googlebotでそれらのページをクロールして、マーチャントセンターでそれらを取得できることを確認します。 そこにタグ付きURLがある場合、[…]それらのタグ付きURLを保持し、再処理します。

他の人がこの種の製品を提出できる可能性もあります。[…]提出するのは必ずしもあなたではないかもしれませんが、あなたに代わって作業している、またはそれを行う許可を持っている人かもしれません。

これらのページへのリンクがどこかにある場合は、クロールを試みます。 ウェブサイト内の内部リンクにタグを付けた場合でも、それを取得してクロールしようとします。 JavaScriptで設定されているものがあり、これらのパラメータがどこかに設定されているトラッキングURLがある場合、JavaScriptを処理すると、それらのトラッキングURLへのリンクのように見えます。これも処理できます。 […]それは個々のケースではなく[…]、むしろこれらのURLの数が多いように思えます。それは、マーチャントセンター側のように感じます。」