Core Web Vitalsとレイテンシ：ページの高速化はAIによる引用を増やすか？

Core Web Vitalsとレイテンシ：ページの高速化は人工知能による引用を増やすか？

はじめに

高速なウェブサイトは、人々にとって使いやすいものです。また、検索エンジンや人工知能システムにとっても、コンテンツの取得、レンダリング、理解が容易になる可能性があります。

しかし、重要な区別が見過ごされがちです。

ページの高速化は、クロールとコンテンツの可用性を向上させる可能性があります。しかし、速度だけが人工知能システムにそのページを引用させる原因となるわけではありません。

2026年8月2日現在、Googleは、安定したサーバー応答時間と低いレイテンシがサイトのクロール能力を高める可能性があると述べています。Googleはまた、その人工知能検索機能が従来の検索と同じ基本的な検索およびインデックス作成システムを使用しており、特別な人工知能マークアップや速度最適化を必要としないとも述べています。（developers.google.com）

この記事は、既に完了した実験が実施されたと主張するのではなく、エビデンスに基づいたテスト計画を提示します。サイト、ページセット、サーバーログ、または引用データセットは提供されていません。目標は、以下の項目を測定できる管理された研究を定義することです。

1. Time to First Byteの短縮がクロール頻度を増加させるかどうか。
2. Largest Contentful Paintの短縮が発見またはインデックス作成を改善するかどうか。
3. Cumulative Layout Shiftの短縮がクロールまたは人工知能による取得に影響を与えるかどうか。
4. パフォーマンスの改善が、人工知能検索システムによってページが視覚的に引用される頻度を増加させるかどうか。

短い答え

Time to First Byteの短縮は、適切な条件下でクロールを改善する可能性がある

Googleの現在のクロールに関するドキュメントによると、Time to First Byteを含むサイトの応答時間が安定または改善すると、クロール能力の上限が増加する可能性があるとされています。応答時間が上昇したり、サイトが過剰なサーバーエラーやレート制限応答を返したりすると、Googleはクロールを削減する可能性があります。（developers.google.com）

しかし、応答時間の高速化は、より多くのクロールを保証するものではありません。クロール需要は、以下の要因にも依存します。

• サイトがどのくらいの頻度で変更されるか。
• サイトとそのページの人気度。
• コンテンツが有用でユニークであるか。
• 重複または低価値のURLがどれだけ存在するか。
• 更新されたURLがサイトマップに含まれているか。

これは、レイテンシの短縮が、新しいコンテンツが限られている小規模なサイトではなく、大規模で頻繁に更新される、またはサーバーに制約のあるウェブサイトに対して最も強い影響を与えるはずであることを意味します。

Largest Contentful Paintの短縮は間接的に役立つ可能性がある

Largest Contentful Paintは、ユーザーにとって主要な可視コンテンツが表示されるタイミングを測定します。Googleはまた、サーバー応答時間とページのレンダリングおよび埋め込みリソースのレンダリングにかかる時間の両方が、クロールの効率に影響を与える可能性があると述べています。（developers.google.com）

考えられる関係は間接的です。

レイテンシの短縮 → リソース配信の高速化 → より効率的なレンダリングまたは取得 → クロールのタイムアウトまたは不完全な取得の減少。

この効果は、重要なコンテンツが以下に依存する場合に最も強くなるはずです。

• 遅いJavaScript。
• 大きな画像。
• レンダリングをブロックするスタイルシート。
• クライアントサイドレンダリング。
• 重い埋め込みリソース。

高速なLargest Contentful Paintスコア自体が、直接的な人工知能による引用シグナルになるとは考えにくいです。

Cumulative Layout Shiftの短縮は、直接的なクロール効果はほとんどない可能性が高い

Cumulative Layout Shiftは、予期せぬ可視コンテンツの動きを測定します。これは主にユーザーエクスペリエンスの指標です。一般的な原因には、寸法のない画像、動的に挿入される広告、埋め込みコンテンツ、Webフォントなどがあります。（web.dev）

クローラーは、人間が訪問するのと同じ方法でレイアウトシフトを経験しません。したがって、Cumulative Layout Shiftの短縮とクロール頻度の増加との間に直接的な関係がある可能性は低いです。

高いレイアウトシフトが以下によって引き起こされる場合、間接的な関係があるかもしれません。

• JavaScriptによって遅れて挿入されるコンテンツ。
• スクリプトが実行されるまで非表示になっている重要なテキスト。
• ページの構築を遅らせる画像または埋め込み。
• 異なる取得時に異なるコンテンツを生成する不安定なテンプレート。

これらの場合、本当の問題はレイアウトシフトスコアではありません。本当の問題は、ページが処理しにくい、または重要なコンテンツを遅すぎて公開している可能性があるということです。

高速なページが自動的に頻繁に引用されるわけではない

Googleによると、人工知能機能に表示されるページは、まずインデックスに登録され、スニペット付きの通常の検索結果に表示される資格がある必要があります。Googleはまた、その人工知能概要や人工知能モードには、追加の技術的要件や特別な人工知能最適化はないと述べています。（developers.google.com）

OpenAIも同様に、ChatGPTの検索ランキングは複数の要因に依存し、その検索クローラーであるOAI-SearchBotを許可することがインクルージョンのために重要であると述べています。Core Web Vitalsの低下が引用の確率を直接増加させるとは述べていません。（help.openai.com）

これは、4段階のモデルを示唆しています。

1. 発見 — システムはURLが存在することを知るか？
2. 取得と処理 — システムはページを取得し、理解できるか？
3. インデックス作成と検索 — 特定のクエリに対してページが選択されるか？
4. 引用選択 — ページが回答に視覚的なソースとして表示されるか？

ページの速度は最初の2つの段階に影響を与える可能性があります。第4段階の直接的な原因として確立されていません。

最近の研究では、人工知能システムが多くの関連ページを読み込む可能性があるものの、その一部しか引用しないことも示されています。言い換えれば、検索と引用は別々のイベントです。（cambridge.org）

何をテストすべきか？

この研究では、「人工知能による可視性」を一つの指標として扱うのではなく、2つの異なる質問をテストする必要があります。

質問1：パフォーマンスはクロールに影響するか？

主要な成果：

• 公開から最初のクローラーリクエストまでの時間。
• 1ページあたりの1日あたりのクローラーリクエスト数。
• 成功した再クロールの間隔。
• 公開された1,000ページあたりのクロールされたページ数。
• 成功した取得の割合。
• サーバーエラーとレート制限応答の発生率。
• 公開からインデックス作成までの時間。

質問2：パフォーマンスは引用の選択に影響するか？

主要な成果：

• 可視的な引用を生成するテスト済みクエリの割合。
• 対象となるページあたりの引用率。
• クエリ内での引用シェア。
• 可視的な引用となる取得されたページの割合。
• 時間の経過に伴う引用の持続性。
• 人工知能システムごとの引用率。

これらの成果は、プロバイダーごとに区別する必要があります。Googleの人工知能概要、ChatGPTの検索結果、Microsoft Copilotの回答、Perplexityの回答、Claudeの検索応答は、それぞれ異なるインデックス、クローラー、ランキングシステム、更新スケジュールを使用する可能性があります。

実験計画

1. 管理されたページセットの構築

意味のあるクローラーおよび引用データを生成するのに十分な大きさのページセットを使用します。

実用的な開始設計には以下が含まれます。

• 240から800ページ。
• ページテンプレートごとに少なくとも20ページ。
• 3〜5つのコンテンツカテゴリ。
• エバーグリーンページと定期的に更新されるページの混合。
• 各治療群に同数のページ。

各ページは以下を持つべきです。

• 同様のHTML構造。
• 同様のコンテンツ長。
• 同じ公開システム。
• 同じ内部リンクパターン。
• 同じカノニカルルール。
• 同じサイトマップ処理。
• 同じrobots.txt権限。
• ユニークで有用なトピック。

実験のためだけに、何百もの薄いページやほぼ重複するページを作成しないでください。Googleのガイダンスは、重複した低価値のURLがクロールリソースを浪費し、サイトの効率を低下させる可能性があると警告しています。（developers.google.com）

マッチングペア設計が有用です。たとえば、類似の特性を持つページをペアにします。

• コンテンツ長。
• トピック需要。
• 更新頻度。
• 内部リンク数。
• 外部リンク数。
• 履歴トラフィック。
• 検索ランキング位置。

次に、各ペアから1つのページを対照群に配置し、もう1つのページを治療群に配置します。

2. 因子治療設計の使用

主要なパフォーマンス治療は、個別に、そして組み合わせてテストされるべきです。

これにより、リクエストされた3つの最適化に関する管理された実験が作成されます。

• HTTP/3。
• コンテンツ配信ネットワークのエッジキャッシング。
• 画像圧縮。

レイアウト安定性治療は、最初の3つの最適化ではCumulative Layout Shiftを確実に分離できないため必要です。画像圧縮は、レイアウト安定性をまったく変更せずにLargest Contentful Paintを低下させる可能性があります。

HTTP/3が独自の測定を必要とする理由

HTTP/3はQUICトランスポートプロトコルを使用し、独立したストリームを提供するため、TCP上のHTTP/2に見られるトランスポートレベルのヘッドオブラインブロッキングを回避できます。その利点は、クライアントまたはクローラーが実際にHTTP/3をネゴシエートするかどうかによって異なります。（rfc-editor.org）

したがって、すべてのリクエストについてネゴシエートされたプロトコルを記録します。

• HTTP/1.1。
• HTTP/2。
• HTTP/3。

HTTP/3を有効にしても、すべてのクローラーがそれを使用するとは限りません。Googlebot、OAI-SearchBot、または他のクローラーがHTTP/2を使い続ける場合、HTTP/3はそのクローラーのリクエストに影響を与えることはできません。

エッジキャッシングを慎重にテストすべき理由

コンテンツ配信ネットワークは、リクエスト元に近い場所からコンテンツを提供することで、Time to First Byteを短縮できます。また、オリジンサーバーに到達するリクエストの数を減らすこともできます。（web.dev）

少なくとも3つのキャッシュ状態をテストします。

1. コールドキャッシュ — エッジがオリジンに連絡する必要がある。
2. ウォームキャッシュ — エッジがオリジンに連絡せずにページを提供する。
3. 再検証されたキャッシュ — エッジまたはクローラーがETagまたはLast-Modified値を使用し、304 Not Modified応答を受け取る。

Googleは特に効率的なHTTPキャッシングを推奨しており、不要な処理と帯域幅を削減するために304 Not Modified応答の使用をサポートしています。（developers.google.com）

クローラーに古いまたは誤ったコンテンツがキャッシュによって提供されないようにしてください。以下を記録します。

• キャッシュヒットまたはミス。
• キャッシュ経過時間。
• エッジロケーション。
• オリジン応答時間。
• コンテンツバージョン。
• ステータスコード。
• 検証ヘッダー。

画像圧縮をLargest Contentful Paintに結びつけるべき理由

WebPおよびAVIFは、一般に従来の画像形式よりも優れた圧縮を提供します。画像がLargest Contentful Paint要素である場合、より小さい画像は転送時間を短縮し、Largest Contentful Paintを改善する可能性があります。（web.dev）

テストでは以下を使用すべきです。

• 同じ画像寸法。
• 同じ視覚品質目標。
• レスポンシブなsrcset画像。
• 適切なフォールバックを持つ最新の形式。
• 明示的なwidthとheightの値。
• Largest Contentful Paint画像に対する遅延読み込みなし。
• 初期HTMLに表示される画像URL。

もし実際の遅延がJavaScriptやリソースの遅延発見によるものである場合、画像圧縮だけではLargest Contentful Paintが改善しない可能性があります。Googleのパフォーマンスガイダンスは、Largest Contentful Paint要素が遅れて表示される場合、画像ダウンロード時間の短縮は単にページの別の部分に遅延をシフトさせるだけであると指摘しています。（web.dev）

3. 十分な期間のテスト実施

短いテストでは、クロールスケジュールやインデックス更新の効果を見逃す可能性があります。

実用的な設計は以下の通りです。

• 2週間のベースライン測定。
• 6〜12週間の治療測定。
• 可能であれば、最後の反転またはクロスオーバー期間。

クロスオーバーテストの場合、マッチングされたページグループ間で治療を入れ替えます。治療が削除されたときにパフォーマンス効果が消失する場合、その結果は単純な前後比較よりも強力です。

Core Web Vitalsのフィールドデータは、適切な期間にわたって評価されるべきです。Chrome User Experience Reportは28日間のローリング集計を使用するため、デプロイ後の即時変更を示すようには設計されていません。（developer.chrome.com）

4. クローラー全体の測定

すべての自動トラフィックを一つのグループとして扱わないでください。

最低限、以下を区別します。

検索クローラー

• Googlebot。
• Bingbot。

人工知能検索クローラー

• OAI-SearchBot。
• PerplexityBot。
• Claude-SearchBot。

ユーザーリクエスト型フェッチャー

• Perplexity-User。
• Claude-User。
• 特定可能なChatGPTユーザーフェッチャー。

トレーニングクローラー

• GPTBot。
• ClaudeBot。
• Google-Extendedコントロール。

トレーニングクローラーは、人工知能検索の引用の代理として使用すべきではありません。Anthropic、OpenAI、Googleは、トレーニング、検索、またはユーザーリクエストによる取得に使用されるクローラーを区別しています。Googleはまた、Google-ExtendedがGoogle検索のインクルージョンやランキングに影響を与えないと述べています。（help.openai.com）

Perplexityも同様に、検索インデックス作成をサポートするPerplexityBotと、ユーザーリクエストに応じてページを取得する可能性のあるPerplexity-Userを区別しています。（docs.perplexity.ai）

クローラーのIDは、公開されたIP範囲またはプロバイダーがサポートしている場合は逆DNSを使用して検証します。ユーザーエージェント文字列は、無関係なクローラーによってコピーされる可能性があります。Googleは特にGooglebotユーザーエージェント文字列が偽装される可能性があると警告しています。（developers.google.com）

収集すべき指標

パフォーマンス指標

ラボデータとリアルユーザーデータの両方を収集します。

• Time to First Byte。
• First Contentful Paint。
• Largest Contentful Paint。
• Cumulative Layout Shift。
• Interaction to Next Paint。
• 総ページサイズ。
• 初期HTMLサイズ。
• 画像転送サイズ。
• リクエスト数。
• サーバー処理に費やされた時間。
• Largest Contentful Paintリソースの待機時間。
• HTTPプロトコル。
• キャッシュステータス。

Googleは、Time to First Byteの目安として800ミリ秒以下を推奨していますが、Time to First Byte自体はCore Web Vitalではありません。（web.dev）

現在のCore Web Vitalsの「良好」のしきい値（75パーセンタイル）は以下の通りです。

• Largest Contentful Paint: 2.5秒以下。
• Cumulative Layout Shift: 0.1以下。
• Interaction to Next Paint: 200ミリ秒以下。（web.dev）

クロール指標

検証済みのすべてのクローラーリクエストについて、以下を記録します。

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

以下を計算します。

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

人工知能引用指標

各プラットフォームで固定されたクエリセットを使用します。クエリセットには以下を含めるべきです。

• 直接的な事実に関する質問。
• 比較に関する質問。
• 「最高の」または推奨に関する質問。
• 鮮度に関する質問。
• テスト対象ページが最も適切な回答となる質問。
• テスト対象ページが関連性はあるが支配的ではない質問。

各クエリについて、以下を記録します。

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

人工知能の回答は変化する可能性があるため、クエリを繰り返します。週に3回などの固定されたスケジュールを使用し、エンジンやモデルの変更を記録します。

Microsoft Bing Webmaster Toolsは現在、サポートされているMicrosoftの人工知能体験全体で引用されたページ、根拠となるクエリ、引用トレンドを示す人工知能パフォーマンスレポートを提供しています。Microsoftは、データが集計され、サンプリングされており、観察的なものであり、特定のページ変更が引用の変更を引き起こしたことを証明できないと警告しています。（bing.com）

Googleも2026年6月にSearch Consoleで専用の生成AIパフォーマンスレポートの展開を開始しました。このレポートは当初、ウェブサイトの一部にのみ利用可能だったため、アクセス状況は異なる場合があります。（developers.google.com）

統計分析

クロール頻度

負の二項モデルのような混合効果計数モデルを使用します。

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

一部のページは当然ながら他のページよりも多くの注目を集め、異なるクローラーは異なるスケジュールを持つため、ページおよびクローラーの効果は重要です。

発見とインデックス作成

以下の項目について生存分析を使用します。

• 公開から最初の取得までの時間。
• 公開から最初のインデックス作成までの時間。
• 更新から再クロールまでの時間。

主要な結果は、単にページが最終的にクロールされたかどうかではありません。治療がページが発見され処理されるのに必要な時間を短縮したかどうかです。

人工知能引用選択

階層ロジスティックモデルを使用します。

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

2つの独立したモデルを実行します。

1. 取得モデル — ページは取得されたか、または候補として表示されたか？
2. 引用モデル — 取得された場合、ページは視覚的に引用されたか？

この区別は不可欠です。クロールを増加させるが取得を増加させないパフォーマンス改善は、人工知能の引用効果ではありません。取得を増加させるが引用を増加させないパフォーマンス改善は、ページが検討されているものの、ソース選択中に却下されたことを示唆しています。

予想される発見

これらは作業仮説であり、主張される実験結果ではありません。

仮説1：Time to First Byteが最も明確なクロール効果を持つだろう

以下の条件下で、Time to First Byteの短縮とクロール能力の間に正の相関関係を期待します。

• サイトに多くのページがある。
• ページが頻繁に変更される。
• オリジンサーバーが遅い、または過負荷になっている。
• サイトが5xxまたは429応答を返す。
• クローラーが応答を待つのにかなりの時間を費やす。

クロール需要の低い小規模なサイトでは、ほとんど測定可能な効果は期待できません。

仮説2：Largest Contentful Paintはレンダリングとリソース配信を通じて重要となるだろう

Largest Contentful Paintの短縮が以下の場合に役立つと期待されます。

• ページがブラウザレンダリングに依存している。
• 重要なコンテンツがJavaScriptの背後にある。
• インデックス作成に大きな画像やスタイルシートが必要である。
• クローラーが多くのページリソースを取得する。
• 遅い治療がタイムアウトまたは不完全なレンダリングを引き起こす。

ページの重要なテキストが初期HTMLにすでに存在する場合、弱い関係を期待します。

仮説3：Cumulative Layout Shiftは直接的な影響がほとんどないだろう

ページの構造とJavaScriptの動作を制御した後でも、Cumulative Layout Shiftとクロール頻度または引用率との間に意味のある直接的な関係は期待されません。

もしCumulative Layout Shiftが引用を予測するように見える場合、それが以下の代理として機能しているかどうかを調査します。

• クライアントサイドレンダリング。
• 遅いコンテンツ挿入。
• 不安定な広告。
• 隠された、または遅延したテキスト。
• 構造の悪いHTML。

仮説4：速度だけでは人工知能の引用は増えないだろう

引用選択の最も強力な予測因子は、以下のままである可能性が高いです。

• クエリへの関連性。
• コンテンツの品質。
• 明確な回答。
• 鮮度。
• 権威と信頼。
• 検索インデックスの適格性。
• 検索ランキング。
• ページが主張されている内容を直接支持しているか。

Googleのガイダンスは、有用で信頼できる、人間中心のコンテンツを強調し、人工知能検索機能は既存の検索およびインデックス作成システムに根ざしていると述べています。（developers.google.com）

人工知能取得のために調整されたパフォーマンス予算

以下は提案される運用予算です。これは公開された人工知能ランキング式ではありません。

Googleの現在のドキュメントによると、Googlebotはサポートされているファイルの最初の2メガバイトを取得し、外部スクリプトとスタイルシートは別々に取得します。また、重要なメタデータと構造化データをHTMLの早い段階に配置することを推奨しています。（developers.google.com）

実装に関する推奨事項

HTTP/3

ホスティングプロバイダーとコンテンツ配信ネットワークがHTTP/3をサポートしている場合は、これを使用します。

測定項目：

• HTTP/3ネゴシエーション率。
• HTTP/2フォールバック率。
• 接続設定時間。
• Time to First Byte。
• 地域ごとのパフォーマンス。
• クローラーごとのパフォーマンス。

HTTP/3を、検索または人工知能の最適化が保証されるものとして扱わないでください。これは、それを使用するクライアントのみに役立つ可能性のあるトランスポートの改善です。

コンテンツ配信ネットワークのエッジキャッシング

公開された、パーソナライズされていないページの場合：

• 明確なCache-Controlルールを設定します。
• バージョン管理された静的アセットには、長期間のキャッシングを使用します。
• 頻繁に更新されるHTMLには、短期間で有用なキャッシングを使用します。
• 不要なクエリパラメータによるキャッシュの断片化を避けます。
• カノニカルURLを保持します。
• ETagとLast-Modifiedをサポートします。
• コールド、ウォーム、および再検証されたキャッシュ状態をテストします。
• クローラーのリクエストが人間のリクエストと同じ重要なコンテンツを受け取ることを確認します。

コンテンツ配信ネットワークは、古くなった、一貫性のない、またはボット固有のページバージョンを作成することなく、レイテンシを削減すべきです。

画像圧縮

画像の場合：

• 視覚的品質が許容できる場合は、AVIFまたはWebPを使用します。
• レスポンシブな画像サイズを提供します。
• 小さなモバイル画面にデスクトップサイズの画像を提供しないでください。
• Largest Contentful Paint画像を遅延読み込みしないでください。
• 画像寸法を含めます。
• Largest Contentful Paint画像を初期HTMLに配置します。
• fetchpriority="high"は、適切な場合にのみ使用します。
• 重要な説明は、画像内にのみ埋め込むのではなく、テキストで保持します。

画像がLargest Contentful Paint要素である場合、画像圧縮は最も価値があります。サーバーレンダリングやJavaScript実行が主な遅延の原因であるページを修正することはありません。（web.dev）

レイアウトの安定性

Cumulative Layout Shiftを減らすために：

• 画像にwidthおよびheight属性を設定します。
• 広告のためにスペースを予約します。
• 埋め込みビデオおよびソーシャルコンテンツのためにスペースを予約します。
• 既存のテキストの上にバナーを挿入することを避けます。
• 安定したフォント読み込み戦略を使用します。
• ページ読み込み後にサーバーレンダリングされた大きなブロックを置き換えることを避けます。

これらの変更は、クロールや引用に測定可能な影響がない場合でも、ユーザーエクスペリエンスを向上させます。（web.dev）

ツールとモニタリング

パフォーマンスツール

以下を使用します。

• リアルユーザーのCore Web VitalsにはChrome User Experience Report。
• 自動化されたフィールドデータ収集にはChrome User Experience Reportアプリケーションプログラミングインターフェース。
• ラボ監査とフィールドデータにはPageSpeed Insights。
• 再現可能なラボテストにはLighthouse。
• プルリクエストのパフォーマンス予算にはLighthouse Continuous Integration。
• 複数ロケーションでのテスト、キャッシュ状態、プロトコル比較にはWebPageTest。
• Largest Contentful PaintとレイアウトシフトのデバッグにはChrome DevTools。
• リアルユーザーモニタリングにはweb-vitals JavaScriptライブラリ。

Chrome User Experience Reportアプリケーションプログラミングインターフェースは、Largest Contentful Paint、Cumulative Layout Shift、Interaction to Next Paint、および実験的なTime to First Byteを含む、ページレベルおよびオリジンレベルの集計フィールドデータを提供します。（developer.chrome.com）

Lighthouse Continuous Integrationは、すべてのコード変更に対してパフォーマンスチェックを実行し、予算を超えた場合にビルドを失敗させることができます。（github.com）

クローラーモニタリング

サーバーログ、エッジログ、および少数の合成プローブを使用します。

プローブの例：

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

同じテストを以下で実行します。

• Googlebot。
• Bingbot。
• OAI-SearchBot。
• PerplexityBot。
• Claude-SearchBot。
• 通常のブラウザユーザーエージェント。

テストは以下を検証すべきです。

• ステータスコード。
• Robotsの許可。
• 応答ヘッダー。
• HTMLコンテンツ。
• HTTPバージョン。
• キャッシュ状態。
• 応答時間。
• JavaScriptなしで重要なテキストが存在するかどうか。

検索およびインデックス作成モニタリング

以下を使用します。

• Google Search Consoleのクロール統計。
• Google Search Consoleのページインデックスレポート。
• Google Search ConsoleのURL検査。
• Google Search Consoleのサイトマップデータ。
• 利用可能な場合はGoogle Search Consoleの生成人工知能レポート。
• Bing Webmaster Toolsのクロールリクエストとインデックスされたページ。
• Bing Webmaster Toolsの人工知能パフォーマンス。
• 日次のサイトマップとlastmodチェック。

Search Consoleアプリケーションプログラミングインターフェースは、データ制限に従い、ページ、クエリ、日付、デバイス、検索結果表示形式ごとのパフォーマンスデータを取得できます。（developers.google.com）

引用モニタリング

トピックごとに50〜200個の安定したクエリを含む引用パネルを作成します。パネルを固定スケジュールで実行し、以下を記録します。

• プラットフォームが検索したかどうか。
• どのソースが表示されたか。
• テスト対象URLが引用されたかどうか。
• 引用順序。
• 回答の日時。
• ページが変更されたかどうか。
• モデルまたは検索体験が変更されたかどうか。

異なるシステムからの引用数を同等であるかのように比較しないでください。Microsoftは、引用活動はランキングスコア、権威スコア、トラフィック測定値、または品質スコアではないと述べています。（bing.com）

アラートルール

以下のアラートを作成します。

• Time to First Byteが25パーセント以上増加した場合。
• Largest Contentful Paintが75パーセンタイルで2.5秒を超えた場合。
• Cumulative Layout Shiftが0.1を超えた場合。
• 5xxまたは429応答の持続的な増加。
• クローラーの成功率の低下。
• robots.txtの変更。
• サイトマップエラー。
• インデックスされたページの急落。
• 複数のプラットフォームでの人工知能引用の急落。
• 単一のプラットフォームにのみ影響する引用量の変化。

単一のプラットフォームに影響する引用の減少は、ページパフォーマンスの問題ではなく、モデル、インデックス、クエリ、または製品の変更によって引き起こされる可能性があります。Microsoftは、引用トレンドは観察的なものであり、コンテンツの更新、ユーザー需要、システムまたはモデルの変更によって変化する可能性があると明示的に警告しています。（bing.com）

最終結論

最も擁護できる結論は次のとおりです。

ページの高速化は、特にサーバーレイテンシ、リソースサイズ、エラー、またはレンダリング遅延が制限要因である場合に、クロールの効率を向上させることができます。しかし、Core Web Vitalsの低下が人工知能システムにページを引用として選択させる直接的な原因であるという強力な証拠は現在ありません。

予想される因果関係は次のとおりです。

text レイテンシの短縮 → サーバー容量の改善 → 失敗または遅延した取得の減少 → 発見と処理の高速化 → インデックス作成と検索される機会の向上 → 引用の増加の可能性

最後の段階は不確実なままです。引用の選択は、関連性、品質、鮮度、権威、クエリ意図、検索ランキング、および各人工知能システムの動作に依存するためです。

したがって、ほとんどのウェブサイトにとって、正しいパフォーマンス戦略は「人工知能の引用のために単独で最適化する」ことではありません。それは次のとおりです。

1. 重要なコンテンツを初期HTMLで利用可能に保つ。
2. Time to First Byteを安定させる。
3. 公開コンテンツにエッジキャッシングを使用する。
4. 重要な画像を圧縮し、優先順位を付ける。
5. レイアウトシフトを防ぐ。
6. 信頼性の高いステータスコードを返す。
7. サイトマップと内部リンクを最新に保つ。
8. 正しい検索クローラーを許可する。
9. クロール、インデックス作成、検索、引用を別々の段階として測定する。

このアプローチは、人々にとってより高速なウェブサイト、検索クローラーにとってより健全なサイト、そして人工知能の可視性を理解するためのテスト可能な基盤を生み出します。