
ChatGPTが商業クエリの26%に広告表示、関連性に課題も浮上
ChatGPTが商業目的のクエリの約4回に1回の割合で広告を表示していることが、SEOツール企業SE Rankingの調査で明らかになった。表示頻度はGoogleのAIモードに迫る水準だが、広告の関連性や広告主の可視性に課題が残る。
今回の調査は20分野にわたる5万件以上の商業クエリを分析したもので、会話型AI上での広告配信の実態が初めて大規模に可視化された。AI検索時代の新たな広告チャネルとして注目されるChatGPT Adsだが、その仕組みにはGoogle検索とは異なる独自の難しさがある。
商業クエリの約26%で広告が出現、Google AIモードに肉薄

SE Rankingの調査によると、ChatGPTは商業クエリの25.94%でスポンサードプレースメント(広告)を表示した。これは同社が以前調査したGoogle AIモードの29.45%にかなり近い数字だ。AIチャットボットの広告表示率が、従来型検索エンジンのAIモードと肩を並べつつある状況が浮かび上がった。
表示スタイルはシンプル、1クエリに単一広告
広告の表示スタイルは現在のところ非常にクリーンだ。調査で観測されたすべての広告は、生成された回答の下部に表示され、他の広告主と並んで競合することはなかった。1つの回答に対して常に1つのスポンサーオファーのみが表示される。
Googleの検索結果画面とは異なり、ユーザー体験を大きく阻害しない形で広告が統合されている点は注目に値する。ただし、このシンプルさは広告枠の稀少性を意味しており、将来的に入札競争が激化した際にどう変化するかは未知数だ。
広告の関連性に課題、約14%が的外れな表示

ChatGPT Adsの大きな課題として浮上したのが、広告の関連性だ。SE Rankingのセマンティック分析によると、表示された広告の約14.35%が、ユーザーのプロンプトと実質的な関連性を持たなかった。これは7件に1件の割合で、的外れな広告が表示されている計算になる。
カテゴリによるばらつきが顕著
ミスマッチの発生率はカテゴリによって大きく異なる。ペット分野ではわずか2.6%だったのに対し、人間関係やニュース・政治分野では半数以上が無関係な広告だった。特定のトピックでは、会話の文脈を正しく解釈して適切な広告を選ぶことが依然として難しいことがわかる。
実際のミスマッチ例
調査で観測された例では、デートアプリに関するプロンプトに衣料品小売店の広告が表示されたり、新聞の購読を尋ねるクエリに電力会社の広告が出たりといったケースがあった。ユーザーの意図と広告の内容が明らかにずれている。
このようなミスマッチは、広告主にとって広告費の無駄遣いになるだけでなく、ユーザーのAI体験の質を下げる要因にもなる。ChatGPTが広告プラットフォームとして成熟するためには、文脈理解の精度向上が不可欠だ。
従来のキーワードターゲティングとは根本的に異なる仕組み
ミスマッチが起きる背景には、ChatGPT Ads特有のターゲティング方式がある。広告主はキーワードリストではなく、自然言語で書かれた「コンテキストヒント」を提供する。これは「自社の広告を表示したい会話の文脈」を説明するテキストで、厳密なマッチングルールではなく、AIによるゆるやかなマッチングのガイドとして使われる。
加えて、広告主は現在のところ、実際にどのクエリや会話が自社の広告表示をトリガーしたのかを確認できない。これでは不適切なプレースメントが起きても原因を特定しづらく、改善のためのフィードバックループを回すのが難しい。
広告出稿とAI回答でのブランド露出はほぼ無関係

調査の中で特に注目すべき知見は、ChatGPT上で広告を出稿しても、それが生成AIの回答本文にブランドとして登場する確率はほとんど上がらないという点だ。
広告が表示されたクエリのうち、同じブランドが回答の情報源として引用されたケースはわずか3.63%だった。さらに、広告のURLがそのまま引用に現れたのは0.09%にすぎない。ブランド名の言及も4.44%にとどまる。
つまり、ChatGPTに広告費を投下しても、AIが生成するオーガニックな情報として認識される可能性は極めて低い。有料プレースメントとオーガニックなAI可視性は、今のところ完全に分離していると考えてよい。
YMYL分野で目立つ広告表示、Google AIモードとの違い

ChatGPT Adsは、健康やニュースといったYMYL(Your Money or Your Life)分野で、Google AIモードに比べて顕著に多くの広告を表示している。
調査によると、ヘルスケア関連のプロンプトでは28.69%で広告が表示されたのに対し、Google AIモードではわずか2.64%だった。ニュース・政治カテゴリでも同様に、ChatGPTが28.76%、AIモードは6.8%と大きな開きがある。
この差は、ChatGPTの広告セーフガードが緩いことを必ずしも意味しない。むしろ、2つのAIプラットフォームが広告表示に対して異なるポリシーやマッチングモデルを採用している証拠と見るべきだ。広告主は、AI検索チャネルごとにまったく異なる配信傾向があることを前提に戦略を立てる必要がある。
広告主が今おさえておくべきポイントと今後の展望

ChatGPT Adsは急速に成長する有料メディアチャネルだが、Google検索広告と同じ感覚で運用すると期待はずれに終わる可能性が高い。会話型AI上の広告は、キーワードではなくコンテキストに依存するため、精度の高いコンテキストヒントの設計と継続的な実験が欠かせない。
また、どのような会話で広告が表示されたかというレポートの不足は、最適化の足かせとなる。OpenAIが今後、広告主向けにより詳細な分析ダッシュボードを提供するかどうかが、チャネルとしての成熟度を左右するだろう。
さらに、AI検索の世界では、有料広告とオーガニックなブランド認知が直接リンクしない構造が鮮明になった。SEOにおけるブランド構築や被リンク獲得といった従来手法は、AIが回答を生成する時代にも強みを発揮する。広告だけでAI上の可視性を買おうとする発想は現実的ではない。
この記事のポイント
- ChatGPTは商業クエリの約26%で広告を表示し、Google AIモードと同等の水準に達している
- 広告の約14%がクエリと無関係で、会話ターゲティングの精度に課題が残る
- 広告出稿しても、ブランドがAI回答内で情報源として引用される確率は3%程度と低い
- 健康やニュース分野では、ChatGPTの広告表示率がGoogle AIモードより顕著に高い
- 会話型AI広告の最適化には、精密なコンテキストヒント設計と、広告表示ログの透明性が必要

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

GoogleのAI責任者ジェフ・ディーン氏が退任、新会社を設立。AI研究の巨人の軌跡とSEOの今後
GoogleのアルファベットCEO、サンダー・ピチャイ氏が2026年8月5日、大規模な組織改編と重要人物の退任を発表した。今回のニュースの核心は、27年にわたりGoogleの検索基盤と現代のAI技術を支えてきたチーフサイエンティスト、ジェフ・ディーン氏が退任し、新会社を設立することだ。
彼の退任は、単なる一社の人事異動ではない。TensorFlowの共同発明、知識蒸留の概念、MapReduceといった、今日の検索エンジンと生成AIの土台そのものを築いた人物の離脱である。この記事では、今回の発表内容、ディーン氏の技術的遺産、そしてこの出来事がSEO業界に投げかける長期的な影響を読み解く。
Google DeepMind新体制とデミス・ハサビス氏の役割拡大

今回の発表で、GoogleのAI研究開発におけるリーダーシップ体制が一新された。Google DeepMindの共同創業者でありCEOであるデミス・ハサビス氏が、新たにアルファベット社全体のチーフサイエンティスト、そしてGoogle DeepMindの会長に就任する。彼はDeepMindの顔としての役割を維持しつつ、Googleが持つ他のAI関連部門に対しても影響力を拡大することになる。
とりわけ注目すべきは、医薬品開発を行うアイソモルフィック・ラボ(Isomorphic Labs)への関与だ。この部門はAIを駆使して新たなバイオ医薬品や治療薬を発見することを目的としており、既にイーライリリーやノバルティス、ジョンソン・エンド・ジョンソンといった製薬大手と提携している。数兆円規模の巨大市場である医薬品産業において、GoogleがAIを中核に据えた事業展開を本格化させる意思が明確に示された形だ。
また、DeepMindのCTOを務めてきたコライ・カブクチュオール氏は、Google DeepMindのシニアバイスプレジデントに昇格し、実務的な日々のリーダーシップを担う。彼の管掌範囲には、Geminiモデルとアプリケーションの開発チーム、そして最先端のフロンティアモデルが含まれる。ピチャイCEOは声明の中で「彼は13年間DeepMindに在籍し、深層学習チームを立ち上げ、WaveNetやDQNといったブレークスルーを主導してきた」と評しており、まさに技術面での最高責任者としてGoogleのAI開発を牽引する役割を負う。
この一連の体制変更は、GoogleがAI研究の成果を検索やクラウドだけでなく、より実体経済に近い分野へと応用する段階に入ったことを示唆している。
ジェフ・ディーン氏の退任とその考古学的な功績

SEOやサイト運営者の間ではあまり知られていないかもしれないが、ジェフ・ディーン氏の名前は現代のインターネットの風景を語る上で欠かせない存在だ。彼はGoogleの初期検索インフラから、ニューラルネットワークによる現代AIの時代に至るまで、最も重要な技術的転換点の数々を牽引してきた。ピチャイCEOが「現代AI時代の創造に貢献した」と述べるのも当然のことである。
彼の退任が「巨大な損失」と形容される理由は、その業績リストを見れば一目瞭然だ。以下に、ディーン氏が関わった主要な研究論文と、その歴史的意義をまとめる。
MapReduce(2004年)
大規模クラスター上でのシンプルなデータ処理手法を提示したこの論文は、後のApache Hadoopの開発に強い影響を与え、ビッグデータ産業そのものの創出を可能にした。検索エンジンが扱う膨大なウェブデータの分散処理は、この着想なくしては実現しなかったと言っても過言ではない。
Bigtable(2006年)
構造化データを数千台のサーバーに分散して保存し、ペタバイト級にスケールさせる方法を示した。これは、超巨大規模でのウェブインデックス作成に直接的な影響を与え、Google検索の根幹技術のひとつとなった。
Large Scale Distributed Deep NetworksとDistBelief(2012年)
この論文は、数十億のパラメータを持つモデルのトレーニング手法を提示した。ここで紹介された分散学習フレームワーク「DistBelief」は、TensorFlowの直接の前身にあたる。スケーラブルな深層学習という、現在の巨大AIモデル時代の扉を開けたものだ。
知識蒸留(Distilling the Knowledge in a Neural Network、2015年)
大小さまざまなAIモデルを扱う企業や研究者にとって、知識蒸留は今や常識とも言える重要な技術である。これは、大規模で高性能な「教師モデル」の振る舞いを、より小さく高速な「生徒モデル」に学習させる手法を指す。簡単に言えば、ベテラン職人の技術を新人に凝縮して継承するイメージだ。ディーン氏は、この概念の主要な発明者の一人である。
この技術は、OpenAIやAnthropicのトップモデルを模倣するために中国企業が使用したと非難されたり、AIによる検索結果をリバースエンジニアリングする際に使われたりと、模倣や分析の文脈でも頻繁に話題に上る。AIの民主化と技術流出という、現代的な課題の根源にも関わる発明なのだ。
TensorFlow(2016年)
そして、おそらく最も広く知られているのが、機械学習ライブラリ「TensorFlow」の共同発明である。TensorFlowは、今日のAIを形作ることを可能にした柔軟なインフラ層だ。開発者が機械学習モデルを構築し、トレーニングするためのツールキットであり、現在の生成AIブームの縁の下の力持ちとも言える。TensorFlowの存在なくして、ChatGPTに代表される大規模言語モデルの急速な発展はありえなかった。
今回の退任がSEOとサイト運営に与える長期的な影響

SEOコミュニティの多くは、ジェフ・ディーンという個人名に馴染みが薄いかもしれない。しかし、彼の存在はこれまでの検索エンジンの進化、つまりSEOそのもののゲームルールを決定づけてきた。ここでは、彼の退任がもたらすであろう、より深い地殻変動を考察する。
GoogleのAI研究開発の方向性変化
最高技術責任者の退任と後任者の就任は、組織としての研究開発の優先順位や文化に変化をもたらすことが一般的だ。ディーン氏の代わりに実務のトップに立つコライ・カブクチュオール氏は、Geminのような大規模言語モデルと、その先のフロンティアモデルに直接責任を持つ。この体制が続く限り、Googleの研究開発リソースは「より賢く、より大きなAI」を追求する方向性が加速するだろう。
AIによる検索品質とアルゴリズム進化の加速
同時に、ディーン氏が積み上げてきた分散処理と大規模学習の基盤は、既にGoogle検索の血肉となっている。Googleが「AIによる検索体験」をどこまで推し進めるのか。AI Overviewsのような機能の進化は、後任者たちの手腕にかかっている。ディーン氏の退任は、ある種の完成を迎えた基盤技術の上で、応用レイヤーの競争がいよいよ本格化する合図とも読み取れる。
AIスタートアップ「Discovery Loop」とGoogleの特別な関係
サンダー・ピチャイ氏は、ディーン氏とGoogleのシニアフェローであるサンジェイ・ゲマワット氏が、機械学習や科学、工学における発見を加速させる独立した公益法人(Public Benefit Corporation)を設立すると述べた。この新会社「Discovery Loop」はGoogleからの独立組織だが、Google自身が出資者かつクラウドパートナーとなり、研究フレームワークでも協業するという。つまり、まったくの別会社というわけではなく、Googleのエコシステムと強固に結びついた「外部の頭脳」として機能する可能性が高い。両社の研究成果が間接的にGoogle検索に還流する未来も十分に考えられる。
この記事のポイント
- Googleのチーフサイエンティスト、ジェフ・ディーン氏が27年のキャリアに幕を下ろし、AI研究の新会社「Discovery Loop」を設立。
- ディーン氏はMapReduce、Bigtable、TensorFlow、知識蒸留など、現代の検索とAIの基盤技術を数多く発明。事実上の「検索エンジンの父」の一人。
- 後任のハサビス氏はDeepMind会長兼アルファベット全体のチーフサイエンティストとなり、医薬品開発などAIの応用領域を拡大する方針。
- この人事は、GoogleのAI研究が「基盤づくり」から「応用と収益化」へとフェーズを移行させるシンボリックな出来事。
- SEO実務者にとっては、AI Overviewsの高度化など、検索体験のさらなる変貌を前提とした長期的視点でのサイト運営がこれまで以上に求められる。

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

cats.txtが暴いたGEOの証拠水準。AIクロールは機能の証明にならない
AI検索時代におけるSEOの延長線上にあるGEO(生成AIエンジン最適化)。その効果を裏付ける「証拠」として、しばしば4つの観測があげられる。AIボットがファイルをクロールした、Googleがインデックスした、LLMがその内容を出力した、ChatGPTが有効性を認めた。しかし、これらの観測は本当に「有効性の証明」と言えるのか。
Search Engine JournalのMark Williams-Cook氏が公開した風刺的な検証が、この疑問に痛烈な答えを出している。同氏は架空の規格「cats.txt」を考案し、上記4つの証拠すべてをクリアすることを実証した。つまり、ウェブ上に置かれたどんなテキストファイルにも同様の現象は起こり得るのであり、それらは機能を保証するものではないというわけだ。
GEO業界でまかり通る「4つの証拠」とその問題点

以下、それぞれを詳しく見ていこう。
1. AIボットがクロールしている
クローラーの役割は、Web上にあるファイルを片端から取得することだ。そのため、cats.txtのような冗談まじりのファイルにも、PerplexityBotやGPTBot、ClaudeBotがアクセスしてくる。サーバーログにボットの痕跡があったからといって、そのファイルが「特別に利用されている」証拠にはならない。配達員が門を通るのと、家の中のゴミ箱の中身が役立っているというのは別の話である。
2. Googleにインデックスされた
Googleはテキストファイルをきわめて積極的にインデックスする。cats.txtもGoogle検索結果に現れ、Search Consoleで「インデックス登録されました」と表示された。しかしそれは、URLが存在し、何かしらの文字が書かれているという事実を確認しただけだ。信ぴょう性や有用性とは無関係である。
3. LLMがファイルの内容を出力した
検索拡張生成(RAG)は、LLMが検索結果を参照して回答を生成する仕組みだ。cats.txtが検索上位に登場すると、AIはその猫情報を何の疑いもなく引用する。これはファイルが特別な「プロトコル」として機能しているのではなく、単に1つのWebページとして扱われた結果に過ぎない。
4. ChatGPTが有効性を認めた
ChatGPTに「cats.txtは役立ちますか」と尋ねると、公開直後は「検索エンジンやLLM駆動システムでのランク向上に寄与する可能性があります」という回答が返ってきた。これはネット上に「有効だ」と書かれたテキストが多かったからであり、AI自身が何かを判断したわけではない。興味深いことに、このファイルが風刺であると知れ渡った後は、同じChatGPTが「これは冗談です」と答えるようになった。AIの意見は、周囲の言説の平均値にすぎないのである。
「収束問題」が引き起こす根拠の循環

この「収束問題」こそが、4つの証拠の背後にある根本的なメカニズムだ。LLMは与えられたネット上の言説の平均的な意見を出力するに過ぎない。cats.txtが「効果的だ」と答えたのも、公開当初に肯定的な書き込みが一定数集まったからである。もし皆が「これはデタラメだ」と書いていれば、AIもそう答えたはずだ。
このように、AI自身の意見を「お墨付き」と捉えるのは危険である。流動的な世の中の雰囲気に左右される出力を、数値や因果関係の証拠と混同してはいけない。
真のSEO・GEO最適化が目指すべきもの

cats.txtの実験が示したのは、あるGEO施策の効果を主張するために使われる「証拠」があまりにも脆弱だという事実だ。AIボットのクロール、インデックス、LLMの出力、ChatGPTの賛同。これらはどれも、「施策が機能していること」の証明にはならない。
問題は、こうした根拠不十分な手法に時間と予算を費やすことにある。確かな価値が実証されている基本的なSEO改善(コンテンツ品質、サイト速度、ユーザー体験の向上)こそが、長期的にAI検索からのトラフィックを伸ばす土台となる。最適化とは、検証可能な小さな改善を積み重ね、競合よりもわずかに優位に立つことだ。まだ誰も検証していない「次のGEOの秘策」を追いかけることではない。
この記事のポイント
- AI検索最適化の「証拠」とされる4つの観測(クロール、インデックス、LLM出力、ChatGPT賛同)は、どのテキストファイルにも起こる現象であり、施策の有効性を担保しない
- 2026年8月に公開されたcats.txtは、この4つの証拠すべてをクリアし、根拠の脆弱性を浮き彫りにした
- LLMの自己評価はネット上の意見の平均を返しているに過ぎず、エコーチェンバー効果によって「有効」と誤認されやすい
- 限られたリソースは、検証済みの基本SEO改善に集中させるべきであり、エビデンスの弱い新手法に振り回されてはならない

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

GoogleサーチコンソールにAI検索レポート登場。見るべきポイントと活用術
Google は 2026 年 6 月 3 日、Search Console に生成 AI 専用のパフォーマンスレポートを追加した。AI Overviews(AI 概要)や AI Mode(AI モード)といった検索体験の一部として、自社サイトの URL がどの程度表示されたかを切り分けて確認できるようになっている。
これまで「AI 検索に自社のコンテンツが出ているのかどうか」は、通常の検索パフォーマンスの数字に埋もれてわからなかった。今回の分離によって、どのページが生成 AI の回答元として使われているのかを確認できるようになったが、あくまで「表示回数」ベースのデータであり、クリックや引用のされ方までは把握できない点に注意が必要だ。
この記事では、新レポートで何が読み取れるのか、従来の検索表示回数とどう違うのか、そして実際にサイト改善に役立てるための診断フローを解説する。
AI検索レポート、ついに独立

生成AI専用レポートの概要
この新しい Search レポートは、AI Overviews と AI Mode からの表示回数のみを集計する。Discover 向けの生成 AI 機能は別レポートとして提供されている。また、Labs の実験的機能は対象外だ。
レポートでは、URL 単位、国別、デバイス別、日付別に表示回数をセグメントできる。ただし現時点では、以下の指標は含まれていない。
- 検索クエリ
- クリック、クリック率(CTR)
- 平均掲載順位
- 引用の位置(回答内でリンクがどの順序で表示されたか)
- 回答の基となった文章の特定
- コンバージョンや収益データ
Google は「今後、追加指標の要望をサイト運営者とともに検討する」と述べており、機能拡張の可能性はある。また、AI Overviews や AI Mode にコンテンツを含めるかどうかを制御する新しい設定も Search Console でテスト中だ。デフォルトは「含める」で、オプトアウトすると従来の検索結果には影響なく、生成 AI の回答からも自社コンテンツが除外される。
まずは「どの部分が使われているか」を把握するために
現時点のレポートが答えられるのは「サイトのどのページが生成 AI の表示に使われているのか、どのくらいの頻度か」という問いだ。それ以上の詳細は得られないが、この可視化だけでもこれまでにない手がかりになる。
AI表示回数は従来の表示回数とは異なる

表示回数の数え方の基本
Google の定義では、AI 表示回数とは「生成 AI の機能内でユーザーにリンクが表示された回数」を指す。集計方法はレベルによって異なり、グラフのプロパティ全体では、1 つの回答内に同じサイトの異なる URL が複数出ても 1 回とカウントされることがある。一方、ページテーブルでは各 URL が個別に 1 回ずつ計上されるケースもある。
つまり、ページレベルの表示回数を足し上げた合計が、必ずしもプロパティ合計と一致しない。これは集計単位の違いによるもので、数値に矛盾があるわけではない。
従来の検索との違いと混同禁止
従来の検索結果での表示回数は、検索結果リスト内の 1 つの掲載としてユーザーが認識しやすい。一方、AI Overviews や AI Mode の表示は、合成された回答文の一部として現れる。リンクが目立つ場合もあれば、折りたたまれた引用リストの中に埋もれている場合、フォローアップの質問の後に出現する場合もある。
また、AI Overviews ではリンクがスクロールされるか展開されるまで表示回数としてカウントされない。AI Mode ではフォローアップの質問が新しいクエリとして扱われ、後続の回答で表示されたリンクが追加の表示回数を生む。
これらの違いから、生成 AI の表示回数と通常の検索表示回数を合算して「総検索可視性」のように扱うのは全くの誤りだ。CTR のブレンド計算も同様に意味をなさない。レポート画面で数字が並んでいても、それらは性質の異なる指標であることを肝に銘じたい。
このレポートで診断できること

このレポートの真価は、表示回数の総数ではなく、どのページが生成 AI 検索で使われているかを通常の検索パフォーマンスと比較できる点にある。
これは概念図だが、レポートの表示回数を通常の Search Console の検索パフォーマンスと並べて分類すると、上記の4パターンに整理できる。それぞれ次のような特徴がある。
高オーガニック表示・低AI表示のページ
通常検索ではよく見られていても、生成 AI の回答にはあまり使われないページだ。必ずしも問題とは限らない。クエリ自体が AI 応答を引き起こさないケースもある。しかし、次のような点を確認すると原因が見えてくる。
- 具体的な質問に直接答えているか
- 見出し構造が整理されているか
- 重要な情報がテキストとして HTML 上に露出しているか(タブや画像、JavaScript に隠れていないか)
- AI 応答が発生しやすいクエリにマッチする内容か
通常のランキングで上位に上がる能力があっても、合成に使えるクリーンな回答を提供できなければ、AI 表示にはつながりにくい。
低オーガニック表示・高AI表示のページ
こちらの方が注目に値する。通常の検索では目立たずとも、生成 AI で高い頻度で表示されるページがある。定義や統計、比較、説明が明快なコンテンツがこれにあたる。
こうしたページを分析すると、以下の共通点が見えてくることが多い。
- セクションの冒頭付近で直接的な回答を提示している
- 見出しの階層が明確で情報が取り出しやすい
- 独自の調査や一次情報を含んでいる
- 有益な表やリストがある
- トピックの範囲が絞られており、曖昧な表現が少ない
1 つの成功パターンを見つけたからといって、それを再生産すればうまくいくとは限らないが、サイト内で「Google が使いやすい」と判定している構造や表現のヒントになる。
ページ改修の効果を追う
コンテンツを大幅に修正した後に、AI 表示回数がどう変化するかをウォッチするのにも有用だ。たとえば以下のような改修が効果を持つ可能性がある。
- 明確な要約や定義を冒頭に追加
- 古い情報を更新し、鮮度を高める
- 重複したページを統合
- 見出しを書き直して情報の抽出を助ける
- 画像や動画に頼っていた重要情報を HTML テキストに移す
- 独自の証拠や専門家のコメントを加える
ただし、1 つの見出しを変えた翌週に数字が上がったからといって「AI 検索のアルゴリズムを解明した」と騒ぐのは禁物だ。需要や競合、AI 機能の出現頻度そのものが変動する。持続的な増加が確認できて初めて意味のあるシグナルとなる。
データを分析する実践ワークフロー

エクスポートと分類、従来データとの比較
分析は次の 6 ステップを踏むと整理しやすい。
- AI 表示回数の上位ページをエクスポート
意味のある期間を選ぶ。リリース直後の数日で判断しない。 - 同じ URL・期間で通常の検索パフォーマンスをエクスポート
通常の検索表示回数、クリック、CTR、平均順位、可能なら上位クエリを加える。比較することで、AI と通常検索で差があるページを特定できる。 - ページを属性で分類
ページタイプ、トピック、検索意図、テンプレート、著者、公開日、最終改訂日、ファネルステージなどを付与。URL と表示回数を並べただけでは分析にならない。 - 外れ値を調査
AI 表示回数が極端に高いページや低いページを探す。テンプレートやトピック、著者によってなぜ差が生まれるのかを実際に HTML 構造や本文を見て確認する。この段階で初めて手を動かす必要がある。 - アナリティクスのデータを別に確認
AI 経由のトラフィックやコンバージョンが特定できれば、表示回数がどの程度実際の訪問につながっているかを評価する。ただし Search Console と Analytics では計測方法が異なるため、数字のズレに一喜一憂しない。 - 日次の変動ではなくトレンドを追う
新しいデータは暫定的な数値の可能性もある。週次や月次で傾向を見るほうが建設的だ。1 日で上がった下がったに右往左往しない。
経営ダッシュボードに載せるべきではない指標

「AI」とラベルされた大きな数字が現れると、ダッシュボードの一番上に大きく表示したくなるものだ。しかし、生成 AI の表示回数はあくまで特定の状況でのリンク出現を示しており、ビジネス成果に直結するとは限らない。
以下のような報告は避けるべきだ。
- 生成 AI 表示回数と通常検索表示回数を合算した「総視認性」
- 両者をブレンドしたクリック率
- 自社の AI 表示回数だけを元にした「AI シェア」
- 表示回数に紐づけたコンバージョンの推測
- 1 つの最適化施策が効いたかのように見せるための表示回数の増加報告
- ページレベルの合計をプロパティ全体の露出と誤認させる表示
代わりに、ダッシュボードに盛り込むべきは「生成 AI 表示回数の推移」「表示回数がついたページ数」「表示されているトピック・ページタイプ」「AI 可視ページと通常検索パフォーマンスとの関係」「期間中に実施した改修」「AI 経由の識別可能なトラフィックやコンバージョン(分けて報告)」「追加調査が必要な仮説」といった項目だ。
この記事のポイント
- Search Console の新レポートで、AI Overviews と AI Mode の表示回数が通常検索と分離された
- 表示回数はクリックや引用位置の情報を含まず、あくまで「リンクが表示された」という指標である
- 従来の検索表示回数とは性質が異なり、合算やブレンド分析は誤解を招くため厳禁
- 通常検索との比較で、コンテンツの抽出しやすさや構造の課題を発見できる
- 分析の際は長期的なトレンドとページ属性の分類が不可欠で、数字の上下だけで施策の成否を判断しない

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

クロールバジェット最適化の新ガイドライン、ECサイトが実践すべき手法
Googleがクロールインフラストラクチャの公式ドキュメントを更新し、「クロールバジェットの最適化」に関する新たなガイドラインを公開した。ECサイト運営者にとって、この変更は商品ページのインデックス速度に直結する。クロールされなければ検索結果に表示されないからだ。
今回の更新で注目すべきは、新サイトに割り当てられる「保守的なクロールバジェット」の考え方と、304ステータスコードに関する注意喚起だ。特に304の扱いは、安易に導入すると検索順位に影響を与える可能性がある。
この記事では、Googleの新ガイドラインの要点と、ECサイトが実践すべきクロールバジェット最適化の手法を解説する。
クロールバジェットとは何か

クロールバジェットとは、Googlebotが一定期間内に特定のサイトをクロールするURLの総量を指す。インターネット上のURL数は膨大であり、Googleは各サイトに割り当てるクロール量を最適化する必要がある。この割り当てが「バジェット(予算)」と呼ばれる理由だ。
サイト構造が整理されておらず、無駄なURLが多いサイトは、クロールに時間がかかり、結果としてインデックスされるページ数が少なくなる。ECサイトの場合、商品ページがインデックスされなければ、検索経由の流入機会を失うことになる。
クロールバジェットを意識したサイト設計は、検索エンジンに「このサイトは効率的にクロールできる」と認識させる第一歩だ。以下、Googleの新ガイドラインに沿った具体的な施策を見ていく。
新サイトには保守的なクロールバジェットが割り当てられる

Googleの更新されたドキュメントで明確にされたのが、新規サイトに対するクロールバジェットの初期値だ。新サイトには「保守的な」バジェットが割り当てられ、サーバーに過負荷をかけずに重要なコンテンツをカバーできるよう設計されている。
段階的なコンテンツ公開が鍵
新サイトを立ち上げる際は、一度に大量のページを公開するよりも、徐々にページ数を増やす方がGooglebotの信頼を得やすい。たとえば、100商品を1日で公開するより、1日3商品ずつ約1ヶ月かけて公開する方が、クロールバジェットの観点からは有効だ。
この段階的アプローチにより、Googlebotはサイトの更新パターンを学習し、クロールバジェットを徐々に拡大していく。XMLサイトマップの自動更新と組み合わせることで、さらに効果が高まる。
表示速度の改善がバジェットを増やす
サイトの読み込み速度が速いほど、Googlebotは効率的にクロールできる。これは以前から知られていた事実だが、今回のガイドラインでも改めて強調された。表示速度の改善は、ユーザー体験の向上だけでなく、クロールバジェットの増加にも直結する。
Googleが提供するPageSpeed InsightsやLighthouseを使って定期的にパフォーマンスを測定し、改善を続けることが重要だ。ECサイトでは、画像の最適化や不要なスクリプトの削減が特に効果的だ。
人気ページはクロール頻度が高まる
外部リンクや内部リンクを多く集めているページは、Googlebotの巡回頻度が高くなる。ECサイトの場合、トップページや主要カテゴリページ、よく参照される商品ページが該当する。内部リンク構造を最適化し、重要なページへリンクを集中させることで、クロール頻度を向上させられる。
クロール効率を下げる要因とその対策

クロールバジェットを浪費する要因はいくつかある。以下に主要なものと対策を示す。
robots.txtで不要ページをブロック
プライベートログインページ、ショッピングカート、動的に生成されるページなど、インデックス不要なページはrobots.txtのdisallowディレクティブでブロックする。これにより、Googlebotが本当に重要なページだけを巡回するよう誘導できる。
重複コンテンツの削除と統合
同じ内容のページが複数存在すると、クロールバジェットが分散される。商品バリエーション(色違い、サイズ違い)でURLが分かれている場合は、canonicalタグで正規URLを指定するか、統合を検討する。
ソフト404とリダイレクトチェーンを回避
削除されたページが200ステータスコードを返す「ソフト404」は、Googlebotが無駄なクロールを続ける原因となる。存在しないページは404または410レスポンスを返すように設定する。また、1つのページに対して複数のリダイレクトが発生する「リダイレクトチェーン」も、クロール効率を低下させるため避けるべきだ。
Search Consoleのクロール統計を活用
Google Search Consoleの「設定」→「クロール統計」レポートでは、Googlebotのクロール頻度や発生した問題を確認できる。このレポートを定期的にチェックし、クロールバジェットの消費状況を把握することが、最適化の出発点となる。
304ステータスコードの注意点

今回のガイドライン更新で追加されたのが、304(Not Modified)ステータスコードに関する推奨だ。Googleは「前回のクロールからページが変更されていない場合、304コードを返すことでGoogleにキャッシュ版の再利用を促し、サーバー帯域とリソースを節約できる」としている。
しかし、この推奨には注意が必要だ。Practical Ecommerceの記事では、Jill Kocher氏が次のような見解を示している。304コードを重要なページに使用すると、検索結果での表示順位やインデックスステータスに影響を与える可能性がある。同氏は、期限切れ商品やポリシーページなど、重要性の低いページに限定して使用することを推奨している。
ECサイト運営者としては、この304コードの推奨を鵜呑みにせず、自社のSEO戦略に照らして慎重に判断する必要がある。売上に直結する商品ページやカテゴリページには適用せず、重要度の低い固定ページに限定するのが賢明だ。
この記事のポイント
- 新サイトのクロールバジェットは「保守的」に設定されるため、段階的なコンテンツ公開が有効
- 表示速度の改善と定期的な更新が、クロールバジェット拡大の鍵
- robots.txtの活用、重複コンテンツの統合、ソフト404の排除で無駄なクロールを削減
- Search Consoleのクロール統計レポートで状況を定期的にモニタリング
- 304ステータスコードは重要ページには使用せず、影響の少ないページに限定する

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Googleがrobots.txtを無視する理由とSEOへの悪影響を解説
GoogleのJohn Mueller氏が、robots.txtに関する見落としがちな設定ミスについて回答した。このミスは、SEOやサイトのインデックス目標に悪影響を及ぼす可能性があり、特に検索ボックススパムへの対策を複雑化させる。なぜrobots.txtが正しく機能しないのか、その根本原因と具体的な解決策を解説する。
「無視されるrobots.txt」が生まれる仕組み

robots.txtは、検索エンジンのクローラーに対して「どのページをクロールしてよいか」を指示するためのファイルだ。しかし、設定の書き方を誤ると、その指示が完全に無視され、意図しないページがGoogleにインデックスされる事態を引き起こす。
Disallow: /search
Disallow: /private
Disallow: /admin
Disallow: /search
Disallow: /private
Disallow: /admin
Disallow: /
User-agent別ルールと優先順位の落とし穴
問題の核心は、robots.txtの「より具体的なルールが優先される」という仕様にある。一般的なクローラー向けの User-agent: * セクションと、Googlebot専用の User-agent: googlebot セクションが同じファイル内に存在する場合、Googlebotは自身に直接関係するセクションのみを参照する。
Search Engine Journalの記事によると、あるShopifyサイトでは検索ボックススパム対策として Disallow: /search を User-agent: * 内に記述していたが、別途 User-agent: Googlebot セクションが存在したため、この禁止指示がGooglebotに無視されていた。結果として、スパムによって生成されたURLがGoogleのインデックスに残り続けることになった。
これはrobots.txtの設計に起因する合理的な動作だ。特定のクローラーにだけピンポイントで指示を出し、それ以外のクローラーには別のルールを適用できる柔軟性を持たせるための仕組みである。しかし、この「柔軟性」が、設定の分断と見落としを生み出す。
■ クローラーの動作
■ 発生した問題
robots.txtが制御するのは「クロール」であって「インデックス」ではない
もう一つの重要な前提として、robots.txtはページのクロールを制御するものであり、インデックスを直接制御するものではない。robots.txtでブロックしたページでも、何らかの理由でGoogleがそのURLを知り得た場合、コンテンツをクロールせずにインデックスすることがある。この仕様は、robots.txtだけに依存したインデックス制御が根本的に不完全であることを示している。
robots.txtとnoindexの正しい使い分け

インデックスそのものを確実に防ぎたい場合、robots.txtよりも meta robots タグによる noindex 指定の方がはるかに効果的だ。robots.txtはドアの前に立つ警備員のようなもので、部屋の中のものを「知らない」ままでいられるが、部屋の存在自体を消し去ることはできない。noindex は、その部屋に「公開禁止」の札を貼るようなもので、検索エンジンに直接「これを検索結果に表示しないでほしい」と伝える。
Disallow: /search
noindexを確実に適用するための注意点
noindex を適用する際、robots.txtでそのページをクロール禁止にしてしまうと、Googlebotはそもそもそのページを読みに行けず、noindex タグを発見できない。結果として、いつまでもインデックスから削除されないという、本末転倒な事態を招く。クロールを許可した上で、noindex を指示することではじめて、意図したインデックス制御が機能する。
ShopifyとWordPressにおける具体的な対策

検索ボックススパムは、どのようなCMSでも発生しうる問題だが、幸いShopifyとWordPressの両方には、比較的簡単に実装できる緩和策が用意されている。
Shopifyでの検索ページnoindex設定
Shopifyでは、テーマの theme.liquid ファイルを編集することで、すべての検索結果ページに自動で noindex タグを追加できる。これにより、スパムクエリによって生成された無意味なページが検索結果に表示されることを防ぐ。
{% if template contains 'search' %}
<meta name="robots" content="noindex">
{% endif %}このコードをテーマの <head> セクションに追記するだけで、すべての検索ページへのnoindex適用が完了する。robots.txtによる制御と異なり、検索結果ページのURLを確実にインデックスから除外できるため、より根本的なスパム対策となる。
WordPressでの検索スパム対策
WordPress環境では、主要なSEOプラグインを導入するだけで検索結果ページへの noindex がデフォルトで有効になる。Yoast SEO、Rank Math、All In One SEO Packといったプラグインは、インストールしたその日から検索スパムに対する基本的な防御壁として機能する。
さらに、Diviをはじめとする一部のテーマやページビルダーは、スパムワードを含む検索クエリに対して、結果を表示する代わりに「該当する結果がありませんでした」というメッセージを返す仕組みを備えている。これにより、スパムURLそのものが生成されにくくなるという副次的な効果も期待できる。
robots.txtの正しい知識がサイトを守る

robots.txtは強力なツールだが、その仕様を正しく理解していないと、かえってサイトの健全性を損なう原因になりうる。特に、User-agent別のルールの優先順位や、クロール制御とインデックス制御の違いといった基礎知識は、サイト運営者にとって必須のリテラシーと言える。
この記事のポイント
- robots.txtでUser-agent: Googlebotの専用セクションがあると、一般的なUser-agent: *のルールはGooglebotに無視される。
- robots.txtはクロールの制御であり、確実なインデックス除外にはmeta robotsタグのnoindex指定が必要。
- 検索ボックススパム対策には、robots.txtよりnoindexの方が根本的な解決策となる。
- ShopifyやWordPress(SEOプラグイン利用)では、テンプレートや設定を少し修正するだけで検索スパムを効果的に緩和できる。

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Google NotebookLMがGemini Notebookに改称、AIスクレイピング対策の緊急対応
Googleが研究支援ツールNotebookLMをGemini Notebookに改称した。実体は同じだが、このタイミングでユーザーエージェントの表記が「Google-NotebookLM」から「Google-GeminiNotebook」に変更される。旧ユーザーエージェントは2026年8月をもって廃止されるため、サイト運営者は数週間のうちにスクレイピング対策の見直しを迫られている。
今回の変更は単なる名称の刷新にとどまらず、AIによる自動コンテンツ収集と再利用のリスクを改めて浮き彫りにする。本記事では、Gemini Notebookのスクレイピング機能の実態、robots.txtを無視するユーザートリガー型フェッチャーの仕組み、そして具体的なブロック手法を簡潔にまとめる。
NotebookLMがGemini Notebookに改称、機能は変わらず

名前変更の背景と影響
2026年7月18日、Googleはユーザートリガー型フェッチャーのドキュメントを更新し、NotebookLMをGemini Notebookに置き換えた。ブランド統合の一環であり、既存のNotebookLMユーザーにとって使い勝手に違いは生じない。
しかし、サイト運営者にとって重大なのは、旧ユーザーエージェント「Google-NotebookLM」が2026年8月で無効になる点だ。ファイアウォールや.htaccessにこの文字列を直書きしている場合、猶予期間内に新しいユーザーエージェントへ切り替えなければ、ブロックが機能しなくなる。
Gemini Notebookの主な機能
Gemini Notebookは、ユーザーが提供した文書やURLを「グランドトゥルース(信頼できる基盤情報)」として扱い、AIが調査や学習を支援するマルチモーダルツールだ。YouTubeの動画や音声ファイルを取り込んで分析することも、逆にアップロードされた資料を音声ポッドキャストや動画解説に変換することもできる。
この「資料をもとに新しいコンテンツを自動生成する」という特徴が、後述するスクレイピング問題の根本にある。生成された音声や動画がオンラインで公開されれば、元の記事と直接競合する可能性があるからだ。
Gemini Notebookが引き起こすスクレイピング問題

Discover Sourcesによる自動スクレイピング
Gemini Notebookの「Discover Sources」機能は、ユーザーが設定したクエリやテーマに沿って最大10件のオンライン記事を自動で収集し、AI要約を生成する。問題は、サイト所有者の許可を一切取らずにクローリングが行われ、参照元へのリンクも一切発生しない点だ。
従来の検索エンジンであれば、クローラーが収集した情報は検索結果としてユーザーをサイトへ誘導する。しかしGemini Notebookの要約はクローズドな環境で完結し、トラフィックの恩恵は元サイトに還元されない。SEOの観点からは、コンテンツが無断で「搾取」される構造といえる。
音声・動画コンテンツの自動生成と競合
さらに、アップロードした資料からポッドキャストや動画解説を生成できる点も看過できない。仮に自社サイトの記事が材料に使われ、第三者が公開すれば、同一テーマでオリジナルと競合する二次コンテンツが無数に生まれる危険がある。
Googleのドキュメント上、これらは「ユーザー調査のための機能」と位置づけられているが、実質的には許可なきスクレイピングとリパーパス(再利用)を自動化する仕組みにほかならない。コンテンツを資産とするウェブサイト運営者にとって、対策は急務だ。
緊急対応すべきブロック手法

ユーザートリガー型フェッチャーとは
Gemini Notebookのクローラーは「ユーザートリガー型フェッチャー」に分類される。これは、ユーザーが明示的に指示(URL貼り付けやDiscover Sourcesの実行)をトリガーとして起動するため、robots.txtの指示に従わない。robots.txtはあくまで紳士協定であり、一般的なクローラーは自発的に従うが、ユーザートリガー型には適用されないのだ。
ただし、robots.txtが効かないからといって手立てがないわけではない。サーバー側でHTTPリクエストのユーザーエージェント文字列を検査し、該当するアクセスを拒否することは可能である。
.htaccessによる具体的なブロック例
多くのレンタルサーバーで使えるApache環境であれば、.htaccessに以下のルールを追記するだけでGemini Notebookのアクセスを遮断できる。
RewriteEngine On
# Gemini Notebookのユーザーエージェントをブロック
RewriteCond %{HTTP_USER_AGENT} Google-GeminiNotebook [NC]
RewriteRule ^ - [F,L]この設定により、該当のユーザーエージェントを含むすべてのリクエストに対して「403 Forbidden」が返される。Nginxを利用している場合は、if ($http_user_agent ~* "Google-GeminiNotebook") { return 403; } のような記述で同様の制御が可能だ。
重要なのは、新旧両方のユーザーエージェントをカバーするか、あるいは直ちに新UAのみに移行することである。2026年8月以降、旧UAはGoogle側で廃止されるが、それまでにサイト側のルールを更新しておかなければ、一時的にブロックがすり抜けるリスクが生じる。
旧ユーザーエージェントの猶予期間と注意点

Googleはドキュメント内で、旧ユーザーエージェント「Google-NotebookLM」を2026年8月までサポートすると明記している。ハードコードしているサイト運営者は、この期間内に新しい文字列へ切り替える必要がある。
なお、合わせて「Project Mariner」に関する記述がドキュメントから完全に削除された。同プロジェクトは2026年5月に終了しており、混乱を避ける意味でも、ユーザーエージェント周辺の情報は最新版を参照すべきである。
この記事のポイント
- NotebookLMはGemini Notebookに改称され、ユーザーエージェントが変更された
- Discover Sources機能が許可なく記事を収集し、AI要約や音声コンテンツを生成する
- ユーザートリガー型フェッチャーはrobots.txtを無視するが、ファイアウォールや.htaccessでブロック可能
- 旧UA「Google-NotebookLM」は2026年8月に廃止、既存のルールを直ちに更新する必要がある

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

bot判定画面が原因でGoogleインデックスから消える?セキュリティ対策の盲点と解決策
Webサイトの安全を守るセキュリティ対策が、意図せず検索順位を急落させる原因になっているかもしれない。不審なアクセスを防ぐための「bot判定画面」が、Googleの巡回を妨げる事例が報告されている。
この問題が発生すると、検索エンジンにページが登録されなくなったり、他サイトのコピーとして処理されたりするリスクがある。サイト運営者が気づかないうちに進行する、セキュリティとSEOの衝突について詳しく解説する。
bot判定画面がGoogleインデックスからページを消し去る仕組み

サイトのセキュリティを強化すると、不正なアクセスやスパムを遮断できる。しかし、その防御壁がGoogleのクローラー(検索エンジンの巡回ロボット)まで阻んでしまうことがある。これがインデックス消失を引き起こす引き金だ。
不審なアクセスと判定されたGooglebot
クローラーとは、世界中のWebサイトを巡回して情報を集める自動プログラムのことだ。Googleが派遣するクローラーは「Googlebot(グーグルボット)」と呼ばれる。通常、このGooglebotはサイトのコンテンツを自由に読み取れる必要がある。
しかし、サイトのセキュリティフィルターがGooglebotのアクセスパターンを「不審な自動プログラム」と誤認することがある。その結果、本来のコンテンツの代わりに「私はロボットではありません」という確認を求める画面を返してしまう。この画面は一般に「インターシャルページ」や「bot判定画面」と呼ばれるものだ。
重複コンテンツとして処理されるリスク
Googlebotがサイトを巡回した際、どのページにアクセスしても同じ「bot判定画面」が返ってくると、検索エンジンは混乱する。すべてのページの中身が同一であると判断してしまうからだ。
Search Engine Journalの記事で紹介されたGoogleのJohn Mueller(ジョン・ミューラー)氏の解説によると、このような状況ではGoogleは複数のページを「重複コンテンツ」として処理する。さらに、他の多くのWebサイトでも同じセキュリティサービスのbot判定画面が使われているため、Googleはそれらをすべて同じグループとみなしてしまう。最悪の場合、他人のサイトのページが本物(正規バージョン)と判定され、自サイトのページが「コピー」として検索結果から排除される事態に陥る。
上の図が示すように、セキュリティが強すぎるあまりGooglebotを一般の不審なアクセスと区別できなくなると、検索エンジンにはエラー画面しか届かなくなる。
なぜサイト運営者はこの問題に気づきにくいのか

この問題の最も恐ろしい点は、サイトの管理者が普通に自分のサイトを閲覧しているだけでは、異常に全く気づけないことだ。問題が静かに進行し、検索順位が落ちて初めて事態を把握することになる。
一般ユーザーには正常に表示される罠
bot判定画面は、すべての訪問者に表示されるわけではない。セキュリティシステムが「怪しい」と判定したアクセスに対してのみ表示される。サイト運営者や一般的なファンがパソコンやスマートフォンからアクセスする場合、通常は信頼できるアクセスとして処理されるため、何の問題もなくサイトが表示される。
そのため、運営者が「今日もサイトはきれいに表示されている」と思っていても、Googlebotだけは裏でブロックされ、エラー画面を見せられ続けているというねじれ現象が起きる。これが発見を遅らせる最大の原因だ。
Search Consoleで異常を検知する方法
この問題を検知するには、Googleが公式に提供している無料ツール「Google Search Console(グーグルサーチコンソール)」を活用するしかない。具体的には以下のステップで確認を進める。
- 「ページ」レポートを開き、エラーの推移を確認する
- 「重複コンテンツ」や「送信されたURLが正規URLとして選択されていません」というステータスが急増していないかチェックする
- 不審なページの「URL検査」を実行する
- Googleが選択した正規URLの項目を確認し、自分のドメインとは異なる見知らぬ外部サイトのURLが登録されていないか確認する
もしURL検査の結果、Googleが選択した正規URLに他人のサイトが指定されていた場合、自サイトのbot判定画面が他サイトのそれと「同一の重複コンテンツ」とみなされた可能性が極めて高い。
セキュリティ対策とクローラー巡回の衝突

なぜこのような誤判定が起きるのだろうか。それは、Webサイトを高速化・安全化するためのインフラの仕組みに関係している。
CDNやホスティングによる自動ブロック
多くのWebサイトは、CDN(コンテンツ配信ネットワーク)やホスティングサーバーが提供するセキュリティ機能を利用している。CDNとは、世界中に配置されたサーバーを経由してサイトの表示を高速化し、同時に不正なアクセスからサイトを守る仕組みだ。
これらのセキュリティシステムは、短時間に大量のアクセスを行う接続元を自動的に検知し、アクセス制限をかける。Googlebotはサイト内の多くのページを素早く巡回するため、クローラーの活動が活発になったタイミングで、セキュリティシステムが「DDoS攻撃(サーバーに過剰な負荷をかける攻撃)」や「不正な情報引っこ抜き」と誤認してブロックを起動してしまうのだ。
「エラーコードなし」でコンテンツが空になる現象
この問題がさらに厄介なのは、サーバーが「アクセス拒否」を示すエラーコード(403 Forbiddenなど)を返さないケースがある点だ。セキュリティシステムによっては、接続自体は「200 OK(正常に通信完了)」として処理し、画面の見た目だけをbot判定画面に差し替える。
Googleのクローラーは「通信は成功した」と受け取るため、壊れたページとして処理せず、そのままbot判定画面のテキストをインデックスしてしまう。過去にも、セキュリティ設定がGooglebotのアクセスを静かに遮断し、中身が全くない状態でページが登録されるトラブルが報告されている。通信の成否だけを監視する単純なチェックツールでは、この異常を検出できない。
通信自体が「正常終了」とみなされるパターンBの場合、システム監視をすり抜けてしまうため、SEOに深刻なダメージを与えるまで放置されやすい。
検索順位を守るための具体的な解決手順

もしSearch Consoleで「重複コンテンツ」のエラーを発見したり、特定のページがインデックスから消えていることに気づいたりした場合は、迅速な対処が必要だ。
セキュリティ設定のホワイトリスト化
根本的な解決策は、導入しているセキュリティサービスやCDN、ホスティングサーバーの設定を見直すことだ。Googlebotなどの主要な検索エンジンクローラーを「ホワイトリスト」に登録し、bot判定の対象から除外する設定を行う。
多くの大手セキュリティサービス(Cloudflareなど)には、検索エンジンのクローラーを自動的に認識して通過させる機能が標準で備わっている。この機能がオフになっていないか、またはカスタムルールによって上書きされてブロックされていないかを確認する必要がある。設定が難しい場合は、セキュリティの担当者やサーバーのサポート窓口に相談することを推奨する。
修正後の再クロール申請
ブロック設定を解除した後は、Googleにサイトが修正されたことを伝える必要がある。これを放置すると、Googleが次の巡回を行うまでエラー状態が維持されてしまう。
具体的には、Search Consoleを開き、該当するエラーレポート内にある「修正を検証」ボタンをクリックする。これにより、Googleに対して優先的な再クロールをリクエストできる。また、特に検索トラフィックにとって重要なページがある場合は、「URL検査」ツールから個別に「インデックス登録をリクエスト」を送信すると、より早く検索結果に復帰させることができる。
この記事のポイント
- セキュリティ対策のbot判定画面が、Googleクローラーの巡回を遮断することがある
- Googlebotがブロックされると、サイト内の全ページが「同じエラー画面」になり重複コンテンツとみなされる
- 他サイトの同じエラー画面と同一視され、最悪の場合は他サイトのコピー扱いとしてインデックスから消える
- 一般ユーザーには正常に表示されるため気づきにくく、Search Consoleでの定期的なエラー確認が必須となる
- 解決には、CDNやサーバーのセキュリティ設定でGooglebotをホワイトリストに登録し、修正後に再クロールを申請する

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験











