Googleにインデックスさせる方法とAPIの対象範囲

このトピックの全体像Claude Code 完全ガイド｜料金・使い方・法人導入の全体像連携・自動化の記事

公開日: 2026年3月25日最終更新: 2026年9月15日

公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について

Googleにインデックスさせるには、通常記事はURL検査とサイトマップの2つを使い分け、Indexing APIは対象ページに限定します。

要点1: 少数URLはURL検査、多数はサイトマップ。リクエストしても登録は保証されません。
要点2: 未登録ならnoindex、robots.txt、canonicalと取得状態を切り分けます。
要点3: Indexing APIの通知受付は、クロール完了やインデックス登録完了とは別です。

対象読者：SEO担当者、Web担当者

今日やること: 登録したい公開URLを1件、Search Consoleで検査します。

この記事の著者

株式会社Nexa 代表取締役川島陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る AI顧問の無料相談

Googleにインデックスさせるには、通常の記事ならSearch ConsoleのURL検査から始めます。Indexing APIは一般記事を一括登録するための機能ではありません。

公開したページが検索に出ないとき、申請不足とは限りません。取得できない設定や、別URLを正規ページとして扱う設定も確認が必要です。通常記事の登録リクエストと原因調査を先に説明し、後半で対象ページ向けのGCP設定、Python通知、Claude Code連携を紹介します。

訂正（2026年9月15日）旧版の「2〜3分でクロール」「23件を送信した実績」には、確認可能な根拠を提示できないため撤回します。一般記事へのAPI利用推奨と「24〜48時間以内にクロール」とする記述も訂正しました。通知の受付を、登録完了や速度改善の証拠として扱いません。

Googleにインデックスさせる方法をページの種類で選ぶ

通常記事を登録したい場合、少数ならURL検査、多数ならサイトマップを使います。Googleはページを発見し、内容を取得したうえで、検索用のデータベースへ登録するか判断します。内容の取得を「クロール」、検索用データベースへの登録を「インデックス登録」と呼びます。

ページの種類・状況	最初に使う方法	作業の目的
新規記事や修正記事を数件確認したい	Search ConsoleのURL検査	状態確認と登録リクエスト
多数の通常記事を知らせたい	XMLサイトマップ	URLの発見を助ける
要件を満たす求人・ライブ配信ページ	Indexing API	追加・更新・削除を通知
noindexや取得エラーがある	設定・サーバーの修正	登録を妨げる原因を取り除く

Search Consoleは、自社サイトの検索状況を確認するGoogleの管理ツールです。対象サイトの所有権確認が必要で、管理していない他社URLの登録依頼には使えません。まず公開URLと、そのURLを含むプロパティを用意してください。

Google Indexing APIとは？求人とライブ配信向けの通知機能

Google Indexing APIは、対象ページの変更をプログラムからGoogleへ通知する機能です。APIとは、別のプログラムから所定の形式で処理を依頼する窓口です。通常記事を検索結果へ強制登録する仕組みではありません。

Google公式の利用ガイドは、対象を次のページに限定しています。

JobPostingの構造化データを含む求人ページ
VideoObject内にBroadcastEventを含むライブ配信ページ

構造化データは、ページの種類や内容を機械が理解しやすい形式で記述したものです。単に動画を埋め込んだブログ記事は、上のライブ配信要件と同じではありません。通常記事に実態と異なる求人データを付けて、対象に見せかけることも避けてください。

公式対象に当てはまらない記事では、APIの設定や送信コードを実行せず、URL検査とサイトマップを選びます。対象を判定できない場合も、送信を保留します。

図1: 通常記事はURL検査・サイトマップ、対象要件を満たす求人・ライブ配信はIndexing APIを検討します。

通常記事はURL検査の3手順で登録をリクエストする

URL検査では、Googleが保持している情報と、現在の公開ページを分けて確認します。所有者またはフルユーザーの権限を持つアカウントで操作してください。Indexing APIの委任所有者設定とは、必要な権限が異なります。

1. 公開URLを入力して登録状態を確認する

Search Consoleで対象プロパティを開き、上部の検査欄に完全なURLを入力します。下書きのプレビューURLではなく、読者が閲覧する公開URLを使います。「URLはGoogleに登録されています」などの判定と、「ページのインデックス登録」の詳細を確認します。

未登録の場合は、その理由と最終クロール日時を記録します。この画面は原則としてGoogleが保持する情報であり、今修正したばかりのページをそのまま表すとは限りません。HTTPとHTTPS、wwwの有無、末尾スラッシュが異なるURLを混同しないことも必要です。

2. 公開URLをテストし、取得を妨げる問題を直す

「公開URLをテスト」を実行し、現在のページをGoogleが取得できるか確認します。取得失敗やインデックス登録を拒否する設定があれば、原因を修正して再テストします。「テスト済みのページを表示」で、返されたHTMLや画面も確認できます。

テストの合格は、インデックス登録済みという意味ではありません。公開URLテストだけでは、GoogleがどのURLを正規ページに選ぶかも確定できません。修正後の表示と、Googleが以前保持した状態を別々に記録してください。

3. インデックス登録をリクエストする

問題を修正したら、検査結果画面の「インデックス登録をリクエスト」を押します。受付後は申請日とURLを記録し、後日同じURLを検査します。ライブテストで登録できないと判断されたページは、先に原因を解消する必要があります。

操作と各判定の意味はGoogle公式のURL検査ヘルプで確認できます。画面の言語や更新により、表示名は異なる場合があります。

インデックス登録までの時間と再申請の判断

申請直後に検索へ出ないだけで、処理失敗とは判断できません。Googleは再クロールの依頼に関する公式説明で、クロールに数日から数週間かかる場合があると案内しています。これは登録までの保証期間ではありません。

同じURLを繰り返し申請しても、クロールが速くなるわけではありません。毎日押し直すよりも、申請後にページを変更したか、取得エラーが残っていないかを確認します。企業規模やサイトの知名度だけで「何日で登録される」と予定を組むのは避けてください。

例えば公開直後のURLなら、申請日時、設定確認結果、次の確認日を作業表に残します。一方、更新前から未登録が続くURLなら、待つだけでなく以下の設定と内容を調べます。検索への掲載を期限付きで約束しない運用が必要です。

noindexで登録を拒否していないか確認する

検索に出したいページにnoindexがある場合は、設定を修正します。noindexは、検索エンジンにインデックス登録しないよう伝える指示です。HTML内のmetaタグと、サーバーが返すHTTPヘッダーの両方を確認してください。

<!-- 検索に出したいページに残っていないか確認する例 --><meta name="robots" content="noindex"><meta name="googlebot" content="noindex">

ヘッダーではX-Robots-Tag: noindexやnoneにも注意します。WordPressならサイト全体の検索表示設定、SEOプラグインの投稿設定、サーバー側設定を確認します。HTMLだけ修正しても、ヘッダーに指示が残っていれば解消しません。

noindexの公式仕様では、robots.txtにnoindexを書く方法はサポートされていません。またGoogleがnoindexを認識するには、対象ページをクロールできる必要があります。非公開ページの設定まで一括解除せず、検索に出したいURLだけを対象に修正します。

robots.txtでクロールを止めていないか確認する

robots.txtは、クローラーがアクセスできるURLを制御するファイルです。サイトのルートにある/robots.txtを開き、対象のパスがDisallowに含まれていないか確認します。全体を禁止するDisallow: /が公開サイトに残っていれば、調査対象になります。

ただし、robots.txtは「検索結果から確実に消す設定」ではありません。Googleのrobots.txt解説は、他ページからリンクされたURLが、内容をクロールされずに登録される可能性を説明しています。noindexとは働きが異なります。

登録したいページではクロール制限とnoindexを別々に確認してください。社内ページなど意図的な制限がある場合は、解除の前に公開範囲を確認します。原因が一部のパスだけなら、robots.txt全体を削除する必要はありません。

canonicalとリダイレクトの向き先を確認する

似た内容のURLが複数あると、Googleは代表となる正規URLを選びます。canonicalは、その候補をサイト側から伝える指定です。別記事のURLを誤って指定すると、公開したいURLとは別のページが代表として扱われる原因になります。

<!-- 対象ページ自身を正規URL候補にする場合の説明例 --><link rel="canonical" href="https://example.com/article/">

URL検査で「ユーザーが指定した正規URL」と「Googleが選択した正規URL」を比較します。リダイレクトは、アクセスを別URLへ転送する仕組みです。転送がある場合は、転送先の内容と登録状態も確認してください。

正規URLの指定に関する公式ガイドに沿い、canonical、内部リンク、サイトマップで同じ正規URLを示します。canonicalはGoogleへのシグナルで、指定どおりの選択を保証する命令ではありません。意図どおりに重複URLが除外されているだけなら、無理に全URLを登録する必要はありません。

検出済み・クロール済みの未登録を切り分ける

未登録の表示だけでは、問題が起きた段階を判断できません。URLを知っていても未取得なのか、取得後に未登録なのかで、調査する内容が変わります。担当者には判定名だけでなく、対象URLと確認日時も渡してください。

URL検査などで見える状態	優先して確認する内容
検出済み・インデックス未登録	サイトマップ、内部リンク、サーバーの応答状況
クロール済み・インデックス未登録	実際に返した本文、重複、正規URL、独自の情報の有無
サーバーエラー・取得失敗	5xx、アクセス制限、障害、意図しないログイン要求
noindexによって除外	metaタグとHTTPヘッダーの設定
適切なcanonicalのある代替ページ	正規URLの選択が意図どおりか

「クロール済みだから低品質が原因」と一つに決めつけないでください。例えば本文が空のテンプレートや、別ページとほぼ同じ内容を返していないかを調べます。修正は見出しや文字数を増やすためではなく、読者の疑問に答える情報を補うために行います。

AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。

AI顧問の無料相談はこちら →

事前準備：GCPでAPIとサービスアカウントを設定する

ここからのAPI設定は、対象要件を満たす求人・ライブ配信ページ向けです。Google Cloud Platform（GCP）は、APIの有効化や認証情報を管理する基盤です。通常記事のURL検査を使うだけなら、以下のサービスアカウントは不要です。

APIを有効にする

Google Cloud Consoleで管理用プロジェクトを選択、または作成します。
「APIとサービス」のライブラリで「Web Search Indexing API」を探します。
APIを有効化し、利用するプロジェクトを記録します。

Google公式の事前準備にあるセットアップツールからも進められます。プロジェクトを複数作ることで送信上限を回避する設計にはしません。本番利用の承認状況とクォータも、実送信前に確認します。

サービスアカウントと鍵を用意する

サービスアカウントは、人のログインではなくプログラムの認証に使うアカウントです。「IAMと管理」から作成し、メールアドレスを控えます。Indexing API用のこの手順では、GCP側の広い編集者ロールを付ける必要はありません。

以下のPython例では、サービスアカウントのJSON鍵を使用します。組織で鍵の作成が許可されている場合だけ発行し、リポジトリの外へ保存してください。鍵の内容はAIへのプロンプト、共有資料、公開ログに貼りません。組織の制限で発行できない場合は、制限を迂回せず管理者に認証方式を確認します。

Search Consoleへサービスアカウントを委任所有者として追加する

GCP側で認証できても、対象サイトの所有者権限がなければ通知できません。公式手順に従い、Search Consoleで所有権を確認したサイトへ、サービスアカウントを「委任所有者」として追加します。単にフルユーザーにする手順とは区別してください。

所有権を確認済みの管理者がSearch Consoleを開きます。
通知対象URLを含むプロパティを選択します。
「設定」から「ユーザーと権限」を開きます。
サービスアカウントのメールアドレスを、所有者権限で追加します。
権限一覧を読み直し、メールアドレスと権限を確認します。

URLプレフィックス型のプロパティでは、対象URLのスキームやパスも適用範囲に関係します。権限エラーが出たら、鍵が属するアカウントと、所有者として登録したアカウントが一致するかを確認します。エラー解決のために、無関係な管理者権限を追加しないでください。

Pythonで対象ページの単一URLを通知する

対象要件と権限を確認できたら、1件の更新通知から試します。以下は説明用の最小コードで、初期状態では送信せず、JSONを表示します。一般記事には実行しません。

ライブラリをインストールする

python3 -m venv .venv.venv/bin/python -m pip install google-auth google-api-python-client

更新通知のスクリプトを作る

次をsubmit_url.pyとして保存します。--sendと--eligible-confirmedの両方を指定した場合だけ送信します。後者は担当者による確認の記録であり、コードが構造化データの適格性を自動判定する機能ではありません。

import argparseimport jsonimport osfrom urllib.parse import urlsplitdef main():    parser = argparse.ArgumentParser()    parser.add_argument("url")    parser.add_argument("--send", action="store_true")    parser.add_argument("--eligible-confirmed", action="store_true")    args = parser.parse_args()    parsed = urlsplit(args.url)    if (parsed.scheme not in {"https", "http"} or not parsed.netloc            or parsed.fragment or parsed.username or parsed.password            or any(c.isspace() for c in args.url)):        parser.error("公開ページの完全なURLを指定してください")    if args.send and not args.eligible_confirmed:        parser.error("対象要件・所有権・承認を確認してから送信してください")    body = {"url": args.url, "type": "URL_UPDATED"}    if not args.send:        print("DRY RUN（未送信）")        print(json.dumps(body, ensure_ascii=False, indent=2))        return    from google.oauth2 import service_account    from googleapiclient.discovery import build    from googleapiclient.errors import HttpError    credentials = service_account.Credentials.from_service_account_file(        os.environ["GOOGLE_APPLICATION_CREDENTIALS"],        scopes=["https://www.googleapis.com/auth/indexing"],    )    service = build("indexing", "v3", credentials=credentials)    try:        result = service.urlNotifications().publish(body=body).execute()    except HttpError as exc:        raise SystemExit(f"通知失敗: HTTP {exc.resp.status}") from exc    print("通知受付の応答（インデックス登録完了ではありません）")    print(json.dumps(result, ensure_ascii=False, indent=2))if __name__ == "__main__":    main()

未送信の確認と、承認後の実行を分ける

# 以下のURLは説明用です。自社の適格な公開URLに置き換えます。.venv/bin/python submit_url.py "https://example.com/jobs/42"# 鍵の内容ではなく、保存先のパスを設定します。export GOOGLE_APPLICATION_CREDENTIALS="/secure/path/service-account.json"# 対象要件・所有権・利用承認を確認した場合のみ実送信します。.venv/bin/python submit_url.py "https://example.com/jobs/42" \  --send --eligible-confirmed

実送信では返された応答を保存しますが、notifyTimeは通知の受付時刻です。登録時刻として記録しないでください。削除通知のURL_DELETEDはこの例に含めていません。利用する場合は、対象URLが404・410を返すか、noindexになっていることを公式手順に沿って先に確認します。

図2: 少数の通常記事はURL検査で確認し、問題を直してから登録をリクエストします。

サイトマップで複数URLをGoogleに伝える

通常記事をまとめて知らせる場合は、サイトマップを送信します。XMLサイトマップは、検索エンジンへ伝えたいURLを列挙したファイルです。APIに全URLを投入するための一覧ではありません。

WordPressやSEOプラグインが生成するサイトマップURLを確認します。
ファイルを開き、新規公開した正規URLが含まれているか確認します。
Search Consoleの「サイトマップ」でそのURLを送信します。
読み取り状況を確認し、個別ページの登録はURL検査で追跡します。

/wp-sitemap.xmlや/sitemap_index.xmlなど、パスは構成により異なります。先頭要素がsitemapindexなら、その中には記事URLではなく子サイトマップのURLが並びます。子ファイルを開いて目的の記事を探してください。

サイトマップの作成・送信ガイドに従い、正規URLを記載します。lastmodを使う場合は実際の重要な更新日を反映し、更新していない記事の日付を毎日書き換えないようにします。送信の成功やURLの掲載だけでは、全ページの登録を保証できません。

Indexing APIのクォータとバッチ処理の数え方

Indexing APIには、初期導入とテスト用の標準クォータがあります。クォータとは、一定期間に利用できるリクエスト数の枠です。本番利用を無条件に認める枠ではありません。

項目	公式仕様の確認点
初期テスト用publish枠	1プロジェクトにつき1日200リクエスト
対象の操作	`URL_UPDATED`と`URL_DELETED`を合算
日次枠のリセット	太平洋時間の深夜
バッチ送信	最大100通知を1HTTPリクエストにまとめる
バッチの枠消費	まとめた各通知がそれぞれ消費
本番利用と増枠	Googleへの承認・クォータ申請を確認

承認とクォータの公式案内にあるフォームを確認し、利用目的とプロジェクト情報を準備します。申請すれば必ず承認される、あるいは何日で終わるとは想定しません。

バッチ化は通信回数を減らすための仕組みです。「100件をまとめれば消費は1件」という理解は誤りです。対象要件を満たすURLでも、変更のないページを繰り返し送らず、送信済み記録と残り枠を見て処理します。

API受付・クロール・登録を別々に確認する

APIが成功応答を返しても、Googleの検索結果に載ったとは言えません。作業ログでは、通知受付、クロール、登録の3段階を分けて扱います。公開ページ自体のHTTP 200と、APIのHTTP 200も別の応答です。

段階	確認する証拠	その証拠だけでは分からないこと
通知受付	APIのHTTP 200、通知の`notifyTime`	実際の取得・登録完了
クロール	URL検査の最終クロール日時など	登録されたか、検索に出るか
インデックス登録	URL検査の登録判定とGoogle選択の正規URL	特定キーワードでの順位・表示保証

Indexing APIのgetMetadataが返すのは、Googleが最後に通知を受け付けた情報です。登録や削除の完了時刻ではありません。公式の「HTTP 200なら近いうちに再クロールを試みる可能性がある」という説明を、必ずクロールすると読み替えないでください。

一方、URL Inspection APIは、Googleが保持するインデックス状態を取得する別APIです。現在の公開URLをライブテストする機能や、登録をリクエストする機能ではありません。名前が似ていても、通知用と状態参照用を取り違えないことが必要です。

図3: APIの通知受付、クロール、インデックス登録は別々に確認します。

Claude CodeのWordPress公開ワークフローに確認処理を組み込む

Claude Codeでは、公開後の確認処理をコードや手順として定義できます。Claude CodeはAnthropicのAIコーディングツールで、指示に応じてファイル編集やコマンド実行を支援します。すべての記事へIndexing APIを送るのではなく、ページの種類で分岐させます。

記事作成 → レビュー → WordPress公開  → 公開URL・本文・HTTP応答・noindex・canonicalを確認  → 通常記事：サイトマップ掲載確認 → 必要なURLを手動検査  → 適格な求人・ライブ配信：承認・所有権確認 → API通知  → 通知履歴と登録状態を別々の項目で記録

WordPressをコマンドで操作するWP-CLIを使う場合も、下書きやプレビューではなく公開状態を確認します。URLはCMSが返すパーマリンクを使い、タイトルから推測して作りません。リライトでは既存URLを変えず、そのURLを確認対象にします。

Claude Codeの公式Skills機能で手順を定義するなら、「公開確認」「対象判定」「送信前の承認」「結果記録」を分けます。例えば「通常記事ならAPIを呼ばず、URL検査が必要な一覧だけ作成する」と明記します。鍵の中身はAIに読ませず、承認済みスクリプトが指定パスから認証情報を読み込みます。

403なら権限とプロパティ範囲、429ならクォータ、5xxなら一時障害の可能性を調べます。同じ処理を無制限に再実行せず、失敗したURLだけを記録して人が判断できる状態にします。自動化の完了条件は「全件登録」ではなく、許可した確認と通知が終わったことです。

あわせて読みたい

Claude Codeの使い方：導入から安全な運用まで — 初めて使う際の操作と安全設定を確認できます。

Claude Code Skills：カスタムスキルの作り方と活用法 — 繰り返す確認手順を再利用する方法が分かります。

Nexaの実測：公開URLで確認できる範囲

2026年9月15日15:51（日本時間）、Nexaはこの記事の公開URLを1件診断しました。認証なしで取得できるHTTP応答、HTML、robots.txt、XMLサイトマップだけを使った点検です。APIへの送信やGoogle側の登録判定は、この測定に含めていません。

点検した項目	取得結果	判断できる範囲
公開URLのHTTP応答	200、転送先も同一URL	この取得時点でページが応答した
HTMLのcanonical	この記事自身のURLと一致	サイト側が示した正規URL候補
noindex指示	HTML・HTTPヘッダーとも検出なし	取得した応答に登録拒否指示がない
robots.txt	Googlebotに対し当該パスを許可	robots.txt上のクロール制限がない
投稿サイトマップ	全476URLの中に当該URLあり	サイトマップでURLを知らせている

測定元は公開robots.txtと投稿サイトマップ、この記事のHTTP応答とHTMLです。サイトマップの件数は測定時点の値で、更新により変わります。

5項目を確認しても「Googleに登録済み」とは判定できません。Googlebotの実際の訪問や、Googleが選んだ正規URLも未確認です。この診断は設定の点検であり、速度改善や検索順位への効果を示す実験ではありません。

公開URLの応答やHTMLを確認するだけでは、Googleの登録状態やクロール時刻は分かりません。測定した事実と、Search Consoleで別途確認すべき情報を区別して扱います。

よくある質問

Q. Google Indexing APIは一般のブログ記事にも使えますか？

一般ブログ記事は公式の利用対象ではありません。求人のJobPosting、またはVideoObject内のBroadcastEventを含む対象ページに限定されています。通常記事はURL検査とサイトマップを使います。APIから成功応答があっても、対象範囲が広がった証拠にはなりません。

Q. Search Consoleの所有者追加はどう進めますか？

まず管理者がサイトの所有権を確認し、公式手順に従ってサービスアカウントを委任所有者として追加します。この記事は管理画面での操作を説明しています。GCPでアカウントを作成しただけでは、サイトの所有者権限は付きません。

Q. 1日に何件まで登録をリクエストできますか？

Indexing APIの初期テスト枠はpublishが1日200件/プロジェクトです。本番利用には承認・クォータ申請を確認します。Search ConsoleのURL検査にも申請上限がありますが、APIの200件をそのまま当てはめることはできません。多数の通常記事はサイトマップで知らせます。

Q. Claude Codeで記事公開から登録まで全自動にできますか？

公開後の設定確認や、適格なページのAPI通知は自動化できます。ただしGoogleが実際にクロール・登録するかは制御できません。URL Inspection APIも登録依頼の窓口ではないため、通常記事の手動リクエストと自動確認処理を分けて運用します。

Q. 登録リクエストをしても検索に出ない場合は？

URL検査で未登録の理由、最終クロール、Google選択の正規URLを確認します。登録済みでも、特定の検索語で表示される保証はありません。登録状態と順位の問題を分け、設定の不備がなければ内容や検索意図との一致を確認してください。

まとめ

Googleにインデックスさせるための作業は、ページを知らせる方法の選択と、登録を妨げる原因の確認から始まります。通常記事は少数ならURL検査、多数ならサイトマップを使います。Indexing APIは、要件を満たす求人・ライブ配信ページの通知に限定してください。

登録されないときは、noindex、robots.txt、canonical、取得状態を切り分けます。通知受付や公開URLテストの成功を登録完了と混同せず、Googleが保持する状態を別に追跡します。

まず公開URLを1件検査し、判定、原因、確認日を記録してください。修正すべき設定があれば直してからリクエストし、後日の確認につなげます。

AI導入に関するお困りごとをサポートします

株式会社NexaのAI顧問は、ツール選定から業務への適用、社内定着までを月額制でサポートします。特定のツールに限らず、「AIをどう使えばいいか分からない」という段階からご相談いただけます。

AI顧問の詳細・無料相談はこちら →