--- title: "Fetch as Googleとは？終了の経緯とURL検査ツールでの代替手順" url: "https://www.issoh.co.jp/column/details/7161/" published: 2025-06-10 updated: 2026-09-09 categories: ["SEO"] publisher: "株式会社一創" --- # Fetch as Googleとは？終了の経緯とURL検査ツールでの代替手順 Fetch as Googleは、Googleウェブマスターツール（現Search Console）にあった機能で、指定したURLをGoogleのクローラーに取得させ、そのままインデックス登録を申請できるものでした。2026年現在、この名前のツールはSearch Consoleに存在しません。2019年の再編でURL検査ツールへ役割が移り、旧画面ごと提供が終了しています。ただし操作そのものが消えたわけではなく、置き場所と制約が変わりました。旧ツールの3操作が今のどこに対応するのか、送信本数の上限がどう変わったのか、「ブラウザでは正常なのにライブテストだと崩れる」原因になるクローラーの違いまで、Googleの公式ドキュメントを基に整理します。 ## まとめ：Fetch as Googleの操作は3つともURL検査ツールに残っている 結論から示します。Fetch as Googleは2019年3月末までのSearch Console再編でURL検査ツールへ統合され、旧名称のメニューは戻っていません。旧ツールの「取得」はライブテスト、「取得してレンダリング」はライブテストのスクリーンショットとレンダリング結果、「インデックスに送信」は「インデックス登録をリクエスト」に対応します。 実務で押さえる差分は3つです。第一に、送信本数の上限がかつては公開値（単独URLで1週間に50件）だったのに対し、現在は「1日あたりの上限」とだけ書かれ、件数は公開されていません。第二に、ライブテストを実行しているのはGooglebotではなくGoogle-InspectionToolという別のクローラーです。第三に、URL検査ツールのAPIからインデックス登録をリクエストすることはできません。 ## Fetch as Googleが担っていた3操作と、2019年の統合までの経緯 ### 「取得」「取得してレンダリング」「インデックスに送信」の役割分担 Fetch as Googleの原型は、URLをGooglebotとして取得し、サーバーの応答とHTMLを確認する診断ツールでした。ここにインデックス送信の機能が加わったのが2011年です。Google検索セントラルブログの日本語版記事「Fetch as Googlebot ツールを使って Google へ URL の送信が可能になりました。」（2011年8月18日）は、追加された動作をこう説明しています。「Fetch as Googlebot ツールがページを正しく取得できた場合、その URL を Google のインデックスへ送信するオプションが表示されるようになります」。 取得できたページだけが送信対象になる設計で、この考え方は後述のURL検査ツールにも引き継がれています。もう一つの「取得してレンダリング」は、CSSやJavaScriptを読み込んだうえでの見え方をスクリーンショットで確認する機能でした。 ### 2019年3月末の機能移管と旧Search Consoleの提供終了 移管を予告したのは、2019年1月25日の公式ブログ記事「新しい Search Console で重大な問題に集中する」です。同記事は「2019 年 3 月末までに予定している Search Console の変更」を列挙し、その中に「URL 検査ツールで Google のようにフェッチ」という節を置きました。節の本文は、新ツールで「HTTP ヘッダー、ページリソース、JavaScript コンソールログ、ページのスクリーンショットなど」を確認でき、「ページの再クロールをツールから直接リクエストできる」と述べています。 旧インターフェースの縮小は同年9月9日の記事「旧バージョンの Search Console の提供終了について」で決定的になりました。ホームページとダッシュボードを含む旧Search Consoleの多くのレポートがサポート終了となり、アクセスすると関連するSearch Consoleのページへリダイレクトされます。現在のヘルプ「レポートの概要」にある「以前のツールとレポート」に掲載されているのはデータハイライターとWeb Toolsで、Fetch as Googleは含まれていません。 ## URL検査ツールでの代替手順と、旧操作との対応関係 | 旧Fetch as Googleの操作 | 現在のURL検査ツールでの操作 | 取得の主体 | | ------------------- | --------------------- | --------------------- | | 取得 | 公開URLをテスト（ライブテスト） | Google-InspectionTool | | 取得してレンダリング | ライブテストのスクリーンショットとHTML | Google-InspectionTool | | インデックスに送信 | インデックス登録をリクエスト | Googlebot（後日クロール） | | 該当なし | インデックス登録済みバージョンの確認 | 直近のクロール結果を参照 | URL検査ツールは、ヘルプが「Search Console 画面の上部にある検査検索バー」と呼ぶ入力欄にURLを入れて起動します。旧ツールと最も違うのは、最初に表示される画面が「今のページ」ではない点です。 ### 最初に出る画面はインデックス登録済みバージョン ヘルプ「URL 検査ツール」は、検査結果の冒頭にこう明記しています。「これはライブテストではありません。結果に表示されるのは、直近にインデックスに登録されたバージョンのページであり、ウェブ上で現在公開されているバージョンとは限りません」。修正直後にこの画面だけを見ると、公開中のページへ変更が反映されていないように見えることがあります。 逆に、この画面でしか分からない情報もあります。Googleが選んだ正規URL、参照元ページ、参照しているサイトマップは、インデックス登録済みバージョンからしか確認できません。ヘルプは正規バージョンについて「ライブテストでは、テスト対象のバージョンが正規バージョンになるかどうかを予測することはできません」と補足しています。正規化の意図どおりに評価されているかを見たいときは、[canonicalタグとは？SEOでのURL正規化の目的・書き方・設定方法を解説](/column/details/4873/)と併せて、この画面のGoogle選択の正規URLを確認してください。 ### ライブテストで確認できるスクリーンショットとレンダリング結果 今のページを見たいときは「公開URLをテスト」を押します。ヘルプの表現では「これはライブテストです。つまり、ツールはリアルタイムで URL を取得して検査します」。旧「取得してレンダリング」に相当するのがこの操作で、レンダリング後の画面はここでしか出ません。ヘルプは「レンダリングされたページのスクリーンショットは、ライブテストでのみ利用できます」と限定しています。 さらに「クロール済みのページを表示」を開くと、「返された未加工の HTML、HTTP ヘッダー、JavaScript コンソールの出力、読み込まれたページリソースなど」が並びます。JavaScriptで本文を生成しているページでは、まずコンソール出力で停止したスクリプトを確認し、リソース一覧で取得に失敗したCSSやJavaScriptを特定します。スクリプトがエラーで止まっていれば、レンダリング結果に本文が入りません。 ### インデックス登録をリクエストできる条件と、できない条件 検査結果ページの「インデックス登録をリクエスト」を押すと、ヘルプの記述どおり「インデックス登録エラーをすばやく検出する簡易チェックをパスしたページは、インデックス登録キューに送信されます」。ただし「ライブテストでインデックス登録不可と判断された場合は、インデックス登録をリクエストできません」。noindexが残っていたり、robots.txtでブロックされていたりすると、送信そのものが弾かれます。 送信後の見通しについても、ヘルプは断定を避けています。「通常、インデックス登録は 1 日程度ですみますが、長くかかる場合もあります」「リクエストを送信しても、ページが Google インデックスに表示されるとは限りません」。待機期間の目安は文書によって幅があり、「URL の再クロールを Google にリクエストする」では「クロールには数日から数週間かかることがあります」となっています。 ## 送信上限の変化：公開値の週50件から、非公開の1日上限へ | 比較軸 | 旧Fetch as Googlebot（2011年） | 現在のURL検査ツール | | ---------- | -------------------------- | --------------- | | 単独URLの送信 | 1週間に50件 | 1日あたりの上限（数値非公開） | | リンク先も含む送信 | 1カ月に10件 | 機能なし | | 残数の表示 | ツール画面に表示 | 表示なし | | 大量URLの推奨手段 | サイトマップ | サイトマップ | ### 旧ツールが公開していた上限の実数 旧ツールの上限は日単位ではなく、単独URLは1週間、リンク先を含む送信は1カ月を単位としていました。2011年の公式ブログはこう書いています。「URL を単独で送信する場合は、1 週間に 50 件まで送信可能です。URL とそれにリンクされているすべてのページを送信する場合は、1 カ月に 10 件まで送信できます」。残り本数もFetch as Googlebotの画面に表示されていました。 現在のヘルプにあるのは「送信できるインデックス登録リクエストの数には、1 日あたりの上限が設定されています」という一文だけで、具体的な件数は書かれていません。検査のリクエスト数とライブテストの実行回数にも、それぞれプロパティごとの1日上限があります。数字が非公開である以上、残り件数を数えながら運用する設計は成り立ちません。 ### 上限に当たる規模での、サイトマップとURL検査APIの使い分け ヘルプは大量ページの扱いを振り分けています。「インデックス登録したいページが多数ある場合は、サイトマップを Google に送信してみてください」。個別リクエストに非公開の上限がある以上、多数のURLはサイトマップ側で処理します。サイトマップを更新し、[インデックスカバレッジとは？「ページのインデックス登録」レポートの見方とエラー対処法](/column/details/5710/)で扱う「ページのインデックス登録」レポートで結果を追うほうが確実です。 確認作業を自動化したい場合は、2022年1月31日に公開されたURL Inspection APIが使えます。割り当ては公式の使用量上限ページでサイトあたり2,000 QPD（1日あたりのクエリ数）、600 QPM（1分あたりのクエリ数）と明示されており、画面操作の上限とは別枠です。ただし守備範囲は限定されています。Search Console APIのディスカバリ文書に定義されているURL検査系のメソッドは`urlInspection.index.inspect`のみで、インデックス登録のリクエストやライブテストに対応するメソッドは存在しません。APIで取得できるのはインデックス登録済みバージョンの情報だけ、と理解してください。 Indexing APIは、通常ページのインデックス登録リクエストを代替するAPIではありません。公式のクイックスタートは対象を「`JobPosting` が追加されたページ、または `VideoObject` に `BroadcastEvent` が埋め込まれたページをクロールするためにのみ使用できます」と限定しており、publishエンドポイントの初期デフォルト割り当ては、プロジェクトごとに1日200リクエスト（URL\_UPDATEDとURL\_DELETEDの合計）で、1つのHTTPリクエストには最大100呼び出しをまとめられます。通常のコラム記事や製品ページを送るAPIではありません。求人情報とライブ配信を扱っていないサイトでは、選択肢から外して構いません。 ## ライブテストの取得主体はGooglebotではなくGoogle-InspectionTool ### ユーザーエージェント文字列と、robots.txtが持つ2つのトークン 「Googlebotの視点でページを見る機能」という説明は、現在のURL検査ツールには正確に当てはまりません。Googleのクローラー一覧によれば、URL検査ツールとリッチリザルトテストのアクセスはGoogle-InspectionToolという専用クローラーが担当します。デスクトップのユーザーエージェントは、英語版の公式一覧では`Mozilla/5.0 (compatible; Google-InspectionTool/1.0)`と記載されています（日本語版の一覧は末尾にセミコロンが付いた旧表記のままなので、WAFの照合ルールを書くときは英語版を参照してください）。ヘルプ側も「Google-InspectionTool がどのようにページを認識しているかをスクリーンショットで確認できます」と、この名前で説明しています。 実務上の効き目が大きいのは、robots.txtの扱いです。同じクローラー一覧は、Google-InspectionToolが従うrobots.txtのユーザーエージェントトークンとして`Google-InspectionTool`と`Googlebot`の2つを挙げています。つまり、Googlebot向けにdisallowを書けば、URL検査ツールのライブテストも同じディレクトリで止まります。逆に検証環境だけで`Google-InspectionTool`を名指しでブロックすると、Google検索のクロールには影響しないままライブテストだけが失敗します。クローラー一覧は影響範囲を「Search Console のリッチリザルト テストや URL 検査などの検索テストツールに影響します。Google 検索やその他の製品には影響しません」と限定しています。robots.txtの記述ルールは[robots.txtとは？クロール制御の書き方と効く場面・不要な場面【2026年時点】](/column/details/16577/)にまとめています。 ### ブラウザでは正常なのにライブテストで崩れるときの切り分け順序 レンダリング結果が崩れたときは、次の順序で取得失敗の有無を切り分けます。まず「クロール済みのページを表示」でページリソース一覧を開き、取得できなかったファイルを特定します。次に、そのファイルのパスがrobots.txtのdisallow配下にないかを確認します。2019年1月の公式ブログが、旧「ブロックされたリソース」レポートを廃止した理由として「ブロックされたリソースは URL 検査ツールで直接特定できるようになっています」と書いたのは、まさにこの手順を指しています。 WAFやアクセス制限をかけている環境では、ユーザーエージェントの許可リストにGooglebotだけを登録しているケースが落とし穴になります。Google-InspectionToolは別の文字列で来るため、Googlebotだけを通す設定ではライブテストが弾かれます。ブラウザで見えるかどうかは判断材料になりません。ただしユーザーエージェント文字列は詐称できるため、アクセスログでは送信元IPも確認し、Googleが公開するIP範囲との照合、または逆引きと正引きのDNSが一致するかでGoogleからのリクエストかを検証します。 ## インデックス登録のリクエストと検索順位の関係 リクエストの送信は、再クロールを依頼する操作であって、評価を上げる操作ではありません。2011年の公式ブログの時点で、Googleは判定プロセスが変わらないことを明言していました。「URL をインデックスに加えるかどうかの判定は、正規のプロセス（Fetch as Googlebot 以外の方法で発見された URL に対して用いるプロセス）と同様に行われます」。現在のヘルプも「リクエストを送信しても、ページが Google インデックスに表示されるとは限りません」と同じ立場です。 順位が落ちた記事へ繰り返しリクエストを送るのは、時間の使い方として誤りです。公式ドキュメント「URL の再クロールを Google にリクエストする」は「同じ URL に対して再クロールを何度もリクエストしても、早くクロールされることはありません」と明記しています。回数は評価にもクロール時期にも効きません。順位側の要因はクロールとは別レイヤーにあり、この切り分けには[SEO内部対策とは？クロール・インデックス・UXの3分類で施策を優先度順に解説](/column/details/12834/)の3分類がそのまま使えます。 ## リクエスト後もインデックスされないときの確認順序 送信後も登録されない場合は、ライブテストでは確認できない正規URL、サイトマップ、参照元ページを確認します。ヘルプは、ライブテストが検出できない条件を明示しています。「ライブテストでは、サイトマップや参照元ページに URL が含まれていることを確認するわけではありません」。加えて「正規の問題や、URL がサイトマップで送信されているかどうかなど、リアルタイムでテストできない問題がある」ため、ライブテストが有効判定でもインデックス登録に至らないことがあります。 確認は次の順で進めてください。第一に、インデックス登録済みバージョンの画面でGoogleが選んだ正規URLを見ます。別URLが正規と判定されていれば、そのページは重複として扱われており、リクエストを繰り返しても状況は変わりません。第二に、参照元ページとサイトマップの欄を見ます。ここが空でも孤立ページとは断定できません。ヘルプは「この値が表示されていない場合は、参照元ページがないわけではなく、現時点で URL 検査ツールがその情報を把握していない可能性があります」と注意しており、サイトマップ欄にも未表示となる既知の問題があります。サイト内リンクを実際に辿って発見経路を確認してください。[クローラビリティとは？SEOでの重要性と向上させる方法](/column/details/4614/)で扱う導線の設計が、単発のリクエストより効きます。 第三に、ページの中身を疑います。ヘルプは、ライブテストの判定が有効でも登録されない条件として、品質とセキュリティに関するガイドラインへの準拠、手動による対策やセキュリティの問題の有無、削除申請の対象になっていないかを挙げています。手動による対策を受けている場合、URL検査ツールでは解決しません。[Googleの再審査リクエストの書き方｜理由の記載例と手動による対策の解除手順](/column/details/7150/)の手順に沿って、原因を除去してから再審査へ進んでください。 ## よくある質問 ### Fetch as Googleは今も使えますか？ 使えません。2019年1月25日の公式ブログで「2019 年 3 月末までに予定している Search Console の変更」として機能の移管が告知され、同年9月9日には、ホームページとダッシュボードを含む旧バージョンの多くのレポートがサポート終了となり、アクセスすると関連するSearch Consoleのページへリダイレクトされる状態になりました。現在のヘルプ「レポートの概要」にある「以前のツールとレポート」にも、Fetch as Googleは含まれていません。同じ操作はURL検査ツールで行えます。 ### SEOで言うフェッチとは何を指しますか？ フェッチは、クローラーが指定したURLへアクセスしてコンテンツを取得する動作を指します。Fetch as Googleという名称も、この「取得」に由来します。取得の成否はHTTPステータスやサーバーの応答で決まり、取得できた内容をもとに解析とインデックス登録の判断が行われます。取得とインデックス登録は別の工程で、取得に成功しても登録されるとは限りません。URL検査ツールでは、取得結果を「クロール済みのページを表示」から未加工のHTMLやHTTPヘッダーとして確認できます。 ### Fetch as Googleの使い方を今のSearch Consoleで再現するには？ Search Console画面上部の検査検索バーにURLを入力し、旧「取得」「取得してレンダリング」に当たる操作は「公開URLをテスト」を押します。ライブテストの結果画面でスクリーンショットとレンダリング後のHTMLを確認でき、「クロール済みのページを表示」からHTTPヘッダー、JavaScriptコンソールの出力、読み込まれたページリソースを開けます。旧「インデックスに送信」に当たるのは「インデックス登録をリクエスト」です。ライブテストでインデックス登録不可と判定されたページは、リクエスト自体を送信できません。 ### インデックス登録をリクエストすると検索順位は上がりますか？ 上がりません。2011年の公式ブログは、送信したURLの扱いについて「正規のプロセス（Fetch as Googlebot 以外の方法で発見された URL に対して用いるプロセス）と同様に行われます」と説明しており、現在のヘルプも「リクエストを送信しても、ページが Google インデックスに表示されるとは限りません」としています。公式ドキュメント「URL の再クロールを Google にリクエストする」も「同じ URL に対して再クロールを何度もリクエストしても、早くクロールされることはありません」としています。内容を改善してから1回送る運用が適切です。 ### インデックス登録のリクエストは1日に何件まで送れますか？ Googleは具体的な件数を公開していません。ヘルプにあるのは「送信できるインデックス登録リクエストの数には、1 日あたりの上限が設定されています」という記述のみで、検査のリクエスト数とライブテストの実行回数にもプロパティごとの1日上限があります。参考として、旧Fetch as Googlebotでは単独URLが1週間に50件、リンク先を含む送信が1カ月に10件と公開されていました。多数のページを登録したい場合、ヘルプはサイトマップの送信を案内しています。 ## 関連記事 - [インデックスカバレッジとは？「ページのインデックス登録」レポートの見方とエラー対処法](/column/details/5710/) - [robots.txtとは？クロール制御の書き方と効く場面・不要な場面【2026年時点】](/column/details/16577/) - [クローラビリティとは？SEOでの重要性と向上させる方法](/column/details/4614/) - [SEO内部対策とは？クロール・インデックス・UXの3分類で施策を優先度順に解説](/column/details/12834/) - [canonicalタグとは？SEOでのURL正規化の目的・書き方・設定方法を解説](/column/details/4873/) --- 出典: [Fetch as Googleとは？終了の経緯とURL検査ツールでの代替手順]()（株式会社一創）