公開したページが数日たっても検索結果に出てこない。そうなると、多くの担当者は Search Console の URL 検査ツールを開き、インデックス登録をリクエストします。ここまでは自然な流れです。ただし、そこで止まる運用は勧められません。インデックス登録を早めたいなら、最初に申請するのではなく、未登録の理由を分類してください。
Google も、クロールとインデックス登録の基本として、クロール可否、重複、サイトマップ、モバイル対応、JavaScript 描画などを個別に確認する前提を示しています。また、URL 検査ツールでも、インデックス登録のリクエストは掲載を保証するものではなく、多数の URL はサイトマップで知らせるほうが適していると案内しています。つまり、申請は最後に添える一手であり、最初に取る行動ではありません。
実務で優先したいのは、Search Console を「申請窓口」ではなく「診断装置」として使うことです。ページ全体の傾向を見ずに単一 URL だけ深掘りすると、共通設定の不具合や URL 設計の乱れを見落とします。反対に、原因ごとにまとまりで把握してから代表 URL を確認すれば、直すべき箇所が明確になります。この記事では、Google インデックス登録を早めたいときに、何を先に見て、何を後回しにし、どの条件なら申請すべきかを、現場で使いやすい基準に絞って整理します。
インデックス登録を急ぐ前に確認順を固定する
先に結論を示します。インデックス登録を急ぐ案件ほど、確認の順番を固定する必要があります。 私は次の順番を崩さないよう勧めています。
- ページのインデックス登録レポートで未登録理由を確認する
- 代表 URL を URL 検査ツールで深掘りする
- 技術修正後にサイトマップ送信や限定的な申請を行う
この順番を勧める理由は明快です。レポートを先に見れば、単発の問題なのか、共通設定の問題なのかを最初の数分で切り分けられるからです。公開直後の案件では、1 本だけ未登録に見えても、同じ構成の 20 本がまとめて止まっていることがあります。ここで URL 検査ツールから入り、たまたま正常な 1 本だけを見て「問題なし」と判断すると、対応が一日単位で遅れます。
反対に、レポートを見れば「Discovered - currently not indexed」「Crawled - currently not indexed」「重複しています」「robots.txt によりブロックされました」など、打ち手の異なる問題が一画面で並びます。未登録を一括りにしてはいけません。 原因が違えば、直す場所も、待つべき時間も、申請の要否も変わります。
使い分けを表にすると、実務では次の整理が最もぶれません。
確認する場面 | 先に使うべき道具 | 何が分かるか | 先にやってはいけないこと |
|---|---|---|---|
未登録が1本か複数本か分からない | ページのインデックス登録レポート | 理由別の件数、まとまりの有無、サイト全体の傾向 | 代表 URL 1 本だけ見て全体を正常と判断すること |
代表 URL の現状を掘りたい | URL 検査ツール | 取得可否、canonical、インデックス許可、ライブテスト結果 | 全 URL を個別に申請して対応した気になること |
新規 URL や更新 URL をまとめて伝えたい | 正本 URL の通知、更新日の伝達 | 技術不具合を直さないまま送信だけ増やすこと |
特に月間 PV 10 万未満のサイトでは、「URL 検査ツールで見えるから大丈夫」と考えがちです。しかし、小規模サイトほど CMS 更新や公開フローの設定漏れが、そのまま本番に残りやすいものです。数本しか公開していないつもりでも、カテゴリーページ、タグページ、プレビュー URL が同時に増えているケースは珍しくありません。だからこそ、最初の入口は常にレポートに置くべきです。
URL 検査ツールの読み違いを減らしたい場合は、関連記事の URL検査ツールの使い方を誤らないために Search Consoleで判断精度を上げる実務 も合わせて読むと判断が安定します。URL 単位の画面は便利ですが、全体傾向を見た後で使ってこそ武器になります。
最初の十分で技術的な詰まりを洗い出す基本手順
インデックス登録を早めたいとき、私は最初の十分で六つの確認を終えます。ここを飛ばして本文改善や再申請に進むべきではありません。 Google 側の評価以前に、そもそも取りに行きにくい、読みにくい、正本が割れているという状態なら、申請を増やしても速度は上がらないからです。
- HTTP ステータスが 200 で安定しているかを確認する
公開 URL は常時 200 を返す必要があります。301 が二段以上続く、モバイルだけ 302 になる、公開直後の数時間だけ 5xx が混じる、といった状態なら修正を先に選んでください。目安として、公開後 24 時間のあいだに 5xx が一度でも混じるページは、申請より配信の安定化を優先すべきです。急ぎ案件ほどサーバーログと監視を見たほうが早く片づきます。
- robots.txt でクロールを止めていないかを確認する
robots.txt の概要にある通り、robots.txt はクロール制御であって、検索結果からの完全除外を保証する手段ではありません。インデックスさせたい URL を robots.txt で閉じる運用は避けるべきです。公開ページなのに `Disallow` の影響を受けているなら、内容改善より設定修正が先になります。 例外もあります。会員専用ページ、テスト環境、契約上非公開にすべき資料は、あえてクロールさせない判断が妥当です。ただし、その場合は「早く登録したい」という対象から外してください。
- noindex の有無を HTML とレスポンスヘッダーの両方で確認する
noindex を使用してページを検索インデックスから除外の通り、Google が noindex を読むにはページを取得できる必要があります。つまり、robots.txt で閉じたまま noindex を置いても意味がありません。公開直後の本番で noindex が残っている事故はよくあります。特に CMS の下書き設定から複製したページは要注意です。公開後 48 時間以内に反応がないなら、まず noindex を疑うべきです。
- canonical、内部リンク、サイトマップの正本 URL を一本にそろえる
重複した URL の正規化と重複 URL の統合でも、canonical の整合性が重要だと示されています。実務ではここが最も崩れやすい部分です。公開 URL は `/service/seo` なのに、canonical は `/service/seo/`、サイトマップは旧 URL、内部リンクはパラメータ付き URL というように合図が割れていると、Google はどれを正本として扱うべきか迷います。正本を早く載せたいなら、まず正本を一つに決める必要があります。
- サイトマップに正本 URL が載り、更新日が古すぎないかを確認する
サイトマップの概要とサイトマップの作成と送信を読むと、サイトマップは URL の存在を伝える手段として有効でも、内容の品質問題までは解決しないと分かります。新規公開したのにサイトマップに入っていない、`lastmod` が一週間以上前のまま、canonical ではない URL を送っている。この三つは、公開直後に動きが鈍る案件で頻出です。新規ページなら公開当日中、遅くとも翌営業日までにサイトマップへ反映してください。
- モバイル表示と JavaScript 描画後の HTML を確認する
モバイル ファースト インデックスに関するベスト プラクティスとJavaScript SEO の基本を理解するを読むと、Google はモバイル側の内容差分や、描画後でないと見えない本文に影響を受けると分かります。パソコンでは見えていても、モバイルで本文が畳まれたまま取得されていない、初期 HTML に見出しがない、内部リンクが描画後にしか出ない。こうした構成は、速度以前に理解を遅らせます。JavaScript 依存の強いページでは、本文と見出しが初期 HTML にある構成を基本に据えるのが安全です。 例外として、検索流入を狙わない会員専用機能やアプリ連携画面は、ここまで厳密に整えなくても問題になりにくいでしょう。ただし、SEO 対象ページでは例外にしないほうが無難です。
この六つを最初の十分で確認できれば、「技術修正で進む案件」か「内容整理まで必要な案件」かがおおむね見えてきます。見えないまま申請を繰り返す運用は、忙しいようでいて最も遅い進め方です。
未登録理由ごとに打ち手を切り分ける実務基準
未登録理由を一括で扱うと、対応は必ずぼやけます。理由ごとに、やることとやらないことを先に決めてください。 Search Console でよく見かける状態ごとに、実務で使いやすい判断基準を示します。
Discovered - currently not indexed が多い場合 この状態は、Google が URL の存在は知っているものの、まだ取りに来ていない段階です。ここで申請を繰り返しても、根本の改善にはつながりません。最優先は「見つけやすい経路を太くすること」です。 私は、次の条件に当てはまるなら内部リンクとサイトマップの見直しを先に行うべきだと判断しています。
- 対象 URL がトップまたはカテゴリーページから 3 クリック以上離れている
- 新規公開から 48 時間以上たっているのに、同じ理由の URL が 10 本以上ある
- 週あたりの新規公開本数が 20 本を超えているのに、サイトマップ更新が日次になっていない
この場合は、対象ページをカテゴリーページや関連記事から自然につなぎ、サイトマップへ正本 URL を載せ、`lastmod` を更新してください。本文からの関連リンクを 2 本以上追加できるなら、そのほうが一覧の機械的なリンクより効きます。内部リンクの考え方は、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 と合わせて整理すると判断しやすくなります。 例外は、公開から 24 時間以内の単発ページです。1〜2 本だけで、サイト全体に異常がないなら、まずは慌てず一日待つ判断も妥当でしょう。
Crawled - currently not indexed が多い場合 この状態では、Google はページを取得したうえで採用を見送っています。ここでやるべきことは申請ではありません。重複の整理か、内容の差別化です。 私の基準では、次のどちらかに当てはまるなら、再申請より先に本文や構成を見直すべきです。
- 本文が 800〜1,200 文字未満で、既存ページとの差分が見出し数個しかない
- 同一テーマのページが 3 本以上あり、検索意図の違いを冒頭で説明できない
特に、地域名だけ差し替えたページ、製品名だけ違う比較記事、ほぼ同じ説明文が続くサービスページは、クロールされても採用が鈍りやすくなります。この場合は、統合できるものは統合し、残すページには一次情報、比較軸、導入条件、失敗例などを加えて役割を明確にしてください。「少し書き足してもう一度送る」だけでは足りないケースが多い。これが現場の実感です。 例外もあります。速報性の高いニュース、法改正、障害告知のように時間価値が高いページは、本文量がやや短くても採用されることがあります。ただし、その場合も重複ページを増やさない前提は変わりません。
robots.txt や noindex が原因の場合 ここは悩む余地がありません。登録したいなら停止命令を外すべきです。 robots.txt と noindex の役割は別であり、両方を誤って重ねると、Google が状態変化を読み取りにくくなります。ステージングからの複製、レビュー用のひな型の流用、公開フラグの解除漏れは典型的な事故です。共通設定単位で残っているなら、代表 URL だけ直しても足りません。同じ設定を使う全ページを点検してください。 例外は、公開対象でないページです。その場合は修正対象ではなく、一覧から除外して管理するべきです。
重複または代替ページが多い場合 この状態でやるべきことは、URL を増やすことではなく、減らすことです。並び順、絞り込み、計測用パラメータ、末尾スラッシュ違い、スマホ旧 URL などが増えると、正本候補が乱立します。Search Console で重複が 20 URL を超えているのに、サイトマップへ複数系統を混ぜて送っているなら、その運用は見直すべきです。 EC や求人などの大量 URL 型サイトでは、商品詳細や求人詳細の正本 URL だけをサイトマップに載せ、一覧や絞り込み結果を無差別に混ぜない判断が安全です。ここで URL を増やし続けると、重要ページのクロール配分が薄まります。
要するに、Discovered は発見経路、Crawled は採用理由、Blocked は設定、重複は URL 設計を直す問題です。 それぞれの論点を混ぜないことが、インデックス登録を早める最短ルートになります。
月間PV別に優先施策を変える実務判断基準
「サイト規模によって変わる」とだけ書いても、実務では役に立ちません。どこで運用を切り替えるかを数値で決める必要があります。ここでは、月間 PV と公開本数を基準に、現実的な優先順位を示します。
月間 PV 10 万未満で、週の新規公開が 10 本未満の場合 この規模では、URL 単位の確認がまだ有効です。まずレポートで理由を見てから、代表 URL を 3〜5 本だけ URL 検査ツールで確認してください。問題が解消した後に限定的な申請を行うのは有効です。 ただし、毎日 20 本も 30 本も手動申請する運用はやめるべきです。小規模サイトで効くのは、申請件数ではなく、robots.txt、noindex、canonical、サイトマップ、内部リンクの五点をそろえることです。 例外として、プレスリリースやイベント告知のように公開日が成果へ直結するページは、修正後に代表 URL を申請して様子を見る価値があります。
月間 PV 10 万から 100 万で、週の新規公開が 20〜100 本の場合 この規模では、単発 URL より共通設定や導線の乱れを疑うべきです。最初に見るべきはレポートの件数推移であり、URL 検査ツールを主軸に据えるべきではありません。日次のサイトマップ更新、カテゴリーからの導線整備、関連記事の文脈リンク追加を優先してください。 `Discovered - currently not indexed` が増えるなら、不要 URL の整理と内部リンクの見直しを優先し、`Crawled - currently not indexed` が増えるなら、重複整理と記事の役割分担を優先すべきです。アンカーテキストまで見直す段階なら、アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 が役立ちます。
月間 PV 100 万以上、または週の新規公開が 500 URL を超える場合 この規模では、手動申請を主軸にしてはいけません。サイトマップ運用、共通設定の監視、サーバーログ確認、正本 URL の統制が中心になります。手動申請は、障害復旧後の代表 URL 確認に限定すべきです。 `Crawled - currently not indexed` が数百 URL 単位で出ているなら、品質だけではなく URL 設計の崩れを疑ってください。大量 URL のなかに、同じ役割のページやパラメータ付き URL が混ざっていれば、まず整理が先です。 例外は、重要なキャンペーンページや法対応ページなど、事業上の優先度が極端に高いページです。その場合に限り、正本 URL を厳格に統一したうえで、代表 URL の個別確認を行います。
EC、求人、データベース型の大量 URL サイトの場合 このタイプは月間 PV だけで判断してはいけません。URL の増え方が激しいため、重要なのは「何を残し、何を増やさないか」です。色やサイズ、在庫、並び順、エリア、雇用形態などで URL が増えるなら、インデックスを早めるより先に、不要 URL を index 対象から外す設計を選ぶべきです。 私なら、同一構成の派生 URL が 10 パターンを超えた時点で、正本 URL の整理を最優先にします。ページを追加するより、クロールを食い潰す URL を減らしたほうが、主要ページは早く動きます。
このように、月間 PV 10 万未満では代表 URL の確認が効きやすく、10 万超では全体傾向の把握が優先、100 万超では個別申請を捨てる判断が必要です。自分の規模に合わない運用を続けることが、最も無駄の大きい遠回りになります。
申請ボタンを押す前に誤解を潰しておく実務整理
インデックス登録の相談では、技術不具合そのものより、先入観のほうが厄介なことがあります。焦るほど、申請が万能に見えてしまうからです。ここでは、現場で起こりがちな誤解を先に整理しておきます。
誤解1: URL 検査ツールで申請すれば掲載が早まる これは半分だけ正しく、半分は誤りです。単発 URL の再確認には役立ちますが、掲載を保証するものではありません。Google も URL 検査ツール でその点を明示しています。多数の URL が未登録のときに、申請を中心施策にしてはいけません。
誤解2: robots.txt で閉じれば検索結果にも出ない robots.txt の概要にある通り、外部からリンクされれば URL 情報だけが結果に出ることはあります。結果から除外したいなら noindex、あるいは認証制御を使うべきです。robots.txt は「見せない」ではなく「取りに来させない」に近い仕組みだと理解したほうが、実務では事故が減ります。
誤解3: noindex を外せば、すぐ登録される noindex を外しても、Google が取りに来られない状態なら変化は起きません。robots.txt で止めていないか、HTTP 200 で安定しているか、サイトマップに載っているかまで確認してください。設定変更だけで終えず、Google がその変更を観測できる状態まで整える必要があります。
誤解4: canonical は多少ずれても問題ない ここは甘く見ないほうがいいです。canonical、内部リンク、サイトマップが三方向に割れていれば、Google に「どれが本命なのか」を自分で当ててもらうことになります。急ぐ案件ほど、判断を Google に委ねる余地を減らすべきです。正本 URL は一つに決め、その URL に全ての合図を集めてください。
誤解5: JavaScript で表示されているなら Google も同じように読める これは危険な思い込みです。描画後にしか本文や見出しが出ないなら、理解も遅れます。特に公開直後のページで速度を重視するなら、本文、見出し、canonical、主要内部リンクは初期 HTML に含める設計が無難です。
誤解6: 未登録はすべて悪い状態だ これも違います。重複や代替ページが未登録であること自体は自然です。大事なのは、正本にしたい URL が登録されているかどうかです。レポートの件数だけを見て慌てるのではなく、正本ページの状態を先に確認してください。
JPSM SEO 編集事業部でも、公開後に動きが鈍い相談を受けた際、最初に見るのは申請履歴ではありません。canonical とサイトマップと内部リンクの向き先がそろっているか、そして未登録理由が一種類か複数種類かです。ここがそろうだけで、Search Console の見え方はかなり変わります。
三日で進める実務手順を具体化する工程表
最後に、実際の進め方を三日単位でまとめます。急ぎ案件ほど、作業量を増やすより順番を固定したほうが再現性は高まります。
1日目は原因を三種類までに絞る日です。 ページのインデックス登録レポートを開き、未登録理由を件数順に確認してください。理由が四つ以上に散っている場合でも、まずは件数の多い三種類だけに絞るべきです。そのうえで、各理由から代表 URL を 1〜2 本、合計 3〜5 本選び、URL 検査ツールで以下を確認します。
- 200 で返っているか
- robots.txt で止まっていないか
- noindex が残っていないか
- canonical が正本 URL を向いているか
- モバイルと描画後 HTML に本文と見出しがあるか
2日目は正本 URL の合図を一本化する日です。 技術修正を行い、canonical、内部リンク、サイトマップの向き先を同じ URL にそろえてください。`Discovered - currently not indexed` が多いならカテゴリーや関連記事から本文リンクを追加し、`Crawled - currently not indexed` が多いなら統合か大幅改稿を優先します。大量 URL 案件なら、この日に申請はしません。まずサイトマップ更新と不要 URL 整理を終えるべきです。
3日目は代表 URL だけを再確認する日です。 修正後に同じ理由が減っているかを見ます。`Discovered` が残るなら導線とサイトマップ、`Crawled` が残るなら内容差分と重複、`Blocked` が残るなら設定漏れを再点検してください。この時点で単発の重要 URL だけ申請する判断はありますが、件数を増やしても効果は伸びません。
実務では、次のチェックリストを持っておくと判断がぶれにくくなります。
- ページのインデックス登録レポートで、未登録理由を件数つきで確認したか
- 代表 URL を 3〜5 本選び、URL 検査ツールで現状を見たか
- 200 応答、robots.txt、noindex、canonical の四点を同時に見たか
- サイトマップに正本 URL が入り、`lastmod` が更新されているか
- 正本 URL へ向かう内部リンクを本文または一覧から追加したか
- `Crawled - currently not indexed` に対して、申請ではなく統合か改稿を選んだか
- 修正後は代表 URL だけ再確認し、同じ原因が他ページにも残っていないか見たか
インデックス登録を早める近道は、申請回数を増やすことではありません。Search Console で原因を分類し、正本 URL への合図をそろえ、未登録理由ごとに打ち手を変えることです。今日やるべき最初の一手は一つしかありません。URL 検査ツールを開く前に、ページのインデックス登録レポートで未登録理由の件数を確認し、代表 URL を三本だけ選んでください。