Google Search Console の使い方

Google Search Console とは

Google Search Console とは、Google 検索における自身のサイトパフォーマンスを確認できるサービスです。サイトパフォーマンスとは、サイトの性能の評価や、キーワードごとの掲載順位、クリック数の情報などです。Google 検索の持つ情報を確認できるサービスは他に存在しないため、Google Search Console が唯一の情報源となります。

Google Search Console を利用しなければ確認できない代表的な情報に、検索キーワードのパフォーマンス情報があります。Google アナリティクスにおいても、プロパティの設定から Google Search Console とリンクしなければ Google の検索結果から訪問したユーザの検索キーワードが (not provided) と表示され見ることができません。Google アナリティクスと Google Search Console をリンクさせるためには、Google アナリティクスのプロパティ設定から Search Console の調整を行う必要があります。

注意アイコン
(not provided) について
(not provided) は、プライバシー保護を目的として暗号化された結果です。Google は、2011 年 10 月からサイトに訪問したユーザーの参照元情報 (検索キーワード) に暗号化を施し、どのようなキーワードでサイトに訪問したのかを非公開としました。ただし、Google Search Console では統計データとしてキーワード情報を確認できます。

関連するリンク一覧

外部リンク
内部リンク

サマリー

サマリーでは、検索パフォーマンス、カバレッジ、拡張のデータが一覧化されており、ダッシュボードとしての役割を果たしています。これらの項目は個々に詳細なレポート情報を持っており、リンクからレポートに飛ぶことができます。これらの詳細は、後述する別章で説明します。

サマリー
サマリー

検索パフォーマンス

検索パフォーマンスは、Google Search Console の中でも最重要の機能のひとつで、キーワードごとの合計クリック数、合計表示回数、平均 CTR、平均掲載順位を確認することができます。どのキーワードが、どれだけのパフォーマンスがあるか知ることはサイトを改善する上で非常に重要なヒントになります。

検索パフォーマンス
検索パフォーマンス

検索パフォーマンスでは、クエリ (検索キーワード)、ページ、国、デバイス、検索の見え方ごとのパフォーマンスを確認することができます。一覧は、最大で 1,000 件まで確認することが可能で、1 ページあたりの行数は 10, 25, 50, 100, 250, 500 行から選択可能です。

一覧は、項目ごとにフィルタすることが可能です。例えば、検索キーワードは「htaccess」を含み、クリック数は 1,000 件以上の行を抽出するといった方法も可能です。また、一覧は CSV としてダウンロードしたり、Google スプレッドシートにコピーすることもできます。

上記の図ではクエリ (検索キーワード) についてパフォーマンスを表示しています。クリック数順に並び替えたとき、「htaccess 書き方」という複合キーワードをクリック数、表示回数、CTR、掲載順位がトップに来ていることがわかります。

クリック数
クリック数は、検索キーワードによって検索結果画面に表示された回数のうち、何回クリックされたかを表します。CTR はクリック数と表示回数の割合であるため、クリック数が多ければ CTR も高くなります。ただしクリック数は、ある程度までは掲載順位との相関関係があるため、どれだけのクリック数を獲得できれば良いという絶対の指標はありません。掲載順位に対して、極端に低い場合や、極端に高い場合に原因を分析すると良いでしょう。
表示回数
表示回数は、検索キーワードによって検索結果画面に表示された回数です。表示回数が多いほど、多くのユーザーに需要があることを示しており、キーワード別の検索ボリュームを確認することができます。そのため、表示回数が少ないキーワードに対して改善策を講じても効果は薄いことになります。
CTR
CTR は、クリック数を表示回数で割ったパーセンテージです。CTR が高ければ、検索キーワードで表示されたあなたのサイトに訪問するユーザーの割合が多いことを示します。ただし、CTR は掲載順位とある程度までの相関関係があるため、掲載順位が低ければ CTR も低くなる傾向があります。
掲載順位
掲載順位は、検索キーワードで検索したときのランキング順位です。ただし、「oauth2」、「oauth 2.0」、「oauth2.0」などのように同じ意味のキーワードでも、表記が異なると掲載順位が変動する点に注意してください。また、掲載順位は常に変動しているため、掲載順位は将来的に変化する可能性があります。

URL 検査

URL 検査は、URL が正常に Google にインデックスされているか確認することができます。正常にインデックスされていない場合は、何が原因であるかがレポートされます。URL 検査には、以下の機能があります。

インデックス登録された URL の検査
Google のインデックスに登録されたページの情報を取得します。
公開 URL の検査
対象の URL がインデックスに登録できるかテストします。
URL のインデックス登録リクエスト
検査済みの URL を クロールするようにリクエストします。
レンダリングされたページの表示
Googlebot がどのようにページを認識しているかを確認します。

インデックス登録された URL の検査

URL 検査機能を利用するためには左側のメニュー、または上部の URL 入力欄から利用できます。

URL 検査の入力欄
URL 検査の入力欄

URL 入力欄には、現在のプロパティ内の URL を指定する必要があります。現在のプロパティは、左上に表示されている URL のことです。例えば、https://murashun.jp/ 内の URL は登録可能ですが、https://murashun.com/ 内の URL は登録できません。もしも、https://murashun.com/ 内の URL を登録する場合、プロパティを追加する必要があります。

現在のプロパティ
現在のプロパティ

URL を入力する場合、次のことに注意してください。

プロパティ内の URL であること
プロパティ内の URL ではない場合、テストできません。他にもプロパティがある場合は、プロパティを切り替えて URL をテストしてください。
AMP と非 AMP の URL は区別されること
AMP と非 AMP の URL の両方を検査できます。URL 検査にはそのページに対応する AMP と非 AMP バージョンについての情報が表示されます。
ページの代替バージョンも表示されること
代替バージョンがあるページの場合、正規バージョンの情報もツールに表示されます。例えば hreflang を使って代替言語バージョンを指定している場合などです。

所有する各プロパティに対する検査のリクエスト数には、1 日あたりの上限が設定されています。そのため URL の数が多い場合は、代わりにサイトマップの送信が推奨されます。URL 検査の結果は、Google の登録状況、インデックスカバレッジ、拡張機能のセクションに分かれた以下のような画面になります。

URL 検査のレポート
URL 検査のレポート

ただし、URL 検査のレポートについては以下の点について注意してください。

ライブテストではないこと
URL 検査結果は、前回インデックスに登録されたページのバージョンであり、今現在 Web で公開されているページのバージョンではありません。そのため、Google がサイトを前回クロールしてから、そのページが変更された場合や、利用できなくなっている場合もあります。ページの最新版をテストする場合は、[ライブテスト] ボタンを選択します。
登録済みでも検索結果画面に表示されるとは限らないこと
検索結果に実際に表示されるには、ページとその構造化データが品質とセキュリティに関するガイドラインに準拠している必要があります。URL 検査ツールでは、手動による対策、コンテンツの削除、URL の一時的なブロックはいずれも考慮されません。

Google の登録状況

Google の登録状況は、Google の検索結果に対象の URL が表示されるかどうかを示します。具体的な表示内容は以下のとおりです。

Google の登録状況ステータス一覧
表示ステータス説明
URL は Google に登録されています
表示の意味
URL はインデックスに登録されており、Google 検索結果に表示される可能性があります。ページ内で検出された拡張機能 (構造化データ、AMP ページへのリンクなど) に問題はありません。
必要なアクション
何もする必要はありません。
注意アイコン
表示ステータスと URL 削除ツールについて
URL 削除ツールを使って URL を一時的にブロックしている場合でも、URL 検査ツールは「URL は Google に登録されています」と表示され、[インデックスカバレッジ] のステータスは「クロール済み」となります。
URL は Google に登録されていますが問題があります
表示の意味
URL はインデックスに登録されており、Google 検索結果に表示される可能性があります。ただし、ページに適用している拡張機能に問題があるため、検索結果に拡張機能が反映されない可能性もあります。
必要なアクション
表示されている警告やエラーの情報を参照して問題を解決します。
URL が Google に登録されていません。インデックス登録エラー
表示の意味
重大な問題があるため URL をインデックスに登録できません。URL を Google 検索結果に表示させるには、検出された問題を解決する必要があります。
必要なアクション
[インデックスカバレッジ] から、インデックスに登録しようとしたときの詳細情報を確認します。後述するインデックスカバレッジエラーの一覧と、修正手順を参照してください。
URL が Google に登録されていません
表示の意味
この URL は Google 検索結果に表示されませんが、それはサイト所有者の意図によるものと Google は判断しています。
必要なアクション
[インデックスカバレッジ] の詳細情報から登録されていない理由について確認します。
注意アイコン
URL が Google に認識されない場合
「URL が Google に認識されていません」というステータスが表示された場合、URL はインデックスに登録されていません。その原因は、Google がまだ URL を確認していないか、正しくマークされた代替ページとして検出したがクロールできなかったかのいずれかです。修正するにはライブテストを実行し、検出されるすべての問題を修復してからインデックス登録用のページを送信します。
URL は代替バージョンです
表示の意味
この URL は、同じページの代替バージョンセット内の 1 つです。このようなグループには、AMP ページのペア、正規ページのペア、PC 版とモバイル版のペアなどがあります。インデックスに登録された URL は [インデックスカバレッジ] の [Google が選択した正規 URL] の項目で確認できます。
必要なアクション
Google が選択した正規 URL が想定通りのページか確認します。

インデックスカバレッジ

インデックスカバレッジには、URL のインデックスのステータスと、インデックスに登録するプロセスの詳細を表示します。

インデックス カバレッジのステータス
Google での登録状況の詳細が表示され、URL が Google に登録されている理由、または登録されていない理由が説明されています。ステータスは、成功、警告、エラー、除外のいずれかです。
サイトマップ
サイトマップレポートで送信されたサイトマップ、または、robots.txt に記載されたサイトマップを表示します。
参照元ページ
Google が検索対象の URL を見つけるために使用した可能性のあるページの URL を表示します。この値が表示されていない場合は、参照元ページが存在しないわけではなく、現時点で URL 検索ツールがその情報を把握していない可能性があります。「URL は、現時点でレポートされていない他のソースから認識されている可能性があります」と表示される場合は、対象の URL をサイトマップと参照元のページ以外から検出しており、その参照情報は現時点でこのツールでは利用できないことを示しています。
前回のクロール
対象のページを Google が前回クロールした日時を表示します。
クロールを許可?
ページへのクロールを Google に許可しているか、または robots.txt を使ってブロックしているかを示します。
ページの取得
Google がページをサーバーから実際に取得できたかどうかを示します。クロールを許可していない場合は、この項目には常にエラーと表示されます。クロールを許可している場合でも、さまざまな理由でページを取得できない可能性があります。
インデックス登録を許可?
ページのインデックス登録を明示的にブロックしているかどうかを示します。インデックスの登録がブロックされている場合、その理由が説明されます。
ユーザーが指定した正規 URL
ページで明示している場合、ユーザーが指定した正規 URL が表示されます。正規 URL を指定する方法は複数あり、<link rel="canonical"> タグ、HTTP ヘッダー、サイトマップ、またはその他の方法で指定できます。
Google が選択した正規 URL
類似ページ、または重複ページが検出された際、Google が正規 URL として選択したものが表示されます。ユーザーが正規 URL を指定している場合でも、Google は別の URL の方が正規ページとしてふさわしいと判断することもあります。

拡張機能

拡張機能は、インデックス登録時に Google が検出した検索の拡張機能に関する情報が表示されます。URL がインデックスに登録できなかった場合や、拡張機能が検出されなかった場合、この欄には何も表示されません。

モバイルユーザビリティ
ページがモバイルフレンドリーであるかを表示します。モバイルフレンドリーではない場合、問題点が一覧で表示されるため、任意の行を選択してエラーの詳細を確認することができます。
モバイルユーザビリティ
モバイルユーザビリティ
AMP
ページが AMP バージョンにリンクしている場合、現在の AMP バージョンの詳細について確認できます。ここでは、一般的な AMP エラーに加えて、Google 固有の AMP エラーが表示されることがあります。特定の問題の影響を受けるサイトの他のページを表示するには、問題の説明の行を選択して、[レポートを開く] を選択します。
リッチリザルトタイプ
ページ上で見つかったリッチリザルトタイプ (構造化データ) の情報が表示されます。この情報には有効な項目の数、各項目の説明、見つかった警告やエラーについての詳細などが含まれます。

公開 URL の検査

プロパティ内の URL をテストして、Google でインデックス登録ができるかどうかを確認できます。これはインデックス登録された URL と同様の情報が公開 URL に含まれているかをテストする機能で、ページに何かしらの変更を加えた際に現在インデックス登録されているページと変更後のページを比較するために行います。ただし、所有する各プロパティに対するライブテストのリクエスト数には、1 日あたりの上限が設定されています。公開 URL をテストする手順は以下のとおりです。

  1. 検索バーに URL を入力して、インデックス登録されたページを検査します。ページのインデックス登録が未完了でも問題ありません。
  2. [ライブテスト] を選択して、公開版のページをテストします。
  3. ページ上で [Google インデックス] または [ライブテスト] を選択して、ライブテストの結果とインデックス登録済みの結果を切り替えます。
  4. ライブテストを再実行するには、ページ上の再読み込みアイコンを選択するか、新しい検査を開始します。
ライブテスト結果
注意アイコン
ライブテストについて
このツールはリアルタイムで URL を取得して確認します。ライブテストに表示される情報はインデックス登録された URL とは異なる場合があります。

Google に登録される可能性

一番上のカードには公開 URL がインデックス登録される可能性があるかついて、全般的な評価が記載されています。ただし、検索結果に表示されるためには、ページとその構造化データが品質とセキュリティに関するガイドラインに準拠している必要があります。具体的な表示内容は以下のとおりです。

公開 URL がインデックス登録される可能性があるかのステータス一覧
表示ステータス説明
URL は Google に登録できます
表示の意味
URL がブロックされることはありません。また、インデックス登録を妨げるようなエラーも検出されていません。URL が品質とセキュリティに関するガイドラインに準拠しており、手動による対策、コンテンツの削除、URL の一時的なブロックの対象となっていなければ、Google が URL をインデックス登録すると、Google 検索結果に表示されます。
必要なアクション
インデックス登録をリクエストが可能です。また、サイトマップを送信するか、クロールされるのを待つ選択肢もあります。
URL は Google に登録できますが、問題があります
表示の意味
URL は Google にインデックス登録できます。ただし、ページに実装しようとしている拡張機能に問題があるため、検索結果に拡張機能が反映されない可能性があります。
必要なアクション
警告やエラーの情報の詳細を確認してください。
URL は Google に登録できません
表示の意味
重大な問題があるため Google 検索結果に表示できません。
必要なアクション
登録の可否に記載された詳細を確認してください。

登録の可否

登録の可否には Google でページのインデックス登録ができるかどうかが記載されます。ただし、検索結果に表示されるには、ページとその構造化データが品質とセキュリティに関するガイドラインに準拠している必要があります。

インデックスレポートのステータス一覧
インデックスレポートのステータスライブテストに表示されない理由
送信された URL ... 送信された URL... で始まるステータスはライブテストには表示されません。このステータスはユーザーがサイトマップを送信したときに表示され、サイトマップの情報はライブテストには適用されないためです。
  • 送信して登録されました
  • インデックス登録されましたが、サイトマップに送信していません
同様のステータスである「URL はインデックスに登録できます」が表示されます。
robots.txt によりブロックされましたが、インデックスに登録しました 「インデックス登録済み」というフレーズは、ライブテストには適用されません。ブロックされると、対応するエラー「robots.txt によりブロックされました」が表示されます。
検出 - インデックス未登録ライブテストには適用されません。
クロール済み - インデックス未登録ライブテストには適用されません。
  • 代替ページ (適切な canonical タグあり)
  • 送信された URL が代替バージョンとしてインデックス登録されました
  • ページが重複しています (canonical タグなし)
  • Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました
  • 送信された URL が canonical として選択されていません
Google の正規情報はライブテストには表示されません。また、重複ページの情報も一切表示されません。ユーザーが正規ページを明示している場合は、その情報が表示されます。

拡張機能

インデックス登録された URL の [拡張機能] の欄と同様です。

レンダリングされたページの表示

Googlebot がどのようにページを認識しているかをスクリーンショットで確認できます。この機能は公開されている URL でのみ利用できます。

  1. URL に対してライブテストを実行します。
  2. ページ判定カードの [テスト済みのページを表示] をクリックして、追加の情報パネルを開きます。情報パネルを開けない場合、ライブテストでページにアクセスできていない可能性があります。
  3. [スクリーンショット] タブに移動します。
レンダリングされたページを表示する
レンダリングされたページを表示する

検査済み URL を Google にクロールさせるようリクエストできます。インデックス登録には 1 ~ 2 週間程度かかります。処理状況のステータスは、この画面から確認できます。

インデックス登録をリクエストするには、レポートで [インデックス登録をリクエスト] を選択します。インデックス登録エラーをすばやく検出する簡易チェックをパスしたページは、インデックス登録キューに送信されます。ライブテストでインデックス登録不可と判断された場合は、インデックス登録をリクエストできません。

インデックス登録をリクエスト
インデックス登録をリクエスト

カバレッジ

カバレッジは、どのページがインデックス登録されているかや、インデックス登録できなかったページの修正方法を確認できます。グラフの各バーは、Google が認識している URL の合計数をステータス別に表しています。通常は、サイトが拡大するにつれて、有効なインデックス登録済みページの数が徐々に増えていく状態になる必要があります。

インデックスカバレッジレポート
インデックスカバレッジレポート

最上位のレポートには、Google がクロールを試みたサイト上のすべてのページのインデックスステータスが、ステータス別と理由別にグループ化されて表示されます。各ページは、次の一般的なステータスのクラスのいずれかになります。各ステータス (有効、警告、エラー、除外) にはそれぞれ固有の理由があります。表のデータは理由別にグループ化されており、各行には 1 つ以上の URL が記載されています。

エラー
ページはインデックスに登録されていません。詳細およびエラーの修正方法については、後述するエラータイプの説明を参照してください。
警告
ページはインデックスに登録されているか、何らかの理由により登録されなかった可能性があります。
除外
通常はユーザーによる対処が不可能な何らかの理由によって、ページはインデックスに登録されていません。こうしたページはインデックス登録処理の途中段階にある可能性があります。また、ページが noindex ディレクティブなどを使用して意図的に除外されていて、正しい動作であることもあります。
有効
ページはインデックスに登録されました。

エラー

サーバーエラー (5xx)
サーバーから 500 レベルのエラーが返されました。以下の点について確認してください。
動的ページへのリクエストに伴う過剰なページ読み込みを減らす
GET パラメータが付与された動的ページは応答に時間がかかるため、タイムアウトの原因になることがあります。原則としてパラメータは短くし、使用する数を少なくすることが推奨されます。また、サイトでのパラメータの処理方法について Google に知らせることもできます。
ホスティング サーバーの停止、過負荷、設定ミスがないかを確認する
上記を行っても、接続、タイムアウト、または応答の問題が解決しない場合は、ウェブホスティングプロバイダに相談して、サイトのトラフィック処理能力の増強を検討します。
Google のクローラを誤ってブロックしていないか確認する
DNS 設定、ファイアウォールや DoS 対策保護システムの設定、コンテンツ管理システムの設定が原因で Google のクローラがブロックされる場合があります。保護システムは多くの場合、大量のサーバーリクエストを自動的にブロックするように設定されています。Googlebot は大量にリクエストすることが多いため、クロールがブロックされる場合があります。こうした問題を解決するには、インフラストラクチャのどの部分が Googlebot をブロックしているかを判断し、ブロックを解除します。
検索エンジンによるサイトのクロールとインデックス登録を適切に管理する
ファイアウォールなどにより、意図的に Googlebot のアクセスを阻止することがあります。こうした問題を解決するには、Googlebot を全面的にブロックせずにサイトのクロールとインデックス登録の方法を適切に管理します。
リダイレクト エラー
URL でリダイレクトエラーが発生しました。リダイレクトチェーンが長すぎる、リダイレクトループが発生している、リダイレクト URL が最終的に URL の最大長を超えた、リダイレクトチェーンの URL が無効であるなどの可能性が考えられます。
送信された URL が robots.txt によってブロックされました
インデックスに登録するために送信したページが、robots.txt によってブロックされています。robots.txt を検証するには robots.txt テスターでページをテストを行います。
送信された URL に noindex タグが追加されています
インデックスに登録するために送信したページに meta タグ、または noindex ディレクティブがあります。このページをインデックスに登録するには、これらを削除する必要があります。
送信された URL はソフト 404 エラーのようです
インデックスに登録するために送信したページが、サーバーによってソフト 404 と判断されました。
送信された URL が未承認のリクエスト (401) を返しました
インデックスに登録するために送信したページから、Google が 401 (Unauthorized: 承認が必要) レスポンスを受け取りました。認証機能を使ったページの保護を削除するか、Googlebot からのアクセスであることを確認して、ページへのアクセスを許可してください。
送信された URL が見つかりませんでした (404)
インデックスに登録するために送信した URL が存在しませんでした。404 エラーのほとんどは、そのサイトの Google 検索結果でのランキングに影響を及ぼすことはないため、エラーを無視しても問題はありません。404 エラーの調査と修正については、以下の点を検討してください。
修正の必要があるかを判断します
404 エラーはサイトのインデックス登録やランキングに影響を及ぼすことはないため、他のエラーは無視しても問題はありません。
  • ページが削除されており、代わりのページや同じようなページがない場合は 404 を返すようにしてください。
  • スクリプトが生成した無効な URL や、サイトに存在したことがない URL の場合、特に問題はありません。レポートには表示されますが、URL のスペルが間違っていない限り修正する必要はありません。
無効なリンクが公開されている場所を確認します
修正方法は、リンクがサイトからのリンクか、他のサイトからのリンクかによって異なります。URL をクリックして [これらのページからのリンク] 情報を確認します。
  1. 存在しないページへのご自分のサイトからのリンクを修正するか、必要に応じて削除します。
    • コンテンツを移動した場合は、リダイレクトを追加します。
    • コンテンツを完全に削除した場合は、元の URL から 404 (Not Found: 未検出) または 410 (Gone: 消滅)を返すようにします。Google では、410 を 404 と同じものとして扱っています。存在しないページについて 404 か 410 以外のコードを返すと問題になる可能性があります。そのようなページはソフト 404 エラーと呼ばれ、ユーザーにとっても検索エンジンにとっても混乱の原因となるおそれがあります。
    • URL が不明な場合は、サイトに存在したことのない URL に対して 404 エラーが表示されることがあります。そのような予期しない URL は、Googlebot が動的なリンク、または他の埋め込みコンテンツの中で検出されたリンクか、サイトマップにのみ存在している可能性があります。Googlebot は、実在するページでなくてもクロールを試みる場合があります。その場合、このリンクが 404 エラーとして [クロールエラー] レポートに表示されます。ただし、このエラーがサイトのクロールやランキングに影響を及ぼすことはありません。
  2. スペルミスがある他のサイトからのリンクを 301 (Moved Permanently: 恒久的に移動) リダイレクトで修正します。例えば、誰かがサイトにリンクする際に正規の URL のスペルを誤っただけで、エラーが発生します。そのような場合は、正しい URL への 301 リダイレクトを作成して、サーバーの設定にそのスペルミスのある URL を登録できます。また、リンクが間違っているサイトの管理者に連絡して、リンクの更新や削除を依頼することも検討してください。
他のエラーは無視します
エラーのある URL をブロックするために、ダミーコンテンツの作成、ホームページへのリダイレクト、robots.txt の使用はしないでください。これらの対応は、Google がサイトの構造を把握して適切に処理ができなくなる原因となります。クロールエラーレポートで [この問題は修正済み] をクリックしても、一時的に 404 エラーが非表示になるだけで、次回 Google が URL をクロールしようとしたときに再度エラーが表示されます。また、URL 削除ツールを使って URL の削除をリクエストした場合でも、このレポートからエラーは削除されません。
送信された URL のクロールに問題があります
インデックスに登録するために送信したページで、上記のいずれにも該当しない不明のクロールエラーが発生しました。URL 検査ツールを使用して、ページをデバッグしてください。

警告

ステータスが警告のページでは、対応が必要になることがあります。特定の結果に応じて、インデックスに登録されなかった可能性があります。

robots.txt によりブロックされましたが、インデックスに登録しました
このページは robots.txt によりブロックされましたが、インデックスに登録されています。Google では、robots.txt を使用して登録しますが、他のユーザーがこのページにリンクしている場合、robots.txt は使用されません。このページを検索結果からブロックしてもよいかどうかわからないため、警告のステータスとなります。インデックスに登録されないようにするには、noindex を使用するか、認証を使ってページへの匿名アクセスを禁止してください。

除外

ステータスが除外であるページは通常、インデックスに登録されません。つまり、インデックス登録しないのが適切であると Google が判断したページがこの項目に該当します。ステータスが除外となるケースは以下のとおりです。

noindex タグによって除外されました
Google がページをインデックスに登録しようとしたときに noindex ディレクティブが検出されたため、インデックスに登録されませんでした。このページをインデックスに登録したくない場合は、正しく作動しています。このページをインデックスに登録したい場合は、noindex ディレクティブを削除してください。
ページ削除ツールによりブロックされました
ページは URL 削除リクエストによりブロックされています。確認済みのサイト所有者であれば、誰が URL 削除リクエストを送信したかを URL 削除ツールで確認できます。ブロックの期間が過ぎるとインデックス登録リクエストを再送信しなくても Googlebot が再びページにアクセスし、ページがインデックスに登録されることがあります。ページをインデックスに登録したくない場合は、noindex を使用するか、認証機能を使ってページを保護するか、ページを削除します。
robots.txt によりブロックされました
このページは robots.txt ファイルによって Googlebot のアクセスがブロックされています。robots.txt でブロックされていても、他の方法によってページがインデックスに登録されることがあります。Google のインデックスに確実に登録されないようにするには、robots.txt によるブロックを削除して noindex ディレクティブを使用します。
未承認のリクエスト (401) が原因でブロックされました
このページへのアクセスには認証が必要なため、Googlebot のアクセスがブロックされています。Googlebot がこのページをクロールできるようにするには、認証機能を使ったページの保護を削除するか、Googlebot によるページへのアクセスを許可します。
クロールエラー
この URL の取得時に不特定のエラーが発生しました。HTTP レスポンスコードが 4xx または 5xx レベルのエラーの可能性があり、ページはインデックスに登録されていません。この問題に対処するためには、URL 検査ツールを使用して問題が発生するかどうかを確認します。
クロール済み - インデックス未登録
ページは Google によりクロールされましたが、インデックスには登録されていません。今後、インデックスに登録される可能性がありますが、登録されない可能性もあります。この URL のクロールのリクエストを再送信する必要はありません。
検出 - インデックス未登録
ページは Google により検出されましたが、まだクロールされていません。これは通常、Google が URL をクロールしようとして、サイトが過負荷だったためにクロールの再スケジュールが必要となった場合です。そのため、レポート上で最終クロール日が空欄になっています。
代替ページ (適切な canonical タグあり)
このページは Google が正規ページとして認識しているページと重複しています。正規ページへのリンクが正しく指定されているため、これ以上の対処は必要ありません。
重複しています。ユーザーにより、正規ページとして選択されていません
このページには重複するページがあり、そのどのページも正規ページとして指定されていません。Google ではこのページが正規ページではないと判断しています。明示的にこのページの正規ページを指定する必要があります。この URL を検査すると、Google が選択した正規 URL が表示されます。
非 HTML ページの重複
非 HTML ページ (PDF ファイルなど) が、Google が正規ページとして認識した別のページと重複しています。通常は正規 URL のみが Google 検索結果に表示されます。必要に応じて、HTTP レスポンスヘッダーを使用して正規ページを指定できます。
重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました
Google は、対象のページではなく、正規ページとして適切であると考えるページをインデックスに登録しました。対象の URL を検査すると、Google が選択した正規 URL が表示されます。対象のページを正規 URL の重複ページとして明示的にマークすることが推奨されます。
見つかりませんでした (404)
このページのリクエスト時に 404 エラーが返されました。Google は、リクエストやサイトマップなしで、対象の URL を検出しました。別のサイトからのリンクとして URL を検出、またはページが削除された可能性があります。クロールの頻度は次第に低下しますが、検出済みの URL を Googlebot から完全に削除する方法はありません。意図的に 404 レスポンスを返している場合は問題ありませんが、ページを移動した場合は 301 リダイレクトを使用して新しいアドレスに転送してください。404 エラーの調査と修正については、以下の点を検討してください。
修正の必要があるかを判断します
404 エラーはサイトのインデックス登録やランキングに影響を及ぼすことはないため、他のエラーは無視しても問題はありません。
  • ページが削除されており、代わりのページや同じようなページがない場合は 404 を返すようにしてください。
  • スクリプトが生成した無効な URL や、サイトに存在したことがない URL の場合、特に問題はありません。レポートには表示されますが、URL のスペルが間違っていない限り修正する必要はありません。
無効なリンクが公開されている場所を確認します
修正方法は、リンクがサイトからのリンクか、他のサイトからのリンクかによって異なります。URL をクリックして [これらのページからのリンク] 情報を確認します。
  1. 存在しないページへのご自分のサイトからのリンクを修正するか、必要に応じて削除します。
    • コンテンツを移動した場合は、リダイレクトを追加します。
    • コンテンツを完全に削除した場合は、元の URL から 404 (Not Found: 未検出) または 410 (Gone: 消滅)を返すようにします。Google では、410 を 404 と同じものとして扱っています。存在しないページについて 404 か 410 以外のコードを返すと問題になる可能性があります。そのようなページはソフト 404 エラーと呼ばれ、ユーザーにとっても検索エンジンにとっても混乱の原因となるおそれがあります。
    • URL が不明な場合は、サイトに存在したことのない URL に対して 404 エラーが表示されることがあります。そのような予期しない URL は、Googlebot が動的なリンク、または他の埋め込みコンテンツの中で検出されたリンクか、サイトマップにのみ存在している可能性があります。Googlebot は、実在するページでなくてもクロールを試みる場合があります。その場合、このリンクが 404 エラーとして [クロールエラー] レポートに表示されます。ただし、このエラーがサイトのクロールやランキングに影響を及ぼすことはありません。
  2. スペルミスがある他のサイトからのリンクを 301 (Moved Permanently: 恒久的に移動) リダイレクトで修正します。例えば、誰かがサイトにリンクする際に正規の URL のスペルを誤っただけで、エラーが発生します。そのような場合は、正しい URL への 301 リダイレクトを作成して、サーバーの設定にそのスペルミスのある URL を登録できます。また、リンクが間違っているサイトの管理者に連絡して、リンクの更新や削除を依頼することも検討してください。
他のエラーは無視します
エラーのある URL をブロックするために、ダミーコンテンツの作成、ホームページへのリダイレクト、robots.txt の使用はしないでください。これらの対応は、Google がサイトの構造を把握して適切に処理ができなくなる原因となります。クロールエラーレポートで [この問題は修正済み] をクリックしても、一時的に 404 エラーが非表示になるだけで、次回 Google が URL をクロールしようとしたときに再度エラーが表示されます。また、URL 削除ツールを使って URL の削除をリクエストした場合でも、このレポートからエラーは削除されません。
法的申し立てにより、ページが削除されました
ページは法的な申し立てによりインデックスから削除されました。
ページにリダイレクトがあります
URL はリダイレクトであるため、インデックスに登録されませんでした。
クロールのキューに追加されました
ページはクロールのキューに追加されています。数日後に、クロールされたかどうかをもう一度確認してください。
ソフト 404
ページをリクエストしたところ、ソフト 404 のレスポンスが返されました。見つからなかったページで 404 レスポンスコードを返すか、ソフト 404 ではない詳細情報をページに追加することが推奨されます。
送信された URL は削除済みです
このページのインデックス登録リクエストが送信されましたが、このページは何らかの理由でインデックスから削除されています。
重複しています。送信された URL が正規 URL として選択されていません
この URL は、正規ページとして明示的に指定されていない重複した URL の 1 つです。この URL はインデックスに登録するよう明示的にリクエストされましたが、重複ページであるため、Google は別の URL を正規ページとして適切と判断しました。この URL の代わりに、Google の選択した正規ページがインデックスに登録されています。インデックス登録が明示的にリクエストされていない場合は、「Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」のステータスになります。この URL を検査すると、Google が選択した正規 URL が表示されます。

有効

ステータスが有効であるページはインデックスに登録済みです。

送信して登録されました
インデックスに登録する目的でこの URL を送信し、インデックスに登録されました。
インデックス登録されましたが、サイトマップに送信していません
この URL は Google によって検出され、インデックスに登録されました。重要な URL はすべて、サイトマップを使用して送信することが推奨されます。
インデックス登録されましたが、正規ページとしての登録を検討してください
この URL はインデックスに登録されています。重複する URL がありますが、この URL が正規 URL として見なされます。これは、明示的に正規として指定されておらず、明示的に正規として指定することが推奨されます。

サイトマップ

サイトマップレポートを使用すると、自分のサイトのどのサイトマップが処理されたかや処理エラーを確認したり、新しいサイトマップを送信したりできます。Google がサイト上の適切なコンテンツを検出できるようにするため、またはコンテンツの追跡やエラーの報告を改善するために、サイトマップの使用が推奨されます。クロール用の新しいサイトマップを送信するには、以下の手順で行います。

  1. サイトにサイトマップを掲載します。
    • サポートされているサイトマップ形式のいずれかを使用する必要があります。
    • サイトマップには Googlebot がアクセスできるようにしておき、ログインを求めるページなどでブロックされないようにしておく必要があります。
  2. サイトマップレポートで、サイトマップの相対 URL を入力して [送信] をクリックします。
  3. サイトマップはただちに処理されます。ただし、サイトマップに記載された URL のクロールには時間がかかることがあります。また、サイトのサイズ、アクティビティ、トラフィックなどによっては、すべての URL がクロールされる保証はありません。
サイトマップレポート
サイトマップレポート
サイトマップの送信
サイトマップの送信
サイトマップの処理結果
サイトマップの処理結果
サイトマップ URL
サイトマップが掲載されている場所の URL です。この URL は、すべてのディレクトリ、またはサブディレクトリに配置されたサイトマップが表示されます。
タイプ
サイトマップのタイプです。値は以下のとおりです。
  • サイトマップ: 標準のサイトマップ
  • サイトマップインデックス: サイトマップのサイトマップ
  • 不明: 送信されたファイルが既知のタイプのサイトマップではない、またはサイトマップがまだ処理されていないことを示します。
送信日
サイトマップが送信された日
最終処理日時
Google によってサイトマップが最後に処理された日時です。
ステータス
送信またはクロールのステータスです。値は以下のとおりです。
  • 正常に処理されました: サイトマップが読み込まれ、エラーなしで正常に処理されました。すべての URL がクロールのキューに追加されます。
  • 問題があります: サイトマップにエラーがあります。サイトマップから取得可能な URL はクロールのキューに追加されます。
  • 取得できませんでした: 何らかの理由によりサイトマップを取得できませんでした。
URL 数
サイトマップに記載されている URL の数です。サイトマップインデックスの場合、この数は参照されているすべてのサイトマップに記載されている URL の総数になります。重複する URL は 1 回のみカウントされます。

サイトマップのエラー

サイトマップでエラーが発生した場合、以下のエラーがサイトマップレポートで報告されます。

URL にアクセスできません
Google がサイトマップ内の URL を表示しようとしてエラーが発生した場合です。URL 検査ツールを使用して、サイトマップ内の URL を検査し、URL が Google で使用できるかどうかを確認してください。
クロールが完了できなかった URL
一部の URL に含まれるリダイレクトの数が多すぎて、サイトマップの処理を完了できなかった場合を通常示します。別のページにリダイレクトする各 URL を、リダイレクト先の URL に置き換えることが推奨されます。リダイレクトでクロールできないその他の理由と解決策は以下のとおりです。
  • Lynx などのテキストブラウザを使用してサイトを確認します。ほとんどの検索エンジンでは、Lynx に表示される形式でサイトが認識されます。JavaScript、Cookie、セッション ID、フレーム、DHTML、Flash などの機能が使用されており、サイトの一部がテキストブラウザで表示されない場合は、クロールできない可能性があります。
  • あるページから別のページに完全にリダイレクトする場合は、恒久的リダイレクトを使用できます。ただし、JavaScript や meta-refresh タイプのリダイレクトは使用しないようにしてください。
  • 可能な場合は、相対リンクではなく絶対リンクまたは完全リンクを使用します。
許可されていない URL
サイトマップの一部の URL が、そのサイトマップのファイルより上位の階層、または異なるドメインにあります。それらの URL は、サイトマップでは無効になります。
圧縮エラー
圧縮されたサイトマップファイルを Google が解凍しようとした際にエラーが発生しました。gzip などのツールでサイトマップをもう一度圧縮してサイトにアップロードし、再送信してください。
空のサイトマップ
サイトマップに URL がまったく含まれていません。サイトマップを確認してください。サイトマップでサイトマッププロトコルを使用している場合は、URL のタグが正しいかどうかを確認してください。
サイトマップのファイルサイズ エラー: サイトマップのサイズが上限を超えています。
サイトマップのサイズが圧縮されていない状態で 50 MB を超えています。サイトマップが上限を超える場合は小さなサイトマップに分割し、分割したサイトマップをサイトマップインデックスファイルに記載してください。
属性値が無効です
XML のタグ属性に無効な値が割り当てられています。サイトマップに属性や値の入力ミスがないか確認し、指定可能な属性や値を割り当てるようにしてください。
無効な日付
サイトマップに無効な日付が含まれています。日付の形式が間違っているか、日付自体が無効である可能性があります。日付は W3C Datetime 形式で指定する必要がありますが、時間の部分は省略できます。
タグの値が無効です
サイトマップ内の URL が無効です。サポートされていない文字、スペース、引用符などの記号が使用されている、形式に誤りがあるなどが考えられます。サイトマップ内の URL が読み取り可能な形式でエンコードされ、適切にエスケープされていることを確認してください。また、ブラウザに URL をコピーして、ページを読み込めるかどうかも確認してください。
サイトマップインデックスファイル内の URL が無効: 不完全な URL
サイトマップインデックスファイル内で、各サイトマップファイルの完全な URL が指定されていません。サイトマップインデックスファイルを確認する際に、このファイルが参照するディレクトリでサイトマップファイルを探します。例えば、サイトマップインデックスファイルのパスが /sitemap_index.xml の場合、サイトマップが sitemap.xml と表示されていると、/sitemap.xml でサイトマップを探します。この場所にサイトマップファイルが存在しない場合、このエラーが表示されます。サイトマップインデックスファイルを更新し、各サイトマップファイルへの完全なパスを指定して、再送信してください。
無効な XML: タグが多すぎます
サイトマップに重複するタグがあります。例えば、以下の例では <loc> タグが 2 つあるためエラーが発生します。このエラーには、問題のあるタグと行番号が表示されます。重複するタグを削除して、サイトマップを再送信してください。
<url>
  <loc>http://www.example.com/</loc>
  <loc>http://www.example.com/page1.html</loc>
  <lastmod>2005-01-01</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.8</priority>
</url>
<loc> タグが 2 つあるサイトマップの例
XML 属性が指定されていません
サイトマップ内のタグの必須属性が指定されていません。サイトマップ内の必須属性がすべて指定されていることを確認してください。属性の値を修正し、サイトマップを再送信してください。
XML タグが指定されていません
必須タグが指定されていないエントリがサイトマップにあります。エラーメッセージには行番号が表示されます。
サムネイル URL がありません
サムネイル画像への URL が指定されていない動画エントリがあります。サムネイルの URL の場所が <video:thumbnail_loc> タグで指定されているか確認してください。
動画のタイトルがありません
タイトルが指定されていない動画エントリがあります。サイトマップ内の各動画に <video:title> タグでタイトルが指定されているか確認してください。
サイトマップインデックスの形式に誤りがある: ネストされたサイトマップインデックス
サイトマップインデックスファイル内のエントリで、独自の URL または別のサイトマップインデックスファイルの URL が使用されています。サイトマップインデックスファイルに、指定できるのはサイトマップファイルのみです。サイトマップインデックスファイルを指すエントリをすべて削除し、サイトマップを再送信してください。
解析エラー
Google がサイトマップの XML を解析できなかった場合に発生するエラーです。多くの場合、URL にエスケープされていない文字が含まれていることが原因です。他の XML ファイルと同様に、データ値には、特定の文字にエンティティのエスケープコードを使う必要があります。データ値が正しくエスケープしているかどうかを確認してください。
一時的なエラー
サイトマップの処理を妨げる一時的なエラーが Google で発生しました。通常、このエラーが発生した場合は、サイトマップを再送信する必要はありません。しばらくしてから、Google はサイトマップの取得をもう一度試みます。数時間経ってもエラーがそのままの場合は、サイトマップを再送信してください。
サイトマップの制限数超過 (サイトマップインデックスファイル内)
サイトマップインデックスファイルに、50,000 件を超えるサイトマップが指定されている場合に発生するエラーです。サイトマップインデックスを複数のサイトマップインデックスファイルに分割し、各ファイル内のサイトマップ数を 50,000 件以下にします。
URL の制限数超過 (サイトマップ内)
サイトマップに 50,000 件を超える URL が指定されている場合に発生するエラーです。サイトマップを複数のサイトマップに分割し、各ファイル内の URL 数を 50,000 件以下にします。サイトマップインデックスファイルを使用してサイトマップを管理することもできます。
サポートされていない形式
サイトマップがサポートされていない形式が使われています。サイトマップに正しいヘッダーを指定する必要があります。例えば、サイトマップに動画情報を含める場合は、以下のようなヘッダーを指定します。
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
サイトマップに動画情報を含める場合のヘッダー例
パスの不一致: www がない
サイトマップへのパスに www プレフィックスが指定されていません。www を含まない URL に対するサイトマップを送信したい場合で、リスト内の URL には www を指定する場合は、www をサイトの使用するドメインとして選択します。それ以外の場合は、サイトマップを変更して、サイトマップの場所と一致するようすべての URL から www を削除してください。
パスの不一致: www がある
サイトマップへのパスに www プレフィックスが指定されているのに、リスト内の URL には指定されていません。www を含む URL に対するサイトマップを送信したい場合で、リスト内の URL には www を指定する場合は、www を含まないバージョンをサイトの使用するドメインとして選択します。それ以外の場合は、サイトマップを変更してサイトマップの場所と一致するようすべての URL に www を追加してください。
誤ったネームスペース
サイトマップのルート要素で正しいネームスペースが指定されていない、ネームスペース宣言に誤りがある、タイプミス、URL の誤りのいずれかがあります。ファイル形式の正しいネームスペースを使用していることを確認してください。
スペースで始まっています
サイトマップがネームスペース宣言ではなく、スペースで始まっています。XML ファイルの先頭には、使用する XML バージョンを指定した XML 宣言を記述する必要があります。このエラーが発生してもサイトマップは処理されますが、ファイルが XML 規格に従うようにスペースを削除し、このエラーが発生しないようにしてください。
HTTP エラー (特定のステータスコード)
サイトマップをダウンロードしようとした際に HTTP エラーが発生しました。このメッセージには、Google が受信したステータスコードが表示されます。サイトマップの URL を正しく指定していることと、指定した場所にサイトマップがあることを確認し、サイトマップを再送信します。
サムネイルが大きすぎる
サイトマップで指定された動画のサムネイル画像が小さすぎます。動画のサムネイル画像のサイズを 160 x 120 ピクセルに変更してください。
動画の場所と再生ページの場所が同じ
動画サイトマップで、動画コンテンツの URL とプレーヤーの URL に同じものを指定することはできません。<video:player_loc><video:content_loc> の両方を指定する場合は、異なる URL を使用してください。
動画の場所の URL が再生ページの URL になっている
動画サイトマップで、<video:content_loc> の URL がプレーヤーをホストするページを指しています。
サイトマップに robots.txt によってブロックされている URL が含まれている
robots.txt でブロックされているため、Google からサイトマップにアクセスできません。URL 検査ツールを使って、ブロックしているファイルを確認し、robots.txt を修正して Googlebot がアクセスできるようにします。

モバイルユーザビリティ

モバイルユーザビリティレポートでは、モバイル端末で表示した場合にユーザビリティの問題があるものを特定できます。最上位のビューには、モバイルユーザビリティの問題のしきい値レベルを超えるすべてのページが表示されます。それぞれの問題をクリックすると問題の詳細が表示されます。この詳細では、その問題の該当ページのサンプルリスト、修正方法、修正後に Google に通知する手続きを確認できます。

モバイルユーザビリティ
モバイルユーザビリティ

グラフには、選択した内容に応じて、エラーや有効のステータスにあるページの数が表示されます。[表示回数] チェックボックスには、モバイル端末からのページの表示回数が示されます。

表には、最大 1,000 行のデータを表示できます。一部の該当ページが表示されない場合もあります。これには、該当ページ数が 1,000 ページを超えている、問題が検出されなかった、問題が非常に新しいものである、またはユーザビリティのしきい値スコアを上回るページで問題が発生しているといった理由が考えられます。レポートには以下の情報が表示されます。

  • ステータス: ページは以下の 2 つのステータスのいずれかになります。
    • エラー: このページはモバイル対応ではありません
    • 有効: このページはモバイル対応です
  • ページ: この問題が発生しており、ステータスがエラーになっているページの数。
ステータス
Google では、内部のモバイルユーザビリティスコアに応じて、ページを有効またはエラーとしてマークします。このスコアは、問題の数とその相対的な重大度に応じて計算されます。
エラー
エラーのステータスは、ページがモバイルユーザビリティの最低限のレベルを下回っていることを意味します。エラーステータスにあるページは、該当するモバイルユーザビリティの各問題の詳細ページに表示されます。
有効
有効のステータスは、ページがモバイルユーザビリティの最低限のレベルを満たしていることを意味します。モバイルユーザビリティの問題が依然として残っている可能性がありますが、このレポートではページに含まれる問題として記載されません。有効のステータスにあるページにモバイルユーザビリティの問題がまったくないことを確認するには、モバイルフレンドリーテストツールを使用してテストする必要があります。
ページ
有効のステータスにあるページに問題があったとしても、そのページは問題の該当ページ数にはカウントされず、問題に該当するページのリストにも表示されません。エラーステータスにあるページのみが、該当する問題の数にカウントされ、該当ページのリストに表示されます。

モバイルユーザビリティのエラー

モバイルユーザビリティレポートには、以下のエラーが表示される可能性があります。サイトのエラーを修正したら、Google に修正済みページの再クロールをリクエストします。詳細については、後述するの「検証」の章を参照してください。

互換性のないプラグインを使用しています
ほとんどのモバイル ブラウザでサポートされていないプラグインがページに含まれています。HTML5 など、広くサポートされている最新の Web テクノロジーを使用してページを再設計することが推奨されます。
ビューポートが設定されていません
ページに viewport プロパティが定義されていません。このプロパティは、画面サイズに合わせてページのサイズとスケーリングを調整する方法をブラウザに指示します。サイトにアクセスするユーザーは、大きなデスクトップ モニター、またはタブレットや小型のスマートフォンなど、画面サイズの異なるさまざまな端末を使用しています。そのため、ページでは meta viewport タグを使用してビューポートを指定してください。詳しくは、レスポンシブ ウェブデザインの基礎をご覧ください。
ビューポートが「端末の幅」に収まるよう設定されていません
ページに固定幅の viewport プロパティが定義されているため、異なる画面サイズに合わせて調整することができません。このエラーを修正するには、サイトのページにレスポンシブデザインを導入し、デバイスの幅とスケーリングに合わせてビューポートを設定します。
コンテンツの幅が画面の幅を超えています
このレポートには、ページ上の語句や画像を表示するために水平スクロールを必要とするページが示されます。このエラーは、ページの CSS 宣言で絶対値を使用している場合や、ページの画像が特定のブラウザ幅で最適に表示されるように設計されている場合に発生します。このエラーを修正するには、ページの CSS 要素に対して相対的な幅と位置の値を使用し、画像も同様にスケーリングできるようにします。
テキストが小さすぎて読めません
このレポートには、フォントサイズが小さすぎて文字が読めず、モバイル ユーザーがピンチ操作をして拡大しなければならないページが示されます。ウェブページのビューポートを指定した後にフォントサイズを設定して、ビューポート内で適切にスケーリングします。フォントサイズに関するベストプラクティスについて詳しくは、読みやすいフォントサイズを使用する方法についての記事をご覧ください。
クリックできる要素同士が近すぎます
このレポートには、ボタンやナビゲーションリンクなどのタップ要素同士が近すぎるために、モバイル ユーザーが隣接する要素をタップせずに指を使って目的の要素をタップすることが容易にできないサイトの URL が示されます。これらのエラーを修正するには、ボタンやナビゲーション リンクのサイズやスペースをモバイル ユーザーに適するように正しく設定します。

検証

サイト上で特定の問題のあるページをすべて修正したら、Google に変更の検証をリクエストすることができます。問題の検出されたページがすべて修正されると、ステータスの表でその問題のステータスが「修正済み」に変わり、表の一番下に移動します。Search Console は、問題全体の検証ステータスと問題があるページの検証ステータスの両方をトラッキングします。問題のあるページがすべて修正されると、問題は「修正済み」とみなされます。

問題の継続期間は、サイト上でその問題のあるページが初めて検出された日を起点とし、問題のある最後のページの修正が記録されてから 90 日後までとなっています。同じ問題が再び発生せずに 90 日が過ぎると、その問題はレポートの履歴から削除されます。問題の初検出日は、その問題の継続期間において問題が最初に検出された日付です。この日付は変更されません。そのため、以下のようになります。

  • 問題のあるページがすべて修正され、その 15 日後に同じ問題のあるページが新たに発生した場合、問題は未解決としてマークされ、「初検出日」は元の日付のままとなります。
  • 問題のある最後のページが修正されてから 91 日後に同じ問題が発生した場合、前の問題は解決済みとなっているため、この問題は新たな問題として記録され、初検出日は「今日」に設定されます。
基本的な検証フロー
問題で [修正を検証] をクリックすると実行される検証処理の概要は以下のとおりです。この処理には数日かかることがあり、進捗状況を知らせるメールが届きます。
  1. [修正を検証] をクリックすると、ただちに Search Console によりサンプルとして数ページがチェックされます。
    • サンプルのページに現在も問題が存在する場合、検証は終了し、検証ステータスは変更されません。
    • サンプルのページにエラーが見つからなかった場合は、検証が続行され、検証ステータスは「開始」となります。この検証において無関係の他の問題が検出された場合、そうした問題は該当する他の種類の問題としてカウントされ、検証は続行されます。
  2. Search Console の処理には、この問題に該当する既知の URL のリストが使用されます。サイト全体ではなく、この問題のある既知のページの URL のみが再クロールのキューに追加されます。Search Console の検証履歴にはチェックしたすべての URL が記録されます。検証履歴には問題の詳細ページからアクセスできます。
  3. URL のチェック時に次の処理が行われます。
    1. 問題が検出されなかった場合、問題のあるページの検証ステータスは「合格」になります。このページが検証開始後に初めてチェックされたページである場合、問題の検証ステータスは「修正を確認しました」になります。
    2. URL にアクセスできなくなっている場合、問題のあるページの検証ステータスは「その他」 (エラーとはみなされません) になります。
    3. 問題のあるページがまだ存在する場合は、問題のステータスが「不合格」になり、検証は終了します。このページが通常のクロールで検出された新しいページの場合は、この既存の問題がある新たなページとみなされます。
  4. エラーおよび警告のある URL がすべてチェックされて、問題の数が 0 の場合、問題のステータスは「合格」になります。ただし、該当ページ数が 0 になって問題のステータスが「合格」に変更されても、元の重大度レベル (「エラー」または「警告」) の表示はそのままとなります。
再検証
不合格となった検証の [再検証] をクリックすると、問題があり検証で不合格となったすべてのページのほかに、通常のクロールで新たに同じ問題が検出されたページを対象として、検証が再び開始されます。現在の検証サイクル中に問題を修正した場合でも、現在の検証サイクルが完了するまで待ってから、新たな検証サイクルをリクエストする必要があります。検証に合格したページ (「合格」とマークが付けられたページ) やアクセスできなくなったページ (「その他」とマークが付けられたページ) は再チェックされず、[再検証] をクリックした際に履歴から削除されます。
検証履歴
問題の詳細ページで検証の詳細のリンクをクリックすると、検証リクエストの進捗状況を確認できます。AMP レポートとインデックスステータスレポートでは、検証履歴ページの項目は URL 別にグループ化されます。モバイルユーザビリティレポートやリッチリザルトレポートでは、項目は URL と構造化データの項目 (項目の「name」の値により判断されます) の組み合わせを基準としてグループ化されます。検証ステータスは、調査中の特定の問題に適用されます。ページ上の 1 つの問題に「合格」ラベルが付き、他の問題には「不合格」、「保留中の検証」、「その他」のラベルが付くことがあります。
問題の検証ステータス
個々の問題には、次の検証ステータスが適用されます。
  • 開始前: この問題のあるページが存在しますが、検証はまだ開始されていません。次のステップ
    1. 問題をクリックしてエラーの詳細を確認します。AMP テストを使用して個別のページを調査し、公開中のページ上でのエラーの例を確認します 。
    2. 詳細ページで [詳細] をクリックして、違反しているルールの詳細を確認します。
    3. 表内にある URL の例の行をクリックして、そのエラーの詳細を確認します。
    4. ページを修正し、[修正を検証] をクリックして Google にページの再クロールをリクエストします。Google から検証の進捗状況の通知が届きます。検証には数日から最大で約 2 週間かかります。
  • 開始: 検証が開始されました。この問題が残っているページはまだ検出されていません。以降は検証が進むと Google から対応方法を伝える通知が届きます。
  • 修正を確認しました: 検証が開始され、これまでにチェックしたページがすべて修正されています。以降は必要な作業はありませんが、検証が進むと Google から対応方法を伝える通知が届きます。
  • 合格: 問題のある既知のページがすべて修正、または該当する URL にアクセスできなくなっています。このステータスにするには、[修正を検証] をクリックする必要があります。以降は必要な作業はありません。
  • 該当なし: 検証を開始していませんが、すべての URL で問題が修正されていることが Google により検出されました。以降は必要な作業はありません。
  • 不合格: [検証] がクリックされましたが、一部のページにまだこの問題が存在します。問題を修正して再検証する必要があります。
問題のあるページの検証ステータス
検証をリクエストすると、特定の問題がある既知のすべてのページに次の検証ステータスのいずれかが割り当てられます。ただし、インデックスステータスレポートでは、「合格」と「その他」は使用されません。
  • 保留中の検証: 検証のキューに追加されています。Google による前回の確認時に、このページには該当する問題が存在していました。
  • 合格: チェックの結果、このページに問題は存在しませんでした。このステータスになるのは、このページに対して [検証] をクリックした場合のみです。
  • 不合格: チェックの結果、このページにはまだ問題があります。このステータスになるのは、このページに対して [検証] をクリックした場合のみです。
  • その他: この該当ページをホスティングしている URL にアクセスできませんでした。または、ページ上で項目が見つかりませんでした。このステータスでは「合格」と同等とみなされます。
同じ URL でも、問題ごとにステータスが異なる場合があります。例えば、ある 1 つのページ内に問題 X と問題 Y の両方がある場合に、同じページ内で問題 X の検証ステータスが「合格」、問題 Y の検証ステータスが「保留中の検証」になる可能性があります。

AMP

このレポートは、AMP 固有の機能が表示される Google 検索結果への AMP ページの掲載を妨げるエラーの修正に活用できます。最上位のビューには、サイト上の問題が検出されたすべての AMP ページが、問題ごとにグループ化されて表示されます。それぞれの問題をクリックすると問題の詳細が表示されます。この詳細では、その問題の該当ページのサンプルリスト、修正方法、修正後に Google に通知する手続きを確認できます。

通常、このレポートの内容が以下のようになる必要があります。

  • サイト上に AMP エラーが存在しないこと。
  • レポートの AMP ページの総数 (有効 + 警告 + エラーページ) が、サイト上の AMP ページの数と一致すること。

AMP のエラー

このレポートでは、標準的な AMP 固有のエラーに加えて、次のような問題 (エラーと警告) が明らかになることがあります。

コンテンツの不一致: 埋め込み動画なし
正規のウェブページに埋め込まれている動画が、対応する AMP バージョンに埋め込まれていません。通常、正規のウェブページにある重要なコンテンツリソースはすべて、対応する AMP バージョンに含めることが推奨されます。
推奨サイズより小さい画像を指定してください
AMP の構造化データが、推奨サイズより小さい画像を参照しています。これにより、Google 検索で AMP 関連の機能がページに表示されなくなる可能性があります。また、サイズの大きい画像が Discover カードに表示されなくなり、ウェブページのトラフィックやユーザーのエンゲージメントを低下させる原因となることもあります。修正するには、ガイドラインに沿って大きな画像を使用してください。
AMP ページのドメイン不一致
AMP ページが、正規バージョンのページとは異なるドメインでホストされています。これにより、モバイル端末から検索を行った場合に、検索結果に表示される URL ドメインと、AMP リーダーでページを開くときに表示される URL ドメインが異なってしまうため、ユーザーの混乱を招く可能性があります。
URL が見つかりませんでした (404)
リクエストされた AMP URL が見つかりませんでした。
サーバーエラー (5xx)
AMP ページをリクエストした際に、不明な 5XX サーバーエラーが発生しました。
robots.txt によりブロックされています
リクエストされた AMP URL は robots.txt によってブロックされました。
クロールエラー
AMP ページで不明なクロールエラーが発生しました。問題をトラブルシューティングするには、AMP URL で URL 検査ツールを使用してください。
参照している AMP URL は AMP ではありません
正規ページで参照している AMP は、実際には AMP ページではありません。
参照している AMP URL はスタンドアロン AMP です
正規ページがスタンドアロン AMP を指し示しています。スタンドアロン AMP をページの AMP バージョンとして参照することはできません。
URL に noindex が指定されています
AMP は noindex ディレクティブによってブロックされています。Google は、noindex によってブロックされたページをインデックスに登録することはできません。noindex ディレクティブを削除するか、ブロックされたページへの参照を削除してください。
このページの「unavailable_after」の日付が期限を過ぎています
AMP ページで「unavailable_after」meta タグまたはディレクティブがすでに渡されており、処理されなくなっています。タグを将来の日付に更新するか、タグを削除する必要があります。
正規 URL に指定した URL が無効です
正規ページが参照している AMP バージョンで、無効な形式の URL が使用されています。
AMP ストーリー正規化エラー
ページが、AMP バージョンとして AMP ストーリーページを誤って参照しています。AMP ストーリーページは、定義上スタンドアロンであるため、<rel="canonical"> タグでこのページ自体を指し示す必要があり、別のページの AMP バージョンとしては機能しません。

問題の優先順位の設定と修正

  1. AMP の概要のページで、警告をフィルタで除外して最初にエラーに焦点を合わせます。デフォルトでは、重大度、検証の状態、該当ページ数を組み合わせた条件に基づいて問題が並べ替えられています。このデフォルトの順序に沿って問題を修正することが推奨されます。共通する原因で発生しているエラーを最初に修正してから、各ページに固有のエラーを修正します。
  2. エラーの総数の増加のほとんどが単一のエラーにより引き起こされているかどうかを確認します。具体的には、表内でエラー総数の増加に対応する形で急増している単一の問題を探します。
  3. エラーの急激な増加と AMP ページの欠落への対処に関する情報を確認します。
  4. 表の行をクリックして、エラーの詳細ページを表示します。
    1. 詳細ページにはこのエラーに該当する URL のサンプルが表示されます。この URL の表示は最大 1,000 行という制約があり、また、エラーが最近検出されたページは含まれていない場合があるため、このリストは必ずしも完全なリストであるとは限りません。
    2. 構文エラーの場合は、[詳細] をクリックして公式ドキュメントで正しい構文を確認します。
    3. 調査アイコンをクリックして、該当ページに対して有効性テストを実行します。このテストでは、すべてのエラーを特定し、コードエクスプローラでエラーが強調表示されて詳細情報を確認できます。ライブページでエラーが修正済みであっても、まだ再クロールされていないためにエラーが表示され続けることがあります。その場合は、この問題のあるページをすべて修正した後で検証をリクエストします。
  5. サイト上で該当する問題のあるページをすべて修正し、修正をテストしたうえで、Web に修正が反映されていることを確認します。
  6. 問題の詳細ページに戻り、[検証して更新を Google に通知] ボタンをクリックして検証の処理を開始します。
  7. 引き続き、エラーを修正します。
  8. すべてのエラーの修正が終わったら警告のフィルタを解除し、必要に応じて、警告の出ている箇所を修正します。警告の中には、必須ではない構造化データのマークアップが欠落しているという警告が含まれていることがあります。そうした警告を修正すると、関連するコンテンツのあるページに対して新しい検索機能が有効になります。

エラーの急激な増加

急激な増加が、特定のページ群のステータスの変化が原因で発生したのかどうかを判別します。

  1. 急激な増加が見られる場合は、別のステータス (エラーまたは有効) でそれに対応する減少があるかどうかを探します。
  2. 対応する減少が見つかったら、両者の URL が同じであることを確認します。
  3. URL が別のステータスに変化している場合、ステータスが変わる原因となった変更を探します。

エラーの急激な増加の最もよくある原因は、サイト上の複数のページで使用されているテンプレートへのエラーの混入です。

AMP ページの欠落

レポート内の AMP ページの数 (有効 + 警告 + エラー) がサイト上の AMP ページの数よりも少ない場合は、以下の点を確認します。

  • 正規の非 AMP ページと AMP ページが正しくリンクしていることを確認します。
  • AMP ページと正規ページがいずれも robots.txtnoindex でブロックされていないこと、および認証やログインを求めるページで保護されていないことを確認します。
  • Google 検索で info: <canonical-page-URL> と入力して正規ページを検索し、インデックスに AMP ページと正規ページが登録されていることを確認します。検索結果にページが表示されない場合、ページはインデックスに登録されていません。
    • 検索結果に正規ページが表示される場合は、AMP ページに正しくリンクしていることを確認します。
    • 検索結果に正規ページが表示されない場合は、インデックス登録されるよう正規ページの情報を送信します。
  • AMP ページと正規ページが相互にリンクされていること、ページがサイトマップに記載されていることを確認します。AMP ページの数が少ない場合は正規ページで URL 検査ツールを使用してインデックス登録をリクエストします。ページ数が多い場合はサイトマップを使用します。サイトマップの送信にはサイトマップレポートの使用が推奨されます。
  • Google への新しいページの通知方法によっては、欠落しているページを Google が検出してクロールするまでに数日ほどかかることがあります。

警告について

警告の出ている AMP ページは、インデックスに登録されており Google 検索結果に表示されますが、一部の AMP 機能には表示されないことがあります。サイト上で特定の問題のあるページをすべて修正したら、Google に変更の検証をリクエストすることができます。問題の検出されたページがすべて修正されると、ステータスの表でその問題のステータスが「修正済み」に変わり、表の一番下に移動します。Search Console は、問題全体の検証ステータスと問題があるページの検証ステータスの両方をトラッキングします。問題のあるページがすべて修正されると、問題は「修正済み」とみなされます (実際に記録されるステータスについては、問題の検証ステータスと問題のあるページの検証ステータスをご覧ください) 。

問題の継続期間は、サイト上でその問題のあるページが初めて検出された日を起点とし、問題のある最後のページの修正が記録されてから 90 日後までとなっています。同じ問題が再び発生せずに 90 日が過ぎると、その問題はレポートの履歴から削除されます。問題の初検出日は、その問題の継続期間において問題が最初に検出された日付です。この日付は変更されないため、以下のようになります。

  • 問題のあるページがすべて修正され、その 15 日後に同じ問題のあるページが新たに発生した場合、問題は未解決としてマークされ、「初検出日」は元の日付のままとなります。
  • 問題のある最後のページが修正されてから 91 日後に同じ問題が発生した場合、前の問題は解決済みとなっているため、この問題は新たな問題として記録され、初検出日は「今日」に設定されます。

問題で [修正を検証] をクリックすると実行される検証処理の概要は以下のとおりです。この処理には数日かかることがあり、進捗状況を知らせるメールが届きます。

  1. [修正を検証] をクリックすると、ただちに Search Console によりサンプルとして数ページがチェックされます。
    • サンプルのページに現在も問題が存在する場合、検証は終了し、検証ステータスは変更されません。
    • サンプルのページにエラーが見つからなかった場合は、検証が続行され、検証ステータスは「開始」となります。この検証において無関係の他の問題が検出された場合、そうした問題は該当する他の種類の問題としてカウントされ、検証は続行されます。
  2. Search Console の処理には、この問題に該当する既知の URL のリストが使用されます。サイト全体ではなく、この問題のある既知のページの URL のみが再クロールのキューに追加されます。Search Console の検証履歴にはチェックしたすべての URL が記録されます。検証履歴には問題の詳細ページからアクセスできます。
  3. URL のチェック時に次の処理が行われます。
    1. 問題が検出されなかった場合、問題のあるページの検証ステータスは「合格」になります。このページが検証開始後に初めてチェックされたページである場合、問題の検証ステータスは「修正を確認しました」になります。
    2. URL にアクセスできなくなっている場合、問題のあるページの検証ステータスは「その他」になります。
    3. 問題のあるページがまだ存在する場合は、問題のステータスが「不合格」になり、検証は終了します。このページが通常のクロールで検出された新しいページの場合は、この既存の問題がある新たなページとみなされます。
  4. エラーおよび警告のある URL がすべてチェックされて、問題の数が 0 の場合、問題のステータスは「合格」になります。ただし、該当ページ数が 0 になって問題のステータスが「合格」に変更されても、元の重大度レベル (「エラー」または「警告」) の表示はそのままとなります。

[検証の開始] をクリックしていなくても、問題のあるページが修正されたことが Google により検出されることがあります。通常のクロールによって問題のあるページがすべて修正済みと確認された場合、レポート上のその問題のステータスは「該当なし」になります。

不合格となった検証の [再検証] をクリックすると、問題があり検証で不合格となったすべてのページのほかに、通常のクロールで新たに同じ問題が検出されたページを対象として、検証が再び開始されます。現在の検証サイクル中に問題を修正した場合でも、現在の検証サイクルが完了するまで待ってから、新たな検証サイクルをリクエストする必要があります。検証に合格したページや、アクセスできなくなったページは再チェックされず、[再検証] をクリックした際に履歴から削除されます。

問題の詳細ページで検証の詳細のリンクをクリックすると、検証リクエストの進捗状況を確認できます。AMP レポートとインデックスステータスレポートでは、検証履歴ページの項目は URL 別にグループ化されます。モバイルユーザビリティレポートやリッチリザルトレポートでは、項目は URL と構造化データの項目の組み合わせを基準としてグループ化されます。検証ステータスは、調査中の特定の問題に適用されます。ページ上の 1 つの問題に「合格」ラベルが付き、他の問題には「不合格」、「保留中の検証」、「その他」のラベルが付くことがあります。

個々の問題には、以下の検証ステータスが適用されます。

  • 開始前: この問題のあるページが存在しますが、検証はまだ開始されていません。
    1. 問題をクリックしてエラーの詳細を確認します。AMP テストを使用して個別のページを調査し、公開中のページ上でのエラーの例を確認します。
    2. 詳細ページで [詳細] をクリックして、違反しているルールの詳細を確認します。
    3. 表内にある URL の例の行をクリックして、そのエラーの詳細を確認します。
    4. ページを修正し、[修正を検証] をクリックして Google にページの再クロールをリクエストします。Google から検証の進捗状況の通知が届きます。検証には数日から最大で約 2 週間かかります。
  • 開始: 検証が開始されました。この問題が残っているページはまだ検出されていません。以降は検証が進むと Google から対応方法を伝える通知が届きます。
  • 修正を確認しました: 検証が開始され、これまでにチェックしたページがすべて修正されています。以降は必要な作業はありませんが、検証が進むと Google から対応方法を伝える通知が届きます。
  • 合格: 問題のある既知のページがすべて修正されています。このステータスにするには、[修正を検証] をクリックする必要があります。以降は必要な作業はありません。
  • 該当なし: 検証を開始していませんが、すべての URL で問題が修正されていることが Google により検出されました。以降は必要な作業はありません。
  • 不合格: [検証] がクリックされましたが、一部のページにまだこの問題が存在します。問題を修正して再検証する必要があります。

問題のあるページの検証ステータス 検証をリクエストすると、特定の問題がある既知のすべてのページに次の検証ステータスのいずれかが割り当てられます。

保留中の検証
検証のキューに追加されています。Google による前回の確認時に、このページには該当する問題が存在していました。
合格
チェックの結果、このページに問題は存在しませんでした。このステータスになるのは、このページに対して [検証] をクリックした場合のみです。
不合格
チェックの結果、このページにはまだ問題があります。このステータスになるのは、このページに対して [検証] をクリックした場合のみです。
その他
この該当ページをホスティングしている URL にアクセスできませんでした。または、ページ上で項目が見つかりませんでした。「合格」と同等とみなされます。

同じ URL でも、問題ごとにステータスが異なる場合があります。例えば、ある 1 つのページ内に問題 X と問題 Y の両方がある場合に、同じページ内で問題 X の検証ステータスが「合格」、問題 Y の検証ステータスが「保留中の検証」になる可能性があります。

手動による対策

自分のサイトに対して実施された手動による対策があるかどうかを確認したり、サイトの手動による対策の履歴を表示したりすることができます。サイトに対して手動による対策が実施されると、そのサイトの一部またはすべてが Google 検索結果に表示されなくなります。

手動による対策
手動による対策

手動による対策とは、担当者がサイト上のページを目視で審査し、Google のウェブマスター向けガイドラインに準拠していないと判断した場合、そのサイトに対して手動による対策を実施します。手動による対策のほとんどは、検索インデックスの操作への対処です。手動による対策が実施された場合、ページやサイトの掲載順位が下がったり、検索結果から除外されたりする可能性はありますが、ユーザーが視覚的に識別できるような表示は行われません。手動による対策がサイトに影響を及ぼす場合は、[手動による対策] レポートと Search Console メッセージセンターで通知されます。

自分のサイトに対して手動による対策が実施されているかどうか?
サイトに対して実施された手動による対策の回数がレポートの上部に表示されます。手動による対策が実施されていない場合は、緑色のチェックマークと適切なメッセージが表示されます。
注意アイコン
サイトを最近購入した場合
所有する前にガイドラインに違反していたサイトを最近購入した場合は、レポートに記載されている問題を修正したうえで、サイトを最近取得したこと、現在はガイドラインに準拠していることを再審査リクエストしてください。
影響を受けるページ
手動による対策の説明を展開すると、影響を受けるページのパターンが一覧で表示されます。このリストは、サイトの一部だけのこともあれば、サイト全体に及ぶこともあります。パターンに一致するすべてのページが必ずしも影響を受けるわけではありません。
問題の解決方法
サイトに対する手動による対策を解除するには:
  1. レポートの手動による対策の説明パネルを展開して、詳細を確認します。
  2. 影響を受けているページを確認します。
  3. 問題の種類と簡単な説明を確認します。さらに、[詳細] リンクをクリックして、詳細情報と問題を解決するための手順を確認します。
  4. 影響を受けているすべてのページの問題を修正します。一部のページだけの問題を解決しても、検索結果は変わりません。サイトに対して手動による対策が複数実施されている場合は、それらすべてを確認して解除してください。
  5. Google が各ページにアクセスできることを確認します。影響を受けているページが、ログイン不要であること、robots.txt または noindex ディレクティブでブロックされていないことを確認します。ページにアクセスできるかどうかは、URL 検査ツールを使用してテストできます。
  6. レポートに記載されているすべての問題をすべてのページで修正したら、レポートで [審査をリクエスト] を選択します。再審査リクエストには、修正した内容を記述します。再審査リクエストを明快なものにするために、以下の 3 つの点にご留意ください。
    • サイトの品質に関する問題を正確に説明する。
    • 問題を修正するために行った手順を記述する。
    • 取り組みの結果を記述する。
  7. 再審査には数日から 1 週間程度かかります。進行状況はメールで通知されます。再審査リクエストを送信すると、審査が進行中であることを伝える確認メッセージが届きます。リクエストに対する最終決定が通知されるまではリクエストを再送信しないでください。
再審査にかかる期間
再審査には数日から 1~2 週間かかります。Google にリクエストが届き次第、メールで通知されますので、審査が開始されたことを確認できます。審査が完了したときにもメールで通知されます。リクエストに対する決定が通知されるまではリクエストを再送信しないでください。
手動による対策の履歴を表示する
サイトの手動による対策の履歴は、レポートの下部に表示されます。履歴には、手動による対策に関する通知、審査リクエスト、審査結果が含まれます。履歴は、サイトの所有者が変わっても、少なくとも 1 年間保持されます。

ユーザー生成スパム

サイトの訪問者が送信したスパムがページ上で検出されました。通常、この種のスパムは、フォーラム ページ、ゲストブック ページ、またはユーザー プロフィールで見つかります。Google のウェブマスター向けガイドラインでユーザー生成スパムについて確認し、以下の手順に沿ってサイト内のガイドライン違反箇所を特定して修正します。

  1. ユーザーがサイトにコンテンツを追加する一般的な場所としては、フォーラム、ブログのコメント、ユーザー プロフィールなどが考えられます。サイト内で、ユーザーによってコンテンツが追加された可能性のあるページを特定します。
  2. ユーザープロフィールが営利目的のユーザー名で作成されていないかや、広告、テーマと無関係なリンク、意味不明なテキストなどが投稿に含まれていないかを確認します。上記の範囲に以下の投稿やプロフィールがないかを確認します。
    • 広告と思われる投稿またはプロフィール
    • 文脈やテーマから外れたリンクを持つ投稿またはプロフィール
    • 無関係のサイトにリンクされている、営利目的のユーザー名 (「割引保険」など、実際の人名とは思えない名前) を使った投稿またはプロフィール
    • 実際のユーザーが作成したものではなく、自動的に生成されたと思われる投稿またはプロフィール
  3. サイト内に予期しないコンテンツやスパム コンテンツがないか確認します。Google 検索で site: 演算子を使用し、営利目的やアダルト関連など、サイトのテーマに無関係のキーワードを指定します。
  4. 不適切なコンテンツをすべて削除します。
  5. ユーザー生成スパムを防止する方法を実施することが推奨されます。
  6. サイトがガイドラインに違反していないことを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  7. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

スパム行為のある無料ホスト

無料のウェブホスティングサービスでホストされているサイトのうち、かなりの割合のページでスパム行為が行われている場合は、サービス全体を対象に手動による対策を実施することがあります。

  1. サービスの不正使用を識別、防止するためのヒントを確認します。
  2. スパム行為のある既存のアカウントをサービスから削除します。
  3. ホスティング サービスを担当する技術チームに連絡して、手動による対策について伝えます。
  4. サイトが Google のウェブマスター向けガイドラインに準拠していることを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  5. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

構造化データに関する問題

ページ上の一部のマークアップで、構造化データに関するガイドラインに違反する手法が使用されていると見られる箇所が確認されました。お客様のサイトに当てはまる可能性がある構造化データに関する問題は、以下のとおりです。

ページのコンテンツが構造化データと異なる
求人情報が掲載されていないページで JobPosting 構造化データが検出されました。
求人ページから応募できない
ページのコンテンツが構造化データと一致しません。
構造化データがコンテンツと一致しない
ページのコンテンツが構造化データと一致しません。
求人への応募に支払いを要求している
JobPosting 構造化データを含むページで、求人への応募に手数料が設定されています。
求人ページで仕事の依頼が検出された
JobPosting 構造化データを含むページが仕事を提供するページではなく、仕事を探すページになっています。
勤務地について誤解を招くおそれがある
JobPosting 構造化データを含むページに、誤解を招くおそれのある勤務地の欄があります。
求人元が採用していない
JobPosting 構造化データを含むページで応募者を募集していますが、採用が行われていません。
リストページで構造化データに関する問題が発生している
リストを含むページでは、各項目を個別にマークアップする必要があります。複数の項目から 1 つの構造化データ要素にデータを集約する操作はガイドラインに反します。
リストページに JobPosting 構造化データがある
リストページに各求人の構造化データを含めることは禁じられています。
有効期限切れの求人に JobPosting 構造化データがある
有効期限切れの求人で使用されている JobPosting マークアップに、過去の日付に設定された validThrough プロパティがあります。
ページのコンテンツが構造化データと異なる
主張の審査が含まれていないページで ClaimReview 構造化データが検出されました。
ClaimReview にリファレンスがないか、リファレンスが判定結果と一致しない
ClaimReview 構造化データを含むページに、根拠となる情報の公開元やリファレンスが含まれていません。
非表示のコンテンツで構造化データが検出された
ユーザーに表示されない要素で構造化データが検出されました。
新しいレビューを送信する方法がない
レビューが含まれているページでは、レビューを提供する方法を提示するか、レビューの提供元を明確に示さなければいけません。
会社が商品としてマークされている
構造化データで会社が商品としてラベル付けされています。
商品以外が商品としてラベル付けされている
商品以外の項目、または汎用的な項目が、商品としてマークされています。
サービスを提供しているサイトまたは担当者によってレビューが作成された
カスタマーによる、独立した立場からの、無料の編集上のレビューを除き、ビジネスまたはコンテンツ プロバイダがレビューを書いたり提供したりすることは禁じられています。
イベントの構造化データがプロモーションである
表示テキストまたは構造化データの説明が、イベントの説明ではなく、イベントのプロモーションや販売に関係しています。
イベント以外がイベントとしてラベル付けされている
イベント以外の項目 (休日、クーポンなど) がイベントとしてマークされています。
レシピ以外がレシピとしてマークされている
レシピ以外の項目がレシピとしてマークされています。レシピは食品を対象とし、材料と手順の両方が含まれている必要があります。
構造化データに関するポリシー違反
1 つ以上のページで構造化データに関するポリシー違反が発生しています。
雇用主が間違っている
hiringOrganization フィールド内の雇用主は求人情報の雇用主と一致する必要があります。
求人の説明が不完全である
説明欄が不完全であるか理解できません。詳細
  1. Google の検索結果に表示されるようにするには、サイトのマークアップが Google の構造化データに関するガイドラインに準拠していることを確認してください。必要に応じて、既存のマークアップの更新や、ガイドラインに違反しているマークアップの削除を行います。
  2. 変更が完了したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  3. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

サイトへの不自然なリンク

サイトへの不自然な人為的、偽装、または不正なリンクのパターンが検出されました。PageRank を操作することを目的としたリンクの購入やリンクプログラムへの参加は、Google のウェブマスター向けガイドラインに違反しています。こうした行為をすると、サイトの一部またはすべてに対して手動による対策が実施される場合があります。

まず、Google のウェブマスター向けガイドラインでリンクについて確認します。以下の手順をしたがって、サイト内のガイドライン違反箇所を特定して修正します。

  1. Search Console から、サイトへのリンクのリストをダウンロードします。
  2. このリストに、ガイドラインに違反するリンクがないか確認します。リストが大きい場合は、リンク数の最も多いリンク元サイト、または最近作成されたリンクから確認を始めます。
  3. ガイドラインに違反するリンクが見つかった場合、そのサイトのウェブマスターに連絡し、リンクを削除するか、rel="nofollow" 属性を追加するなどして PageRank の転送を防ぐように依頼してください。
  4. Search Console のリンクの否認ツールを使用して、削除できなかったリンクの否認を行います。リンクの否認ツールを使用する際には以下の点に注意してください。
    • バックリンクを取り除くことができる場合は、そのバックリンクを削除してください。バックリンクを否認ファイルに追加しても、再審査リクエストは承認されません。
    • 同じドメインからサイトへのマルチリンクについては、否認ファイルで domain: 演算子を使用します。
    • サイトへのオーガニックリンクを否認しないように注意してください。
  5. 人為的なリンクの削除または否認が終了したら、[手動による対策] レポートで [審査をリクエスト] を選択します。ここでは、削除したリンクや削除できなかったリンクに関する説明をリクエストの処理の参考として送ることができます。
  6. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

サイトからの不自然なリンク

サイトにおいて、他サイトへの不自然、人為的、偽装、または不正なリンクのパターンが検出されました。PageRank を操作することを目的としたリンクの購入やリンクプログラムへの参加は、Google のウェブマスター向けガイドラインに違反しています。

まず、Google のウェブマスター向けガイドラインで、リンクについて確認します。以下の手順を行って、サイト内のガイドライン違反箇所を特定して修正します。

  1. サイトで、金銭と引き換えに掲載されているリンクや、過度のリンク交換など、リンクに関するガイドライン違反と思われるリンクを特定します。
  2. 見つかったリンクを削除するか、PageRank を渡さないようにリンクを変更します。例えば、rel="nofollow" 属性を追加するか、robots.txt でブロックしているページを通じてリダイレクトします。
  3. サイトがガイドラインに違反していないことを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。削除した質の低いコンテンツと、追加した質の高いコンテンツの例を記載します。
  4. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

価値のない質の低いコンテンツ

サイト内で低品質のページや浅薄なページが検出されました。価値のない質の低いコンテンツを含むページには、以下のようなものがあります。

  • 自動生成されたコンテンツ
  • 内容の薄いアフィリエイトページ
  • 他のソースからのコンテンツ
  • 誘導ページ

これらのテクニックは、実質的に固有または価値あるコンテンツをユーザーに提供するものではないため、Google のウェブマスター向けガイドラインに違反する行為です。

自動生成されたコンテンツ
自動的に生成されたコンテンツとは、プログラムによって生成されたコンテンツです。Google では、検索ランキングを操作することを目的としたユーザーの役に立たないコンテンツに対し、措置を取ることがあります。例えば、以下のようなものがこれに該当します。
  • 検索キーワードを含んでいるが、文章としては意味をなさないテキスト
  • 自動化されたツールで翻訳されたテキストが人間によるチェックや編集を経ず公開されたもの
  • マルコフ連鎖などの自動処理によって生成されたテキスト
  • 自動化された類義語生成や難読化の手法を使用して生成されたテキスト
  • Atom/RSS フィードや検索結果からの無断複製によって生成されたテキスト
  • 複数のウェブページからのコンテンツを、十分な付加価値を加えることなくつなぎ合わせたり、組み合わせたりしたもの
アフィリエイトプログラム
Google のウェブマスター向けガイドラインでは、ユーザーに付加価値を提供する独自のコンテンツを持つサイトを作成することが推奨されています。特に、アフィリエイトプログラムに参加するサイトにとって、これは重要なポイントです。一般的に、アフィリエイトのウェブサイトでは、アフィリエイトネットワークのサイトの商品に関する説明を掲載しています。その結果、アフィリエイトネットワークのコンテンツを中心に扱っているサイトは、他のサイトのコンテンツと差別化できる程度に十分な独自性のあるコンテンツを持たないため、Google 検索結果でのランキングが低くなることがあります。付加価値とは、価格、購入場所、商品のカテゴリに関する追加情報など、意味あるコンテンツや機能のことです。特に、アフィリエイトプログラムに参加し、アフィリエイトネットワーク上でプログラムのコンテンツを配信するサイトがそれに該当します。こうしたサイトの多くが同じコンテンツや類似コンテンツを同一サイト内、または複数のドメインや言語で複製した画一的なサイトやテンプレートのようなサイトです。検索結果ページにこのようなすべて同じコンテンツのサイトが複数表示されることも起こり得るため、このような内容の薄いアフィリエイトサイトはユーザーの利便性を妨げることになります。
  • 商品アフィリエイトリンクを含むページで、商品の説明とレビューを元の販売者から直接コピーし、独自のコンテンツや付加価値を加えることなくそのまま掲載しているもの。
  • サイトの大部分がアフィリエーションで構成され、独自のコンテンツやユーザーへの付加価値がごくわずかしか含まれていない商品アフィリエーションのページ。
アフィリエイトプログラムに参加しているサイトが必ずしもすべて内容の薄いアフィリエイトサイトというわけではありません。例えば、質の高いアフィリエイトは独自の商品レビュー、評価、商品やカテゴリのナビゲーション、商品比較などを提供することで付加価値を加えています。アフィリエイトプログラムに参加する場合、サイトを目立たせて他のサイトと差別化を図るのに役立つ方法がたくさんあります。
  • アフィリエイトプログラムのコンテンツで付加的な機能を提供できない場合は、そのコンテンツがサイトのコンテンツのごく一部だけになるようとどめる。
  • ユーザーが元の販売者のサイトに直接アクセスせずに、このサイトにアクセスしようとする理由を考える。元の販売者が提供しているコンテンツを転載するだけでなく実質的な付加価値を提供するサイトにする。
  • アフィリエイトプログラムを選択する際、サイトの対象ユーザーに適した商品のカテゴリを選択する。サイトのコンテンツに合ったアフィリエイトプログラムを選択することで、サイトの付加価値や Google の検索結果でのランキングが高くなり、アフィリエイトプログラムから収益を得られる可能性が高くなります。
  • ウェブサイトでユーザーのコミュニティを形成する。熱心な読者の獲得に役立ち、サイトのテーマに関する情報が集まる場を作ることができます。例えば、ディスカッション フォーラム、ユーザー レビュー、ブログなどでユーザーに独自のコンテンツと付加価値を提供できます。
  • 常に最新で関連性の高いコンテンツを提供する。テーマに一貫性のある最新の情報を提供すると、コンテンツを Googlebot がクロールし、ユーザーがクリックする可能性が高まります。
ウェブ上の多くのサイトに掲載されているようなコンテンツで構成されたアフィリエイトのためだけのサイトは、Google 検索結果で上位に表示されず、検索エンジンによる評価が低くなる可能性があります。関連性が高い独自のコンテンツを提供すれば、ユーザーに価値を提供し、サイトを他のアフィリエイトサイトと差別化することができるため、サイトが Google 検索結果の上位に表示される可能性が高くなります。
無断で複製されたコンテンツ
ウェブサイトの中には、サイト上のページを増やすことがそのコンテンツの関連性や独自性に関係なく長期的に効果的な戦略になるという考えの下に、評判の良い他のサイトのコンテンツを流用しているサイトもあります。高品質のソースからのものであるとしても、無断で複製しただけのコンテンツは、サイトで他の役立つサービスやコンテンツを提供しない限り、ユーザーに付加価値を提供するとはいえません。場合によっては、著作権侵害にあたるおそれもあります。無断複製されたコンテンツの例としては、次のようなものが挙げられます。
  • 他のサイトのコンテンツをコピーし、独自のコンテンツや付加価値を加えることなく転載しているサイト
  • 他のサイトのコンテンツをコピーし、若干の修正を加えた上で転載しているサイト
  • 何らかの独自の体系付けやユーザーへの利便性を提供することなく他のサイトからのコンテンツ フィードをそのまま掲載しているサイト
  • ユーザーに実質的な付加価値を提供することなく、他のサイトの動画、画像、その他のメディアなどのコンテンツを埋め込んだだけのサイト
誘導ページ
誘導ページは、特定の検索キーワードで検索結果の上位に表示されることを目的に作成されたサイトまたはページです。誘導ページにより、類似する複数のページが検索結果ページに表示され、どの検索結果からも同じ内容のサイトやページにユーザーが誘導されるため、ユーザーの利便性が妨げられることになります。また誘導ページは、最終的なアクセス先となるサイトやページに比べ有用性の低い中間ページにユーザーを誘導することもあります。誘導ページの例としては、以下のようなものが挙げられます。
  • 特定の地域や都市を対象としたドメイン名やページを複数持ち、それらのドメインから 1 つのページにユーザーを誘導するもの
  • サイト内の有用なコンテンツや関連性の高いコンテンツにユーザーを案内することを目的として生成されたページ
  • サイト内における階層が明確に定義されていないため構造としては検索結果の一覧に近い、内容が類似する複数のページ

次に以下の手順を行って、サイト内のガイドライン違反箇所を特定して修正します。

  1. 他の場所にあるコンテンツを複製したコンテンツがサイト内にないかを確認します。
  2. アフィリエイトリンクを含む実質のないコンテンツ ページがサイト内にないかを確認します。
  3. 誘導ページや自動生成されたコンテンツがサイト内にないかを確認します。
  4. サイト内にこのような種類のコンテンツが含まれている場合は、サイトがユーザーに意味のある付加価値をもたらしているかどうかを検討します。
  5. ユーザーに意味のある付加価値をもたらすようにウェブサイトを改善します。
  6. サイトがガイドラインに違反していないことを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。削除した質の低いコンテンツと、追加した質の高いコンテンツの例を記載します。
  7. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

クローキング、不正なリダイレクト

サイトにおいて、Google が確認したページとは別のページがユーザーに表示されたり、Google が確認したページとは異なるページにユーザーがリダイレクトされたりすることがあります。クローキングや不正なリダイレクトは、Google のウェブマスター向けガイドラインに違反する行為です。

まず、Google のウェブマスター向けガイドラインで、クローキングと不正なリダイレクトについて確認します。次に以下の手順を行って、サイト内のガイドライン違反箇所を特定して修正します。

  1. Search Console の URL 検査ツールを使用して、サイト内の影響を受けている領域からページを取得します。
  2. Google が取得したコンテンツと、サイトにアクセスしたユーザーが見るコンテンツを確認します。
  3. コンテンツが異なる場合は、Google とユーザーに異なるコンテンツを提供しているサイト内の部分を特定し、削除します。このためには、サーバー上のサイトのコードを確認する必要があります。
  4. ユーザーを予定とは異なる場所にリダイレクトする URL がサイト内にないかを確認します。
  5. 条件に応じてリダイレクトする URL がサイト内にないかを確認します。
  6. これらの方法のいずれかでユーザーがリダイレクトされる場合は、これらのリダイレクトを発生させる部分をサイト内で特定し、削除します。このためには、サーバー上のサイトのコードを確認する必要があります。
  7. サイトがガイドラインに違反していないことを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  8. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

悪質なスパム

一部のページで、ウェブマスター向けガイドラインに違反する手法が使用されている可能性があります。このサイトは、意味不明な内容の自動生成、クローキング、他のウェブサイトからのコンテンツの無断複製といった悪質なウェブスパム テクニックを行使しているか、その他の Google の品質に関するガイドラインに繰り返し違反、または大きく違反しています。

  1. Google のウェブマスター向けガイドラインに準拠するようにサイトを更新します。
  2. サイトがガイドラインに違反していないことを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。削除した質の低いコンテンツと、追加した質の高いコンテンツの例を記載します。
  3. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

クローキングされた画像

サイトで表示される画像の一部が Google の検索結果に表示される画像と異なる場合があります。クローキングとは、検索エンジンと人間のユーザーにそれぞれ異なるコンテンツを表示することです。クローキングは、Google のユーザーが予想した結果と異なる結果をユーザーに提供するものであるため、Google のウェブマスター向けガイドラインへの違反と見なされます。画像のクローキングでは、不明瞭にした画像や一致しないサムネイルを使用することで検索対象の画像がユーザーに表示されず、これは Google 画像検索結果のユーザー エクスペリエンスを低下させる原因となります。画像のクローキング動作の例としては、次のようなものが挙げられます。

  • 画像をブロックするテキスト ブロックなど、別の画像でわかりにくくした画像を Google に提供する。
  • ページの訪問者に提供する画像と異なる画像を Google に提供する。

Google 検索結果から画像をブロックする必要がある場合は、下記の方法を使用してください。

  1. サイト上でも Google の検索結果でも、完全に同じ画像がユーザーに表示されるようにします。ただし、下記に詳述するように、画像検索のインラインリンクをオプトアウトする場合は、クローキングの例外として認められます。
  2. サイト上と Google の検索結果で表示されるサイトの画像が完全に同じであることを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  3. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

隠しテキスト、キーワードの乱用

一部のページに隠しテキストが含まれているか、ページ内でキーワードが乱用されている可能性があります。

まず、Google のウェブマスター向けガイドラインで、隠しテキストとキーワードの乱用について確認します。次に以下の手順を行って、サイト内のガイドライン違反箇所を特定して修正します。

  1. Search Console の URL 検査ツールを使用して、クローラには認識されるが、サイトにアクセスしたユーザーには表示されないコンテンツがないかを確認します。
  2. ウェブページの背景と同じ色または類似した色のテキストがないか確認します。
  3. CSS のスタイルや配置を使用して隠されたテキストがないかを確認します。
  4. 隠しテキストを削除するか、スタイルを変更して、検索エンジンのクローラでも実際のユーザーでも相違なく認識できるようにします。
  5. 単語の繰り返しからなる文脈のないリストや段落がないかを確認します。
  6. 繰り返される単語の文字列に <title> タグや代替テキストが使われていないかを確認します。
  7. このような単語やキーワードの乱用を削除します。
  8. サイトがガイドラインに違反していないことを確認したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  9. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

AMP コンテンツの不一致

AMP バージョンとその標準ウェブページで、それぞれ内容が異なっています。AMP バージョンとその標準ウェブページは、内容が基本的に同じでなければなりません。テキストが同一である必要はありませんが、トピックは同じものにして、ユーザーがどちらのページでも同じタスクを完了できるようにする必要があります。手動による対策の影響を受ける AMP ページは、Google の検索結果に表示されません。その代わりに、標準ページが表示されます。

  1. AMP で正しい標準ウェブページが参照されていることを確認する。
  2. AMP と標準ページの内容が全体的に同じであることを確認する。
  3. AMP と標準ページの両方について、URL 検査ツールを使用し、Google が認識するページとユーザーに表示されるページに違いがないことを確認する。いずれかのページで robots.txt により重要なリソースがブロックされている場合、不一致が生じることがあります。URL 検査ツールでは、ブロックされたリソースも表示されます。
  4. AMP と標準ページの内容が基本的に同じである場合、[手動による対策] レポートで [審査をリクエスト] を選択します。
  5. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

不正なモバイル リダイレクト

このサイトの一部のページが、クローラには提供していないコンテンツにモバイルデバイスのユーザーをリダイレクトしている可能性があります。不正なリダイレクトは、Google のウェブマスター向けガイドラインに違反する動作です。Google サーチクオリティチームでは、ユーザーに高品質な検索結果を提供するため、このようなサイトの URL を Google インデックスから削除するなどの対策を講じています。

多くの場合、デバイスの種類に応じて多少異なるコンテンツを表示しても問題はありません。例えば、スマートフォンの小さな画面に合わせて最適化するために、画像などの一部のコンテンツを変更することが考えられます。同様に、モバイル専用のリダイレクトとして、モバイルユーザーエクスペリエンスの向上のために、モバイルユーザーをリダイレクトすることは、ユーザーにとって有益です。しかし、モバイルユーザーを異なるコンテンツへ不正にリダイレクトすることは、好ましいユーザーエクスペリエンスではありません。

意図的に行っていない場合
  1. サイトがハッキングされていないかを確認します。[セキュリティの問題] レポートで、サイトがハッキングされていることを Google が認識しているかどうかを確認します。
  2. サイト上のサードパーティのスクリプトや要素を調べます サイトがハッキングされていない場合は、サードパーティのスクリプトや要素によるリダイレクトがないかを調べることが推奨されます。手順は以下のとおりです。
    1. リダイレクト元のページから、自分で管理していないサードパーティのスクリプトや要素を 1 つずつ削除します。
    2. 各スクリプトや要素を削除したら、モバイル デバイスか Chrome モバイルエミュレータでサイトの動作をチェックして、リダイレクトがなくなったかどうかを確認します。
    3. 不正なリダイレクトの原因と考えられるスクリプトや要素を特定できたら、それをサイトから削除することを検討します。場合によっては、そのスクリプトや要素を提供したプロバイダと共同で問題の解決にあたります。
意図的に行っている場合
  1. スマートフォンかモバイルデバイスのエミュレータで、Google の検索結果からページにアクセスし、ページが修正されたことを確認します。
  2. サイト内のすべてのページで問題を修正したら、[手動による対策] レポートで [審査をリクエスト] を選択します。
  3. 再審査リクエストを送信してからしばらくすると、Search Console のアカウントに再審査のステータスに関するメッセージが表示されます。これは、サイトの再審査が終了したことを通知するメッセージです。サイトがガイドラインに違反していないことが確認でき次第、手動による対策が解除されます。

セキュリティの問題

マルウェアの感染や、ハッキングによるサーバーが乗っ取りなど、サイトに深刻なセキュリティの問題が発生すると、Search Console からメッセージが送られます。同時に Google では、検索するユーザーを守るために検索結果にサイトを表示しないようにします。セキュリティの問題が発生した場合、セキュリティの問題を解決してから Google に再審査をリクエストして検索結果に復帰させる必要があります。

最初の手順としては、サイトを訪問するユーザに悪影響を与えないようにサイトを隔離します。サイトの隔離する方法は、.htaccess を使ってサイト全体の HTTP レスポンスコードを 503 に変更します。.htaccess の書き方については、.htaccess の書き方を参照してください。

次に情報を収集して原因の特定を行います。これには Google セーフブラウジング診断を利用します。セーフブラウジング診断を行うには、以下のサイトから対象のドメインを調べることでセキュリティに関する情報が表示されます。

一般的な情報収集として重要な点は、マルウェアやハッキングなどの攻撃を受ける原因となった脆弱性や、攻撃による影響と範囲、情報の流出やユーザーへの感染などです。これらの原因が特定できたらサイトの復旧作業を行います。

復旧作業の最初に行うべき作業は、今回の脆弱性と、その他にも考えられる脆弱性に対してセキュリティパッチを当てることです。サーバーの OS、ミドルウェア、アプリケーションなど、最新版になっているかを確認し、アップデートを行います。アップデートが完了したら、サイト全体を問題発生前のバックアップからリカバリーを行います。

すべての対処が完了したら、Search Consoleの [セキュリティの問題] から Google へ再審査リクエストを行います。また、マルウェアに感染した場合は、Google から問題ないと判断されれば 24 時間以内にサイトのセキュリティ警告は解除されます。セキュリティ警告が解除されると、検索結果にも通常通り表示されるようになります。

セキュリティの問題
セキュリティの問題

リンク

リンクは、外部リンク、内部リンク、上位のリンク元サイト、上位のリンク元テキストが一覧表示されるダッシュボードです。

リンク
リンク
外部リンク
プロパティ外からプロパティへのリンク。
内部リンク
プロパティからプロパティへのリンク。
上位のリンク元サイト
プロパティ外からプロパティへのリンク。値はルートドメインごとに調整され、グループ化されます。ホストページのサブドメインが除外されている場合、現在のプロパティの一覧がここに表示されます。
上位のリンク元テキスト
プロパティにリンクしている外部ページのリンクテキスト。

設定

設定では、プロパティ内の所有権の確認と、ユーザーと権限の設定を行うことができます。

設定
設定

所有権の確認では、HTML ファイル、HTML タグ、Google Analytics、ドメイン名プロバイダ、Google タグマネージャーから行うことができます。

設定
設定
HTML ファイル
特別な HTML ファイルをサイトにアップロードして、そのサイトの所有権を確認できます。この方法では、以下のエラーが発生することがあります。
確認ファイルが見つかりませんでした。
Search Console の [確認] ページで提供される確認ファイルをダウンロードして、変更を一切加えずにそのファイルを指定の場所にアップロードしてください。ファイルの名前またはコンテンツが、提供された HTML ファイルと一致しない場合、サイトの所有権を確認することはできません。
確認ファイルのコンテンツが正しくありません。
Search Console では、確認ファイルのファイル名やコンテンツが、[確認] ページで提供されるファイルと同じであるかどうかを確認します。ファイルの名前またはコンテンツが、提供された HTML ファイルと一致しない場合、サイトの所有権を確認することはできません。Search Console の [確認] ページで提供される確認ファイルをダウンロードして、変更を一切加えずにそのファイルを指定の場所にアップロードしてください。
確認ファイルが空です。
Search Console では、確認ファイルのファイル名やコンテンツが、[確認] ページで提供されるファイルと同じであるかどうかを確認します。ファイルの名前またはコンテンツが、提供された HTML ファイルと一致しない場合、サイトの所有権を確認することはできません。Search Console の [確認] ページで提供される確認ファイルをダウンロードして、変更を一切加えずにそのファイルを指定の場所にアップロードしてください。
確認ファイルから 200(OK)ではなく XXX の HTTP ステータスコードが返されました。
サーバーから HTML 確認ファイルについて 200(OK)以外の HTTP ステータスコードが返された場合、Search Console では、そのファイルのファイル名やコンテンツが適切であることを確認できません。HTTP ステータスコードについて詳細をご確認ください。
ダウンロード リクエストのリダイレクト回数が多すぎます。
サイトへのトラフィックを別のサイトにリダイレクトしている場合は、代わりに meta タグによる確認を行うことが推奨されます。
確認ファイルによって、許可されていない場所にリダイレクトされます。
Googlebot は、確認ファイルによるリダイレクトに従いません。サイトへのすべてのトラフィックを別のサイトにリダイレクトしている場合は、meta タグによる確認を行うことが推奨されます。
HTML タグ
特定のページの HTML に meta タグを追加すると、サイトの所有権を確認できます。meta タグが正しい位置に挿入されているかどうかが確認されます。タグを検出できない場合は、発生したエラーに関する情報が表示されます。このタグは特定のユーザーに関連付けられています。この方法では、以下のエラーが発生することがあります。
ホームページで確認メタタグが見つかりませんでした。
確認メタタグは、ページの <HEAD> セクション内に挿入してください。このエラーが表示された場合は、次の点を確認してください。
  • 正しいページに確認 meta タグが挿入されているかどうか。
  • ページの正しい位置に確認 meta タグが挿入されているかどうか
メタタグが正しくありません。
確認 meta タグを検出しましたが、コンテンツが適切ではありませんでした。エラーを防ぐには、Search Console の [確認] ページで提供される meta タグをコピーして貼り付けてください。
ホームページから 200(OK)ではなく XXX の HTTP ステータスコードが返されました。
サーバーからホームページについて 200(OK)以外の HTTP ステータスコードが返された場合、Search Console では、そのホームページに含まれている meta タグが適切であることを確認できません。
Google Analytics
Google アナリティクスを使用してサイトのトラフィックをトラッキングする場合は、サイトに関連付けられた Google アナリティクス トラッキング コードを使用してサイトを確認できます。この操作を行うには、該当ページでトラッキング コードが使用されているウェブ プロパティの「編集」権限が必要になります。また、トラッキング コードで analytics.js または gtag.js スニペットを使用している必要があります。
ドメイン名プロバイダ
ご利用のドメイン名プロバイダを経由してサイトを確認できます。この方法では、ご利用のドメイン名プロバイダにログインできることや、新しい TXT レコードまたは CNAME レコードを追加できる必要があります。
DNS で検出されません
確認用の TXT レコードが見つかりませんでした。
確認用の TXT レコードのコンテンツが正しくありません。
Search Console では、DNS レコードが、[確認] ページで提供されるレコードの詳細情報と一致するかどうかを確認します。一致しない場合、サイトの所有権を確認できません。
DNS の TXT レコードが正しくありません
確認用の DNS レコードの TXT が正しくありません。見つかった TXT を表示します。
DNS 解決でのパーマネントエラー
確認用の DNS レコードのルックアップでパーマネントエラーが発生しました。
DNS 解決エラー
確認用の DNS レコードのルックアップでエラーが発生しました。
Google タグマネージャー
Google タグマネージャーのアカウントをお持ちの場合は、Google タグマネージャーコンテナスニペットコードを使用して、サイトの所有権を確認できます。

確認済みのサイト所有者がいなくなった場合や、確認済みの所有者が不明の場合には、別のサイト所有者の確認を行います。新しい所有者は、該当のサイトについて確認が済んでいるすべての所有者とユーザーの一覧に加え、それぞれの所有者について行われた確認方法を閲覧できるようになります。必要に応じて、過去の所有者の確認に使用された確認トークンを削除することで、その所有者を未確認の状態に戻すこともできます。

設定
設定

Search Console プロパティでは以下の役割がサポートされています。

オーナー
所有者は Search Console でプロパティを完全にコントロールできます。他のユーザーの追加と削除、設定、すべてのデータの表示、すべてのツールの利用が可能です。所有者には以下の 2 タイプがありますが、Search Console のウェブサイトではその違いは表示されません。プロパティには確認済み所有者が 1 人以上必要です。確認済み所有者のないプロパティにはユーザーはアクセスできません。
確認済み所有者
プロパティの所有権を確認するための操作を行ったか、Google によって所有権があると判断された所有者です。確認済み所有者が Search Console を使って追加した所有者はすべて、委任された所有者となります。
委任された所有者
プロパティの所有権が確認されていない所有者です。他の委任された所有者を追加できます。
ユーザー
ユーザーはすべてのデータを表示でき、一部の操作を行うことができますが、他のユーザーを追加することはできません。ユーザーは所有者が追加する必要があります。ユーザーには以下の 2 タイプがあります。
フル
ほとんどのデータの表示権限があり、一部の操作を行うことができます。
制限付き
ほとんどのデータの表示権限があります。
協力者
協力者は、Google のプロパティやモバイルアプリを Search Console を通じてウェブサイトに関連付けることができます。所有するウェブサイトとの関連付けを第三者から Search Console を通じてリクエストされた場合、関連付けの内容のタイプに応じた機能が Search Console によって付与されます。例えば、モバイルアプリをウェブサイトに関連付けると、状況に応じてウェブサイトではなくアプリへのリンクを検索結果に表示するよう Google Search に通知されます。

確認済みのサイト所有者がいなくなった場合や、確認済みの所有者が不明の場合には、別のサイト所有者の確認を行います。新しい所有者は、該当のサイトについて確認が済んでいるすべての所有者とユーザーの一覧に加え、それぞれの所有者について行われた確認方法を閲覧できるようになります。必要に応じて、過去の所有者の確認に使用された確認トークンを削除することで、その所有者を未確認の状態に戻すこともできます。

まとめ

Google Search Console は、Google 検索に関する情報やサイト内のパフォーマンスに関する情報を取得することができます。その情報の中には、サイトの改善を行うヒントを見つけ出すことができます。

しかし、活用方法が不明であったり、情報が散らばっていたため、本ページでは体系的にまとめてあります。どのような場合に、どのようなエラーが発生し、どのように対処を行えば良いのかをまとめました。Google Search Console で迷った場合に参照して頂ければと思います。

Category:
検索エンジン最適化
公開日:
更新日:
Pageviews:
5,488
Shares:
113
Tag:
Google Search Console
SEO
アクセス解析