Search Console で「インデックス未登録」が増えた時、先に疑うべきは Google の気分ではありません。確認すべきなのは実装の整合性です。公開後一週間たっても検索結果に出てこない、記事を二十本出したのに半分以上が入らない、刷新後に主要ページだけ急に未登録へ傾いた。この場面で登録リクエストを繰り返す運用は、ほぼ例外なく遠回りになります。
結論は明確です。未登録が続くなら、最初にやるべきことは登録依頼ではなく、`200` 応答、`301` の統一、`canonical`、`noindex`、内部リンク、サイトマップ、初期 HTML の七項目確認です。月間 PV 十万未満のサイトなら本文改善より発見経路の補強を優先し、月間 PV 十万以上で共通ひな型が複数あるなら、個別ページより共通部の不整合を先に潰すべきでしょう。
Google も クロールとインデックス登録の基本 と インデックス登録の考え方 の中で、URL の発見、取得、理解、正規化という流れでページを扱っています。実務では、この流れを確認手順に落とし込めるかどうかで、対応速度が決まります。JPSM SEO 編集事業部でも、未登録の相談を受けた時にいきなり順位要因へ飛ぶことはありません。まずは「Googlebot が何を受け取っているか」を一枚の表に整理し、原因を実装で説明できる状態まで持っていきます。
未登録が出た日に再登録依頼を急がない理由
Search Console の未登録対応で、登録リクエストを最初の手段に選ぶべきではありません。 理由は単純で、登録リクエストは原因を直す操作ではないからです。URL 検査ツール も、あくまでクロールの再確認を促す機能であり、インデックス可否を上書きする道具ではありません。`noindex` が残っている URL、正規 URL が割れている URL、本文が実質重複している URL に登録依頼を送っても、結果はほとんど変わりません。
ここで重要なのは、Search Console のラベルを感覚で読まないことです。未登録理由は、そのまま対処法を示しているのではなく、止まっている工程を見分ける手がかりです。次の表のように読み替えると、初動を誤りにくくなります。
Search Console の見え方 | 実務での意味 | 最初に疑うべきもの | 先にやるべきこと |
|---|---|---|---|
検出されたが未登録 | URL は知られているが優先度が低い | 内部リンク不足、サイトマップ反映遅延、孤立ページ | 通常導線から 3 本以上リンクし、サイトマップへ即時反映する |
クロール済みだが未登録 | 取得はされたが登録価値が弱い | 重複、本文不足、量産ページ、描画差分 | 類似ページを統合し、固有情報を増やす |
代替ページ、重複 | 別 URL が正規と見なされている | `canonical`、内部リンク先、サイトマップ URL の不一致 | 正規 URL を 1 本に揃える |
送信された URL に `noindex` | 出したい URL 自身に除外指示がある | ひな型の条件分岐、公開切替漏れ | HTML とヘッダーの両方で `noindex` を外す |
この表で分かる通り、未登録を一律に「再クロール不足」と解釈するのは誤りです。特に `検出されたが未登録` と `クロール済みだが未登録` は、打つべき手が正反対になりやすい。前者は発見経路、後者はページ品質と重複処理です。ここを混ぜると、修正しているつもりでも前へ進みません。
例外もあります。たとえば障害修正がすでに完了しており、`200`、`canonical`、`noindex`、内部リンク、サイトマップがすべて整っている主要 LP であれば、登録依頼を一回だけ使う価値はあります。ただしそれは修正後の確認手段であって、初動ではありません。
最初の三十分で固める実装確認七項目の順番
未登録対応で最初に固めるべきなのは、本文の書き換えではなく土台です。三十分で見るべき順番は、`HTTP`、リダイレクト、`canonical`、`noindex`、内部リンク、サイトマップ、初期 HTML の七項目。この順番を飛ばすと、たまたま直ったように見えても再発します。
私が現場で使う確認順は次の通りです。
- 対象 URL が本当に `200` を返しているか
`404` を返すべき URL が `200` になっていれば soft 404 の候補になりますし、`503` が断続的に出ていれば安定して取りに来てもらえません。
- `http` / `https`、`www` 有無、末尾スラッシュ有無が一回の `301` で正規 URL に着地するか
二回以上のリダイレクトや、一部だけ `302` が混ざる構成は避けるべきです。主要ページでこれが十件以上あるなら、個別修正ではなく共通ひな型か配信設定を直してください。
- `rel="canonical"` が自己参照、または意図した代表 URL を指しているか
重複した URL の正規化 と 重複 URL の統合 で示されている通り、`canonical` は単独では機能しません。内部リンク、サイトマップ、リダイレクト先まで同じ URL に揃って初めて効きます。
- 初期 HTML とレスポンスヘッダーに `noindex` が残っていないか
検索インデックスから除外する方法 を逆に読むと、出したいページに `noindex` がある限り、登録は進みません。公開直後に外したつもりでも、共通ひな型の条件分岐で残っていることは珍しくないはずです。
- 通常導線から最低三本の内部リンクが張られているか
トップ、カテゴリ、関連記事の三系統が理想です。パンくずだけ、あるいはサイトマップだけでは弱い。関連する設計は 内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 もあわせて確認してください。
- サイトマップに正規 URL だけが載り、公開後二十四時間以内に反映されているか
サイトマップの概要 と サイトマップの作成と送信 を読むと分かる通り、サイトマップは保証ではありません。ただし、反映が遅いサイトは未登録が長引きやすい。更新バッチが一日一回未満なら見直す必要があります。
- JavaScript を切っても、H1、導入、本文の骨格が読めるか
JavaScript SEO の基本 は、検索上重要な情報を取得できる状態にしておくべきだと整理しています。検索流入を取りにいくページで、初期 HTML に本文がほぼない構成は避けるべきです。
確認手段も使い分けが必要です。次の表だけ押さえておけば、初動の迷いはかなり減ります。
確認手段 | 向いている場面 | 強み | 弱み |
|---|---|---|---|
URL 検査ツール | 重要 URL を今すぐ切り分けたい時 | 現時点の取得状況、正規 URL 認識、ライブ確認ができる | 一覧性は弱い |
ページのインデックス登録レポート | 問題が一部か全体かを見たい時 | ひな型単位の傾向をつかみやすい | 個別 HTML の差分までは追いにくい |
サーバーログ | 大規模運用や再現しない障害 | Googlebot の実際の取得履歴が分かる | 見られる体制がないと遅い |
最初の三十分は URL 検査ツールと実ページ確認、その後にレポート、最後にログ。この順番を崩す理由はほとんどありません。例外は、月間 PV 百万以上で CDN や WAF の一時遮断が疑われる時だけです。その場合は最初からログを見るべきでしょう。
検出されたが未登録で止まる時の実務対処順序
`検出されたが未登録` が続く時は、本文改善より先に発見経路を強くするべきです。このラベルは、URL を知ってはいるが優先して取りに来ていない場面でよく出ます。小規模から中規模のサイトでは、品質論より前に「重要ページが孤立している」ことのほうがはるかに多い。
判断基準は曖昧にしないほうがいいでしょう。私は次の三条件に一つでも当てはまれば、発見経路の問題として扱います。
- 公開後七日たっても、通常導線からの内部リンクが二本以下
- サイトマップ反映が公開から二十四時間以上遅れる
- 対象 URL までトップから四クリック以上かかる
この状態なら、登録依頼より先に内部リンクを足してください。最低でもカテゴリーページ、関連記事、パンくずの三系統でつなぐことを勧めます。特に月間 PV 十万未満のサイトでは、三本未満の内部リンクしかない新規記事は、本文が良くても検出止まりになりやすい。逆に、公開当日から通常導線で三本以上つながっている記事は、三日から十日で再取得されることが多くなります。
内部リンクを足す時は、数だけで満足しないことが重要です。`/article/abc/`、`/article/abc`、パラメータ付き URL が混ざっていれば、発見経路は増えても正規 URL の信号は弱まります。リンク先 URL を統一し、その考え方は アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 でも確認してください。
サイトマップの扱いにも基準が必要です。載せるべきなのは `canonical` と一致する URL だけです。HTTP 版、末尾スラッシュ違い、検索結果ページ、会員専用ページまで混ぜる運用は避けるべきでしょう。大規模サイトでは「全部載せるほど安心」という発想がよく失敗します。重要 URL が埋もれるからです。
ここでの例外は二つあります。ひとつは大手ニュースサイトのようにトップ露出が極端に強いケース。もうひとつは外部から恒常的にリンクされる公的資料ページです。この二つは内部リンクが少なくても発見されやすい。ただし、一般的な事業サイトやメディアでその条件を満たすことは多くありません。
Search Console を使った再クロール促進の考え方は、Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切る にもまとめています。未登録対応でも、まず道具の使い方より導線設計を整えるほうが再現性は高まります。
クロール済み未登録で疑う重複と本文不足の順番
`クロール済みだが未登録` は、より厳しく見るべきラベルです。Googlebot は一度取りに来ています。そのうえで登録されていないなら、まず重複、次に本文の独自性不足を疑うべきです。ここで「一五〇〇文字あるから大丈夫」と考えるのは危険でしょう。文字数があっても、見出し構成と結論が似通っていれば、実務では重複群として扱われやすくなります。
私が統合を勧める基準は、次の三つです。
- 同じ検索意図を狙う記事が五本以上あり、見出し構成が七割以上似ている
- 一ページあたりの固有情報が四百文字未満で、差分が地名や商品名の置換に留まる
- 一覧ページや比較ページで、並び順だけ違う URL が三本以上ある
この条件に当てはまるなら、似たページを増やすのではなく、代表ページを一本深くするべきです。たとえば「地域名だけ差し替えたサービスページ」が二十本あるより、比較表、費用、導入条件、例外条件をまとめた代表ページが一本あるほうが、登録も評価も安定します。
逆に、次の条件なら分割掲載を維持する価値があります。
分けて残すべきケース | 統合すべきケース |
|---|---|
価格、在庫、法規制、手続きが地域ごとに実質的に違う | 見出しだけ同じで本文差分が少ない |
事例、FAQ、対象条件がページごとに明確に異なる | 導入文と箇条書きだけが違う |
店舗・拠点・商品ごとに固有データがあり、検索意図も分かれる | 並び順やタグだけ違う一覧 URL |
本文の独自性も数値で見たほうがぶれません。私は、検索流入を狙うページなら冒頭六百文字の中に、その URL だけの判断材料が二つ以上入っているかを必ず見ます。具体例、比較条件、料金差、運用条件、手順の順番、失敗例のどれかが二つ以上ないなら、本文が薄い可能性が高い。反対に八百文字台でも、判断基準が明確で、他ページと役割が分かれていれば入ることはあります。
Google の考え方は 有用で信頼できるコンテンツの作成 にも通じますが、未登録対応で大事なのは抽象論ではありません。「何が違うのかを一読で説明できないページは、統合する」。このくらい強く決めたほうが、量産ページの膨張を止められます。
例外は、EC の商品詳細、店舗情報、求人票のように、共通ひな型は似ていても固有データが明確に違うページです。この場合は統合ではなく、独自情報の追記を優先します。レビュー、仕様差、対応範囲、配送条件など、検索意図に直結する情報を追加してください。
JavaScript依存ページで先に直す実装箇所
JavaScript を使っていること自体は問題ではありません。問題なのは、検索上必要な情報まで後段描画に寄せていることです。検索流入を取りに行くページで、H1、導入文、`canonical`、`robots`、本文骨格が初期 HTML にない構成は避けるべきです。JavaScript SEO の基本 と モバイル ファースト インデックスの考え方 を合わせて読むと、その判断はかなり明確になります。
次の条件に一つでも当てはまるなら、実装を戻す判断を勧めます。
- JavaScript を切った状態で本文テキストが三百文字未満
- スマートフォン版の本文量が PC 版の七割未満
- タブを開く、ボタンを押すなどの操作をしないと主本文が出ない
- `canonical` や `meta robots` がクライアント側でしか確定しない
この場合、最適化より再設計が先です。API 応答を速くする、画像を軽くするといった改善も大切ですが、本文が初期 HTML にないなら優先順位はそこではありません。まずサーバー側で主内容を返す構成へ寄せるべきでしょう。
特に刷新案件で多いのが、PC では十分な情報量があるのに、モバイルで要約だけに削ってしまう設計です。見た目は整いますが、検索側には「情報が少ないページ」と映りやすい。比較 LP、FAQ、導入事例でこの削り方をすると、未登録や流入停滞の温床になります。
`robots.txt` の扱いにも注意が必要です。robots.txt の概要 と robots.txt ファイルの作成方法 が示す通り、`robots.txt` は主にクロール制御です。検索に出したい URL を `robots.txt` で塞ぎ、同時に `noindex` も付ける設計は避けるべきです。Googlebot が `noindex` を読めないからです。
例外はあります。ログイン後ページ、見積り結果ページ、操作用ダッシュボードなど、そもそも検索に出すべきでないページなら、JavaScript 中心でも問題になりません。ここで述べているのは、あくまで自然検索を取りに行く記事、カテゴリ、サービス、事例ページの話です。
サイト規模ごとに変える未登録対応の優先順
未登録対応は、どのサイトでも同じ順番で深掘りすればよいわけではありません。規模と構成によって、最初に見る場所を変えるべきです。ここを誤ると、一週間で終わる修正が一か月仕事になります。
次のように切り分けると、着手順を決めやすくなります。
- 月間 PV 十万未満で URL 数が五千未満なら、内部リンクとサイトマップを最優先にしてください。ログ解析より、孤立ページの解消のほうが効きます。
- 月間 PV 十万から百万で共通ひな型が三種類以上あるなら、`canonical`、`noindex`、モバイル差分の監査を先に行うべきです。この帯では、個別記事の出来より共通部の不整合が未登録を増やします。
- 月間 PV 百万以上、または URL 数が五万を超えるなら、サーバーログ、CDN、WAF、キャッシュ設定の監視を最優先にしてください。大規模運用では一ページずつ追うより、群で異常を見るほうが早くなります。
- WordPress や一般的な CMS が中心なら、SEO 系プラグインの `canonical` と `noindex` の競合を先に棚卸しするのが妥当です。設定衝突は想像以上に多く、テーマ改修より短時間で改善できます。
- Next.js や Nuxt のように SSR と CSR が混在する構成なら、初期 HTML と描画後の差分確認を先にやるべきです。見た目が同じでも、取得できる本文量が違うことがあります。
- Headless CMS と CDN 配信を組み合わせているなら、最終レスポンスを返す層を特定し、ヘッダーとキャッシュルールを監査してください。CMS で正しくても、配信段で壊れているケースは少なくありません。
この切り分けがあるだけで、会議の質も変わります。「原因はたぶん品質です」で終わらず、「この規模なら内部リンクを先に直す」「この構成なら初期 HTML を先に見る」と言い切れるからです。未登録は曖昧な SEO 相談として扱うより、重要ページ群の公開品質に関わる障害として扱ったほうが、技術組織では前に進みやすくなります。
JPSM SEO 編集事業部でも、相談時にまず聞くのは検索順位ではなく、月間 PV、URL 数、ひな型の数、配信構成です。この四点が分かれば、かなり高い確率で「最初の一手」を外さずに済みます。
誤対応を止める公開前後の実務確認チェック表
未登録対応は、正しい打ち手を増やすより、間違った手順を止めることのほうが先です。現場でよく見る誤対応と、採るべき対応を整理します。
やってはいけないこと | なぜ悪いか | 取るべき対応 |
|---|---|---|
登録リクエストを毎日送る | 原因が残ったままでは結果が変わらない | 修正差分が出た時だけ一回使う |
`robots.txt` で止めれば検索結果から消えると考える | 非表示の仕組みではない | 非表示が目的なら `noindex` または認証を使う |
`canonical` だけ直して内部リンクとサイトマップを放置する | 正規 URL の信号が割れる | リンク、サイトマップ、リダイレクト先まで揃える |
スマホ版だけ本文を短くする | モバイル基準で情報不足になりやすい | 主内容は PC と同等に保つ |
似た量産ページを増やす | 重複群として扱われやすい | 代表ページへ統合し、固有情報を厚くする |
ブラウザ表示が正常なら問題ないと思い込む | Googlebot が同じものを見ているとは限らない | URL 検査ツールと初期 HTML を両方確認する |
公開前後の確認は、次の八項目を最低ラインにすると安定します。
- 対象 URL が `200` を返し、正規 URL 以外は一回の `301` で統一されている
- `canonical` が自己参照、または意図した代表 URL を指している
- 初期 HTML とヘッダーの両方に不要な `noindex` がない
- 通常導線から最低三本の内部リンクが張られている
- サイトマップに `canonical` と一致する URL だけが載っている
- JavaScript を切っても H1、導入、本文骨格が読める
- Search Console の URL 検査ツールでライブ確認をしている
- 公開後三日、七日、十四日でインデックス状態の変化を記録している
この八項目が曖昧なまま順位改善やリライトへ進むのは、順番が逆です。未登録は検索評価の議論というより、公開品質の不備が Search Console に表れている状態だと考えてください。
明日から三営業日で着手する改善作業の進め方
未登録対応は、勢いで動くより順番を固定したほうが成果につながります。三営業日で着手するなら、次の進め方を勧めます。
- 一日目は、重要 URL を十本選んでください。
売上に近いページ、問い合わせに近いページ、公開後に未登録が続く新規ページを優先し、`200`、`301`、`canonical`、`noindex`、内部リンク本数、サイトマップ掲載、初期 HTML の七項目を表にします。十本中二本以上で同じ不整合が出るなら、個別修正ではなく共通ひな型の修正へ切り替えるべきです。
- 二日目は、発見経路か重複かを切り分けてください。
`検出されたが未登録` が多いなら、カテゴリ、関連記事、パンくずの三系統で内部リンクを補強し、サイトマップ反映を当日中に揃えます。`クロール済みだが未登録` が多いなら、類似ページ群を洗い出し、一本化する URL と残す URL を決めます。
- 三日目は、Search Console で差分を確認し、修正ログを残してください。
ページのインデックス登録レポート と URL 検査ツール を見直し、「どの修正で何が変わったか」を記録します。記録が残らない運用では、次回も同じ場所で詰まります。
Search Console で未登録が続く時に必要なのは、焦って押すことではなく、Googlebot が登録しない理由を実装で説明できる状態に戻すことです。`HTTP`、`canonical`、`noindex`、内部リンク、サイトマップ、初期 HTML、本文の独自性。この順番で見れば、少なくとも「何を直せばいいか分からない」という状態からは抜け出せます。
今日やるべきことは一つです。未登録が多いディレクトリから重要 URL を十本抜き出し、七項目の確認表を作ること。表が埋まれば、登録依頼を送る前に直すべき箇所が、ほぼ自動的に見えてきます。