SEOオフィスアワー–2021年10月8日

公開: 2021-10-15

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

内容を隠す

1索引付けされたページの数とサイト権限

2Webサイトの主な目的を評価する

3リンクのリダイレクト

4コアアップデートからのリカバリ

ゲスト投稿の5つのリンク

6ランキング要素としての製品価格

7サイトマップ間でのURLの移動

8マルチリージョンコンテンツ

9サイト移動でのリダイレクト

10APIとクロール予算

11JavaScriptとGoogleのキャッシュ

索引付けされたページの数とサイト権限

03:52 「それで、あなたは過去に何度か、大きなサイト[…]がより小さなページのセットに焦点を合わせるように勧めました[…]。私が現在取り組んでいるサイトには、[…]トラフィックがまったくない、古いページが1,000ページあるので、それらを削除することをお勧めします。しかし、私たちの開発チームは、Googleがあなたのサイトのインデックスを作成するページが多いほど、サイトに帰属する権限が高く、ページを削除することを躊躇しているという印象を受けていたという疑問があります。それに光を当てていただけませんか？」

ジョンが言ったように、 「あなたがより多くのページを索引付けしているなら、あなたのウェブサイトがより良いと私たちが考えるということは絶対にありません。 […]多くのページにインデックスを付けることが理にかなっている場合があります。時々、それらはそのように索引付けされた一種の有用なページです。ただし、インデックスに登録されるページ数に関しては、品質の兆候ではありません。特に、[…] 1,000、2,000、5,000ページについて話している場合、これは一般的なシステムではかなり少ない数です。そして、5,000ページが1,000ページよりも優れていると言っているわけではありません。私たちにとって、それはすべての種類のようなものです、まあ、それは小さなウェブサイトであり、私たちはそこから引き出すことができるものでやり遂げます。そしてもちろん、小さなウェブサイトは相対的です。無関係なウェブサイトだと言っているわけではありません。小さいかもしれませんが、それでも非常に役立つかもしれません[…]」。

Webサイトの主な目的を評価する

10:03 「前回、ウェブサイトの問題について話しました[…] –これはeコマースのウェブサイトで、情報やトランザクションの情報があります。 […]あなたのアドバイスは、このコンテンツをトランザクション指向のページと情報指向のページに少し分けることでした。だから私はこれに関して別の質問があります。たとえば、eコマースWebサイトがあり、巨大なブログや雑誌など、情報がたくさんあるようなものがある場合、それは古いセクションです。一方、これらすべての製品ページやカテゴリなどがあります。それで、純粋な情報のものを含むこの巨大なブロックは、ウェブサイト全体に一種の情報的なタッチまたはキャラクターを与えるので、Googleは、これが[…]人々が物を買うのではなく情報を得ることができるものであるかどうかはわかりません。この評価はページごとに行われますか？」

ジョンは次のように述べています。「[…]私の理解では、これはページレベルのものです。 […]多くのウェブサイトには、さまざまな種類のコンテンツが混在しています。次に、これらのページのどれが検索者の意図に一致するかを把握し、それらを適切にランク付けしようとします。 […]

つまり、ニュースWebサイトでよく見られます。 […]最近のイベントがありますが、発生した古いイベントのセクションもあります。[…]他の大きなイベントの場合は、分離されたアーカイブセクションがあります。そして、それらは非常に異なる意図です。実際に起こっていることをしたい場合、またはある種の情報調査、常緑樹タイプのコンテンツが必要な場合。

[…]私たちはページごとにそれを見る必要があります、そして、ああ、ここにいくつかの研究コンテンツがあるので、これは研究ウェブサイトであるとは言わないでください。

リンクのリダイレクト

13:21 「人々が[…]私たちの、たとえばページのサブカテゴリにリンクしているのを見ています。そして問題は、[…]私たちのコンテンツが行き来することです。つまり、一部のカテゴリにはより多くのコンテンツが表示されることがあります。コンテンツが削除されることがあります。そのため、サブカテゴリを作成したり、非表示にしたりすることができます。そして、それらがもはや存在しないサブカテゴリーにリンクしているので、私たちはバックリンクからのたくさんの紹介を見ています。ここでの私の質問は、これらのリンクを親カテゴリにリダイレクトしても大丈夫ですか[…]。そして、そうする場合、どのようにそれを行うのでしょうか？たとえば、302ではどうでしょうか。一時的なリダイレクトのように、将来、このサブカテゴリにはコンテンツが再び表示される可能性があるため、[…]永続的なリダイレクトではありません。」

ジョンは次のように答えました。「したがって、これが親レベルにリダイレクトする大規模なものである場合、おそらくそれはソフト404と見なされます。[…]そして、404コードの代わりにリダイレクトしているので、おそらくそれはユーザーにとっては良いのですが、404と見なされます。[…]ユーザーの観点からリダイレクトすることが理にかなっている場合は、私はそれを選びます。

[…]301または302に関しては、これはソフト404と見なされるか、正規化の質問と見なされるため、ここでは重要ではないと思います。ソフト404の場合、コードは重要ではありません。正規化の質問の場合は、検索結果に表示されるURLに依存します。そして通常、より高いレベルのものはとにかくより強い信号を持っているでしょう、そして我々はより高いレベルのものに焦点を合わせます。その場合、それが301であるか302であるかは関係ありません。

[…]それをソフト404と見なすと、[…]ここには何もないため、その特定のURLのクロールが遅くなります[…]。リダイレクトと見なす場合[…]、プライマリURLに焦点を合わせているため、これを毎日クロールする必要はありません。したがって、どちらの場合も、実際には、これはまた新しいものである可能性があることを示す新しいシグナルを取得するまで、そのURLのクロールを遅くすると思います。 […]それは内部リンク、またはサイトマップファイルのようなものです[…]。そして、それは私たちが再び這うためのより強い兆候となるでしょう。しかし、クロールの速度低下は、これらすべての場合で同様であると思います。

[…] [更新]サイトマップだけではおそらく十分ではないと思います。 内部リンクも明確になっていることを確認します」。

コアアップデートからのリカバリ

18:34 「約1年前、トラフィックが大幅に減少しました。監査後、[…]すべての信号がサイトの品質に問題があるサイトを示していました。今年の2月までにこれらの問題に対処することができました。そして、6月のコアアップデートまでに、いくつかの増加が見られました。しかし、それでも、約1年前に減少する前のレベルには達していません。だから私の質問は、サイトの品質の問題です。もしそうなら、これは私たちが期待できる回復ですか、それとも特定されたすべての問題に対処したと思うなら、より多くの回復を期待できますか？」

ジョンは次のように述べています。「[…]何かを修正しなければならない状況と見なすほどではありません。しかし、むしろ[…]あなたがあなたのウェブサイトの関連性を改善することに取り組んでいるなら、[…]あなたはより良いウェブサイトを持っています。したがって、[…]以前の状態に戻すわけではありません。 […]以前と同じでも同等でもないので、以前の状態に変わることを期待するのはちょっと難しいでしょう[…]。

[…]コアアップデートでは、個々の問題だけに焦点を当てるのではなく、Webサイト全体の関連性に焦点を当てています。 これには、使いやすさやページ上の広告などが含まれる場合がありますが、基本的にはWebサイト全体です。そして通常、それはコンテンツの焦点、物事を提示する方法、ソースが何であるかなど、コンテンツの背後にあるものをユーザーに明確にする方法も意味します[…]。あなたが本当にグーグルにあなたのウェブサイトをかなり良いものとして見させたいのなら、あなたはおそらくコンテンツ側でも働く必要があります。

[…]低品質のコンテンツがどこにあるのか、ユーザーが私のWebサイトにアクセスしたときに混乱する可能性があるのかを考えてください。そして、その混乱は、UXの変更によって、技術的な問題で対処できるものですか？それとも、提示するコンテンツの一部を実際に変更する必要がありますか？」

ゲスト投稿のリンク

28:24 「[…][ウェブサイトに]ゲスト投稿があり、Googleがそれが支払われているかどうかわからない場合、Googleは[彼らが]このリンクを取得するか、このリンクを焼き付けるかをどのように判断しますか？私たちがあらゆる角度から安全であるための答えは何ですか？」

ジョンによると、「[…]リンクとゲスト投稿に関するガイダンスは、フォローしないようにすることです。 […]私は、リンクがフォローされていないことを確認するために本当に気をつけます。そうすることで、意識を高め、自分がしていることについて話し、ユーザーが自分のページ。しかし、本質的に、それはあなたのビジネスのための広告です。ですから、その観点から、私は彼らをフォローしないようにします。」

サイトマップ間でのURLの移動

34:04 「200のサイトマップファイルがあり、URLの20％から30％が毎週、あるファイルから別のファイルにジャンプする場合、それはどれほど悪いことでしょうか。それとも、URLを永久に同じファイルに厳密に保持する必要がありますか？」

「[…]通常、同じサイトマップファイルに同じURLを保持することをお勧めします。 その主な理由は、サイトマップファイルをさまざまなレートで処理することです。したがって、あるサイトマップファイルから別のサイトマップファイルに1つのURLを移動する場合、複数のサイトマップファイルからシステムに同じURLがある可能性があります。また、この1つのURLに異なる情報がある場合（たとえば、異なる変更日など）、実際に使用する属性はわかりません。

したがって、その観点から、常に同じサイトマップファイルにある場合は、このURLの情報がここにあると言うのがはるかに簡単です。この情報はそこにあるだけなので、信頼できます。だから、それは私が[…]これらのURLがランダムにシャッフルするのを避けようとするものです。しかし同時に、通常はサイトマップファイルの処理を中断することはありません。そしてそれは間違いなくあなたのウェブサイトにランキング効果をもたらすことはないでしょう。 したがって、私たちのサイトマップシステムには、Webサイトの品質に対応するようなものはありません。」

マルチリージョンコンテンツ

38:13 「私はニュース業界で働いています。私のチームは、国際的なプレゼンスを拡大することを目指しており、マルチリージョンのサブディレクトリを設定するための作業を行ってきました。ほとんどの場合、さまざまなマルチリージョンエディションのページは同じように見えます。政治やライフスタイルなどのホームページやセクションページには、地域に固有のいくつかの部分を除いた同様のコンテンツが含まれます。

記事はトリッキーです。関連するリンクを持つモジュール以外のマルチリージョンサブディレクトリ間で区別できることはあまりないため、重複コンテンツの問題が心配になります。 Googleはニューススペースの重複コンテンツをどのように処理しますか？ […]コンテンツは同じままですが、テンプレートの要素は異なります。すべてのマルチリージョンのWebサイトで正規のWebサイトを1つだけにする必要がありますか？」

ジョンの回答は次のとおりです。「[…]これらは同じ国内の異なる地域であり、同じ言語コンテンツであるようです。 […]これらが異なる国である場合、ジオターゲティングの側面があります。これは、これらが異なる言語である場合に役割を果たします。たとえば、ヨーロッパで働いていて、ドイツ、フランス、イタリアなどをカバーしている場合は、さまざまな言語も使用できます。

[…]しかし、同じ国、同じ言語のコンテンツについて話している場合は、[…]これらの技術的なつながりすべてについて心配する必要がないため、少し簡単です。しかし一方で、重複コンテンツの問題ははるかに目立ちます。そして、コンテンツを複製することになると、このようなサイトでのトリッキーな側面は、本質的に自分自身と競争することになるということです。また、5つまたは6つの異なる地域のWebサイトで公開するニュース記事が1つある場合、これらの異なる地域のWebサイトはすべて、まったく同じ記事にランク付けしようとします。その結果、その記事が他の方法と同じようにランク付けされなくなる可能性があります。

そのため、これらの個々の記事の正規URLを見つけて、実際に「」と言えるようにすることをお勧めします。この1つの記事は、5つの地域のWebサイトにありますが、これは私が見たいと思っているバージョンです。探す'。そして、私たちはすべてのエネルギー、すべての信号をその1つの好ましいバージョンに集中させることができ、それをもう少し良くランク付けすることを試みることができます。常に同じバージョンである必要はありません。したがって、ある地域内にある1つのニュース記事が正規の種類であり、別のニュース記事が別の地域の場合はより正規である場合があります。正規として選択する地域をどのように選択するかは、完全にあなた次第です。 […]通常、あなたはそれが最も関連性のある場所を見つけ出し、それを正規バージョンとして選択しようとします。だから、それは個々の記事自体のためです。

カテゴリ、セクション、ホームページについては、コンテンツがよりユニークで、個々の地域に固有のものであるように思われます。そのため、これらのインデックスレベルを分離しておくようにします。したがって、5つの異なる地域のWebサイト、それらのホームページ、それらのカテゴリセクションがある場合、それらはすべて個別にインデックス付けされます。そして、ニュース記事自体は、これらの異なる地域の1つにマッピングされます。ですから、そこで私たちが推奨するアプローチの一種です[…]。

そして、このアプローチは[…]異なるドメイン名でも機能します。したがって、地域ごとに異なるドメインがあり、それがすべて同じニュースグループの一部である場合でも、異なるバージョン間でこの標準的なシフトを行うことができます。同じドメイン内でサブディレクトリを使用して実行している場合は、それでも問題ありません。」

サイト移動でのリダイレクト

44:34 「すべてのURLを新しいURLのセットに301リダイレクトする必要がある場合に取るべき最善の行動は何ですか？ページ数は100万を超えますが、サンドボックスの影響を最小限に抑えたいですか？サンドボックス効果がある場合、どのくらいの時間がかかりますか？決して回復しないかもしれないランキングを失うでしょうか？ 1対1のリダイレクトを計画しており、バッチリダイレクトをリクエストしていましたが、それは不可能であるため、ページ、画像、URLなどを同時に反転する必要があります。」

ジョンが言ったように、「私には、これは従来のサイト移動の状況のように聞こえます。あるドメインから別のドメインに移動し、すべてのURLを古いサイトから新しいサイトにリダイレクトします。これに対処する必要があります[…]。 サイトの移動に関しては、サンドボックス効果として定義されているものはありません。 したがって、サイトの移動を行う必要がある場合は、サイトの移動を行い、すべてのページをリダイレクトします。多くの場合、最も簡単なアプローチは、すべてのページを一度にリダイレクトすることです。私たちのシステムも、それを認識しようとするために少し調整されています。したがって、Webサイトがすべてのページを別のWebサイトにリダイレクトし始めたら、そのサイトの移動をできるだけ速く処理できるように、少し速く再処理しようとします。 そして、私たちが言うことは間違いなくそうではありません、ああ、彼らはサイトの移動をしているので、私たちは物事を遅くします[…]」。

APIとクロール予算

46:13 「データを取得するためにクライアント側のAPIに接続するWebサイトがあります。それらのURLはクロール予算に含まれていますか？これらのURLを許可しない場合、[…]問題が発生しますか？」

「[…]ページのレンダリング時にこれらのAPIが含まれている場合、はい、それらはクロールに含まれ、ページをレンダリングするためにこれらのURLをクロールする必要があるため、基本的にクロール予算にカウントされます。レンダリング中にクロールされないようにしたり、使用されないようにしたい場合は、robots.txtでブロックできます。あなたがそれを好むなら、完全にあなた次第です。特に、維持にコストがかかる、または多くのリソースを必要とするAPIがある場合は、それが理にかなっている場合があります。

トリッキーな部分は、APIエンドポイントのクロールを許可しない場合、インデックス作成にAPIリターンに関するデータを使用できなくなることだと思います。したがって、ページのコンテンツが純粋にAPIからのものであり、APIのクロールを許可しない場合、その連絡先はありません。 […]APIが、地図や[…]ページ上にある数値テーブルのグラフィックを描画するなど、ページを補足するものを実行する場合、[…]そのコンテンツがそうでないかどうかは問題ではありません。インデックス作成には含まれていません。もう1つは、APIがブロックされているときにページがどのように機能するかが重要な場合があるということです。特に、JavaScriptを使用していて、robots.txtが原因でAPI呼び出しがブロックされている場合は、その例外をなんらかの方法で処理する必要があります。また、JavaScriptをページに埋め込む方法、APIで何を行うかに応じて、JavaScriptが引き続き機能することを確認する必要があります。そのため、そのAPI呼び出しが機能せず、ページの残りのレンダリングが完全に中断した場合、レンダリングするものが残っていないため、多くのインデックスを作成できません。

ただし、API呼び出しが中断し、ページの残りの部分にインデックスを付けることができる場合は、それで問題ない可能性があります。 […]他の人のためにAPIを実行する場合は注意が必要です。クロールを許可しない場合、他の人のWebサイトがAPIに依存している可能性があるという2次的な影響があります。そして、APIの機能によっては、突然、彼らのWebサイトにインデックス可能なコンテンツがなくなります。そして、彼らは突然気づかなかったので気付かないかもしれません、あなたはそこに不許可を追加しました。そして、それは一種の間接的な影響を引き起こすかもしれません[…]」。

JavaScriptとGoogleのキャッシュ

49:36 「つまり、同じドメインから発信された2つのページがあります。 URLは少し異なり、同じディレクトリ構造の一部です。そして[…]それらはNextJSによって生成されます。つまり、NextJSはサーバー側でレンダリングされたreactフレームワークです。そして、それらはインデックスに登録されていますが、1つのページがGoogleキャッシュにあり、2番目のページがGoogleキャッシュにありません。そして、ページの生成方法に関係なく、同じパターンが表示されます[…]。ほとんどのページはGoogleキャッシュにありますが、現在、これらすべてのページを生成するJavaベースの技術スタックからGoogle NextJSに移行しているため、心配しています。 […]デバッグしているときに、これは私たちが使用していた古いJavaスタックの問題でもあることがわかりました。

したがって、問題は2つの部分です。基本的に、なぜこの動作ですか？そして第二に、この行動は私のランキングに影響を与えますか？ Googleのキャッシュにない検索結果にこれらのページが表示されます。」

ジョンは次のように答えました。「[…]キャッシュページは、インデックスに登録するものから完全に分離されています。したがって、キャッシュページがあるかどうかは、ランキングにはまったく関係ありません。インデックス作成にはまったく関係ありません。 キャッシュページがない技術的な理由がある場合があります。場合によっては、個々のURLのキャッシュページがないことがあります。もう1つは、ページがJavaScriptフレームワークを使用している場合、そのJavaScriptがキャッシュページで実行されるかどうかは、キャッシュページがGoogleドメインでホストされているため、注意が必要な場合があります。使用しているJavaScriptの種類、JavaScriptファイルを取り込む場所によっては、JavaScriptをGoogleドメインで実行できない場合があります。

[…]キャッシュページはレンダリングされたページではありません。基本的には、要求したHTMLファイルとそのコピーです。そして、HTMLファイルに何かが表示されている場合は、それで問題ありません。 JavaScriptを使用していて、キャッシュページであるためにJavaScriptが実行されない場合も、同様に問題ありません。キャッシュページに表示されないだけです。したがって、キャッシュページが表示されない場合は、心配する必要はありません。それは問題の兆候ではありません。そして、多くの場合、[…]キャッシュページがあるかどうかを制御することはできません。私はそれを無視します。」

https://www.youtube.com/watch?v=Vd0rEQrwHDc