SEO・AIO
クロール済み未登録
— Search Consoleの原因調査を、APIだけで誤診しないために
Google Search Console（GSC）で「クロール済み - インデックス未登録」が数百・数千件と表示されると、サイトに重大な問題が起きているように見えます。私たち自身、自社サイト（netsujo.jp）でこの件数が右肩上がりに増えるのを見て、原因を取り違えたまま9日間、誤った前提で対応を進めてしまいました。
この記事は、その失敗の時系列をそのまま公開し、同じ誤診を避けるための調査手順を整理するものです。数字の大きさに驚いて対処を急ぐ前に、まず「その件数の正体は何か」を正しく掴むための実務的な進め方をお伝えします。
この記事の範囲
本記事は、GSCのインデックス状況をどう調べ、どう解釈するかという調査手順と教訓を扱います。今回の主因だったホスティング環境（Vercel Skew Protectionの?dpl=パラメータ）に対する技術的な対処の詳細は、姉妹記事Vercel Skew ProtectionとSEOに切り出しています。「そもそもサイトが検索に出てこない」という総合的な自己診断はサイトが検索に表示されないときの診断をご覧ください。
この記事の要点
「クロール済み - インデックス未登録」の件数は、記事ページの問題とは限りません。CSS・JS・faviconといったビルドアセットが、デプロイのたびに別URLとして積み上がっているだけのことが多くあります。
GSCのSearch Analytics APIは表示回数のあるURLしか返さないため、アセットURLは原理的に見えません。原因を断定する前に、GSC画面のドリルダウンCSVで実際のURL一覧を取得します。
健全性は未登録の「件数」ではなく、サイトマップ掲載ページのインデックス率で測ります。慌ててリダイレクトを剥がしたり、robots.txtで塞いだりしないことが大切です。
— 01
「クロール済み - インデックス未登録」とは何か
対処を考える前に、このステータスが示す状態を正確に押さえます。似た名前のステータスと混同すると、原因の切り分けを最初から誤ります。
検出 - インデックス未登録
GoogleがURLの存在は把握したが、まだクロール（取得）していない状態。クロール待ち、あるいは優先度が低いと判断された段階です。
クロール済み - インデックス未登録
Googleがページを取得したうえで、インデックスに登録しなかった状態。「見に来たが、検索結果に載せる価値をいまは認めなかった」という判断で、原因はページ側にも、そもそも登録が不要なURL（アセット等）にもあり得ます。
ページにリダイレクトがあります / 代替ページ
URL自体は別URLへ統合されている状態。正規化やサイト移行が正しく効いていれば、ここに入るのは想定どおりです。
重要なのは、「クロール済み - インデックス未登録」は必ずしも異常ではないという点です。そもそも検索結果に載せる必要のないURL（アセットや同一ファイルの別URLなど）がここに入っているだけの場合もあれば、公開直後のページが一時的にここを通過している場合もあります。「件数が多い＝深刻」と早合点しないことが出発点になります。
— 02
実話：APIだけを見て9日間、原因を取り違えた
自社サイトで未登録が1,342件から増え続けていたとき、私たちはGSCのAPIで取得できたURLを調べ、「サイト移行前の旧CMS時代のURL在庫が主犯だ」と結論づけました。この結論は、9日後にGSC画面のドリルダウンCSVを実際に開くまで、覆りませんでした。
| 時点 | 起きたこと | その時の解釈 |
|---|---|---|
| 2026-07-04 | ビルドアセットに noindex を付ける対処をコードへ追加（結果的に、この時点で新規発生は止まっていた）。 | 正しい対処。ただし記録がコードのコメントに残るだけで、後日の調査に引き継がれなかった。 |
| 2026-07-12 | 「クロール済み - インデックス未登録」が1,342件。APIで取得できた範囲を調べ、「旧CMS時代のURL在庫が主犯」と診断。 | ❌ 誤り。API経由で見えたURLだけを母集団と誤認していた。 |
| 2026-07-21（初版） | 再検証。しかし同じ前提のまま、初版でも旧URL在庫を主犯とする結論を踏襲。 | ❌ 誤りを9日間引き継いだ。 |
| 2026-07-21（夕方） | GSC画面から「クロール済み - インデックス未登録」のドリルダウンCSV（1,000件）を取得し、URLを一件ずつ分類。 | ⭕️ 実態が判明。旧URL在庫は0件、大半はデプロイのたびに増えるアセットURLだった。 |
皮肉なことに、この件数の主因（ドリルダウンで観測できた1,000件の実態）は、誤診が始まるより前の7月4日にすでに正しく特定され、設定ファイルのコメントとして記録されていました。にもかかわらず、その記録を読まずにAPIの結果からゼロで推測を始めたために、誤った結論が9日間引き継がれました。過去の対処記録を先に読むという当たり前の手順が、最大の教訓です。
— 03
なぜAPIだけだと原因を取り違えるのか
誤診は不注意ではなく、道具の性質から生まれました。GSCのSearch Analytics APIは、表示回数（impressions）が付いたURLしか返しません。
CSSやJavaScript、フォント、faviconといったビルドアセットのURLには、検索での表示回数が通常付きません。つまりアセットURLはAPIからは原理的に見えないのです。一方で、かつて検索に露出していた旧コンテンツURLには表示回数が残るため、APIを叩くとそれらばかりが返ってきます。
この「見える範囲だけを母集団と誤認する」バイアスが、誤診の正体でした。実際にGSC画面からドリルダウンCSV（1,000件）を取得して分類すると、内訳は次のとおりで、旧CMS時代のURLは1件も含まれていませんでした。
| URLの種類 | 件数 | 比率 |
|---|---|---|
| JSバンドル（/_next/static/chunks） | 639件 | 63.9% |
| フォント等（/_next/static/media） | 288件 | 28.8% |
| 同一faviconの別URL | 70件 | 7.0% |
| OG画像ルート | 2件 | 0.2% |
| 実際のコンテンツページ | 1件 | 0.1% |
| 旧CMS時代のURL | 0件 | 0.0% |
1,000件のうち994件が?dpl=というパラメータ付きのアセットでした。これはホスティング側の仕組み（Vercel Skew Protection）によるもので、デプロイ中に古い版と新しい版が混在してもページが壊れないよう、アセットにデプロイ単位の識別子を付ける有用な機能です。その副作用として、中身が同じアセットがデプロイのたびに新しいURLとして発行され、Googleがそれをクロールして未登録の件数に積み上がっていました。この仕組みと技術的な止め方の詳細は姉妹記事にまとめています。ここで押さえるべきは、件数の正体はコンテンツではなくアセットだったという調査結果そのものです。
— 04
正しい調査手順：ドリルダウンCSVから始める
同じ誤診を避けるための手順は、順番が決定的に重要です。「原因を断定してからURLを見る」のではなく、「URLの実物を見てから原因を絞る」向きに進めます。
- 1GSC画面でドリルダウンCSVを取得する：「ページのインデックス登録」レポートで対象の理由（例：クロール済み - インデックス未登録）の行をクリックし、開いた先の一覧をエクスポートします。これはAPIでは取得できません。まずここでURLの実物を見ます（エクスポートは最大1,000件までという上限も把握しておきます）。
- 2URLを「種類」で分類する：コンテンツページ、ビルドアセット（CSS・JS・フォント）、favicon・OG画像、旧CMSの遺物、クエリパラメータ違いなどに仕分けます。多くの場合、件数の大半はアセットやパラメータ違いで、実際のコンテンツページはごく一部です。
- 3コンテンツページだけを個別に確認する：仕分けで残った実ページについてのみ、URL検査ツールでHTTPステータス・canonical・robots・被リンクの有無を確認します。「1,437件すべてを人力で調べる」のではなく、「実害のある数件に絞る」のが要点です。
- 4過去の記録とコードのコメントを先に読む：同じ症状に過去どう対処したかは、設定ファイルのコメントやドキュメントに残っていることがあります。今回の原因は7月4日の時点でコードのコメントに正しく記録されていたのに、それを読まずにゼロから推測を始めたことが誤診の直接の引き金でした。
この順番を守るだけで、「数千件を前に途方に暮れる」状態から、「実害のある数件に集中する」状態へ切り替わります。私たちの場合、1,000件を分類した結果、追跡すべき実コンテンツページはわずか1件に絞り込め、そのURLだけを個別にインデックス登録の申請に回せました。
— 05
健全性は「件数」ではなくインデックス率で見る
「クロール済み - インデックス未登録」の総数をKPIにすると、アセットの増減に振り回されます。実態に即した指標は、次の2つです。
指標1
サイトマップ掲載ページのインデックス率
自分が検索に載せたいページ（＝サイトマップに載せたページ）が、実際にどれだけ登録されているか。ここをサンプリングしてURL検査で確認します。自社では日本語の掲載ページで約88%が登録済みで、トップ・主要サービス・ハブなどの重要ページは全件登録されていました。「載せたいページが未登録」という最悪の状態は起きていなかった、という判断ができます。
指標2
実際に失っている検索露出
未登録扱いのURLのうち、過去に表示回数があった（＝検索露出への影響が疑われる）ものだけを数えます。自社では該当が42件・表示回数にしてサイト全体の約0.63%でした。1,437件という数字の心理的なインパクトに対し、露出ベースの影響候補は1%未満だった、と定量的に言えます。
この2つで測ると、「件数は多いが、実害はほぼない」といった状況を落ち着いて評価できます。逆に、サイトマップ掲載ページのインデックス率が低い場合は、件数の多寡にかかわらず優先して調べるべきサインです。なお、ここで挙げた数値はいずれも自社サイトでの実測値であり、サイトの規模や構成によって水準は変わります。
— 06
やってはいけない、早まった対処
件数を早く減らしたい一心で打つ手が、かえって状況を悪くすることがあります。原因の切り分けが済むまで、次の3つは避けてください。
旧URLのリダイレクトを剥がす
サイト移行後の旧URLは、301／308リダイレクトで新URLへ向けたまま維持します。リダイレクトは「ここへ移った」というシグナルで、404やブロックに変えるとそのシグナルと評価の引き継ぎを失います。件数を消したいという理由で剥がすと逆効果です。
robots.txtで一括ブロックする
robotsでブロックするとGoogleはページ本体を取得できず、noindexの指示すら読めなくなります。登録不要なアセットには、robotsブロックではなくレスポンスヘッダーのnoindex（X-Robots-Tag）を使う方が安全です。noindexはレンダリングに必要な取得までは妨げません。
「そのうち減る」と決めつけて放置する
逆に、無条件に「時間が経てば自然に減る」と考えるのも危険です。原因が「増え続ける発生源」にある場合、放置しても減りません。減衰を見込めるのは、発生源をすでに止められていることを確認できたときだけです。まず出血が止まっているかを実測で確かめます。
共通するのは、原因を掴む前に対症療法を打たないという原則です。ドリルダウンCSVで正体を確認し、発生源が止まっているかを実測してから、必要な手当てだけを行います。
— 07
よくあるご質問
「検出 - インデックス未登録」と「クロール済み - インデックス未登録」は何が違いますか。
「検出」はGoogleがURLの存在を知ったがまだ取得していない段階、「クロール済み」は取得したうえで登録を見送った段階です。新しく公開したページは「検出」から「クロール済み」を経てから登録されることが多く、公開直後に一時的に「クロール済み - インデックス未登録」へ入るのは珍しくありません。慌てて対処する前に、そのURLが実際のコンテンツページなのか、登録の必要がないアセット等なのかを先に切り分けます。
なぜAPIだけで原因を調べると誤診するのですか。
Search ConsoleのSearch Analytics APIは、表示回数（impressions）が付いたURLしか返しません。CSSやJS、faviconといったビルドアセットのURLには通常impressionsが付かないため、APIからは原理的に見えません。API経由で見えるのは表示回数のある旧コンテンツURLなどに偏るため、それを母集団と誤認すると「旧URLが主犯」という誤った結論に至りやすくなります。原因を断定する前に、GSC画面のドリルダウンCSVで実際のURL一覧を確認してください。
未登録の件数が数千件あります。順位や流入への影響は大きいですか。
件数の大きさと実害は必ずしも一致しません。自社サイトでは1,437件の未登録のうち、実際のコンテンツページはドリルダウン1,000件中1件で、残りはデプロイのたびに別URLとして増えるアセットが大半でした。健全性は未登録「件数」ではなく、サイトマップに載せているページのインデックス率と、表示回数のある未登録URL（＝実際に検索露出を失っているページ）の数で測ります。
未登録URLが多いので、robots.txtで一括ブロックしてよいですか。
おすすめしません。robots.txtでブロックするとGoogleはページ本体を取得できなくなり、noindexの指示も読めなくなります。登録させたくないアセット等には、robotsでのブロックではなく、レスポンスヘッダーのnoindex（X-Robots-Tag）を使う方が安全です。noindexはページのレンダリングに必要な取得までは妨げないためです。旧URLについては後述のとおり、404やブロックへ変えるとかえって不利になる場合があります。
サイトを移行した後の旧URLはどう扱えばよいですか。
恒久的に移した旧URLは、301／308リダイレクトで新URLへ向けたまま維持するのが基本です。リダイレクトは「このURLはここへ移りました」というシグナルで、404やrobotsブロックに変えると、そのシグナルと統合先への評価の引き継ぎを失います。未登録の件数を早く減らしたいという理由でリダイレクトを剥がすと逆効果になりやすいため、GSCで減衰を観測しながら待つ判断が無難です。
公開したページが「クロール済み - インデックス未登録」から動きません。何を疑えばよいですか。
HTTPステータスが200であること、canonicalが自己参照であること、noindexが付いていないこと、サイトマップに載っていること、内部リンクがあることをまず確認します。技術的な条件をすべて満たしているのに登録されない場合は、内容の独自性・重複・被リンクの質など、コンテンツ側を疑う段階に移ります。数日単位の増減ではなく、1〜2週間の変化で判断します。
この記事の著者
飯田 友広
代表取締役
Netsujo株式会社 代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。京都ビッグデータ活用プラットフォーム参画(小規模企業会員・ベンチャー)、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」参画(2026-03-10)、IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」を京都府庁旧議場で開催(2026-07-02・Netsujoとして主催、企画・登壇・運営／京都府デジタル政策推進課は共催)。京都美術工芸大学での講義・龍谷大学でのセミナー実績、ITコミュニティ「みやこでIT」(connpassメンバー609名・イベント162回以上・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。ソーシャル企業認証「S認証」認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。
プロフィールを見るこの記事が向いている方
GSCで「クロール済み - インデックス未登録」が増え、原因の切り分け方を知りたい方
未登録の件数の大きさに対して、実害の有無を落ち着いて評価したいBtoB企業のWeb担当者
サイト移行後のインデックス状況を、正しい手順で確認したい方
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. うちの未登録件数は、放置してよいものか対処すべきか判断できません。
ドリルダウンCSVの分類と、サイトマップ掲載ページのインデックス率・失っている検索露出の2指標で、実害の有無を一緒に切り分けます。
Q. サイト移行後に未登録が増えました。旧URLをどう扱えばよいですか。
リダイレクトの維持・robotsブロックの回避・減衰観測の考え方を、貴社の移行状況に合わせて整理します。
Q. 公開したページが登録されません。技術と内容のどちらを疑うべきですか。
HTTP・canonical・robots・サイトマップ・内部リンクの技術条件を先に確認し、満たしていれば内容側の検討へ移ります。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
Web営業基盤｜Netsujo SIGNAL
まず無料で、貴社サイトの現状を確認する
無料Web営業基盤診断では、5領域の参考評価・無料Web診断レポート・根拠付きの最優先課題3件をお渡しします。GA4・Search Consoleの共有は不要です。検索順位やAI回答への掲載を保証するものではありません。