AI検索は「選択レイヤー」だ

AI検索に負けるとは「順位が落ちる」ではなく「回答から消える」

本書が冒頭で置く定義が、以降のすべてを規定している。AI検索は新しい流入チャネルではなく、ユーザーとWebの間に挿入された「選択レイヤー（selection layer）」である。従来の検索エンジンは候補を並べ、選ぶ作業をユーザーに渡していた。AI回答エンジンは先に選び、選ばれた少数のソースから合成した答えだけを見せる。

この差は、失敗したときの落ち方に出る。

ユーザーは省かれたソースの存在自体を知らない。比較が始まる前に、選択肢の集合がすでに圧縮されているからだ。2ページ目に落ちたのではなく、存在しなかったことになる。

そしてもう一つ、SEOの前提を壊す指摘がある。Webページはもう競争の単位ではない。AI回答エンジンはパッセージ（文章の断片）を検索し、エンティティを解決し、ソースの確信度を比べて答えを合成する。モデルはページより小さい単位とページより大きい単位を、同時に評価している。だから、良い段落を1つ持っているだけでは足りない。クローラーが到達できないページは、その段落ごと存在しない。

4層モデル——GEOは施策ではなく順序の問題である

本書はGEOを4層＋乗数で整理する。この「順序」が本書の主張の核心だ。

依存関係は一方通行だ。Layer 1が落ちていれば、以降は何をやっても無効になる。Layer 2が落ちていれば、AIはサイトに来ても見るべき場所が分からない。Layer 3が落ちていれば、来て読んだが何のページか誤認する。Layer 4が落ちていれば、理解はしたが引用する値打ちのある文が見つからない。

監査したサイトの多くはLayer 1かLayer 3で落ちている。しかしコンテンツ投資のほとんどはLayer 4に向かう。だから多くのサイトはAIに引用されない——間違った層に投資しているからだ。

——『The GEO Readiness Manual』第1章

「AIに引用されないので記事を増やす」は、この診断に照らせば最も効率の悪い一手ということになる。

AIクローラーはJavaScriptを実行しない、という前提で設計する

Accessを本書は「ゼロ層」と呼ぶ。最も高度でないが、最も破壊的な事故が起きる層だという意味だ。無料公開章のなかで、日本のサイトに最も刺さるのはここだと考えている。

前提：レンダリングを当てにできるのは実質Googlebotだけ

本書は2026年7月時点の各エンジンの挙動を整理したうえで、実務上の結論をこう置く。AIクローラーはJavaScriptを実行しないものとして設計せよ。

• —Googlebot：レンダリングする。ただし遅延しうる
• —Applebot：ブラウザでレンダリングしうるとAppleは記述。ただし唯一の経路にするな
• —OAI-SearchBot：証拠が一貫しない。レンダリングを前提にするな
• —PerplexityBot / ClaudeBot系：素のHTML取得として扱う

つまり、サーバーが返す初期HTMLに本文が入っていなければ、その本文は存在しない。ユーザーが見ているのはJavaScript実行後の画面で、クローラーが見ているのは最初のHTMLだ。この2つを混同したまま運用されているサイトは多い。レンダリング方式のAIクローラー適性は、SSG ≒ SSR ≒ ISR ＞＞ CSR（非対応）。CSRのみのSPAは、AI検索から見て白紙である（SPAがクローラーからどう見えるかの実測はこちら）。

403は「サイレントキラー」

本書が主な原因として挙げているもの：

• —Cloudflareのボット対策モード（非ブラウザUAをチャレンジまたはブロック）
• —未知のUAを弾くWAFルール
• —JavaScriptチャレンジの完了を要求するボット検出
• —429ではなく403を返すレート制限
• —IP・地域ベースのブロック

確認は推測でなく実測でやる。User-Agentを変えてステータスコードだけ見ればいい。

curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot"    https://example.com/
curl -s -o /dev/null -w "%{http_code}\n" -A "PerplexityBot"    https://example.com/
curl -s -o /dev/null -w "%{http_code}\n" -A "Claude-SearchBot" https://example.com/
curl -s -o /dev/null -w "%{http_code}\n" -A "Googlebot"        https://example.com/
curl -s -o /dev/null -w "%{http_code}\n" -A "Applebot"         https://example.com/

200以外が返ってきたら、robots.txtの中身がどうであれ、そのエンジンから見えていない。

クッキー同意バナーとペイウォールの扱い

同意バナーは視覚的なオーバーレイであるべきで、コンテンツのゲートにしてはいけない。同意クッキーを持たないクローラーに縮退したページを返す実装は、AIから見れば内容のないページを返しているのと同じだ。バナーが表示されていても、本文はDOMに存在していなければならない。全画面のインタースティシャルも同様で、DOM上の順序は「本文が先、割り込みは後」。前面に出すのはCSSの役目である。

引用される文章と、されない文章

Quotabilityの章は、文章術の話ではなく抽出の力学の話として書かれている。本書の言い方を借りれば、モデルはパッセージを大きく書き換えない。軽い編集で使えるものを選ぶ。だから形式がそのまま採否を決める。

本書が挙げる例が分かりやすい。「1つ目はrobots.txt、2つ目はJavaScriptレンダリング、3つ目はスキーマ」というリストは、前後を読まないと意味をなさないので抽出できない。一方「robots.txtがGPTBotやPerplexityBotを拒否している。多くは古いスクレイピング対策の名残で、サイトは初期状態から不可視になっている」は、その1項目だけで完結しているので抜き出せる。

ヘッジと帰属は違う

この章で最も価値があるのは、次の区別だと考えている。

どちらも断定を避ける書き方に見えるが、抽出可能性は正反対になる。不確かなときに書くべきは前者ではなく後者だ、というのが本書の立場である。これはE-E-A-Tの文脈で言われてきたことと、機構の側から完全に一致する。

見出しについても具体的で、「質問形式にする」「凝った表現でなく説明的にする」「そのセクションの中心語を見出しに含める」「階層を飛ばさない」「H1は1つにして構造化データのheadlineと一致させる」。凝った見出しは人間を引きつけるが、意味検索を混乱させる。

この本を日本のサイトに当てはめると、最初にやることは3つ

本書は英語圏のサイトを前提に書かれている。日本の——特に中小規模のコーポレートサイトや制作会社のサイトを見てきた立場から、優先順位を組み替えると次の3つになる。

1. 1

   User-Agentを変えてステータスコードを取る

   これが最も費用対効果が高い。robots.txtの点検より先にやるべきだ。日本のサイトは海外製テーマやセキュリティプラグイン、レンタルサーバー側のボット対策が積み重なっていることが多く、「許可しているつもりで弾いている」状態が起きやすい。所要5分。

2. 2

   主要ページで、初期HTMLに本文が入っているか確認する

   curlの結果をh1やリード文でgrepするだけでいい。近年のサイトはヘッドレスCMSやページビルダー経由が増えており、見た目は問題なくても素のHTMLが空という構成は珍しくない。

3. 3

   記事を増やす前に、既存記事の第1文を書き換える

   新規公開より投資対効果が高い。多くの日本語記事は「近年、AI技術の進化により〜」で始まる。この段落はクロールされ、インデックスされ、ベクトル化されるが、どのクエリからも意味的に遠いので、二度と検索されない。削って、答えから始める。

逆に言えば、llms.txtの整備を最初にやるべき理由はない。本書自身が「llms.txtへの証拠は、access・schema・コンテンツ構造への証拠より弱い」と明言し、優先度は4番目だとしている。30分で作れるから作ればいい、ただし順番を間違えるな、という位置づけだ。ここは当社の見解とも一致している。

この本の数値を、そのまま自社の閾値にしてはいけない

本書は証拠の扱いに関して例外的に誠実だ。第1章で「公式ドキュメント／自社ベンチマーク観測／公開レポート／手動プロンプト検証／RAGの機構からの推論」という5段階の出典階層を宣言し、事実は事実として、観測は観測として、ブラックボックスは確率として書くと明示している。「GeoReadyはreadinessを測るのであって掲載を保証しない」と自ら書き、引用を保証すると謳うベンダーは市場に存在しない確実性を売っている、とまで言い切る。

そのうえで、あえて注記しておく。本書のなかにも、出典が示されないまま具体的な数値になっている箇所がある。

• 「TTFBは200ms以下を目標に」——Googleの一般的な目安はTTFB 800ms以下である
• 「パッセージは40〜120語が理想」「チャンクは200〜500トークン」——傾向としては妥当だが、根拠は示されていない
• 構造化データのheadlineは「110字以内」——これは旧AMPの要件に由来する。現行のGoogleドキュメントに文字数の上限規定はない

これらは経験則としては有用だが、診断ツールの合否基準にしてはいけない。当社が診断の閾値をGoogle公式の記述に揃えているのは、サードパーティのスコアを最適化しても検索の実態は動かないからだ。この本の価値は数値ではなく、層の順序と、機構の説明にある。