AIが自社サイトを読めない？クロール設定とインデックスの確認方法

記事を公開しているのに、AI検索で自社が紹介されない。「サイトの設定が悪くて、内容を読んでもらえていないのでは」と気になっていませんか。文章を直す前に、ページを取得できる状態か確かめると、取り組むべき場所を整理できます。

ただし、AIの回答に出ないことだけで、読み取りの失敗とは判断できません。ページを取得できること、検索の対象として登録されること、回答の参考として選ばれることは、それぞれ違う段階です。

この記事では、Google検索を中心に、クロール設定とインデックスを確認する手順を解説します。サイトの担当者が自分で確認できる範囲と、制作会社やサーバー管理者に調査を頼む範囲を分け、原因を一つずつ絞り込んでいきましょう。

まず「読めない」と「選ばれない」を分けて考える

クロール、インデックス、掲載は別の段階

クロールとは、検索エンジンなどのプログラムがウェブページを取得することです。取得するためのプログラムはクローラーと呼ばれます。インデックスは、取得した情報を検索に使えるよう登録する仕組みだと考えると分かりやすくなります。

お店に例えるなら、案内を受け取れる状態にすることと、その内容が案内帳に載ることは別です。さらに、ある相談への回答でその店を紹介するかどうかも、別の判断になります。

そのため、ページを公開しただけで必ず検索に登録されるわけではなく、登録されたページが必ずAI回答に引用されるわけでもありません。どの段階を確認しているのかを意識すると、不要な設定変更を避けやすくなります。

自分のブラウザーで見えることは、確認の出発点

自分のパソコンで正常に表示されても、ログイン済みだから読めている場合があります。公開ページを調べる際は、いったんログアウトするか、シークレットウィンドウなどで開いてみてください。

本文が見えるか、ログイン画面や認証画面に移動しないか、別のページへ転送されないかを確認します。ただし、この確認でクローラーからも必ず取得できると証明できるわけではありません。

人の閲覧と自動取得では、アクセス元や処理の方法が異なります。ブラウザーでの確認は最初の点検とし、次に検索エンジン側の検査結果を見ていくのがよい順番です。

サイト全体ではなく、調べたいURLを決める

「自社サイトが出ない」という相談だけでは、トップページの話なのか、新しい記事の話なのかが分かりません。調査を始める前に、読んでもらいたいページのURLを一つ選びましょう。

そのページを公開した日、最後に大きく変更した日、期待している検索サービスも記録します。同じサイトでも、公開直後の記事と長く運用している会社概要では、調べる手がかりが違います。

Search Consoleで、登録状況と現在の取得状態を見る

URL検査では、まず保存されている状態を読む

Google Search Consoleは、自社サイトの検索に関する状態を確認するためのツールです。対象サイトへアクセスできる権限を用意し、URL検査に調べたいページのURLを入力します。

最初に表示される情報では、Googleが把握している登録状況などを確認できます。結果だけでなく、取得に関する情報や最終クロール日時も見て、いつの状態を確認しているのかを押さえましょう。

操作方法はGoogleのURL検査ツールの説明で確認できます。画面の表示名が変わった場合は、公式の案内を参照しながら進めてください。

公開URLテストは、今のページを調べるために使う

ページを修正した後は、公開URLテストで現在の取得状態を調べます。保存されている情報と、今の公開ページの状態が違うことはあるため、二つの結果を混同しないようにします。

たとえば、昨日まで登録を止める設定が入っていて、今日解除した場合、保存済みの情報には以前の状態が残っているかもしれません。確認日時を付けて両方の結果を記録すると、変化を追いやすくなります。

なお、公開URLテストが良好でも、登録や検索への掲載が保証されるわけではありません。すべての登録条件をその場で検証するものではなく、現在取得できるかなどを調べるための手がかりです。

一件の問題か、共通設定の問題かを切り分ける

対象ページだけに問題があるのか、同じ種類のページにも起きているのかを確認します。記事だけ、商品ページだけ、最近公開したページだけといった共通点があれば、調べる範囲を絞れます。

いきなり全ページを検査する必要はありません。問題のあるページ、同じ構成で正常なページ、トップページなど、役割の違う数件を比べると、共通の設定か個別の設定かを考えやすくなります。

検査結果を担当者へ渡すときは、良好なページの例も添えてください。「何が違うか」を比べられると、原因を探す作業が進みやすくなります。

robots.txtとnoindexは、違う役割の設定

robots.txtは、取得してよい場所を伝える

robots.txtは、クローラーに対してアクセスしてよい範囲などを伝えるファイルです。特定のフォルダーやクローラーに対する制限が、読んでほしいページにもかかっていないかを確認します。

ここで注意したいのは、取得を制限することと、検索結果から確実に除外することが同じではない点です。Googleでは、取得できなくても、他のページからのリンクなどによってURLが検索結果に現れる場合があります。

基本はrobots.txtの公式説明を参照してください。公開ページの取得を妨げていないかを調べつつ、理由のある制限まで一括で削除しないことが大切です。

noindexは、検索への登録を止めるための指示

noindexは、そのページを検索結果に表示しないよう伝える指示です。HTML内の設定や、サーバーが返すHTTPヘッダーに含まれる場合があり、見た目の本文だけでは分からないことがあります。

制作中の設定が公開後も残っていたり、ページ単位の設定を誤って引き継いだりしていないかを確認しましょう。反対に、検索に出さない目的で設定されているページなら、解除する必要はありません。

Googleにnoindexを認識してもらうには、その指示を取得できる状態が必要です。robots.txtで取得を止めると、noindexを読み取れない場合があります。詳細はnoindexによる登録制御の説明で確認できます。

非公開情報を守る仕組みと混同しない

robots.txtやnoindexは、顧客情報や社内資料を安全に保管するための認証機能ではありません。URLを知っている人が開ける状態なら、検索結果に出ないだけで内容が守られるとは考えないでください。

調査の対象は、外部へ公開したいページに絞ります。会員専用ページや管理画面など、ログインが必要な場所は、検索対策のためにその制限を外す対象にはしません。

公開したいページの障害を取り除くことと、サイト全体の制限を解除することは別です。変更の目的と対象URLを明確にしてから作業しましょう。

登録されない理由は、表示された状態ごとに調べる

「検出」と「クロール済み」では確認する段階が違う

Search Consoleには、ページを見つけているがまだ取得していない状態や、取得したが登録していない状態が表示されることがあります。どちらも検索に出ていないとしても、同じ原因とは限りません。

「検出」はURLの存在を把握している段階、「クロール済み」は取得まで進んだ段階です。詳しい意味はページのインデックス登録レポートの公式説明と照らし合わせて確認してください。

未登録という表示だけで「文章が短いから」「AIで作ったから」と原因を断定しないようにします。取得の状態、重複、ページの役割、本文の内容など、確認できる事実を順番に整理します。

別のURLが代表として選ばれている場合がある

同じ内容へ複数のURLからアクセスできるサイトでは、検索エンジンが代表となるURLを選ぶことがあります。調べているURLが登録されていなくても、別のURLが代表として扱われている可能性があります。

canonicalという設定は、どのURLを代表として扱ってほしいかを伝える方法の一つです。意図せず別の記事やトップページを指定していないか、移転前のURLが残っていないかを確認します。

設定は希望を伝えるものであり、Googleが必ずその通りに選ぶとは限りません。仕組みは正規URLの指定に関する公式ガイドを参照し、必要に応じて制作担当者へ確認を依頼しましょう。

すべての未登録ページを登録させようとしない

サイト内には、内容が重複するページ、終了した企画、検索結果に出す必要のないページもあります。未登録の件数だけをゼロにしようとすると、本来の目的から離れてしまいます。

優先したいのは、見込み客に読んでほしいサービス案内、会社情報、独自の解説記事などです。そのページが検索へ出る必要があるかを決めたうえで、対応する理由を整理してください。

数値の見た目より、重要なページがどの状態にあるかを見ます。担当者同士で優先するURLを共有すると、不要なページの調査に時間を使いすぎずに済みます。

サーバーの応答と、本文の見え方も確認する

アクセス拒否やサーバーエラーを調べる

ページへのアクセスに対して、サーバーは処理結果を示す番号を返します。代表的なものに、アクセス拒否を示す403、見つからないことを示す404、サーバー側の問題を示す5xxなどがあります。

人には表示できても、特定の自動アクセスだけを防御機能が止めている場合があります。CDNやWAFと呼ばれる配信・防御の仕組み、サーバー設定、アクセス記録を管理者へ確認してもらいましょう。

番号の意味はGoogleのHTTPステータスコードに関する説明で確認できます。エラー画面が出た日時とURLを残すと、該当する記録を探しやすくなります。

防御機能は全停止せず、拒否の理由を確認する

取得を許可したいからといって、防御機能を全部止める必要はありません。まず、どのルールが、どのアクセスを、なぜ拒否したのかを管理者と確認します。

アクセス時の名乗りだけで正規のクローラーだと判断せず、提供元が公開している確認方法に沿って調査してもらいます。単にそれらしい名前が記録されているだけでは、判断材料として十分でないことがあります。

変更が必要なら、対象と理由を絞り、作業後に通常の閲覧や問い合わせフォームへ影響がないかも確かめます。検索のための修正と、サイトを安定して運用する確認を一緒に進めましょう。

JavaScriptで表示する本文が、取得結果にもあるかを見る

ページによっては、JavaScriptという仕組みで後から本文を表示します。GoogleはJavaScriptを処理できますが、必要なファイルの取得や実行がうまくいかなければ、期待した内容を確認できない場合があります。

「JavaScriptを使っているから読めない」と決めつける必要はありません。検査結果のHTMLや表示内容を見て、商品説明や料金などの重要な情報が確認できるかを調べます。

詳細はJavaScriptと検索に関する公式ガイドを参照してください。他のAIサービスもGoogleと同じように処理できるとは限らないため、対象サービスごとの確認が必要です。

ページを見つけてもらう経路を整える

重要なページへ、関連する本文からリンクする

公開したページがサイト内のどこからも案内されていないと、人も目的の情報へたどり着きにくくなります。関連するサービスページや記事から、必要な人が自然に進めるリンクを用意しましょう。

リンクの文字は、「詳しくはこちら」だけでなく、移動先の内容が分かる表現にします。たとえば「導入前に確認する利用条件」のように書けば、何が読めるのかを伝えられます。

Googleが読み取れるリンクの基本は、リンクに関する公式ガイドにまとまっています。見た目がボタンでも、実際に移動先へ進める構造かは制作担当者と確認してください。

サイトマップはURLを知らせる補助として使う

XMLサイトマップは、サイトにあるページなどを検索エンジンへ知らせるためのファイルです。重要なページが含まれているか、古いURLや不要なURLばかりになっていないかを確認します。

ただし、送信すれば必ずクロールや登録が行われるわけではありません。サイトマップは発見を助ける手段であり、取得制限や本文の問題を解消する機能ではないからです。

役割はサイトマップの公式説明で確認できます。WordPressなどで自動生成している場合も、公開ページのURLが正しく反映されているかは点検しましょう。

URLを変えた後は、古い案内も見直す

記事のURLを変更した後、メニューや関連記事のリンクが古いまま残ることがあります。外部へ送った資料や社内の案内も含めて、よく使う入口から正しいページへ進めるか確認してください。

転送がある場合も、最終的にどこへ着くのかを確かめます。似た名前の別ページや、内容のないページに移動していると、利用者も意図した情報を読めません。

調査を頼むときは、変更前と変更後のURLを一緒に渡しましょう。今のURLだけでは分からない経緯を共有することで、リンクや転送の問題を発見しやすくなります。

GoogleのAI検索では、掲載を制御する設定も確認する

インデックスとスニペットの条件を確認する

Googleの生成AI検索向けガイドでは、ページがインデックスされ、検索でスニペットを表示できることなどが掲載対象となる条件として示されています。スニペットは、検索結果に表示される短い説明文です。

基本の条件は生成AI検索向けの公式ガイドで確認できます。条件を満たしても必ず掲載されるわけではありませんが、取得できるかだけで確認を終えないことが大切です。

通常の検索には出ているのにAI検索で扱われない場合は、登録状況に加えて、利用範囲を制限する設定がないかを担当者へ確認してもらいましょう。

nosnippetなどの設定が意図したものかを見る

nosnippetは、Google検索で説明文などを表示しないよう指示する設定です。公式仕様では、AIによる概要やAIモードへの直接的な入力としての利用も制限すると説明されています。

また、ページ内の特定部分を対象にする設定や、説明文の長さに関する設定もあります。本文を読める状態でも、利用される範囲に制限がある場合があるため、noindexだけで判断しないでください。

詳細はrobotsメタタグの公式仕様で確認できます。制限が見つかっても、契約や運用上の理由で入れている可能性があるため、目的を確認してから変更します。

Search Consoleの生成AI検索向け設定も確認する

2026年10月6日時点の公式案内では、Search Consoleの設定から、Google検索の生成AI機能にサイトのリンクや内容を含めるか管理できます。対象にはAIによる概要やAIモードなどが含まれます。

親となるサイト範囲の設定を引き継いでいる場合もあるため、現在のページにどの設定が適用されているかを確認します。担当者が見ている範囲だけでなく、上位の設定にも目を向けましょう。

確認方法は検索の生成AI機能を制御する公式ヘルプを参照してください。含める設定は掲載の許可に関するものであり、回答への採用を保証するものではありません。

検索向けの設定と、AI学習などの設定を混同しない

「AIを許可する設定」とひとまとめにすると、対象の機能を取り違えることがあります。たとえばGoogle-Extendedは、Gemini関連の学習や一部の回答生成への利用を管理するための項目で、Google検索への掲載や順位を制御するものではありません。

用途の違いはGoogleのクローラーと制御項目の公式一覧で確認できます。名前にGoogleやAIが付いているだけで、同じ役割だと判断しないようにします。

他社のAIサービスを調べる場合も、そのサービスの検索、学習、利用者の操作による取得を区別してください。Googleで良好な結果が出たことだけで、ほかのサービスも取得できるとは言い切れません。

修正後は、変更内容と再確認の結果を残す

一度に多くを変えず、原因に対応する修正を行う

robots.txt、プラグイン、本文、URLを同時に変えると、何が影響したのか分からなくなります。確認できた問題に合わせ、変更する場所と理由を決めて作業します。

変更前の設定を控え、対象ページで修正結果を確かめてから、必要な範囲へ広げましょう。技術的な操作を担当者へ頼む場合は、公開を希望するページと、制限を維持したい場所も共有します。

「AIに出るように全部直してください」より、「この公開記事の取得が拒否される理由を確認してください」と頼むほうが、作業の対象と完了条件をそろえやすくなります。

リニューアル直後の不具合は、変更履歴と照合する

ここで、架空の企業サイトを例に考えてみましょう。リニューアル前は見つかっていたサービスページが、公開後に検索へ出なくなったとします。この時点では、文章の質が原因だとは決められません。修正を急ぐ前に、経緯も確かめましょう。

まず旧URLと新URL、公開時の設定、検査で分かる取得状況を並べます。制作中の制限が残っているなら解除の対象を確認し、転送先が違うなら正しい移動先を担当者と確かめます。

一方、現在は取得でき、登録も確認できるなら、別の調査が必要です。以前との違いを記録しておけば、原因が未確定の段階で同じ修正を何度も頼まずに済みます。推測と確認済みの事実を分ける姿勢が、調査の時間を節約します。

再クロールの依頼は、即時掲載の予約ではない

修正した少数のURLについては、条件を満たす場合にSearch Consoleからインデックス登録をリクエストできます。ただし、リクエストしても、直ちに取得や登録が行われるとは限りません。

同じURLを繰り返し送っても、処理が早くなるわけではないとGoogleは案内しています。手順は再クロールを依頼する方法で確認し、依頼した日時を記録しましょう。

その後は、最終クロール日時や登録状況に変化があるかを見ます。現在の取得状態が直ったことと、検索側の登録情報が更新されたことを分けて記録すると、次の判断がしやすくなります。

制作会社へ渡す情報を、一枚に整理する

調査結果は、画面の画像だけを大量に送るより、対象URLと事実を短く整理すると伝わります。エラーの文言は勝手に言い換えず、確認日時と一緒に残してください。

まずは重要なサービスページを一つ選び、ログアウトした状態で開いてみてください。次にURL検査で登録状況を確かめ、必要なら公開URLテストへ進みます。分かったことと、まだ分からないことを分けてメモするだけでも、相談は具体的になります。

取得や登録に問題が見つからなければ、その結果を残したうえで、説明内容や検索する人の疑問との関係を見直す段階へ進めます。設定を変え続ける前に、今どこまで確認できたかを一つずつ明らかにしていきましょう。