Indexing APIでブログ記事を送るのは危険？対象と正しい手段

新しい記事が、なかなか検索結果に出てこない。調べていると「Indexing API を使えば、すぐにインデックスされる」という話が見つかる。対応したプラグインや外部ツールもあるらしい。

結論から書きます。ブログ記事や商品ページは、Indexing API の対象ではありません。 Google の公式ドキュメントは、この仕組みを使えるページを「求人情報」と「ライブ配信」の2種類に限っています。通常のページで早く見つけてもらいたいなら、使う道具は Search Console の URL 検査ツールと、サイトマップ（サイト内のページ一覧をまとめたファイル）です。

Indexing API は「求人とライブ配信」のための仕組み

Indexing API は、ページが追加・削除されたことを Google に知らせる仕組みです。Google のクイックスタートは、この通知によって Google が新しいクロール（ロボットがページを読みに来ること）の予定を組めるようになる、と説明しています。

問題は、その次の一文です。公式ドキュメントには「Indexing API は、JobPosting または VideoObject に埋め込まれた BroadcastEvent のいずれかを含むページのクロールにのみ使用できる」という趣旨がはっきり書かれています。JobPosting は求人情報、BroadcastEvent はライブ配信を表す構造化データ（ページの中身を検索エンジンに伝えるための決まった書式）です。

使える場面も、公式は具体的に挙げています。求人や配信動画のように「掲載期間の短いページがたくさんあるサイト」では、サイトマップの代わりに Indexing API を使うことを勧めている、という書き方です。

つまり、対象はページの種類で決まっています。「急いでいるから」「重要な記事だから」は、対象になる理由になりません。

公式が書いている注意書き

では、対象外のページを送ったらどうなるのか。ここは、公式に書かれている範囲だけを正確に確認しておきます。

クイックスタートには、次の内容が明記されています。

• Indexing API を通じた送信は、すべて厳格なスパム検出の対象になる
• 複数のアカウントを使うなどして使用量の上限（クォータ）を超えようとする行為を含め、Indexing API を乱用しようとすると、アクセスが取り消されることがある

使用方法のページでも、ガイドラインとして「Indexing API で送信されたコンテンツにはスパムに関するポリシーが適用される」と書かれています。さらに上限は URL 単位で数えられ、複数のリクエストを1回にまとめて送っても、件数は減りません。

ここから言えるのは、「送れば送るほど得をする」設計ではない、ということです。対象外のページを大量に流し込むのは、公式が示す使える範囲から外れた使い方になります。スパム検出の対象で、乱用すればアクセスを失うこともある。そんな仕組みを、対象外のページを急がせる目的で使う理由は薄いと考えられます。

通常ページで使うべき、公式の2つの手段

通常のページについて、Google は別の手段を案内しています。「Google に URL の再クロールをリクエストする」のページは、方法を URL の数で分けています。

一つめの URL 検査ツールは、Search Console で対象の URL を検査し、「インデックス登録をリクエスト」を押す方法です。すぐに分かる登録上のエラーがないかの簡易チェックを通ると、登録の処理へ送られます。公式は、同じ URL に何度もリクエストしても早くクロールされるわけではない、とも明記しています。連打しても意味はありません。

二つめのサイトマップは、サイトのどのページが重要だと考えているかを Google に伝えるファイルです。Google はこれを読んで、サイトをより効率よくクロールします。URL 検査ツールのヘルプ自身も、多くのページを登録してほしいならサイトマップの送信を試すよう案内しています。

表の三行目は、求人やライブ配信のページを持つサイト向けです。この場合でも、公式はサイト全体をカバーするためにサイトマップを送ることを勧めています。Indexing API と並べて、サイトマップも使う形です。

どの手段でも「すぐ出る」保証はない

ロボットに来てもらう手段を正しく選んでも、待ち時間はなくなりません。

公式は、クロールには数日から数週間かかることがある、としています。そして、クロールをリクエストしても検索結果にすぐ出るとは限らず、まったく出ないこともある、とも書いています。サイトマップについても、中の URL がすべてクロール・登録されるとは保証されません。

同じページには、もう一つ大事な一文があります。Google のシステムは、質が高く役に立つコンテンツを早く取り込むことを優先している、という内容です。

つまり、登録の速さを左右するのは、送る経路だけではありません。送る手段を増やすより先に、そのページ自体を見直す価値があります。URL 検査ツールのヘルプにも、重複しているページは登録されない、という記述があります。似た内容の記事がサイト内にあるなら、そちらを疑うほうが近道になることがあります。

自社サイトを点検して切り替える6ステップ

自社サイトで知らないうちに Indexing API を使っていないか。まずそこから確かめ、正しい手段に移ります。

1. 送信の仕組みを洗い出す：CMS のプラグイン、外部の SEO ツール、制作会社が組んだ自動処理の中に、公開時に Google へ自動で通知するものがないかを確認します。設定画面や説明文に「Indexing API」の文字があるかを見て、分からなければ開発担当や制作会社に聞きます。
2. 送っているページの種類を確かめる：Indexing API を使っていた場合、送信先がどのページかを確認します。求人情報（JobPosting）かライブ配信（VideoObject 内の BroadcastEvent）の構造化データを含むページ以外が混ざっていないかを見ます。
3. 対象外のページへの送信を止める：ブログ記事、商品ページ、カテゴリページなどが含まれていたら、その送信を止めます。求人ページだけに絞れる設定があるなら、それを使います。
4. サイトマップの状態を確認する：Search Console でサイトマップが送信済みか、読み込めているかを確認します。止めた送信の代わりに、通常ページはサイトマップで伝える形にそろえます。
5. 急ぐ数本だけ URL 検査ツールを使う：公開直後で特に早く見てほしい記事が数本だけあるなら、URL 検査ツールで1回ずつリクエストします。同じ URL を繰り返し送らないようにします。
6. 数日おいて「前回のクロール」を見る：URL 検査ツールには、Google が前回そのページをクロールした日時が表示されます。リクエスト後に日時が新しくなったかどうかで、ロボットが来たかを判断します。来ているのに登録されない場合は、送る手段ではなく、重複や内容の側を見直します。

例: 求人ページもある会社のオウンドメディアで試す

架空の例で、6ステップを一度通してみます。自社サイトに、採用情報のページと、週2本更新するお役立ち記事のブログがある会社を考えます。担当者は、記事が遅いと感じて「インデックス即時送信」をうたうプラグインを入れていました。

ステップ1で、プラグインの設定画面に Indexing API の表記が見つかります。ステップ2で送信履歴を見ると、採用ページだけでなく、ブログ記事と会社概要ページまで公開のたびに送られていました。ここが問題の中心です。

ステップ3では、ブログ記事と会社概要の送信を止めます。採用ページが JobPosting の構造化データを含んでいるなら、そこは Indexing API を使える範囲に入ります。含んでいないなら、採用ページも対象外です。

ステップ4で Search Console を開くと、サイトマップは送信済みでした。ブログ記事は今後この経路で伝えます。ステップ5では、今週公開した記事2本だけを URL 検査ツールでリクエストします。

数日後のステップ6で、1本は「前回のクロール」が更新され、検索結果にも出ていました。もう1本は、クロール日時は新しいのに登録されていません。調べると、半年前の記事と見出しも結論もほぼ同じでした。この1本は、送信の経路を変えても解決しないタイプです。統合するか、書き分けるかを検討する段階に進みます。

この例で見えてくるのは、「遅い」の中身が2種類に分かれることです。まだロボットが来ていないのか、来たのに登録されていないのか。送る経路を増やしても、この区別はつきません。

よくある誤解: 求人ページがあるサイトなら全部送ってよい？

求人ページを持つサイトは、正規の手続きで Indexing API を使っていることがあります。そのため「うちは対象サイトだから、ついでにブログも送ってよい」と考えがちです。

ところが、公式が対象を決めている単位はサイトではなくページです。書かれているのは、JobPosting か VideoObject 内の BroadcastEvent を「含むページ」のクロールにだけ使える、という範囲です。同じドメインの中でも、求人の構造化データを持たないページは対象になりません。

もう一つの誤解は、「Google 公式の API なのだから、使えば公式の手段で安全」というものです。公式であることと、どのページに使ってもよいことは別の話です。公式が用意した道具を、公式が決めた範囲で使うところまでが「公式の手段」です。

その場で使える点検リスト

• CMS のプラグインや外部ツールに、Indexing API で自動送信する機能が入っていないか
• 入っている場合、送信先に求人・ライブ配信以外のページが混ざっていないか
• 使用量の上限を超えるために、複数のアカウントを使うような運用になっていないか
• 通常のページは、サイトマップで伝える形になっているか
• URL 検査ツールでのリクエストを、同じ URL に繰り返していないか
• クロールされたのに登録されないページについて、似た内容の記事がサイト内にないか確認したか

リクエストを送ったあとの待ち方はインデックス登録をリクエストしても反映されないときの手順に、登録されない原因の切り分けはインデックスされないページの診断にまとめています。求人ページを正規に運用している場合は、掲載終了した求人の validThrough の扱いも合わせて確認してください。