Geminiに自社サイトを回答の根拠として使ってもらうには
Geminiアプリの回答で自社サイトを根拠に使ってもらいたいなら、公開ページをGoogleが読めるか、検索に登録されているか、Google-Extendedで利用を拒否していないかを先に確かめます。そのうえで、お客様の具体的な質問に、自社で確認した事実で答えるページを作ります。設定を整えても、Geminiが必ず引用するわけではありません。
このサイトで見つかったこと
このサイトの公開ページを点検したところ、トップページの見出しと本文は、JavaScriptを動かす前のHTMLにありました。一方、robots.txtではGoogle-Extendedを禁止していました。Googleの説明では、この設定はGoogle検索への掲載とは別に、Geminiアプリの回答根拠への利用を制御します。そこで公開ページについて許可へ変更しました。
この変更だけで、Geminiの回答に当サイトが選ばれたと判断することはできません。Googleがページを再確認し、利用者の質問との関連性を判断するまでの時間も分かりません。回答画面での引用URLを継続して確かめる必要があります。
なお、Googleの現在の仕様では、Google-Extendedの許可はGeminiアプリでの回答根拠への利用と、将来のGeminiモデルの学習利用の両方に関わります。この二つだけを同じ設定で分離することはできません。他社の学習用クローラーまで一括で許可する必要はありません。
最初に調べる順番
| 確認すること | 自分で確かめる方法 | 分かったら行うこと |
|---|---|---|
| 公開ページの本文 | ブラウザの「ページのソース」で見出しと説明文を探す | 本文が見当たらなければ、初期HTMLにも説明を出す |
| Google検索への登録 | Search ConsoleのURL検査で対象ページを確認する | 未登録なら原因を確認し、サイトマップと内部リンクを整える |
| 利用設定 | robots.txtのGooglebotとGoogle-Extendedの規則を別々に読む | Geminiアプリでの利用を望む公開ページだけ、方針に合わせる |
| ページの答え | お客様が実際に聞く質問でページを読み直す | 誰向けか、条件、方法、根拠、相談先を本文に書く |
ここでいう「回答根拠」はGeminiアプリの話です。Google検索のAIによる概要表示はGoogle検索側の仕組みで、主にGooglebotによる取得と検索への登録を確認します。設定名が似ていても、両者の状態を一つの「AIに読まれる・読まれない」にまとめない方が原因を見つけやすくなります。
公開ページを読めるのに、AIが「アクセスできない」と答えたら
当研究室の継続確認では、公開ページが通常の取得で本文まで返り、検索にも登録されている一方、別のAIの直URL取得機能では「アクセスできない」と返ることがありました。同じ日に異なる結果が出たため、AIの画面に表示された一文だけで、サイト全体が遮断されているとは判断できません。この確認から分かるのは、取得経路によって結果が異なることまでです。そのAIが実際に公開サイトへ要求を送ったか、どこで失敗したかは、その画面だけでは分かりません。
2026年11月5日の自社再検査では、同じトップページを次の三つの経路で確かめました。これは当サイトで起きた事実であり、他社サイトや全AIサービスの結果を示すものではありません。
| 経路 | 実際に確認できたこと | まだ分からないこと |
|---|---|---|
| 一般の公開HTTP取得 | HTTP 200。初期HTMLに見出しと本文があり、正規URLと検索許可も確認 | 個々のAIサービスがその時刻に取得したか |
| AIのWeb取得機能で正規URLを直接指定 | 「このツールではアクセスできない」と表示され、本文を取得できなかった | 実際のHTTP状態、送信元、サイトまで要求が届いたか |
| 同じWeb取得機能で運営会社の公式リンクから進む | 現行のタイトル、見出し、冒頭本文を取得できた | 直URL指定の失敗理由と、それが解消したか |
リンク経由で読めたことを直URLの復旧とは扱いません。また、一般のHTTP取得が通ったことを、すべての検索BotやGeminiアプリでの引用成功とも扱いません。失敗した要求を特定できるまで、Cloudflareの防御設定を広く緩める判断は保留しています。
自社サイトで同じことが起きたら、まず対象URLと試した時刻、使ったAIの機能を記録します。次に、そのURLのHTTP状態、初期HTMLの本文、robots.txt、検索への登録を別々に確かめます。サイト側の記録で該当する要求を特定できた場合に限り、User-Agent、応答状態、CloudflareのRay IDとセキュリティ記録を突き合わせます。要求が確認できない段階で防御設定を広く緩めても、原因を解決したとは言えません。
取得の確認と、回答への採用も分けて測ります。URLを指定した質問で本文を正しく読めても、「沖縄で小さな会社のAI導入を相談したい」のような社名を含まない質問に挙がるとは限りません。両方を新しい会話で試し、回答が示した根拠URLと事実の正しさを残します。公開URLの確認項目はAI検索の取得診断にもまとめています。
一次情報は、お客様の判断に役立つ形で出す
「便利です」「安心です」だけでは、そのサービスが自分に合うか判断できません。たとえば小さな事業者から「今の仕事のやり方を全部変えないとAIを使えませんか」と聞かれたなら、まず「全部変える必要はありません」と答えます。次に、紙や電話など残してよい方法、負担の大きい作業の見つけ方、人が確認すべき判断を説明します。これは私たちが業務を整理するときにも使う考え方です。
実例を書くときは、確認した事実、試した方法、うまくいかなかった点、まだ測れていない結果を分けます。公開していないお客様の情報や社内の数字は載せません。実測のない効果を「成功事例」と呼ぶこともしません。読者が自社へ当てはめられる条件まで書くことが大切です。
何をもって改善と判断するか
公開後は、ページの取得とGoogle検索への登録を確認し、同じ質問をGeminiアプリに入力して回答本文と引用URLを記録します。自社サイトが出なかった場合も、質問の言い方、参照された他サイト、当社ページに足りない答えを記録します。引用されたかどうかだけでなく、回答が事実を正しく伝え、お客様の意図に合っているかまで見直します。
まずは自社サイトの一ページを選び、実際に受けた質問に冒頭で答えているかを確かめてください。どのページから直すか迷う場合は、公開URLの診断や仕事の流れ整理相談から相談できます。
