Google 検索のクロールエラーのトラブルシューティング

サイトの Google 検索のクロールに関する問題をトラブルシューティングして解決する主な手順は次のとおりです。

  1. Googlebot において、サイトの可用性に関する問題が発生していないかを確認します。
  2. クロールされていないが、クロール対象とすべきページがあるかどうかを確認します。
  3. 今より速やかにクロールされるべきコンテンツがサイトにないかを確認します。
  4. サイトのクロール効率を向上させます。
  5. サイトの過剰クロールに対処します。

Googlebot に対してサイトの可用性に関する問題が発生していないかを確認する

サイトの可用性を改善しても、クロール バジェットが増えるとは限りません。前述のとおり、Google はクロールの必要性に基づいて最適なクロール頻度を決定します。しかし、可用性の問題は、Google がサイトをクロールしようとしたときにそれを妨げる原因になります。

診断:

クロールの統計情報レポートを使用して、サイトに関する Googlebot のクロール履歴を確認します。このレポートには、Google がサイトで可用性の問題を検出した日時が表示されます。サイトに関する可用性のエラーや警告が報告されている場合、ホストの可用性グラフで、Googlebot のリクエスト件数が赤色の上限を超えているインスタンスを探してグラフをクリックし、失敗した URL を確認して、サイトの問題と結び付けてみてください。

また、URL 検査ツールを使用して、サイト上の URL をいくつかテストすることもできます。このツールから「ホスト負荷が制限を超えています」という警告が返された場合、サイトで検出された URL が多すぎて Googlebot がクロールしきれないことを意味します。

対応:

  • 可用性の問題を検出して対処する方法については、クロールの統計情報レポートに関するドキュメントをご覧ください。
  • クロールされたくないページのクロールをブロックします（URL 群の管理をご覧ください）。
  • ページの読み込み速度とレンダリング速度を上げます（サイトのクロール効率を向上させるをご覧ください）。
  • サーバー能力を増強します。Google が常にサービス能力の上限でサイトをクロールしているように見えても、必要にもかかわらずクロールまたは更新されていない重要な URL がある場合は、より多くのリソースを提供することで、Google がサイトのページをより多くリクエストできるようになります。クロールの統計情報レポートでホストの可用性の履歴を調べ、Google のクロール頻度が頻繁に上限に達していないかを確認します。頻繁に上限に達している場合は、1 か月間サービス リソースを増やし、その期間にクロール リクエストが増えたかどうかを確認します。

クロールされていないがクロールされるべきページがないかを確認する

Google は、高品質でユーザー価値の高いコンテンツをすべてインデックスに登録するために、サイトに必要なだけの時間を費やしています。Googlebot が重要なコンテンツをクロールできていないとお考えの場合、それは Googlebot がコンテンツを把握していないか、コンテンツが Google からブロックされているか、サイトの可用性によって Google のアクセスが調整されている（あるいは Google がサイトに負荷をかけないようにしている）かのいずれかです。

診断:

Search Console では、サイトのクロール履歴を URL またはパスでフィルタして確認することはできません。しかし、サイトログを調べると、特定の URL が Googlebot によってクロールされているかどうかを確認できます。このクロールされた URL がインデックスに登録されているかどうかは別問題です。

ほとんどのサイトでは、新しいページが認識されるまでに数日かかります。ニュースサイトなど、時間的制約のあるサイトを除き、ほとんどのサイトでは URL がすべて同じ日にクロールされるとは限りません。

対応:

サイトにページを追加してから十分に時間が経過してもクロールされない場合、その原因は、Google がページを認識していない、コンテンツがブロックされている、サイトが処理能力の限界に達している、クロール バジェットの対象外である、のいずれかです。

  1. 新しいページについて Google に指示する: 新しい URL を反映するようにサイトマップを更新します。
  2. robots.txt ルールを調べて、ページが誤ってブロックされていないことを確認します。
  3. クロールの優先順位を確認します（クロール バジェットを上手に使用します）。URL 群を管理し、サイトのクロール効率を向上させます。
  4. 処理能力が不足していないことを確認します。 Googlebot は、サーバーがクロール リクエストに応答できないことを検出すると、クロールを縮小します。

ページがクロールされたとしても、十分な価値やユーザーの需要がなければ、検索結果に表示されないことがあるので、注意が必要です。

更新内容がすぐにクロールされるかどうかを確認する

Google がサイトの新しいページや更新ページをクロールできていない場合、おそらく検知していないか、更新されていることを認識していないことが考えられます。Google がページの更新を認識できるようにするための方法をご紹介します。

Google では、ページを適切なタイミングでチェックしてインデックスに登録するよう努めていますが、ほとんどのサイトでは 3 日以上かかります。ニュースサイトなど、価値が高く時間的制約があるコンテンツがない限り、公開したその日に Google がページをインデックスに登録することはないと考えてください。

診断:

サイトログを調べて、特定の URL がいつ Googlebot によってクロールされたかを確認します。

インデックス登録日を確認するには、URL 検査ツールを使用するか、更新した URL を検索します。

対応:

すべきこと:

  • サイトにニュース コンテンツがある場合は、ニュース サイトマップを使用する。
  • サイトマップ内で <lastmod> タグを使用し、インデックス登録済みの URL が更新されたことを示す。
  • クロール可能な URL 構造を使用して、Google がページを検出できるようにする。
  • Google が容易にページを見つけられるように、標準のクロール可能な <a> リンクを提供する。
  • サイトでモバイル版ページと PC 版ページで別々の HTML を使用している場合は、PC 版ページと同じリンク一式をモバイル版ページにも提供する。同じリンク一式をモバイル版ページでは提供できない場合は、リンク一式がサイトマップ ファイルに含まれていることを確認してください。Google はモバイル版ページのみをインデックスに登録し、表示されるリンクを制限すると、新しいページを検出するのに時間がかかることがあります。

避けるべきこと:

  • 変更されていない同じサイトマップを 1 日に複数回送信する。
  • Googlebot がサイトマップ内のすべてをクロールするか、すぐにクロールすると考える。 サイトマップは Googlebot にとって有用なヒントになりますが、絶対的な要件ではありません。
  • Google 検索の検索結果に表示したくないページの URL をサイトマップに含める。 これを行うと、インデックスに登録されたくないページがクロールされ、クロール バジェットが無駄になる可能性があります。

サイトのクロール効率を向上させる

ページの読み込み速度を上げる

Google のクロールは、帯域幅、時間、Googlebot インスタンスの可用性によって制限されます。 サーバーがリクエストに迅速に応答する場合は、Google がサイトのページをより多くクロールできる可能性があります。ただし、Google がクロールすることを望んでいるのは高品質のコンテンツのみであるため、低品質のページを高速化しただけでは、Googlebot によるクロールは増加しません。逆に、Google がサイトに含まれる高品質のコンテンツを見落していると判断した場合は、コンテンツをクロールするバジェットを増やす可能性があります。

クロール向けにページとリソースを最適化する方法は次のとおりです。

  • robots.txt を使用して、サイズは大きいが重要でないリソースが Googlebot によって読み込まれることを防ぎます。重要でないリソース、つまりページの意味を理解するうえで重要でないリソース（装飾画像など）のみをブロックしてください。
  • ページの読み込みが速いことを確認します。
  • 長いリダイレクト チェーンはクロールに悪影響を及ぼすため、ご注意ください。
  • サーバー リクエストに応答する時間と、ページのレンダリングに必要な時間の両方が重要です。これには、画像やスクリプトなどの埋め込みリソースの読み込み時間と実行時間も含まれます。インデックスへの登録が必要な大きいリソース、つまり読み込みが低速なリソースにご注意ください。

HTTP ステータス コードでコンテンツの変更を示す

Google は通常、クロールに関して If-Modified-Since および If-None-Match HTTP リクエスト ヘッダーをサポートしています。Google のクローラは、すべてのクロールの試みでヘッダーを送信するわけではなく、送信するかどうかはリクエストのユースケースによって異なります（たとえば、AdsBot は If-Modified-Since および If-None-Match HTTP リクエスト ヘッダーを設定する可能性が高くなります）。Google のクローラが If-Modified-Since ヘッダーを送信する場合、ヘッダーの値は、コンテンツが最後にクロールされた日時になります。その値に基づいて、サーバーはレスポンス本文なしで 304 (Not Modified) HTTP ステータス コードを返すことを選択する場合があります。この場合、Google は最後にクロールしたコンテンツ バージョンを再利用します。クローラが If-Modified-Since ヘッダーで指定した日付よりコンテンツの方が新しい場合、サーバーはレスポンス本文付きで 200 (OK) HTTP ステータス コードを返せます。

リクエスト ヘッダーとは無関係に、Googlebot が最後に URL にアクセスしてからコンテンツが変更されていない場合は、Googlebot のリクエストに対してレスポンス本文なしで 304 (Not Modified) HTTP ステータス コードを送信できます。これにより、サーバーの処理時間とリソースが節約され、間接的にクロールの効率が向上する可能性があります。

検索結果に表示させたくない URL を非表示にする

重要でないページでサーバー リソースが浪費されると、重要なページのクロールの妨げとなるため、サイト上の重要な新規または更新済みのコンテンツの検出に大幅な遅れが生じることがあります。

クロールされたくない多数の URL が検索結果に表示されると、サイトのクロールとインデックス登録に悪影響を及ぼす可能性があります。一般的に、こうした URL は以下のカテゴリに分類されます。

すべきこと:

  • リソースやページのクロールを望まない場合は、robots.txt を使用します。
  • 共有リソースを複数のページ（共有画像や JavaScript ファイルなど）で再利用している場合、各ページで同じ URL からリソースを参照するようにすると、Google が同じリソースを何度もリクエストしなくてもキャッシュして再利用できるようになります。

避けるべきこと:

  • サイトのクロール バジェットを再配分する方法として、robots.txt にページまたはディレクトリを定期的に追加または削除しないでください。robots.txt は、長時間にわたって Google に表示させたくないページやリソースにのみ使用します。
  • サイトマップのローテーションまたは他の一時的な非表示メカニズムにより、サイトの割り当てを再配分することはしないでください。

soft 404 件のエラー

soft 404 エラーは、ページが存在しないことと 200 (success) のステータス コードをユーザーに伝えるページを URL が返す場合のエラーです。場合によっては、メイン コンテンツのないページや空白のページなどもこれに該当します。

こうしたページは、ウェブサイトのウェブサーバーやコンテンツ管理システム、ユーザーのブラウザによってさまざまな理由で生成される場合があります。次に例を示します。

  • サーバーサイド インクルード ファイルがない。
  • データベースへの接続が切断されている。
  • 内部検索結果ページが空である。
  • JavaScript ファイルがアンロードされている、または欠落している。

200 (success) ステータス コードを返したのに、ページにエラー メッセージやなんらかのエラーを表示または示唆することは、ユーザーの利便性を損ねます。ユーザーは、そのページが公開中の有効なページであると認識する可能性がありますが、なんらかのエラーが表示されることがあります。このようなページは検索から除外されます。

Google のアルゴリズムが、コンテンツに基づいてそのページが実際にエラーページであることを検出すると、Search Console はサイトのページのインデックス登録レポートに soft 404 エラーを表示します。

soft 404 エラーを修正する

ページの状態と求める結果に応じて、さまざまな方法で soft 404 エラーを解決できます。

ユーザーにとって最適な解決方法を選択してください。

該当ページおよびコンテンツが利用できなくなっている

該当ページが削除されており、同様のコンテンツを含む代替ページがサイトに存在しない場合は、404 (not found) または 410 (gone) のレスポンス（ステータス）コードを返します。これらのステータス コードは、該当ページが存在せず、検索エンジンにページをインデックスに登録してほしくないことを検索エンジンに指定します。

サーバーの設定ファイルにアクセスできる場合は、これらのエラーページをカスタマイズしてユーザーの利便性を向上させることができます。404 ページをわかりやすくカスタマイズすることにより、探している情報の場所をユーザーに知らせることができます。また、役に立つ他のコンテンツを提供して、サイト内をさらに探すよう促すこともできます。有用なカスタム 404 ページを設計するためのヒントは次のとおりです。

  • ユーザーに対して、探しているページが見つからないことを明確に伝えます。親しみやすく平易な言葉を使用します。
  • 404 ページを、サイトのその他の部分と同じデザイン（ナビゲーションを含む）にします。
  • 最も人気のある記事や投稿へのリンクのほか、ホームページへのリンクを追加します。
  • 無効なリンクを報告する方法をユーザーに提供することを検討します。

カスタム 404 ページは、ユーザーのためにカスタマイズして作成されるページです。こうしたページは検索エンジンの観点からは無用なため、ページがインデックスに登録されないように、サーバーが 404 HTTP ステータス コードを返すようにしてください。

該当ページまたはコンテンツが移動されている

該当ページが移動されている場合、または明確な代替ページが存在する場合は、301 (permanent redirect) を返してユーザーを適宜リダイレクトします。リダイレクトを使用することで、ユーザーのページの閲覧が妨げられることがなくなり、ページの新しい場所を検索エンジンに伝えることもできます。URL 検査ツールを使用して、URL が実際に正しいコードを返しているかどうかを確認してください。

該当のページおよびコンテンツが引き続き存在している

正常なページが soft 404 エラーと認識されている場合は、Googlebot に正しく読み込まれなかった、重要なリソースが欠落している、またはレンダリング中に重大なエラー メッセージが表示された可能性があります。URL 検査ツールを使用して、レンダリングされたコンテンツと返された HTTP コードを調べます。レンダリングされたページが空白になるか、ほとんど空白になるか、コンテンツにエラー メッセージがある場合、読み込むことができないリソース（画像、スクリプト、テキスト以外のその他の要素）を多く参照している可能性があります。このような状態は、soft 404 と解釈されます。リソースを読み込めない理由としては、リソースが（robots.txt によって）ブロックされている、ページ上のリソースが多すぎる、さまざまなサーバーエラー、読み込みが遅い、リソースが大きすぎるなどが考えられます。

サイトの過剰クロールに対応する（緊急時）

Googlebot には、クロール リクエストによってサイトが過負荷にならないようにするアルゴリズムがあります。 ただし、Googlebot によるサイトの過負荷が判明した場合、次の方法をお試しください。

診断:

サイト対して Googlebot の過剰なリクエストがないかサーバーを監視します。

対応:

緊急時に、Googlebot による過剰なクロールを緩和するには、以下の手順をおすすめします。

  1. サーバーが過負荷になっているときは、Googlebot のリクエストに対して、一時的に、503 または 429 HTTP レスポンス ステータス コードを返します。Googlebot はこのような URL に対して約 2 日間リクエストを再試行します。「利用不可」を示すコードが数日にわたって返されると、サイトの URL に対する Google のクロールが恒常的に減少または停止します。したがって、次の追加手順を実施する必要があります。
  2. クロール頻度が低下したら、クロール リクエストに対して 503 または 429 HTTP レスポンス ステータス コードを返すのをやめます。2 日間を超えて 503 または 429 を返すと、Google はそれらの URL をインデックスから削除します。
  3. ある程度の期間にわたってクロールおよびホスト能力をモニタリングします。
  4. 問題のあるクローラーが AdsBot クローラーである場合、Google がクロールしようとしているサイト用に動的検索広告ターゲットを作成したことが問題の原因になっている可能性があります。このクロールは 3 週間ごとに再実行されます。これらのクロールを処理できるだけのサーバー容量がない場合は、広告ターゲットを制限するか、配信容量を増やしてください。