GEO技術最適化：ページ構造・読み込み速度・構造化データがAIクロールに与える影響
一、L1 入り口：bot はあなたのページを読めるか
技術最適化の第一層は最適化ではなく、地雷処理です。B2B サイトで最も多い GEO 技術問題は、bot がそもそも入ってこないこと。原因は3つあります。robots.txt の誤ブロック、ファイアウォールによる UA 遮断、JS のみのレンダリングで空の殻が返ることです。
| 問題 | 検出方法 | 修正アクション |
|---|---|---|
| robots が AI bot を誤ブロック | robots.txt と bot のステータスコードを確認 | GPTBot、OAI-SearchBot、PerplexityBot を明示的に Allow |
| WAF が未知の UA を遮断 | curl に bot の UA を付けてテスト | これらの bot UA をホワイトリストに追加 |
| JS のみのレンダリングでファーストビューが空 | curl で HTML を取得し本文を grep | SSR または SSG を導入 |
| 中国語版と英語版でページ内容が不一致 | 2つのバージョンをそれぞれ curl | 両方とも本文を直接出力するようにする |
確認方法は具体的です。サーバーログで直近30日分をこれらの bot の UA で絞り込みます：GPTBot、OAI-SearchBot、PerplexityBot、ClaudeBot、Googlebot。ステータスコードがすべて 4xx なら遮断されています。200 でもアクセスがトップページばかりなら、内部リンクや sitemap で bot が深い階層に到達できていません。sitemap の書き方はサイトリニューアルとドメイン変更のリンク構造の部分をご覧ください。
具体例：WordPress の独立サイトを運営する顧客が、デフォルトで全ての不明な bot を遮断するセキュリティプラグインを導入していました。公開から半年後、ログを調べたところ PerplexityBot は一度も来ていませんでした。ホワイトリストに追加した翌週、bot は製品ページを訪問し始め、4週間後には Perplexity の回答にこの会社の引用が現れ始めました。コンテンツは変えず、設定を一行変えるだけで解決します。
二、L2 速度：TTFB と LCP が bot の訪問頻度を決める
従来の SEO はページ速度をユーザー体験の問題として扱い、Core Web Vitals も人間向けに設計されています。しかし AI bot にとって、速度が決めるのはクロールの優先順位と頻度です。bot はキュー内で応答時間順に並べられ、TTFB が2秒を超えるページは後回しにされ、再クロール周期が3日から2週間に延びます。
| 指標 | 合格ライン | 基準未達の影響 | 改善の方向 |
|---|---|---|---|
| TTFB | 1.5秒以下 | クロール優先度の低下 | CDNキャッシュ、PHPアップグレード |
| LCP | 2.5秒以内 | 初回表示のchunkが不完全 | 画像圧縮、クリティカルCSSのインライン化 |
| INP | ≤ 200ミリ秒 | botへの影響は小さく、実ユーザーへの影響は大きい | サードパーティスクリプトの遅延読み込み |
| CLS | 0.1以下 | GEOへの影響は小さい | 画像のアスペクト比を固定 |
GEOではTTFBとLCPが最も重要です。INPとCLSは主に実ユーザー向けで、botのクロールにはほとんど影響しないため、過度な最適化は不要です。具体的なしきい値と最適化の優先順位は次をご覧くださいCore Web Vitals。CDNノードの選択はTTFBに最も影響します。B2B海外展開サイトでは北米と欧州のノードを両方用意することをおすすめします。詳細は次をご覧くださいCDNによるグローバル高速化。
直感に反する判断ですが、遅いページは「ユーザー体験の問題」ではなく、GEOのクロール頻度の問題です。TTFBが3秒の製品ページは、内容が競合と同じ品質でも、botが2週間に1回しか来なければ、内容の更新がモデルに認識されるのは2週間後になり、引用率は当然遅れます。TTFBを1.5秒以内に抑えれば、botの訪問頻度が4〜5倍になるのと同じです。
三、L3 理解：ページ構造でモデルに推測させない
botが読めて速く読めるようになったら、次は正確に理解できるようにします。この層はページ構造と構造化データで対応します。モデルはHTMLの見出し階層、表、リンクのアンカーからページの内容を判断します。構造が乱れていると、文脈から推測するしかなくなり、推測を誤る確率が上がります。
| 構造項目 | 適切な書き方 | 不適切な書き方 |
|---|---|---|
| H1 | 各ページで1つだけ、主要キーワードを含む | H1が複数ある、またはH1がない |
| H2/H3の階層 | 内容の論理に沿って段階的に | レベルを飛ばしてH4を小見出しに使う |
| 表 | theadがあり、先頭行がしきい値 | 画像を組み合わせて表を作る |
| アンカー | 各H2にidがある | idがなく、モデルが段落を指定できない |
| 内部リンク | アンカーテキストがキーワード | アンカーテキストが「こちらをクリック」 |
構造化データの三点セット（Organization、WebSite、BreadcrumbList）は全サイトで必ず実装してください。これはモデルに送る実体の身分証です。製品ページと記事ページにはさらにProduct、Article、FAQPageを追加します。フィールドは表示内容と一致させる必要があり、不一致はGoogleの手動対策の対象になります。具体的なマークアップ一覧は次をご覧ください構造化データSchema。実体がAIの回答でどう認識されるかは次をご覧くださいナレッジグラフとエンティティマークアップ。
シーン別の例：製品仕様表を画像で作ると、botが見るのは1枚の画像で、OCRが表内の数字を読み取れるとは限りません。本物のHTML tableを使い、theadに「PN16バタフライ弁の使用温度上限」と書けば、モデルはこの行を事実としてそのまま抜き出せます。画像ローカライズの範囲は次をご覧ください多言語サイトのグラフ処理。
四、確認順序と公開期限
3つの層を同時に変更しないでください。順番に進め、各層には明確な検証ツールと期限があります。
| ステップ | ツール | 期限 | 合格基準 |
|---|---|---|---|
| 1 robotsログを確認 | サーバーログでbotのUAを絞り込む | 当日 | 5つのAI botすべてが200ステータスコード |
| 2 TTFB/LCPを測定 | Lighthouse、PageSpeed | 3日以内に修正 | TTFB ≤ 1.5s，LCP ≤ 2.5s |
| 3 Schemaを確認 | リッチリザルトテスト | 当日 | 三点セットにエラーなし |
| 4 H階層を確認 | ブラウザ拡張のoutline | 当日 | H1が1つ、階層の飛びなし |
| 5 botの再クロールを待つ | サーバーログを継続的に監視 | 1から2週間 | botの訪問頻度が上昇 |
修正後、翌日に引用が増えることは期待しないでください。bot の再クロールには1〜2週間、モデルのインデックス更新にもさらに1〜2週間かかります。つまり技術最適化の後は最低4週間待ってから、固定の質問セットで引用率の変化を確認します。このタイムラグは GEO の実験設計で必ず考慮すべき点です。詳しくはGEOの実験設計。
よくある誤りは、いきなり新しいコンテンツを書き始めることです。L1 と L2 が通っていなければ、新規コンテンツも既存コンテンツも同じようにモデルには届きません。まず地雷を除去し、次に速度を上げ、最後にコンテンツを考えます。この3層の順序が逆になると、どの段階の効果も割り引かれます。
もう一つ見落とされがちな点があります。多言語サイトでは技術層を個別に確認する必要があります。ドイツ語、スペイン語、アラビア語の版で同じ robots を使っていても、CDN ノードが米国にしかなければ、非英語市場の TTFB は高くなり、その言語の AI 引用率は上がりません。多言語 GEOで扱っているドイツ語・スペイン語・アラビア語市場では、技術面ではまずローカルノード、ローカルの hreflang タグ、ローカルキャッシュの3つを実装してから、コンテンツの話をします。
具体例です。多言語で海外展開するクライアントで、英語版の引用率は正常でしたが、ドイツ語版は Gemini でほぼゼロでした。ログを調べると、Googlebot が欧州ノードからドイツ語版にアクセスしたときの TTFB が3.2秒で、キューの最後尾に回されていました。CDN の欧州ノードを追加し、ドイツ語版ページをフランクフルトでキャッシュしたところ、TTFB は1.1秒に下がり、3週間後にドイツ語版の引用率が上がり始めました。これはコンテンツとは無関係で、純粋に技術層で一つの地域が抜けていた問題です。
最後に一言。技術最適化が完了したら URL を頻繁に変更しないでください。改版のたびに 301 で引き継ぐ必要があります。そうしないと、bot がやっとクロールし慣れた旧リンクが切れ、新リンクは再び順番待ちになります。サイト移行時の 301 マップの作り方はサイトリニューアルとドメイン変更をご覧ください。技術層は時間のかかる作業なので、いったん安定したらむやみに触らないことです。
3層の技術チェックを毎月の定例作業にし、公式サイト保守期間にある他のルーティン項目と一緒に回します。毎月1回、bot ログ、Lighthouse、Rich Results Test を実行します。技術的負債はコンテンツの負債のように目に見えませんが、あなたのコンテンツがモデルに読まれるかどうかを左右します。安定していて速く、構造が明確なサイトは、すべての GEO コンテンツ作業の前提です。
FAQ よくある質問
GEO の技術最適化はどの層から着手する？
TTFB が遅いとなぜ AI 引用に影響する？
JS だけで描画するサイトは GEO にどんな影響がありますか？
構造化データの Schema は AI の引用にどれほど効きますか？
技術的な最適化を終えてから、引用の改善が見えるまでどれくらいかかりますか？
ページ内のパラメータ表は画像と HTML table のどちらを使うべきですか？
最後に
GEO の技術レイヤーはコンテンツチームに軽視されがちです。みんながより良い記事を書いていますが、記事がどれだけ良くても、bot が入れず、来るのが遅く、読み取れなければ、すべてが無駄になります。三層の技術最適化は、本質的にモデルのために道を整えることです。まず門を開き、次に道を平らにし、最後に道しるべをはっきり描くのです。
実行は 3 ステップです。今週はサーバーログで 5 つの AI bot のステータスコードを確認し、ブロックされているものをホワイトリストに追加します。来週は Lighthouse で TTFB と LCP を測定し、TTFB を 1.5 秒以内に抑えます。3 週目は Rich Results Test で Schema の三点セットを確認し、全サイトのマークアップを補完します。この 3 つを終えたら 4 週間待って質問セットを実行してください。引用率の最初の跳ね上がりが見えてきます。
覚えておきたい一言：GEO 対策はユーザーのためではなく、bot のために道を整えるもの。入口を開き、道をならし、道しるべをはっきり示してこそ、コンテンツはモデルの前にたどり着ける。