2026年上半期に検索で変わったこと

Bingは、AIの回答でページが引用された場所をパブリッシャーに示し始めました。GoogleはDiscoverを変更し、FAQのリッチリザルトを終了し、AIの表示回数の専用レポートを導入しました。こうした目に見える変更に加えて、クローラーの上限、ブラウザのナビゲーション、ドメインの移行も、技術チームの確認項目を増やしました。1月から6月までの変更を、影響を受けるレポート、ページ、リリースの判断と結びつけて振り返ります。

データ

運用上の判断を変えた一連の出来事

順序が重要なのは、出来事ごとに答える問いが違うからです。1月には、練習問題の構造化データのドキュメントが削除され、優先ソースのガイダンスが公開されました。2月には、地域限定で米国の英語向けのDiscoverコアアップデートと、BingのAI Performanceの最初の公開プレビューがありました。3月は、スパムとコアの展開期間が別々で、Googlebotがレスポンスを処理する仕組みの技術解説も加わりました。4月にはコアの展開が完了し、バックボタン乗っ取りがスパムポリシーに追加されました。5月にはFAQのリッチリザルトの表示が終了し、生成AIのガイダンスが公開されました。6月には、Search ConsoleのAIレポート、移行に関する明確化、BingのAIビューの拡充、Yandexの時間別クエリ監視が加わりました。

この整理は、カテゴリの取り違えも防ぎます。クローラーへのレスポンスの不具合は、コアアップデートの最中でも、パブリッシャーがすぐに対処できます。機能の終了にはテンプレートとコンテンツの判断が、レポートの開始には計測の定義が必要です。出来事は、「アルゴリズムの更新」という1つの区別のない列にまとめず、影響を受けたページの根拠の隣に置きます。

製品の変更

Discoverと優先ソース

Googleの2月のDiscoverコアアップデートは、米国の英語向けから始まりました。ガイダンスでは、地域との関連性、タイムリーで独自の専門性、扇情的でない内容が挙げられています。そのため、最初の確認は地域と編集の観点になります。影響を受けた視聴者、言語、形式は、文書化された面の範囲内だったか。その範囲外でDiscoverに動きがあっても、一般的なページテンプレートを変える必要がある証拠にはなりません。表示回数を普遍的なランキングシグナルとみなす前に、コンテンツの地域を示す手がかり、トピックの専門性、公開のタイミング、実際のDiscoverレポートを確認します。

優先ソースは、別の経路をたどりました。Googleは1月にこの機能をドキュメント化し、4月にGoogle検索の全言語に拡大し、5月にはドキュメント上の範囲にAIによる概要とAIモードを加えました。経緯はドキュメントの更新に記録されています。パブリッシャーは、読者が自分を優先ソースに選びやすくなるボタンやリンクを共有できます。選ぶのは読者であり、スキーママークアップが代わりに選ぶことはできません。繰り返し訪れる読者に、媒体としてのはっきりした識別と、選択しやすい手段を用意します。

Discoverの実務的な確認は、コンテンツ自体から始めます。表示されている日付、トピック、地域との関連性、独自の取材や分析を確認します。次に、影響を受けた国と言語を、機能の公表されている範囲と比べます。複数の市場に向けて運営しているサイトでは、米国の英語向けの更新を、すべてのロケールの説明に使わないでください。編集面の改善は、その面に実際に触れられる読者と結びつけて進めます。

製品の変更

AIレポート：面ごとに分けて扱う

2月に、Bing AI Performanceが引用を軸にしたレポートを導入しました。6月のBingの続報では、Intents、Topics、Citation Share、Compareが加わりました。これらのレポートは、BingのAI体験がページをどう引用するかを調べるのに役立ちます。セッション、Googleの順位、AIによる概要の計測の代わりにはなりません。答えるのは、Bingが定義したレポートの面における、引用の可視性についての問いです。

Googleは6月のSearch ConsoleのAIレポートの発表で、検索とDiscoverの生成AI機能における表示回数の専用ビューを導入しました。この表示回数は、従来どおり全体のパフォーマンスレポートにも含まれます。専用ビューは、当初は一部のサイトに提供されました。Yandexは、時間別のクエリ監視データを追加しました。人気の検索クエリを対象にした、別の種類のレポートです。これらは、プラットフォーム、単位、集計期間ごとに分けておきます。クリック数、引用数、速報の時間別の値を足し合わせると、各レポートが実際に測っているものが見えなくなります。

zoom_in

ダッシュボードでは、データをエクスポートする前に、行の定義を決めます。1行が、あるURLグループのGoogle Search Consoleのクリック数のこともあれば、あるトピックのBingの引用数のことも、Yandexのクエリの時間別の観測値のこともあります。行ごとに、プロパティまたは市場、期間、タイムゾーンを決めます。足し合わせる設計ではない指標から、なめらかなグラフを描きたくなる誘惑を避けられます。

対応

クローラーの処理と2 MBの境界

Googleの3月のクローラーの解説で、古くからあるものの見落としやすい制約が、運用の話として扱われました。Googlebotが処理するレスポンスの量には上限があり、HTMLレスポンスの実質的な境界は2メガバイトです。教訓は、バンドルのサイズを数えて終わりにすることではありません。実際のステータス、最終的なURL、レスポンスの本文、canonicalタグ、レンダリング結果に含まれる重要なコンテンツを調べます。重要な指示やコンテンツが遅れて届くと、高速な回線でのブラウザ表示では、その失敗が見えません。

大きなJavaScriptのルートでは、代表URLを1つ選び、生のレスポンスヘッダーとバイト列を保存します。そのうえで、最初のHTMLに含まれるものと、レンダリング後に現れるものを比べます。対象は、メインコンテンツ、canonical、robotsディレクティブ、構造化データ、次の重要なページへのリンクです。根拠があれば、重要でないペイロードをクリティカルパスから外します。ただし、バイト数を満たすためだけにコンテンツを削らないでください。合格の条件は、ページに必要な意味が、クローラーの実質的な制約の範囲内で、到達でき、レンダリングできることです。

zoom_in

2メガバイトの境界は、テンプレートが、メインコンテンツより前に、大きなシリアライズ済みデータ、ナビゲーションのペイロード、重複したマークアップを送る場合に、特に重要です。バイトのコストは、JavaScriptのビルド出力だけでなく、返されるドキュメントの中で探します。canonicalや本文が、長い処理の連鎖のあとにクライアント側で提供されるなら、その依存関係を明示します。クローラーがリクエストできるのと同じルートのパラメーターで、テストします。

対応

スパム更新の展開とバックボタン乗っ取り

3月のスパムアップデートは3月24日から25日に実施されました。3月のコアアップデートは3月27日に始まり、4月に完了しました。調査では、この2つの期間を分けておく必要があります。どちらの期間でも、ページのクリック数が減った原因は、技術的な不具合、クエリの需要の変化、canonicalの問題、競合の動き、より広い品質の問題のどれかです。カレンダーだけでは、どれかを選べません。

4月13日、Googleはバックボタン乗っ取りを、スパムポリシーの明確な違反として追加しました。適用開始は6月15日と発表されました。この期限は、リリースカレンダーに入れます。監査すべきブラウザの具体的な動作があります。訪問者が検索結果から移動したあとで戻るを押したら、前のページに戻るべきで、予期しないナビゲーションの連続に閉じ込めてはいけません。まっさらなブラウザセッションで、デスクトップだけでなくモバイルでもテストします。そのうえで、リダイレクト、履歴の操作、挿入されたスクリプトを調べます。仕組みは、表面的なランディングページの変更で隠さず、取り除きます。

ポリシーの変更と更新期間の違いは、切り分けで重要です。バックボタン乗っ取りは、再現できる操作上の欠陥であり、テストの合否は明確です。コアアップデートと重なっているのは調査の文脈にすぎないので、分けた根拠が必要です。この2つの作業は別にします。紛らわしいナビゲーションは直接修正します。より広いコンテンツの見直しが妥当かどうかは、クエリ単位とページ単位のデータを見てから決めます。

対応

移行計画ではすべてのホストのバリアントを対象にする

6月のサイト移転のガイダンスで、アドレス変更のアドバイスが、すべてのドメインバリアントを対象にすることが明記されました。移行の棚卸しが変わります。ルートのホスト、wwwのホスト、関連するサブドメインのそれぞれに、暗黙の慣習ではなく、明示した最終的な移行先が必要です。優先する1つのホスト名だけを対象にしたリダイレクトマップでは、重複したバリアント、リンク切れ、未確認のバリアントが、ユーザーとクローラーにさらされたままになる恐れがあります。

トラフィックを切り替える前に、テストセットを作ります。稼働中の旧URLごとに、想定する最終URL、直接の恒久的なリダイレクトを1回、最終ステータス、canonical、サイトマップへの掲載、レンダリング後の重要なコンテンツを記録します。そのうえで、公開されているホストのバリアントごとにテストを繰り返します。内部リンク、canonicalタグ、サイトマップは、最終的なホストに更新します。古い慣習の修正を、リダイレクトチェーンに頼らないでください。関連する移行先がないURLは、トップページに送らず、適切なnot foundのレスポンスを返します。

ホストのバリアントのチェックには、ホスト名だけでなくプロトコルも含めます。公開で解決されるなら、HTTPのルート、HTTPSのルート、HTTPのwww、HTTPSのwwwです。移行は、端の部分で失敗しがちです。画像やhreflangのターゲットが古いホストのままだったり、古いサブドメインがリダイレクトを飛ばしていたりします。短い機械可読のマッピングとブラウザでの確認を併用すれば、クローラーにも人にも、最終的な移行先が1つに定まります。

製品の変更

FAQの終了と、範囲の狭い商品データの変更

5月には、性質の異なる2つの構造化データの保守に関する判断が生まれました。Googleは、5月7日からFAQのリッチリザルトの表示を止めました。経緯はドキュメントの更新に記録されています。表示されているFAQは、顧客の疑問に答え続けられます。ただし、有効なマークアップがあっても、この検索での表示が戻るとは限りません。読者向けの質問は、役に立つ場所に残します。機能のためだけの実装は、テンプレート、アナリティクス、アクセシビリティの依存関係を確認してから外します。

同じ5月の更新で、商品とマーチャントのドキュメントにhasAdultConsiderationが追加されました。事実が正確で、誠実に表現されているレコード向けの、範囲の狭いフィールドです。商品フィード全般の機能強化ではなく、機能を狙って挿入するものでもありません。一般的な原則は3つです。表示されるページに一致するセマンティックデータを保つ。グラフと対象の利用先を別々に検証する。製品が提供しなくなった表示の約束はやめる。

FAQでは、表示されている質問をデスクトップとモバイルでテストし、各回答が購入前や問い合わせ時の実際の疑問を減らしているか確認します。減らしているなら、リッチリザルトというメリットがなくても、コンテンツは残せます。adult considerationでは、カタログのレコードに事実の出典を求め、必要なら表示にも反映させます。コンプライアンスに関わるプロパティを、推測にもとづくSEOのフラグとして扱ってしまうのを防げます。

対応

次回のレビューで確認する項目

次回のレビューでは、1つの総合スコアではなく、面ごとに根拠のシートを1枚ずつ作ります。検索での発見では、国、言語、形式、関連する製品のレポートを記録します。AIでの可視性では、プラットフォーム、レポート名、日付、単位、帰属を残します。クロールの作業では、レスポンスヘッダー、本文のサイズ、レンダリングされた重要なコンテンツ、canonicalとrobotsの状態を残します。移行では、すべての入力ホストとルートのマッピングを残します。スキーマでは、表示されている事実、グラフの検証、現在の機能ポリシーを残します。こうした記録があれば、原因の物語を作らなくても、後の変更を説明できます。

• Discoverでは、編集テンプレートを変更する前に、影響を受けた国とコンテンツの形式を、文書化された製品の範囲と比べます。
• Google、Bing、Yandexのレポートは、別々の表で保持します。引用数、Search Consoleのクリック数、時間別のクエリの観測値は、足し合わせないでください。
• 重いルートでは、パフォーマンスを変更する前後で、生のレスポンスサイズとレンダリングされた重要なコンテンツを記録します。
• 移行では、ルート、www、すべての公開サブドメインを、リダイレクトマップ、canonicalタグ、サイトマップ、レンダリング後のページに対してテストします。
• 構造化データでは、役に立ち続ける表示上の情報と、Googleが終了したリッチリザルトの形式を区別します。
• 展開期間は、更新に原因を結びつける前に、クエリ、ランディングページ、技術面の根拠を調べます。