AI エージェントの SEO チェック：エージェントに実際に見えているもの

AI エージェントにページの SEO チェックを頼むと、エージェントはたいてい、テキストに変換されたページをもとに作業します。見出しと本文は届きますが、HTTP ステータス、レスポンスヘッダー、リダイレクトの経由、head 内のタグ、構造化データは、たいてい届きません。そのためエージェントは文章のレビューは上手にこなせても、検索エンジンがページをインデックスに登録するかどうかを左右する要素の大半は確認できません。

取得ツールはアシスタントによって異なり、時とともに変わるため、問うべきはエージェントが何を受け取ったかです。2026 年 10 月、私たちは自社のページの 1 つでこの問いに答えるため、完全な HTTP のやり取りを、エージェントが作業に使うテキスト表示と並べて記録しました。この記事では、実際に実行した内容、それぞれの表示に含まれていたもの、そしてエージェントに欠けている証拠を渡す方法を報告します。

自社のページを 2 通りの方法で取得した

公開済みの記事であるリダイレクト チェーンのガイドを選び、チャットに貼り付けられそうな長いアドレス http://www.seoreport.dev/articles/redirect-chains-guide/ でリクエストしました。素の HTTP、www ホスト、末尾のスラッシュはいずれもサイトが正規化するバリエーションなので、このリクエストは必ずリダイレクトされます。

ページは 3 つの方法で読み取りました。

1. 完全な HTTP のやり取り。 curl を使い、すべての経由、最終的なステータス行、すべてのレスポンスヘッダー、生の HTML を記録しました。
2. 同じ HTML からのプレーンテキスト抽出。 スクリプト、スタイル、<head> を取り除き、表示されるテキストを残しました。多くの取得ツールが、アシスタントにページを読ませる前に行っている変換です。
3. ある AI コーディング アシスタントに組み込まれた取得ツール。 受け取ったコンテンツに文字どおり含まれていたものだけを、項目ごとに報告するよう求めました。

ここで重要な項目については 2 と 3 の表示がすべて一致したため、表ではまとめて示しています。唯一の違いは、取得ツールがページのタイトルを渡したのに対し、プレーンテキスト抽出では同じ文言を持つ H1 が残ったことです。

サイズで見ると、71 KB の HTML レスポンスのうち、テキスト表示は約 10 KB でした。失われたものの大部分はスクリプトとスタイルのコードで、SEO のレビューには必要ありません。残りは、まさに SEO のレビューが読むべき証拠です。

表の中でも、件数より重要な点が 2 つあります。1 つ目は、canonical タグについての回答が、尋ね方によって変わったことです。各タグについて「ある」か「ない」かを答えるよう求めると、取得ツールは、ページに実際にある canonical を「ない」と回答し、<head> に関する注意書きを後から付け加えただけでした。「判断できない」という選択肢を与えると、そちらを選びました。最初の回答を受け取ってそのまま行動するエージェントは、すでに存在するタグの追加を勧めることになります。2 つ目は、Article の JSON-LD と article:modified_time タグがどちらも 2026 年 10 月 3 日という更新日を持っているのに、表示される署名欄には 2026 年 9 月 28 日という公開日しかなかったことです。検索エンジンが「最終更新日」として読み取れる日付は、エージェントが受け取らなかった部分にしか存在しません。

このページに誤りは何もありませんでした。2 回のリダイレクトは、Google のクロールに関するドキュメントがクローラーの追跡上限としている 10 回を十分に下回っており、canonical もページ自身を指しています。わかったのは、どちらが正しいかをエージェントは知りようがなかった、ということです。

取得ツールがステータスを報告したのは、ページの取得に失敗したときだけだった

サイトに存在しないアドレスで同じテストを繰り返しました。サーバーは 404 を返し、取得ツールはそれを伝えました。「HTTP 404 Not Found」と報告し、ページのテキストは返さなかったのです。正常なページでは、200 について一度も触れませんでした。

エラーは表に出るが、成功したレスポンスについては何も言わない。このパターンでは、最も厄介なケースが抜け落ちます。どれも 200 を返すからです。

• 存在しないように読めるのに 200 を返すページ。 私たちの 404 ページには「Article Not Found. The article you are looking for does not exist.」と書かれています。サーバーが同じテキストを 200 のステータスで送ったとしても、テキスト表示はまったく同じです。どちらなのかを検索エンジンに伝えるのはステータス行だけであり、Google が 200 のほうを検出すると、Search Console は「ソフト 404」と報告します。
• 申し分なく読めるのに、検索エンジンにインデックス登録しないよう伝えているページ。 Google の robots メタタグに関するドキュメント（2026 年 10 月に確認）によると、robots メタタグで使えるルールはすべて、X-Robots-Tag HTTP ヘッダーとしても送ることができます。この方法で送られた noindex は、テキストに一切痕跡を残しません。こうしたページの見つけ方と判断の仕方は、Search Console の「URL に noindex が指定されています」で解説しています。
• canonical をヘッダーで指定しているページ。 Google は、rel="canonical" を付けた Link レスポンスヘッダーを、HTML タグの代わりに使える方法として説明しており、PDF のような HTML 以外のファイルにも使えます。テキスト表示ではこれを確認できません。

証拠はページの上ではなく、やり取りの中にある

テキスト表示で失われたものはすべて、同じ種類に属します。サーバーとクローラーの間でやり取りされ、ページを読む訪問者の目には決して触れない証拠です。それは 6 つの場所に分かれます。

ステータスとリダイレクト。 経由するたびに、それぞれ独自のステータスコードを持つ別々のレスポンスがあります。取得ツールの中にはリクエスト前に http:// を https:// に書き換えるものがあり、その場合 HTTP から HTTPS へのリダイレクトはそもそもリクエストされません。どの経由を残すべきかは、リダイレクトと URL 正規化のガイドで解説しています。

レスポンスヘッダー。 X-Robots-Tag、Link、Cache-Control、Vary、各種セキュリティヘッダーは、いずれも HTML より前に送られます。どれもページ上のテキストではありません。

head 内のタグ。 canonical、meta robots、hreflang、メタディスクリプション、Open Graph のタグは <head> 内にあり、テキスト変換で取り除かれます。

構造化データ。 JSON-LD は <script> 要素の中にあります。テキスト変換はスクリプトを取り除くため、JSON-LD も一緒に消えます。何を含めるべきかは、構造化データとソーシャル メタデータのガイドで説明しています。

生の HTML とレンダリング後の HTML。 ページを変換する前に JavaScript を実行する取得ツールもあれば、実行しないものもあり、出力にどちらなのかが書かれていることはほとんどありません。JavaScript の実行後にしかコンテンツが現れないページは、あるツールには完全に、別のツールには空っぽに見えることがあります。この差がどのくらいの頻度で生じるかは、AI クローラーに実際に見えているもので測定しています。

URL の外にあるファイルやページ。 robots.txt は別のファイルで、頼まれない限りエージェントがリクエストすることはありません。Google のドキュメントによると、robots.txt でページがブロックされていると、Google はそのページの noindex をまったく読めないため、両者はセットで確認する必要があります。サイトマップ、内部リンク、重複 URL は、まったく別のページにあります。

sequenceDiagram
    participant U as あなた
    participant A as AI エージェント
    participant F as 取得ツール
    participant S as あなたのサイト
    U->>A: このページの SEO をチェックして
    A->>F: URL を取得する
    F->>S: GET http://www.example.com/page/
    S-->>F: 301 と Location ヘッダー
    F->>S: GET https://example.com/page/
    S-->>F: 301 と Location ヘッダー
    F->>S: GET https://example.com/page
    S-->>F: 200、レスポンスヘッダー、HTML 全体
    Note over F: 経由、ステータス、ヘッダー、head 内のタグ、JSON-LD を破棄
    F-->>A: 表示テキストを Markdown で渡す
    A-->>U: テキストだけに基づく助言

検出する SEO の問題の大半はページのテキストの外にある

レビューのどれだけが、テキスト表示で失われるものに依存しているかは、私たち自身の監査データからわかります。2026 年 5 月から 10 月に SEOReport が監査した外部ウェブサイト 45 件では、検出した 506 件の問題のうち 94% が、ページを読む人には決して見えない場所にありました。レスポンスヘッダー、head 内のタグ、構造化データ、XML サイトマップ、robots.txt、リダイレクト、ページ同士の関係です。

次のグラフは、同じ 506 件の問題を、その証拠を確認するために人が見なければならない場所ごとに分類したものです。

テキスト表示に残る種類の証拠は、ページの表示コンテンツにある 5.9% だけです。それ以外の所在は、エージェントがそれを見るために何を受け取る必要があるかで分けると、3 つのグループになります。HTTP ステータスとヘッダー、head 内のタグ、構造化データは、合わせて 506 件の 69% を占めます。ページ自身のレスポンスの中に届いているのに、テキスト変換で捨てられてしまう証拠です。テキスト抽出を改善しても取り戻せませんが、レスポンスそのものを読めば取り戻せます。XML サイトマップ、まとめて読んだ記事群、ページ同士の関係、robots.txt は合わせて約 20% で、どのページのレスポンスにも含まれない証拠です。残りの 5.6% には、ページやそのアドレスをもう 1 つ別の視点から見る必要があります。生の HTML と並べたレンダリング後のページ、デスクトップ向けと並べたスマートフォン向けのレスポンス、あるいはページの手前にあるリダイレクトの経由です。

同じサンプルでサイトごとの影響も見えます。45 サイトのすべてで、ページの表示テキストの外に 1 件以上の問題が見つかり、24 サイト（53%）では検出した問題がすべて表示テキストの外にありました。この 24 サイトでは、表示テキストに限ったレビューの手元には、検出された証拠が 1 つもなかったことになります。

エージェントに欠けている証拠を渡す方法

エージェントは、見えている証拠については的確に推論します。解決策は、やり取りそのものをエージェントの前に置くことです。

エージェントがシェルを使えるなら、次のコマンドを実行させ、結論を出す前に生の出力を見せるよう頼んでください。使えない場合は、自分で実行して出力をチャットに貼り付けます。

# 1. Every hop, every status, the headers that matter (GET, following redirects)
curl -sL -D - -o /dev/null http://www.example.com/page/ \
  | grep -iE '^(HTTP/|location|x-robots-tag|link|content-type|cache-control|vary)'

# 2. Canonical, hreflang and meta robots tags from the raw HTML
curl -s https://example.com/page \
  | grep -oiE '<link[^>]*rel="(canonical|alternate)"[^>]*>|<meta[^>]*name="robots"[^>]*>'

# 3. How many JSON-LD blocks the raw HTML contains
curl -s https://example.com/page | grep -o 'application/ld+json' | wc -l

# 4. The crawl rules that apply to the page
curl -s https://example.com/robots.txt

回答の信頼性を高める 3 つの習慣があります。

• HEAD ではなく GET を使う。 サーバーによっては 2 つに異なる応答を返します。私たちのサーバーもそうでした。テストの最初の経由は、GET リクエストには 301、HEAD リクエストには 308 を返しました。
• 何が問題かを尋ねる前に、何を受け取ったかを尋ねる。 「見えているステータスコード、ヘッダー、head 内のタグを列挙して」と頼めば、隠れていた欠落が目に見えるようになり、どの「ない」が「受け取っていない」という意味なのかがわかります。
• HTML がレンダリングされたものかどうかを尋ねる。 エージェントのツールが JavaScript を実行していれば、その表示はサーバーが送るものと異なる可能性があります。JavaScript レンダリングのガイドで説明しているとおり、コマンド 2 で得た生の HTML と比べてください。

1 ページを完全にチェックしても、それは 1 ページにすぎない

完全なやり取りが手元にあれば、エージェントは 1 つのページを適切にレビューできます。レスポンスに含まれ得ないのは、サイトの残りの部分です。サイトマップにそのページが掲載されているか、他のページからリンクされているか、別の URL がそのページと重複していないか、サイトマップで告知しているページを robots.txt がブロックしていないか、といったことです。上のサンプルでは、検出した問題のおよそ 5 件に 1 件が、どのページのレスポンスにも現れない場所にありました。これらを網羅するには、多数のページ、多数のセッションにわたって、毎回同じ手法で作業を繰り返す必要があります。それが1 回の AI セッションではサイト全体を監査できない理由のテーマです。

SEOReport の完全な診断は、そうしたサイト単位の作業の多くを 1 つのレポートで行います。サイトマップに掲載されたページをリクエストし、送信されたアドレスをすべてのリダイレクトの経由をたどって追跡し、robots.txt を読み、ホームページの生の HTML とレンダリング後のページを比較します。各検出結果には証拠（ステータスコード、ヘッダーの値、影響を受ける URL）が付き、ページのサンプルに基づく検出結果には調べたページ数が記載されます。エージェントは MCP サーバーと REST API を通じてこのレポートを作成して読み取れるので、テキストではなくサイトの証拠から作業を始められます。

よくある質問

ChatGPT でウェブサイトの SEO をチェックできますか？

届いたコンテンツはレビューできます。見出し、本文、そしてツールが渡せばタイトルです。ステータスコード、ヘッダー、head 内のタグ、構造化データまで見えるかどうかは、その時点で使われる取得ツールによって変わり、それが明示されることはほとんどありません。まず受け取った内容を列挙するよう頼むか、上のコマンドの出力を貼り付けてください。

AI の SEO チェッカーは SEO 監査と同じですか？

AI の SEO チェッカーは通常、ツールが返したコンテンツをもとに 1 ページをレビューします。監査は、HTTP のやり取り、robots.txt、サイトマップ、ページ同士の関係を読み、検出結果ごとに証拠を記録して、結果を検証し再現できるようにします。両者が答える問いは異なります。一方はページの文章をレビューし、もう一方はサイトがクローラーに何を配信しているかを明らかにします。

canonical タグがあるのに、エージェントが「ない」と言ったのはなぜですか？

canonical タグは <head> 内にあり、テキスト変換で取り除かれるからです。私たちのテストでも、取得ツールは実際にある canonical を「ない」と回答しました。こうした助言に従う前に、上のコマンド 2 か、ブラウザでページのソースを表示して確認してください。

エージェントの取得ツールが JavaScript を実行するかどうかは重要ですか？

コンテンツやタグが JavaScript に依存している場合は重要です。ページをレンダリングするツールは、生の HTML にはないタイトルや H1 を報告することがあり、レンダリングしないツールは、ブラウザでは完全に表示されるページをほぼ空と報告することがあります。生の HTML とレンダリング後のページを比べれば、検索エンジンやその他のクローラーが最初に受け取るのがどちらなのかがはっきりします。