バルセロナでは、Google上のAIはSEOの上にある——fan-outはSearch Consoleに出ない

RECAP｜第三者のまとめである

Search Central Live Deep Dive Europeは、Search Relationsがバルセロナで開いた三日間です。We Are ROASTのJohn Campbell氏が、2026年10月2日に3日目を、10月1日に2日目をまとめています。話者として名前が挙がるのは、John Mueller氏、Gary Illyes氏、Ryan Levering氏、Duy Nguyen氏らです。これは出席者のまとめであり、Googleが公開した原稿ではありません。コミュニティの発表者が挙げたクリック率や件数は、本稿には入れません。Day 3 Day 2

JUST SEO｜同じ処理の上にある

3日目のまとめは、Illyes氏が三日間を閉じるときに三つ言った、と書いています。AIは使ってよい。責任を持って使う。Google上のAIは、ただのSEOだ。AIの機能は、従来の結果とまったく同じ処理を使う。モバイルファーストや構造化データに新しい略称が要らなかったように、検索の上のAIにも、おそらく要らない、という整理です。AIの結果はSEOの基盤の上に組み立てられる、SEOは終わっていない、ともまとめています。これは、まとめがIllyes氏の言葉として置いたものです。

FAN-OUT｜利用者のクエリではないので、出ない

同じ3日目で、Mueller氏はクエリの理解を話した、とあります。AIの側では、クエリがLLMへ行き、fan-outのクエリが作られ、検索エンジンへ戻る。その結果が答えの根拠になり、リンクとともに返る、という流れです。fan-outは、元のクエリを、別個の追加クエリで広げる、とあります。Googleのfan-outは Search Console に出ない。利用者から来たものではない、からです。他の場所、たとえばGeminiのアプリや一部のAPIでは出るかもしれない、ともあります。AIの仕組みごとに違う、とも書いています。生成AIのレポートに、fan-outのクエリが載る日付は、このまとめにはありません。

Search Consoleのセッションでは、Ariel Kroszynski氏が、生成AIのレポートについて更新はなかった、とまとめています。チームはAI検索のデータをレポートへ足す作業をしている。日付も詳細もなかった、とあります。作業中であることと、いつ出るかは、別です。

SCHEMA｜コードとしてではなく、文脈として渡る

2日目のまとめは、Levering氏が構造化データの行き先を話した、と書いています。Schema.orgのデータは掃除され、フィルタされ、通常の検索結果に出るか、AI OverviewsとAI Modeの文脈として使われる。schemaの中のテキストは、ページ上のコンテンツと一緒に渡る。コードとしてではなく、文脈に足される、という書き方です。構造化データを持つのが不利になることはない。手間に見合うか、が問いだ、という見方も、同まとめは置いています。

当サイトの「SchemaはAI引用のチートコードではない」は、構造化が引用を保証しない、と分けています。バルセロナのまとめが足すのは、テキストが文脈として渡る、という出席者の記録です。文脈に入ることと、引用されることは、同じ列にしません。

AI SPAM｜捕まえる側にも、AIを使うという話

3日目の品質のセッションで、Duy Nguyen氏は、コンテンツの洪水の話をした、とまとめは書いています。最近スパムアップデートが多いのは、新しいコンテンツがそれだけ多いからで、チームはいま、その多くを捕まえるためにAIを使っている、と。品質の話であって、誰が書いたかではない、ともあります。Illyes氏は、Googleは1日に400億のスパムページを除いている、という数字を出した、とまとめています。品質の更新を続ける理由の一つとして、スケールしたコンテンツが、リンクのスパムより問題になりつつある、という警告も、同まとめは置いています。400億は、まとめがIllyes氏の数字として書いたものです。本稿の計測ではありません。

TIMING｜幅は、転記である

同じ3日目で、Illyes氏はクロール、索引、表示にかかる時間の幅を示した、とまとめは書いています。各工程に、最も速い、典型、最も遅いがあり、Googleの内部の分析に基づく、とあります。工程はつながっていて、遅れは積み上がる、という留保も、Illyes氏のものとして書いています。Search Engine Journalは2026年10月4日、この幅をCampbell氏のまとめから引き、典型の定義も、標本の大きさも、期間も、まとめにもGoogleのイベントページにもない、と書いています。最も速い時間は、まとめの表から落ちている、ともあります。スライドは、記事の時点で Search Central のイベントページにはない、とも書いています。Search Engine Journal

まとめと、Search Engine Journalが転記した典型と、遅い側は、次の範囲です。

新しいURLの発見: 典型は約20時間。遅い側は数週間から、起きない。
端から端までの索引: 典型は約1.5時間。遅い側は数カ月、または品質を理由に起きない。
構造化データの更新: 典型は数時間から1–2週間。遅い側は数週間、または品質を理由に起きない。
サイトの移転: 典型は1–3カ月。遅い側は6カ月から1年以上。
コアアップデートからの回復: 典型は3–6カ月。遅い側は6カ月から1年で、次のコアアップデート、と表にある。

スパムについては、まとめの中に二つの書き方があります。表の Spam update change は、典型が1–2週間（continuous）、遅い側が数カ月（batch refreshes）です。その近くの文は、コアアップデートの展開は2–4週間、スパムアップデートの展開は1–2日、です。一つのまとめが、1–2日と1–2週間を両方置いています。どちらが公式の定義かは、このまとめからは決まりません。2026年9月の一件について、ステータスダッシュボードが最大2週間と置いているのは、その展開の記述です。表の典型と、ダッシュボードの一文は、同じ文ではありません。10月16日の記事は、その一件の状況を扱う枠です。

WHAT TO LOG｜まとめと、公式の文書を混ぜない

残すなら、発言者、何日目のまとめか、Googleの文書に同じ文があるか、です。fan-outが Search Console に出ない、はMueller氏の話としてまとめにあります。schemaが文脈になる、はLevering氏の話として2日目にあります。AIでスパムを捕まえる、はNguyen氏の話としてあります。時間の幅は、定義のない典型です。自社の修正が、この時間で反映する期限にはしません。

出典： We Are ROAST Day 3（2026-10-02）／Day 2（2026-10-01）／Search Engine Journal 2026-10-04（出席者の転記。典型は未定義。スライドはイベントページになかった、と同記事）

次のリソース

Research Hubの知見を、自社の理解・比較・推薦・行動準備へつなげます。