ページ速度はAIクローラに影響するか

ページの表示速度がGoogle検索のランキングに影響することは広く知られています。では、AI検索のクローラに対してもページ速度は重要なのでしょうか。

結論から言えば、「ランキング要因」としての影響は不明ですが、「クロール効率」への影響は確実にあります。レスポンスが遅いページはクローラのタイムアウトでクロール自体が失敗し、AIに認識されない可能性が高まります。

クローラのタイムアウト

Webクローラは、リクエストからレスポンスまでの時間に制限（タイムアウト）を設けています。 AIクローラの正確なタイムアウト値は公開されていませんが、サーバーログの分析から5〜15秒程度と推定されます。

サーバーの応答に5秒以上かかるページは、AIクローラにクロールされないリスクがあります。

レスポンス速度とクロール効率

クローラは1回のセッションで複数ページを巡回します。 1ページあたりのレスポンス速度が、セッション全体でクロールできるページ数に影響します。

平均レスポンス 200ms → 1分間に約300ページ
平均レスポンス 2秒  → 1分間に約30ページ
平均レスポンス 5秒  → 1分間に約12ページ

Googlebotの場合、レスポンスが遅いサイトにはクロールバジェットを少なく配分することが知られています。 AIクローラも同様の挙動をしている可能性が高いです。

TTFBが最も重要な指標

ページ速度の指標のうち、クローラにとって最も重要なのはTTFB（Time To First Byte）です。リクエスト送信からサーバーが最初の1バイトを返すまでの時間を指します。

ブラウザの速度指標             クローラに関係するか
─────────────────────────────────────────
TTFB                          関係する
FCP (First Contentful Paint)  関係しない
LCP (Largest Contentful Paint) 関係しない
CLS (Cumulative Layout Shift)  関係しない

クローラはHTMLを受け取るだけで、レンダリングは行いません。 Core Web Vitalsのうち、クローラに直接影響するのはTTFBだけです。

TTFBの計測

# curlでTTFBを計測
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" \
  https://example.com/blog/target-page

# 複数ページを一括計測
for url in https://example.com/ https://example.com/blog/ https://example.com/products/; do
  ttfb=$(curl -o /dev/null -s -w "%{time_starttransfer}" "$url")
  echo "$ttfb s  $url"
done

TTFB	評価
200ms未満	良好
200ms〜600ms	許容範囲
600ms〜1秒	改善推奨
1秒超	要改善

速度低下の主な原因

サーバーサイドの処理遅延

データベースクエリの遅延がTTFBを直接押し上げます。クローラへの影響が最も大きい要因です。

# 悪い例：N+1クエリ
def get_articles():
    articles = db.query("SELECT * FROM articles LIMIT 100")
    for article in articles:
        article.author = db.query(
            "SELECT * FROM authors WHERE id = ?", article.author_id
        )
    return articles

# 良い例：JOINで一括取得
def get_articles():
    return db.query("""
        SELECT a.*, au.name as author_name
        FROM articles a
        JOIN authors au ON a.author_id = au.id
        LIMIT 100
    """)

リダイレクトチェーン

複数のリダイレクトが連鎖すると、最終ページに到達するまでの時間が増えます。

# リダイレクトチェーンを確認
curl -sIL https://example.com/old-page 2>&1 | grep -E "^(HTTP/|Location:)"

リダイレクトは最大でも1回に抑えてください。多くのクローラは3〜5回で追跡を中止します。

大きなHTMLファイル

HTML単体で200KBを超える場合は、ページの分割やインラインCSSの削減を検討してください。

CDNとキャッシュ

AIクローラのリクエストは世界各地のデータセンターから来ます。 CDNでエッジからレスポンスを返すことで、TTFBを大幅に短縮できます。

CDNなし：クローラ（米国）→ オリジン（日本）→ TTFB 500ms〜1秒
CDNあり：クローラ（米国）→ エッジ（米国）→ TTFB 50ms〜200ms

ブログ記事のように頻繁に更新しないページは、CDNキャッシュが有効です。

サーバーログでの確認

ページ速度がクローラに影響しているかを、サーバーログで確認できます。

# AIクローラのリクエストとレスポンスタイムを抽出
grep -E "GPTBot|ClaudeBot|PerplexityBot" /var/log/nginx/access.log \
  | awk '{print $7, $9, $NF}' \
  | head -20

以下のパターンが見られたら問題があります。

レスポンスタイムが3秒を超えるリクエストが多い
ステータスコード408（Timeout）や504（Gateway Timeout）の発生
特定ページだけクロール頻度が低い

速度改善の優先度

GEO対策の観点での優先度です。

最優先：タイムアウト回避。 TTFBが3秒を超えるページは、クロール失敗のリスクが高いため最優先で改善してください。データベースクエリの最適化、サーバーサイドキャッシュ、CDN導入が有効です。

中優先：クロール効率の向上。 TTFBが1秒以下でもタイムアウトリスクは低いですが、200ms以下にするとクロール対象ページ数が増えます。

低優先：ブラウザのレンダリング速度。 LCP、CLS、INPはユーザー体験とGoogle検索には重要ですが、AIクローラのクロール効率とは直接関係しません。

レスポンスコードの適切な返却

200 → 正常にクロール
301 → リダイレクト先をクロール
404 → クロール対象から除外
429 → レート制限。時間をおいてリトライ
503 → 一時的に利用不可。Retry-Afterヘッダに従う

サーバー負荷が高い場合は503を返して Retry-After ヘッダでリトライ待ち時間を指定してください。

定点観測の仕組み

import requests
import time
import json
from datetime import datetime

def measure_ttfb(url: str, count: int = 5) -> dict:
    ttfbs = []
    for _ in range(count):
        start = time.time()
        requests.get(url, timeout=10)
        ttfbs.append(round((time.time() - start) * 1000))
        time.sleep(1)
    ttfbs.sort()
    return {
        "url": url,
        "min_ms": ttfbs[0],
        "median_ms": ttfbs[len(ttfbs) // 2],
        "max_ms": ttfbs[-1],
        "measured_at": datetime.now().isoformat(),
    }

主要ページのTTFBを週次で計測し、3秒を超えるページがないかを監視してください。

まとめ

ページ速度がAIクローラに与える影響は、「ランキング要因」ではなく「クロール可否」の問題です。 TTFBが3秒を超えるとクロール失敗のリスクがあり、1秒を超えるとクロール効率が低下します。

GEO対策でページ速度を改善する場合、Core Web Vitalsの最適化よりもサーバーの応答速度（TTFB）の改善を優先してください。 CDN導入、サーバーサイドキャッシュ、データベースクエリの最適化が効果の高い施策です。