「自社サイトはAIに読まれているか」を、AIへの質問だけで判断するのは危険です。回答に出なかった理由が、取得できないからなのか、質問と合わないからなのか、別の情報源が選ばれたからなのかを区別できないためです。
そこで2026年8月23日、feelflow.netを外部から取得し、AI検索の土台になる12項目を監査しました。結論は 11項目OK、1項目NG（適合率92%） です。致命的な取得障害はなく、NGは任意の補助ファイルに限られました。
結論：まず「取得・理解・検証」の順で確認する
要点：AI向けの特別な施策より先に、公開ページが取得でき、内容と根拠をHTMLから確認できる状態を整えます。
Googleは、生成AI検索でも通常の検索インデックス、クロール、検索品質の仕組みが土台だと説明しています。OpenAIも、ChatGPT検索に内容を表示するにはOAI-SearchBotをブロックしないよう案内しています。つまり、監査の最初は「AIに好まれる書き方」ではなく、HTTP応答、robots制御、発見経路、HTML本文です。
今回の監査は、公開ページを一般の利用者と同じ経路から取得するブラックボックス検査です。Search Console、Bing Webmaster Tools、サーバーログは使っていません。そのため、クロール可能な条件は確認できますが、各社が実際にクロール・登録・引用したことまでは証明しません。
表1：feelflow.netの技術監査結果
要点：12項目のうち11項目がOKで、公開コンテンツを取得・解釈する基礎は整っていました。
| # | 監査項目 | 結果 | 2026年8月23日の確認内容 |
|---|---|---|---|
| 1 | 主要ページのHTTP応答 | OK | トップと公開済みブログが200 |
| 2 | robots.txt |
OK | User-agent: *にAllow: / |
| 3 | AI検索クローラー | OK | OAI-SearchBotを個別・包括のどちらでも拒否していない |
| 4 | インデックス拒否 | OK | 対象HTMLにnoindex、応答にX-Robots-Tagなし |
| 5 | XMLサイトマップ | OK | indexが200、公開済みブログのcanonical URLを収録 |
| 6 | サーバー生成HTML | OK | JavaScript実行前のHTMLにタイトルと本文が存在 |
| 7 | メタ情報 | OK | title、description、canonical、OGPを確認 |
| 8 | 見出し構造 | OK | 対象2ページともh1は1個、本文はh2以下で整理 |
| 9 | サイトの構造化データ | OK | トップにWebSiteとOrganization |
| 10 | 記事の構造化データ | OK | ブログにBlogPosting、著者、公開日、主画像 |
| 11 | RSSフィード | OK | /news-blog/rss.xmlが200、公開済みブログを収録 |
| 12 | llms.txt |
NG | /llms.txtは404 |
適合率は、当社が定義した12項目の単純集計です。重要度による重み付けはしていません。11 ÷ 12 × 100 = 91.7%を整数へ丸めました。検索順位やAI回答への引用率を示す数値ではありません。
OKだった基盤：特別なAI用ページより通常のWeb品質
要点：クローラーがURLを発見し、200応答のHTMLから主体・記事・根拠を読める構成が強みです。
robots.txtは全クローラーにルート以下を許可し、サイトマップの場所も示しています。公開済みブログはサイトマップに入り、canonical URLが重複を抑えます。トップページには会社を示すOrganization、ブログには記事を示すBlogPostingのJSON-LDがあり、画面上の内容と対応していました。
また、Astroによる静的生成のため、主要な文章はJavaScriptの実行を待たずHTMLに含まれます。これは「AI専用」の実装ではありませんが、検索クローラーだけでなく、ブラウザーや支援技術が内容を取得しやすい構成です。
見出しは構造を助けますが、見出しを細かく増やせば引用されるわけではありません。Googleは、AI検索向けの不自然な文章分割や特別なschemaを不要としています。見出しの役割は、読者が結論・条件・根拠の関係を追えるようにすることです。
NGだったllms.txtの改善方針
要点：
llms.txtは低優先とし、主要な公開経路より先に追加しません。
| 優先度 | 対象 | 改善方針 | 判断理由 |
|---|---|---|---|
| 低 | llms.txt |
対応サービスと運用責任を決めてから採否を再評価する | Googleは不要なAI用テキストファイルとして例示し、OpenAIの公開FAQも必須条件に挙げていない |
llms.txtは、存在確認だけなら簡単です。しかし、誰が内容を更新し、どのサービスが参照し、サイトマップや本文と矛盾したとき何を正とするかまで決めなければ、古い案内を一つ増やします。現時点では、公式に効果が確認できるrobots制御、サイトマップ、HTML本文を優先します。
自社サイトで再現する7ステップ
要点：URLを外部から取得し、事実と推測を分けて記録すれば、同じ観点で一次監査を再現できます。
- トップ、代表記事、重要サービスページへ
curl -I -Lを実行し、最終応答が200か確認する。 /robots.txtを取得し、Googlebot、Bingbot、OAI-SearchBotなど対象クローラーの拒否を確認する。- HTMLの
noindexと応答ヘッダーのX-Robots-Tagを確認する。 - robotsからサイトマップをたどり、公開URLがcanonical形式で収録されているか確認する。
- JavaScriptを実行しない取得結果に、主要なタイトル、本文、リンクがあるか確認する。
- title、description、canonical、OGP、単一の
h1、論理的な見出し順を確認する。 - JSON-LDをパースし、画面上の著者・日付・組織情報と一致するか確認する。
代表的なコマンドは次のとおりです。
curl -I -L https://example.com/
curl -L https://example.com/robots.txt
curl -L https://example.com/sitemap.xml
curl -L https://example.com/page | rg \
'<title|description|canonical|<h1|application/ld\+json|noindex'結果表には確認日、対象URL、HTTP状態、実際に見つけた値を残します。「構造化データがあるから引用される」のように、適合条件を成果保証へ読み替えないことも重要です。
公開研究から見た、構造改善の限界
要点：内容の構造や引用は可視性に影響し得ますが、分野や質問によって効果が変わり、技術監査だけでは引用を保証できません。
KDD 2024採択のGEO論文は、10,000件のクエリを使い、引用・統計・文章表現などの変更が生成回答内の可視性を条件により最大40%改善したと報告しました。一方で、効果は分野や手法で異なります。この研究は、特定のサイトへ同じ改善率を保証するものではありません。
今回の監査が測ったのは、情報へ到達し、内容を解釈する前提です。公開後は、対象とする質問、サービス、地域、言語を固定し、回答内の引用、参照流入、問い合わせを別々に観測して初めて、改善が事業成果へつながったかを評価できます。
FAQ
要点：監査結果は「読める可能性」を示すもので、登録・引用・成果の保証ではありません。
Q. 12項目がすべてOKなら、AIに必ず引用されますか？
要点：引用は保証されません。
質問との適合、情報の独自性と鮮度、他の情報源、サービス側の判断も関係します。技術監査は、取得不能という原因を先に除くための作業です。
Q. robots.txtで許可すれば、必ずクロールされますか？
要点：許可は拒否しないという意味で、訪問や登録の依頼ではありません。
サイトマップ、内部リンク、各社の管理ツール、サーバーログを組み合わせて、発見・訪問・登録を分けて確認します。
Q. llms.txtがないと、LLMOで不利ですか？
要点：少なくともGoogle検索では必須ではありません。
GoogleはAI検索向けの不要なテキストファイルの例としてllms.txtを挙げています。対応状況はサービスごとに変わり得るため、導入時点で公式仕様を再確認します。
Q. 構造化データは多いほど有利ですか？
要点：量ではなく、可視本文と正確に一致することが先です。
GoogleはAI検索専用のschemaを不要と説明しています。組織、記事、商品などページの実体に合う型を使い、検証ツールでエラーを確認します。
まとめ
要点：feelflow.netは取得と理解の基盤を満たしており、次は補助経路の整備と公開後の観測へ進みます。
- 12項目の技術監査は11項目OK、1項目NG、適合率92%だった。
- HTTP、robots、サイトマップ、HTML、メタ情報、見出し、構造化データに致命的な問題はなかった。
- RSSフィードは公開済みで、
llms.txtだけを低優先の改善候補とした。 - この結果はクロール・登録・引用の実績ではなく、その前提条件の確認である。
次回は、記事単体の根拠、著者情報、質問への答え方をどう設計するかへ進みます。
参考資料・データソース
要点：製品要件は各社の公式資料、可視性改善の数値は査読論文の原典を確認しました。
- Google Searchの生成AI最適化ガイド — クロール、検索インデックス、HTML構造、
llms.txt、構造化データに関する公式説明。確認日：2026年8月23日。 - Google Searchの技術要件 — Googlebotの許可、HTTP 200、インデックス可能な内容という最低要件。確認日：2026年8月23日。
- OpenAI「Publishers and Developers - FAQ」 — ChatGPT検索向け
OAI-SearchBotと学習用GPTBotの区別。確認日：2026年8月23日。 - Bing Webmaster Guidelines — サイトマップ、見出し、メタ情報、構造化データとCopilotのgroundingに関する指針。確認日：2026年8月23日。
- Aggarwal, P. et al. “GEO: Generative Engine Optimization,” KDD 2024 — 10,000件のクエリを使ったGEO-bench。arXiv:2311.09735、DOI: 10.1145/3637528.3671900。確認日：2026年8月23日。
※ 表1は、2026年8月23日にフィールフロウが公開URLを取得した独自監査です。対象はトップページと公開済みブログ「SEOとLLMO/AIOは何が違うのか」を中心とし、RSSはブログ一覧から案内される/news-blog/rss.xmlを確認しました。