AI SEO 監査：1 回のセッションでサイト全体を調べられない理由

AI アシスタントは、1 ページのレビューなら上手にこなします。渡されたタイトル、見出し、本文を読み、どこを変えるべきかを説明してくれます。しかし、1 回の AI セッションでウェブサイト全体を監査することはできません。理由は 2 つあります。第一に、SEO 監査に必要な証拠のほとんどは、アシスタントが読むページのテキストの中にはありません。レスポンスヘッダー、robots.txt、XML サイトマップ、リダイレクト、そしてページ同士の関係の中にあります。第二に、ある程度の規模を超えると、サイトの URL 数は 1 回のセッションで読んで同時に比較できる量を上回ります。影響が大きいのは第一の理由であり、モデルを大きくしても小さくはなりません。

2026 年 5 月から 10 月に SEOReport が監査した外部ウェブサイト 45 件では、検出した 506 件の問題のうち 94% が、ページを読む人には決して見えない場所にありました。この記事では、網羅範囲の計算、その証拠がどこにあるか、そして修正に取りかかる前にサイト単位の診断をアシスタントに渡すことで、AI を使ってウェブサイトを監査する方法を説明します。2 つの手法を比較したAI によるスポットチェックが体系的な SEO 監査の代わりにならない理由の続編にあたり、今回のテーマは数字です。

1 回のチャットセッションが扱うものと、サイト監査が記録するもの

チャットでの AI ウェブサイト監査は、たいてい 1 つの URL から始まります。アシスタントの取得ツールがそのページをリクエストし、受け取った内容を、多くの場合は読みやすいテキストに変換して返します。会話はそのテキストをもとに進みます。体系的な監査は、その 1 段上、つまりサイトから始まります。ホスト全体を制御するファイルを読み、リクエストした URL ごとに HTTP レスポンスを記録し、生の HTML とレンダリング後のページを比較し、さらにページ同士、ページとサイトマップを比較します。

1 つの URL をたどる方法にも意味はあります。ただしそれは、数多くの経路を持つサイトの中の 1 本にすぎず、各段階で何かが失われる可能性があります。テキストへの変換では、訪問者が読む文章は残りますが、head 内のタグやレスポンスヘッダーが落ちることがあります。そして次のセッションは、今回のセッションが読んだページを持たない状態で始まります。

アシスタントに監査を任せるサイトの規模はどのくらいか

2026 年 5 月から 10 月に SEOReport が監査した外部ウェブサイト 45 件のうち、15 件（33%）は、robots.txt に記載されたアドレスにも /sitemap.xml にも XML サイトマップがありませんでした。サイトマップに 1 件以上の URL が掲載されていた 29 サイトでは、掲載 URL 数の中央値は約 90 件でした。4 分の 1 のサイトは 20 件以下、4 分の 1 は 440 件超、上位 10 分の 1 は 3,000 件超を掲載していました。

これらは SEOReport の監査に送信されたウェブサイトであり、ウェブ全体から無作為に抽出したサンプルではなく、小規模なサイトに偏っています。それでもばらつきは大きく、上位 10 分の 1 のサイトは、下位 4 分の 1 のサイトの 150 倍を超える URL を掲載しています。想定されるアドレスにサイトマップがない 3 分の 1 のサイトも見逃せません。こうしたサイトには、アシスタントやクローラーが探す場所にページの一覧がないため、リンクをたどって 1 回ずつ取得しながらページを見つけるしかありません。

サイト全体の AI SEO 監査には何回のセッションが必要か

次の表は測定値ではなくモデルです。上記のサイトマップの規模を、1 回のセッションで全文を読み、並べて比較できると仮定したページ数で割っています。前提は次のとおりです。

• セッションは各サイトマップ URL を 1 回ずつ全文読み込み、他のページと比較できる状態で保持する。
• 容量は、1 セッションあたり 25 ページと 100 ページの 2 通りを示す。どちらも説明のための値です。実際の容量はアシスタント、その取得ツール、各ページの重さによって変わり、私たちは測定していません。
• 数えるのはサイトマップの URL だけ。robots.txt、レスポンスヘッダー、リダイレクトの経由、レンダリング後のページの分だけ作業は増えるため、どの数値も下限値です。

サイトマップを持つ 29 サイトのおよそ半数では、余裕のある仮定ならサイトマップ全体が 1 回のセッションに収まります。チャットでのレビューが最も正当化しやすいのはこの範囲です。中央値を超えるとセッション数はサイトの規模に応じて増え、しかも複数のセッションを足し合わせても 1 つの監査にはなりません。

アシスタントにメモリ機能があるか、メモを次のセッションに貼り付けない限り、新しいセッションは前のセッションが読んだページを持たずに始まります。メモに残るのは結論です。後で比較するには証拠そのもの、たとえば 12 ページ目の正確な正規 URL や、340 ページ目のリダイレクトの裏にあるステータスコードが必要です。さらに、毎回自分で進め方を決めるセッションは、バッチごとに異なる項目を確認することがあり、バッチ 7 とバッチ 8 が同じ基準で測られるとは限りません。

SEO の証拠の多くは、貼り付けたページの中にはない

セッション数は小さいほうの問題です。次のグラフは、2026 年 5 月から 10 月に SEOReport が監査した外部ウェブサイト 45 件で検出した 506 件の問題を、その証拠を確認するために人がどこを見なければならないかで分類したものです。94% は、ページを読む人には決して見えない場所にありました。レスポンスヘッダー、head 内のタグ、構造化データ、XML サイトマップ、robots.txt、リダイレクト、ページ同士の関係です。

同じ 45 サイト（2026 年 5 月〜10 月）では、すべてのサイトでページの表示テキストの外に 1 件以上の問題が見つかり、24 サイト（53%）では検出した問題がすべて表示テキストの外にありました。1 サイトあたりの問題が見つかった証拠の所在は中央値で 5 か所、4 分の 1 のサイトでは 6 か所以上でした。セキュリティヘッダーを完全に除いても、残りの問題の 91% は依然としてページの表示テキストの外にありました。

所在ごとに、確認の方法も異なります。

• HTTP レスポンス。 Google のインデックス登録のブロックに関するドキュメント（2026 年 10 月に確認）によると、noindex は X-Robots-Tag レスポンスヘッダーで送ることができます。また、正規 URL の指定に関するドキュメントによると、rel="canonical" は HTTP の Link ヘッダーで送ることができます。どちらもページのテキストには一切現れません。
• robots.txt。 Google の robots.txt に関するドキュメント（2026 年 10 月に確認）によると、このファイルは最上位のディレクトリに置く必要があり、そのルールはファイルを配信したホスト、プロトコル、ポートにだけ適用されます。robots.txt とクロールアクセスのガイドで説明しているとおり、www.example.com と shop.example.com はそれぞれ別のファイルに従います。
• 生の HTML とレンダリング後のページ。 Google の JavaScript SEO に関するドキュメント（2026 年 10 月に確認）によると、Google はレンダリング後の HTML を使ってページをインデックスに登録します。canonical を置く最適な場所は HTML であり、JavaScript で別の URL に変更すべきではないこと、そして Google は noindex を検出するとレンダリングを省略する場合があることも書かれています。SEOReport がサーバーの生の HTML とレンダリング後のページを比較した外部サイト 34 件（2026 年 5 月〜10 月）のうち、7 件（21%）は、検索エンジンが最初に読むものを JavaScript に頼っていました。タイトル、メタディスクリプション、canonical、H1 が JavaScript の実行後にしか現れないか、生の HTML にページのテキストがほとんど含まれていなかったのです。変換後のテキストを読むアシスタントが見ているのはこの 2 つのうちどちらか一方であり、それがどちらなのかが会話の中で明示されることはほとんどありません。

ページ間にしか存在しない問題がある

同じ外部サイト 45 件（2026 年 5 月〜10 月）のうち、32 件（71%）には、どの URL を単独で見ても確認できない問題が 1 件以上ありました。サイトマップと掲載ページを比較したとき、ページ同士を比較したとき、あるいはサイト内の記事群をまとめて読んだときにだけ現れる問題です。記事群に関する問題を除いても、45 件中 28 件（62%）が該当します。

架空のサイトで、こうした証拠がどのように見えるかを示します。

# https://www.example.com/robots.txt
User-agent: *
Disallow: /checkout/

# https://www.example.com/sitemap.xml lists
https://www.example.com/checkout/
https://www.example.com/old-services/      (answers 301)

# https://www.example.com/en/services/ declares
hreflang="es" -> https://www.example.com/es/servicios/

# https://www.example.com/es/servicios/ declares
no hreflang link back to /en/services/

どのファイルも単独では正しく見えます。問題は、これらを合わせて読んだときにだけ現れます。

• サイトマップがページと矛盾している。 Google のサイトマップに関するドキュメント（2026 年 10 月に確認）によると、サイトマップに掲載しても URL のクロールやインデックス登録は保証されず、正規化に関するドキュメントではサイトマップへの掲載を弱い canonical シグナルとしています。リダイレクトする URL、ブロックされた URL、noindex が付いた URL を掲載すると、矛盾したシグナルを送ることになります。SEOReport がサイトマップのページを取得した外部サイト 29 件（2026 年 5 月〜10 月）のうち、8 件（28%）に、リダイレクトする、noindex が指定されている、または robots.txt でブロックされているサイトマップ URL が 1 件以上ありました。
• robots.txt が noindex を隠している。 Google のドキュメントによると、robots.txt でブロックされたクローラーはページの noindex を読むことができず、他のページからリンクされていれば URL がインデックスに登録される可能性があります。これを見つけるには robots.txt とページを一緒に見る必要があり、インデックス可否の矛盾に関する分析で詳しく扱っています。
• 戻りリンクのない hreflang。 Google のローカライズ版に関するガイド（2026 年 10 月に確認）には、「2 つのページが相互にリンクしていない場合、タグは無視されます」と明記されています。hreflang 実装ガイドで示しているとおり、これを確認するには両方のページが必要です。
• 問題のある URL を指定先とする canonical。 リダイレクトするページや noindex が付いたページを指定している canonical は、指定先も取得して初めて見えてきます。

チャットセッションでも、たまたま両方の材料が揃っていれば、これらの問題を見つけられます。しかしセッションが多数に分かれると、2 つの材料は簡単に別々の会話に入ってしまい、どちらの会話でも問題は見えません。

AI によるウェブサイト監査が実際に何を対象にしたかを確認する方法

アシスタントの監査結果をもとに動く前に、4 つのことを尋ねてください。取得した URL の一覧、読み込んだ robots.txt の行、ホームページのステータスコードとヘッダー、そして生の HTML とレンダリング後のページを比較したかどうかです。示せない項目があれば、その項目は監査の対象外だったものとして扱います。そのうえで、アシスタントの URL 一覧を自分のサイトマップと比べます。

同じ証拠は、3 つのコマンドで自分でも集められます。

curl -s https://www.example.com/robots.txt
curl -s -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|location|x-robots-tag|link)'
curl -s https://www.example.com/sitemap.xml | grep -o '<loc>' | wc -l

2 つ目のコマンドは通常の GET リクエストを送り、レスポンスヘッダーだけを表示します。robots.txt に記載されたサイトマップのアドレスが /sitemap.xml と異なる場合は、そちらを使ってください。サイトマップがインデックス ファイルの場合、最後の数は子サイトマップの数であり、ページ数ではありません。また、アシスタントがそもそもページを受け取れたかどうかも確認してください。2026 年 5 月から 10 月に SEOReport に送信された外部ウェブサイト 377 件のうち、少なくとも 51 件（13.5%）は自動クローラーにホームページを評価させず、少なくとも 34 件（9%）はボットチャレンジや CAPTCHA を返しました。アシスタントの取得ツールも自動クライアントです。チャレンジページに当たっていたなら、アシスタントがレビューしたのはそのチャレンジページです。このケースはクローラーをブロックするボット対策の記事で扱っています。

アシスタントにはサイト単位の監査を渡し、修正を任せる

アシスタントが力を発揮するのは、診断の後の作業です。検出結果の説明、テンプレートの変更案の作成、リダイレクトマップの下書き、タイトルの書き直しなどです。セッションに欠けているのは、サイト単位で再現可能なインプットです。SEOReport の完全な診断がそれを提供します。robots.txt とサイトマップを読み、ホームページと、サイトマップに掲載され内部リンクが指しているページのサンプルを調べ、リクエストした各ページの HTTP ステータスを記録し、ホームページの生の HTML とレンダリング後のページを比較します。ページと矛盾するサイトマップの項目、存在しないページへの内部リンク、ほぼ重複した記事など、ページをまたいでしか存在しない検出結果も報告します。各検出結果には証拠が付き、影響を受ける URL が明示され、サンプルに基づく検出結果には調べたページ数が記載されます。どの診断も定義済みの同じチェックを同じ方法で実行するため、同じサイトの 2 つのレポートを検出結果ごとに比較できます。

エージェントは、MCP サーバーと REST API を通じてレポートを作成し、完了を確認し、すべての検出結果を読み取れます。そうすればエージェントのセッションは診断から始まり、容量を修正作業に使って、検出結果を 1 件ずつ処理できます。この構成はエージェント向けページで説明しています。

よくある質問

ChatGPT で SEO 監査はできますか？

十分な能力を持つアシスタントなら、渡されたページや取得できたページをレビューし、問題をわかりやすく説明できます。ただし、サイト全体の SEO 監査には、robots.txt、サイトマップ、レスポンスヘッダー、生の HTML とレンダリング後の HTML、そしてページ間の比較も必要です。チャットでの監査は、読み込んだページのレビューとして扱い、その一覧を求めてください。

AI モデルが大きくなれば、この差は埋まりますか？

容量が増えれば、上記のモデルにおける 1 セッションあたりのページ数は増えます。しかし、証拠がページのテキストに移るわけではありません。ヘッダー、robots.txt、ページ間の矛盾は、引き続き意図的に取得して比較する必要があります。容量と同じくらい重要なのが一定の手法です。2 回の実行結果を一致させるのは手法だからです。

小規模なサイトなら 1 回の AI セッションで十分ですか？

URL が 20 件程度のサイトなら、1 回のセッションですべてのページを読めます。それでも robots.txt、サイトマップ、レスポンスヘッダー、生の HTML を手元に揃える必要があるので、明示的に求めてください。規模は、この問題のうち解決しやすいほうの半分にすぎません。

サイトマップ全体をチャットに貼り付けるべきですか？

サイトマップを貼り付ければ、セッションは URL の一覧を得られます。しかし、ページそのもの、そのヘッダーやステータスコードは得られません。アシスタントは結局 URL を 1 つずつリクエストする必要があり、上で説明したセッション数の計算に戻ってしまいます。