Crawlability vs Indexability、商品ページが抜ける原因はどこにあるのでしょうか？
Crawlabilityは検索ボットがURLを発見してリクエスト・レンダリングできる条件であり、Indexabilityは読み取ったページがインデックス候補として保存される条件です。ページが抜ける箇所をこの2つに分けて考える必要があります。
3行要約
Crawlabilityは検索ボットがページに到達して読み取れるか、Indexabilityは読み取ったページがインデックス候補になれるかを意味します。
サーバー・ファイアウォール・レンダリングはCrawlability、noindex・canonical・重複シグナルはIndexabilityの側で先に確認します。
既存サイトで正常URLと欠落URLを同じテンプレート同士で比較すると、個別送信を繰り返さずに原因を見つけられます。
まず何が違うのか見てみましょうか？
新しく作った商品ページや地域ページが1つや2つではなく数百件単位で検索から抜けているなら、URLを1件ずつ送信しても解決しません。共通テンプレートが検索ボットにブロックされているのか、ページは開くもののnoindexやcanonicalのためにインデックス候補から外れているのかをまず切り分ける必要があります。クローラビリティとインデクサビリティは、このような反復エラーをサイト設定レベルで説明するときに使う言葉です。
比較基準 | Crawlability | Indexability |
|---|---|---|
核心となる質問 | ボットが発見・要求・レンダリングできるか | 読み取ったページがインデックス候補になれるか |
代表的な問題 | 5xx・ブロック・レンダリング・リンク欠落 | noindex・canonical・重複・薄い本文 |
主な証拠 | サーバーログ・レスポンス・レンダリングHTML | URL検査・インデックス状態・代表URL |
確認単位 | パスとテンプレート | テンプレートと文書の役割 |
CrawlabilityとIndexabilityは、名前だけで選びません。実際の業務1件でnoindexとcanonicalを並べて記録してみると、どの段階から先に手を付けるべきかが見えてきます。担当者と再確認日まで同じ記録に残しておかないと、次の修正が推測のまま進んでしまいます。
一度うまく表示された画面だけでは、CrawlabilityやIndexabilityの成果の証拠にはなりにくいです。canonicalとテンプレートのエラー、確認日を保存したうえで、同じ条件で再現されるかを見て、はじめて実際の改善と判断します。
クロールとレンダリングをあわせて見ると
クロールとインデックスは、検索システムが1つのURLを発見して保存する処理段階です。クローラビリティとインデクサビリティは、サイトがその処理を受けられる条件を備えているかを説明する属性に近いものです。同じテンプレートの複数URLで問題が繰り返し発生するとき、この区別は開発範囲を定めるのに役立ちます。
クローラビリティには、URLの発見、サーバー応答、ログイン要件、robots.txt、内部リンクやレンダリング資源などのアクセス条件が含まれます。インデクサビリティ側にはnoindex、canonical、重複または空のコンテンツ、HTTPヘッダーのインデックス指示が置かれます。どちらもGoogleが提供する公認スコアや合格判定ではありません。
サイトで確認する対象 | クローラビリティ条件 | インデクサビリティ条件 |
|---|---|---|
サーバー・セキュリティ設定 | 正常な応答、ボットアクセス、ログイン不要の公開経路 |
|
ページテンプレート | HTML・JS・CSSへのアクセス、レンダリングされた本文とリンク | robotsメタタグ、canonical、重複状態 |
新しいURL生成ルール | 内部リンクとサイトマップで発見可能な構造 | 固有の本文と一貫した代表URLの指定 |
運用点検単位 | パス・テンプレート別のアクセス失敗率 | テンプレート別の除外シグナルと代表URLの衝突 |
いつCrawlabilityを先に確認すべきでしょうか？
同じ商品テンプレートが5xxを返していたり、特定の経路全体がrobots.txtでブロックされていたりする場合、個別の本文を修正しても状況は変わりません。JavaScriptページでは、初期HTMLだけでなく、レンダリング後に主要なテキストとリンクが残っているかも確認します。一般ユーザーと検索ボットに異なる応答を返すCDN・ファイアウォールのルールも、経路全体を遮断する可能性があります。
robots.txtをすべて開放することが目標ではありません。カートのパラメータや内部検索結果のような、検索に不要な大量URLは意図的に収集範囲を制限できます。公開コンテンツとして運用する経路を決めたうえで、新規・既存・終了状態のサンプルURLが同じ方法で開かれるかを比較します。
判断前に確認する項目
アクセス可能なテンプレートでも、レンダリングされたHTMLにnoindexが残っていたり、すべての項目が1つのURLをcanonicalとして指していたりすると、インデックス候補から外れる可能性があります。CMS画面ではインデックス許可に見えても、デプロイ済みテンプレートやHTTPヘッダーが逆の指示を出している場合もあります。新規記事、品切れ商品、ページネーション、多言語のように状態の異なるURLをまとめて確認して、例外を見つける必要があります。
インデクサビリティ条件を満たしているということは、すでにインデックスされている、またはまもなく表示されるという意味ではありません。Googleは、技術要件を満たしたページであっても、クロール、インデックス、表示を約束するものではないと案内しています。実際の状態とGoogleが選択した代表URLは、URL検査とページのインデックス登録レポートで別々に確認します。
テンプレートの不具合はどう見つけますか？
商品・地域・記事テンプレートごとに、新規URL、古いURL、品切れ・終了状態、多言語URLを選び、アクセス条件とインデックス指示を並べて記録します。1回の設定ミスがどこまで広がっているかが分かり、修正後に同じサンプルで再確認できます。一部のページだけ偶然開けている状態を、全体が解決したと誤解する可能性も減らせます。
Google AI概要とAIモードに範囲を限定する場合、参考リンク候補のページにはGoogleインデックスとスニペット表示の資格が必要です。とはいえ、この条件がAI回答での言及や出典リンクを保証するわけではありません。OpenAIはChatGPT検索用のOAI-SearchBotと、将来の学習用のGPTBotを分けて案内しているため、Google以外のサービスでは、それぞれが公開しているクローラーポリシーと実際のアクセス結果を確認する必要があります。
開発依頼に「検索に出ない」とだけ書くと、担当者は原因調査からやり直すことになります。影響を受けるテンプレート、正常・異常のサンプルURL、壊れているアクセス条件やインデックス指示をあわせて書けば、サーバー、レンダリング、CMS設定のどこを修正すべきか判断しやすくなります。
CrawlabilityとIndexabilityを並行運用する際の実際の判断
実務では、CrawlabilityとIndexabilityに関する設定を一度に変更するより、実際の業務1件を選び、URLの発見、サーバー応答、レンダリング項目を並べて記録するほうが早いです。現在の公開URLと運用記録を照合すれば、コンテンツ修正で済む案件と、システム設定が必要な案件を切り分けられます。
CrawlabilityとIndexabilityのレポートでは、noindex項目も1つの総合スコアにまとめません。検索流入が増えても回答に古い情報が残ることがあり、AIで引用されてもコンバージョンページが弱い可能性があります。関連URL・質問・確認日を保存し、同じ条件で再確認して、次の投資の根拠を残す必要があります。
参考資料
一緒に見るとよい記事
資料確認日: 2026年8月9日。クローラビリティとインデクサビリティは本記事における運用上の定義であり、実際の状態判定はGoogleの最新の公式レポートと公開されたページレスポンスを基準に行う必要があります。
既存サイトでは何から比較しますか？
正常URLと欠落URLを1つか2つ問い合わせに残していただければ、この運用方式でサーバーレスポンス、レンダリング、robots指示、canonicalと実際のインデックス状態を照合します。その結果をもとに、SEO・GEOの修正範囲をURL単位ではなくテンプレートと担当領域単位で整理します。
CrawlabilityとIndexability比較後のSearch OS運用
Search OS適用の出発点はサイト移行ではありません。CrawlabilityとIndexabilityの比較で確認するレンダリング、noindex項目を現在のWebサイト上で測定し、コンテンツ・技術・外部情報のうち詰まっている部分だけを修正します。
社内実績集計基準では、Search OSを適用した顧客企業はSEOとAI検索露出が平均88%以上増加しました。その後は、CrawlabilityとIndexabilityの比較に使用した検索とAI回答を同じ周期で再度確認します。改善した状態を基準線とし、逸脱が生じたURLを優先して修正することで、最良の露出状態が継続するよう管理します。