重複クラスタからの離脱は最長2週間、Search Consoleは外部プラットフォームへ｜SEOタイムズ 2026年7月13日

今週のGoogleは、大きな発表よりもドキュメントの改訂で動きがありました。地味に見えて実装や運用の判断に効くものばかりです。Search Consoleに追加された新しいプロパティ種別、正規化を直したあとの待ち時間、商品構造化データの書き方の明確化を順に整理し、最後にAIエージェントとWebMCPをめぐるセキュリティの論点にも触れます。

SNS・動画の投稿を測る「プラットフォームプロパティ」

Search Consoleに、Instagram・TikTok・X・YouTubeへ投稿したコンテンツがGoogle検索やDiscoverでどう扱われているかを見られる新種別「プラットフォームプロパティ」が加わりました。

使い方はシンプルです。プロパティ追加画面で対象のプラットフォームを選び、案内どおりにアカウントを認証するだけ。パフォーマンスレポートではクリック数・表示回数に加え、どの投稿とどのクエリが流入源になっているかを追えます。インサイトレポートでは直近の傾向や上位投稿を俯瞰できる構成です。ロールアウトは数週間かけて段階的に進むため、まだ表示されない環境もあります。

サイトを持たない発信者でも検索経由の見られ方を数字にできる、という点がこれまでとの違いです。SNSと検索の間に空いていた計測の穴が、部分的にせよ埋まりました。公式アカウントを運用しているなら、まず接続して現状を眺めるところからで十分でしょう。

出典：Google 検索セントラル ブログ ／ Search Engine Journal

正規化を直しても、すぐには重複クラスタから抜けない

正規化（canonicalization）のトラブルシューティング用ドキュメントが更新され、修正後の再評価にどれくらいかかるかという記述が追加されました。

書かれている内容はこうです。コンテンツ側の問題を解消したあとも、Googleはそのページを最大2週間ほど重複クラスタに留め置くことがある。そして、新しいコンテンツとクラスタ内の他ページとの差が明確で大きいほど、分離は早く進む傾向がある——。

ここから読み取れる実務上の示唆は2点あります。ひとつは、直した直後にインデックス状況が変わらなくても、慌てて追加の変更を重ねないこと。もうひとつは、「少し文言を変えた」程度の差では分離が進みにくい可能性がある、ということです。似たページを分けたいのであれば、差分は思い切って大きくとるほうが理にかなうと考えられます。

出典：Google 検索セントラル ドキュメント

商品構造化データ：categoryにコード型、そしてセール期間の書き方

ECサイト向けのマーチャントリスティング関連ドキュメントも手が入りました。

ひとつめは`category`プロパティです。従来のテキストに加えて`CategoryCode`型も受け付けることが明記されました。`CategoryCode`を使う場合は、`inCodeSet`にGoogleの商品カテゴリ分類（Google Product Taxonomy）のURLを、`codeValue`にIDまたはカテゴリのフルパスを指定します。テキスト値のほうは商品フィードの`product_type`に近い自由記述として扱えます。複数のカテゴリ値を並べて指定することも可能です。

ふたつめは新設された「セール期間（Sale duration）」のセクション。セール価格の開始日時は`validFrom`、終了日時は`validThrough`または`priceValidUntil`で表します。記述先が`Offer`ノードか`PriceSpecification`ノードかは、セール価格をどちらの`price`で表現しているかで決まります。`priceValidUntil`が`Offer`にしか使えない点は見落としやすいので注意してください。推奨は、開始・終了の両方を指定し、ISO 8601形式でタイムゾーンまで含めることです。

セール価格の表示が意図どおりにならず悩んでいた担当者にとっては、実装の拠り所ができたことになります。

出典：Google 検索セントラル ドキュメント ／ ドキュメント更新履歴

AMPドキュメントから消えた「ビューア」と「キャッシュ」

7月1日付の更新で、AMP関連ドキュメントからAMPビューア・AMPキャッシュ・Signed Exchangeについての記述が取り除かれました。

現行のドキュメントは、Google検索でAMPページのリンクをクリックすると、他のウェブページと同じようにAMPのURLがそのままブラウザに表示される、と説明しています。検索結果からはパブリッシャー自身のAMPページへ直接遷移する、という形です。

新しい仕様変更の告知というよりは、すでに実態として進んでいた変化にドキュメントが追いついたもの——と読むのが自然に思えます（これは編集部の仮説です）。AMPを維持しているサイトでは、キャッシュ経由を前提にした計測やURL処理が残っていないか、この機会に見直しておくと安心です。

出典：Google 検索セントラル ドキュメント ／ ドキュメント更新履歴

エージェントに差し出したWebMCPツールが、乗っ取りの入口になる

WebMCPは、ウェブサイトが「名前のついたツール」をAIエージェントに公開し、エージェントから直接呼び出せるようにする仕組みです。マークアップを解釈させるのではなく、機能そのものを明示的に差し出すアプローチだと言えます。

Search Engine Journalの記事は、この差し出し口がそのままプロンプトインジェクションの経路になりうると指摘しています。手口は大きく2つ。ツール名・パラメータ・説明文の中に指示を仕込むもの。そして、レビューやコメントといったユーザー生成コンテンツがツールの出力に混ざり、そこに命令が埋め込まれるものです。LLMは命令とデータを同じトークン列として扱うため、両者を確実に切り分けるのは難しい——という前提が背景にあります。

Chrome側が挙げる対策としては、ユーザー生成コンテンツに`untrustedContentHint`を付ける、読み取り専用のツールには`readOnlyHint`を使う、`exposedTo`で信頼できるオリジンに限ってツールを公開する、機微な操作の前に`requestUserInteraction()`を挟む、といったものが紹介されています。記事は、公開するツールを公開APIのエンドポイントと同じ厳しさで脅威モデリングすべきだと結んでいます。

WebMCPの導入を検討しているなら、SEO施策としてより、開発・セキュリティ側の設計課題として扱うほうが妥当だと考えられます。

まとめ

Search Consoleの守備範囲は、自社サイトの外——SNSや動画プラットフォームにまで広がりました。正規化の修正については「最大2週間は待つ」という公式の目安ができたので、途中で手を加えたくなる気持ちは抑えたほうがよさそうです。ECの構造化データは、カテゴリの指定方法とセール期間の書き方がはっきりしました。そしてWebMCPは、便利さと攻撃面が同じ入口から入ってくる技術だという点を、導入前に押さえておきたいところです。

出典：Search Engine Journal