【2026年7月】SEO最新ニュース・トレンドまとめ

2026.08.02

2026年7月は、大規模なコアアップデートこそ発表されませんでしたが、検索と行動の距離が縮まった1か月でした。

Google Search ConsoleではSNS・動画コンテンツの計測機能が公開されたほか、AI Overviewsでの画像生成、AI Modeでの外部アプリ連携も始まっています。AMPの配信方式や商品構造化データにも、実務に直結する変更がありました。

本記事では7月1日から31日までの公式発表と主要SEO媒体の報道を時系列で整理し、SEO・コンテンツ・EC担当者が今月中に確認しておきたい対応をまとめます。

今すぐ無料で、
あなたのSEO対策費用を
シミュレーション！

簡単な質問に答えるだけで、
最適なSEOプランと費用が無料でわかります。

SEO対策を
行ったことはありますか？

AMPページがGoogleキャッシュ経由ではなく自社ホストへ直接遷移

7月1日、Googleは検索結果からAMPページを開く際の配信方式を変更しました。これまではAMP ViewerやAMP Cacheを経由する仕組みでしたが、今後はサイト運営者が管理するAMPページへ直接ユーザーを送ります。

あわせてGoogleは、AMP関連ドキュメントからAMP Viewer・AMP Cache・Signed Exchangeに関する記述を削除しました。ランキングロジックが変わったわけではなく、AMPコンテンツは引き続き通常のWebページと同様に評価されます。今回の本質は、順位への影響ではなく、検索結果からページへ移動する「経路」が変わった点にあります。

直接遷移になることで、ブラウザに表示されるURLも自社ドメインに統一されます。Google側のAMPキャッシュやSigned Exchangeを前提とした設定も不要になるため、自社のアクセス解析・同意管理・広告配信は確認しやすくなる一方、表示速度や安定性は自社サーバーやCDNの影響を直接受けるようになります。

そのため、今回の発表だけを理由にAMPを廃止する必要はありません。AMPを残すか、レスポンシブな通常ページへ統合するかは、保守コスト・表示速度・コンバージョン・アクセス規模を踏まえて判断するとよいでしょう。

企業が取るべき対策

まず、検索結果やGoogle DiscoverからAMPページへアクセスし、最終的に自社ドメインのURLが表示されるか確認しましょう。Google Analytics 4など計測ツールでは、AMPページのセッション・参照元・コンバージョンが変更前と同じ条件で記録されているかも点検してください。

あわせて、次の項目も確認しておくと安心です。

AMPページのcanonicalと通常ページのURLが正しく対応しているか
AMPページに古いGoogleキャッシュ前提の設定が残っていないか
自社ホスト環境で表示速度やエラー率が悪化していないか
広告・Cookie同意・アクセス解析が正常に動作しているか
AMP版と通常版で本文や構造化データに大きな差がないか

AMPを廃止する場合は、ページを削除するだけでなく、AMP URLから対応する通常URLへのリダイレクトや内部リンクの変更まで含めた移行計画を立てる必要があります。

■参照情報

Google検索セントラル（2026年7月1日更新）『ドキュメントの最新の更新内容』
Google検索セントラル（2026年7月1日更新）『Google 検索での AMP について』
Search Engine Land（2026年7月1日公開）『Google Search now sends searchers directly to publisher-hosted AMP pages』

CloudflareのAIクローラー設定でGooglebotが遮断される可能性

7月1日、Cloudflareは、AI関連のクローラーを「Search」「Agent」「Training」の用途別に管理できる設定を全顧客向けに発表しました。検索インデックスへの利用、ユーザーに代わるリアルタイム操作、AIモデルの学習といった用途を分けて、許可または遮断できる仕組みです。

SEO担当者が特に注意したいのは、2026年9月15日以降の複数用途クローラーの扱いです。Cloudflareは、SearchとTrainingの両方に分類されるクローラーについて、適用される設定のうち、より制限の厳しいルールに従って処理すると説明しています。そのため、Trainingを遮断しているサイトでは、Cloudflareの分類上、Googlebot、Applebot、Bingbotも遮断される可能性があります。

これはGoogleのクローラー仕様やランキングシステムが変更されたという話ではなく、Cloudflare側のアクセス制御に関する変更です。また、Cloudflareを利用するすべてのサイトで自動的にGooglebotが遮断されるわけでもありません。Trainingをブロックしているか、従来の「Block AI Bots」を利用しているかなど、各サイトの設定によって影響が変わります。

Googlebotへのアクセスを意図せず遮断すると、ページの再クロールやインデックス更新に支障が出るおそれがあります。Cloudflareを利用している企業は、9月15日を待たずに現状の設定を確認しておく必要があります。

企業が取るべき対策

Cloudflareの「Security Settings」でAIクローラーの設定内容を確認する
Trainingの遮断設定に、Googlebotなどの複数用途クローラーが含まれるか確認する
CloudflareのログやBot AnalyticsでGooglebotのアクセスが拒否されていないか調べる
Search ConsoleのURL検査で、主要ページのライブテストを実施する
AI学習の拒否方針と検索エンジンへのクロール許可方針を、法務・情報システム・SEO担当で整理する

クローラーの遮断は、SEOだけでなく、コンテンツの権利管理やセキュリティにも関わります。

担当部署ごとに個別判断するのではなく、どの用途のクロールを許可するのかを社内方針として決めておくと、意図しない設定変更を防ぎやすくなります。

■参照情報

Cloudflare Blog（2026年7月1日公開）『あなたのサイト、あなたのルール：すべてのお客様にAIトラフィックの新たな選択肢を提供』
Cloudflare Developers（2026年7月1日更新）『Block AI Bots』
Search Engine Journal（2026年7月2日公開）『Cloudflare’s AI Crawler Rules Can Block Googlebot』

Search ConsoleでSNS・動画コンテンツの検索実績を計測可能に

7月7日、GoogleはSearch Consoleに「プラットフォームプロパティ」という新しいプロパティタイプを追加すると発表しました。Instagram・TikTok・X・YouTubeに投稿したコンテンツが、Google検索・Discover・Google Newsでどのように表示され、クリックされたかを確認できます。

これまでのSearch Consoleは、自社で管理するWebサイトの検索パフォーマンスを分析するためのツールでした。プラットフォームプロパティの追加により、自社サイト以外のプラットフォーム上に公開したコンテンツについても、Google上での発見のされ方を把握できるようになります。

7月7日時点では段階的な提供でしたが、Googleは7月29日にグローバルで利用可能になったと案内し、具体的な分析方法を説明する公式ガイドもあわせて公開しました。

Googleサーチコンソールのソーシャル投稿や動画投稿のパフォーマンス確認画面

プラットフォームプロパティでは、「パフォーマンス」「インサイト」「Achievements（実績）」という3種類のレポートを確認できます。主に以下のようなデータを見ることができます。

Google検索・Discover・Google Newsでのクリック数と表示回数
ユーザーが検索したクエリ
検索流入を獲得した投稿や動画
国・デバイス・検索での表示形式
直近24時間を含む期間別の実績
前期間との比較やデータのエクスポート

ただし、今回の機能は「SNS投稿がWebサイトの検索順位を直接引き上げる」ことを示すものではなく、SNSや動画の投稿自体がGoogle検索やDiscoverでどう表示されたかを計測する機能です。

SEOとSNSを別々に評価するのではなく、ユーザーがGoogle・動画・SNSを横断して情報を探す状況を把握するためのデータとして活用するとよいでしょう。

企業が取るべき対策

自社で運用しているInstagram・TikTok・X・YouTubeのアカウントを、それぞれSearch Consoleへ登録しましょう。複数の媒体をまとめて一つのプロパティにするのではなく、アカウント単位で登録し、媒体ごとの差を確認できる状態にしておくことがポイントです。

登録後は、少なくとも次の指標を月次で記録することをおすすめします。

媒体別の表示回数とクリック数
クリック率
検索流入を獲得した投稿
投稿が表示された検索クエリ
Webサイトへの遷移や問い合わせへの貢献
動画・画像・テキストなど投稿形式ごとの違い

たとえば、YouTube動画が特定のハウツー系クエリで継続的に表示されている場合は、そのテーマを自社サイトの記事やFAQへ展開できます。反対に、Web記事で需要が確認できているテーマを動画化し、検索結果内での接点を増やす方法も考えられます。

SNSの再生回数や「いいね」だけで評価せず、Google検索でどの投稿が見つかり、どのような意図を持つユーザーにクリックされているかもあわせて確認すると、コンテンツ企画の精度を高めやすくなります。

■参照情報

Google 検索セントラルBlog（2026年7月7日公開）『ソーシャルプラットフォームや動画プラットフォームのコンテンツが Google 検索でどのように表示されているかを確認する』
Google検索セントラルBlog（2026年7月29日公開）『プラットフォームのプロパティがグローバルに展開, 新しいソーシャルおよびビデオパフォーマンスガイドを追加』
Google検索セントラル（2026年7月29日更新）『Search Consoleでソーシャルおよびビデオプラットフォームのコンテンツパフォーマンスを分析する』
Search Engine Land（2026年7月7日公開）『Google Search Console gains reporting on social and video platforms』

商品構造化データにカテゴリとセール期間の指定方法が追加

同じく7月7日、GoogleはMerchant Listing（商品リスティング）向け構造化データのドキュメントを更新しました。主な変更点は、商品カテゴリを示すProduct.categoryの説明追加と、セール価格が有効な期間を伝える方法の明確化です。

Product.categoryでは、販売者が独自に設定する商品カテゴリと、Googleの商品分類体系の両方を記述できます。独自カテゴリを記述する場合は文字列で指定するTextを、Googleの商品カテゴリに対応させる場合はCategoryCodeを使い、Google Product TaxonomyのカテゴリIDまたはカテゴリ階層を設定します。

Merchant Centerの商品フィードで使われるproduct_typeやgoogle_product_categoryとの整合性を高めるための更新で、商品ページの構造化データとMerchant Centerの商品情報を一致させやすくなります。

もう一つの変更が、セール価格の適用期間です。GoogleはvalidFrom・validThrough・priceValidUntilを使って、割引価格の開始日と終了日を記述する方法を示しました。

設定場所には注意が必要です。Offerノードに直接セール価格を設定している場合はvalidFromと（validThroughまたはpriceValidUntil）を、PriceSpecificationノードに価格を設定している場合はvalidFromとvalidThroughを使用します（priceValidUntilはPriceSpecificationノードには使用できません）。セール開始前や終了後に誤った価格が検索結果へ表示されるリスクを減らすうえで、押さえておきたいポイントです。

なお、これらのプロパティを追加しても、検索順位が上がったり商品リッチリザルトが必ず表示されたりするわけではない点には注意してください。構造化データは、Googleによる商品情報の理解や検索機能への参加資格を支援するものであり、表示自体を保証する仕組みではありません。

企業が取るべき対策

ECサイトを運営している場合は、商品ページ・Merchant Centerの商品フィード・実際にユーザーへ表示している価格情報の3つが一致しているかを確認してください。

特にチェックしたいのは、次の点です。

商品カテゴリがページごとに正しく設定されているか
独自カテゴリとGoogle商品カテゴリを混同していないか
セール価格の開始日時と終了日時が正しいか
通常価格とセール価格の関係がページ上でも明確か
商品フィードと構造化データで価格や在庫が食い違っていないか
利用中のECカートやSEOプラグインが新しい項目に対応しているか

自動生成された構造化データは、管理画面上では見えにくいことがあります。リッチリザルトテストやSearch Consoleの商品スニペット・販売者リスティングのレポートで、出力結果まで確認しましょう。セール期間が終了した後も割引価格が残り続けないよう、キャンペーン終了時の更新処理を運用フローに組み込むことも大切です。

構造化データだけでなく、ページ上の表示価格・フィード・在庫管理システムを同時に更新できる体制が理想です。

■参照情報

Google検索セントラル（2026年7月7日更新）『ドキュメントの最新の更新内容』
Google検索セントラル（2026年7月7日更新）『販売者リスティング（Product、Offer）の構造化データ』
Search Engine Journal（2026年7月9日公開）『Google’s New Merchant Listing Structured Data Improves SEO』

類似コンテンツの修正後もcanonical再評価に最大2週間かかる場合がある

7月10日、Googleはcanonicalに関するトラブルシューティングガイドを更新しました。canonicalとは、内容が重複または類似する複数のURLのうち、Googleが代表として扱うURLを指します。

今回追加された説明では、内容の類似性が原因で複数ページが同じ重複クラスターにまとめられている場合、コンテンツを修正した後も、Googleによる再評価に最大2週間かかる可能性があると明記されました。ページ間の違いが明確で大きいほど、別ページとして分離されやすいとも説明されています。

ここで注意したいのは、すべてのcanonical修正やリダイレクトに「最大2週間」という基準が当てはまるわけではない点です。今回示された期間は、主にコンテンツの類似性を解消した後、Googleが重複クラスターを再評価するまでの目安です。canonicalタグの記述ミス、リダイレクト、サーバー設定などは、別の原因として切り分ける必要があります。

修正直後にSearch Consoleの表示が変わらなくても、すぐに追加修正を重ねるべきとは限りません。実装日を記録し、Googleが再クロール・再評価する時間を考慮したうえで判断しましょう。

企業が取るべき対策

URL検査で「ユーザーが指定した正規URL」と「Googleが選択した正規URL」を確認する
canonical、301リダイレクト、XMLサイトマップ、内部リンクの指定先を一致させる
別ページとして評価させたい場合は、語句の差し替えだけでなく、検索意図や提供情報を明確に分ける
修正日を記録し、少なくとも再評価期間を考慮してから効果を判断する
インデックス登録リクエストは、Googleの案内どおり重要なURLに絞って利用する

たとえば、地域名だけを差し替えたエリアページや、商品名だけが異なる類似ページでは、canonicalタグを変更するだけで問題が解決しないことがあります。ページを個別に検索結果へ表示させる必要があるなら、それぞれのページに固有の情報と明確な利用目的を持たせることが前提です。

■参照情報

Google検索セントラル（2026年7月10日更新）『ドキュメントの最新の更新内容』
Google検索セントラル（2026年7月10日更新）『正規化に関する問題の修正』
Search Engine Land（2026年7月10日公開）『Google clarifies canonicalization fixes can take up to two weeks to resolve』
Search Engine Journal（2026年7月10日公開）『Google Says Canonical Re-Evaluation Can Take Up to Two Weeks』

Google画像検索の探索画面とAI Overviewsの画像生成が拡張

7月14日、GoogleはGoogle画像検索の25周年に合わせて、画像を中心とした検索体験の更新を発表しました。

1つ目は、Google画像検索の新しいホーム画面です。米国の英語版デスクトップを対象に、Web上の画像をテーマ別に閲覧できる動的なギャラリーを段階的に展開します（現時点では日本語では利用できません）。表示内容はリアルタイムの話題やユーザーの関心に応じて変化するとのことです。

従来の画像検索は、検索キーワードを入力してから結果を見る使い方が中心でした。新しいホーム画面では、明確な検索語が決まっていない段階でも画像を眺めながらテーマを発見できるため、Discoverに近い探索型の利用が増える可能性があります。

2つ目は、AI Overviews内での画像生成です。画像の作成を求める検索を行うと、Googleの画像生成モデル「Nano Banana」を使い、AI Overviews内で画像を生成できるようになります。発表時点では、AI Modeの画像生成に対応している地域を対象に、英語で段階的に提供されるとされています。

この変更はSEO担当者にとって両義的です。ユーザーが求める画像を検索画面内で生成できるため、素材サイトや画像作成方法を解説するページへ移動せず検索行動が完結する場面が増える可能性がある一方、現時点でGoogleはWebサイトへの画像検索流入がどの程度変化するかを示していません。

また、新しい画像検索のギャラリーによって、Web上の写真・商品画像・図解・制作事例が、検索語の入力前を含む新たな場所で発見される機会も広がります。「AI画像が増えるから画像SEOの価値が下がる」と一方向に捉えるのではなく、生成で代替されやすい画像と、実物や一次情報として価値を持つ画像を分けて考えることが重要です。

企業が取るべき対策

今後は、どのサイトでも用意できる汎用的なイメージ画像だけでなく、自社だから提供できる視覚情報を増やすことが重要です。次のような画像は生成画像では代替しにくく、商品やサービスの信頼性を補強できます。

自社商品の実物写真や利用場面
施工前後・導入前後の比較写真
独自調査をもとにしたグラフや図解
担当者や専門家が説明している写真
店舗・施設・イベントの現地写真
操作画面や具体的な手順を示すキャプチャ

画像を掲載する際は、ファイル名やalt属性だけを機械的に最適化するのではなく、画像の前後に説明文を置き、何を示しているのかをページ全体で理解できるようにしましょう。高解像度の画像を用意しつつ、WebPやAVIFなどを利用して表示負荷を抑えることも大切です。

Search Consoleでは画像検索のパフォーマンスを分けて確認できます。画像ごとの計測には制約がありますが、画像検索から流入しているページ・クエリ・デバイスの変化を月次で確認すると、どのテーマへ写真や図解を追加すべきか判断しやすくなります。

■参照情報

Google公式ブログ（2026年7月14日公開）『ビジュアル検索の革新から25年を祝う』
Google検索セントラル（2026年3月2日更新）『Google 画像検索 SEO ベストプラクティス』
Search Engine Land（2026年7月14日公開）『Google Image Search drops clean search box and adds gallery of images』

AI ModeがInstacart・Canva・YouTube Musicとの連携を開始

7月16日、GoogleはAI Modeから外部サービスへ処理を引き継げる「Connected Apps」の提供を米国で開始しました。

最初の連携先はInstacart・Canva・YouTube Musicです。AI Modeで献立や買い物について相談し、その材料をInstacartのカートへ追加する、Canvaのテンプレートを探す、希望に合ったプレイリストを作成してYouTube Musicへ保存するといった操作が想定されています。

これまで検索は、情報を調べてリンクをクリックし、移動先のサイトやアプリで行動を起こす形が基本でした。Connected Appsが目指すのは、その相談内容を検索結果の中から外部サービスでの具体的な行動へ直接つなげることです。

現時点では米国での提供に限られており、連携サービスも限られています。日本の検索結果や一般的なWebサイトの順位に直接影響する変更ではありません。ただし中長期的には、検索が「情報を提示する場所」だけでなく、「予約する」「購入する」「作成する」といった行動を始める場所へ広がっていることを示しています。Googleは今後さらに連携先を増やす方針も説明しています。

企業側から見ると、検索結果から自社サイトへの訪問が発生しない場面が増える可能性がある一方、自社の商品やサービスがAIによる提案や行動の選択肢として表示されれば、意思決定に近い地点で接触できる可能性もあります。ただし、特定の構造化データを入れればConnected Appsに採用されるといった公式な要件は示されていません。現段階ではAI Mode向けの特殊な対策を急ぐより、Googleや外部サービスが参照できる事業情報を正確に保つほうが現実的です。

企業が取るべき対策

まず、自社のユーザーが検索後に起こす行動を整理しましょう。ECであれば商品選択から購入まで、店舗型ビジネスであれば比較から予約まで、BtoBであれば情報収集から問い合わせまでの流れです。そのうえで、行動に必要な情報がWeb上で正しく一貫して公開されているかを確認します。

商品を扱う企業では、商品名・カテゴリ・価格・在庫・配送条件・返品条件を最新の状態に保ちます。店舗やサービスを運営する企業では、営業時間・所在地・提供エリア・予約方法・料金・キャンセル条件などが重要です。

また、AI検索でブランド名や主力商品・主要サービスを検索し、次の点を定期的に記録しておくと変化を追いやすくなります。

自社が回答内で言及されているか
事実と異なる説明がないか
どのページや外部情報が参照されているか
競合と比較して何が紹介されているか
公式サイトへ移動できる導線があるか

AI検索での露出とサイト流入は同じ指標ではありません。Search Console・アクセス解析・指名検索・問い合わせ数を組み合わせ、検索画面内での接触が事業成果にどう関係しているかを長期的に見ていく必要があります。

■参照情報

Google公式ブログ（2026年7月16日公開）『Connect more of your apps to Search』
Search Engine Land（2026年7月16日公開）『Google AI Mode adds Instacart, Canva and YouTube Music integrations』
Search Engine Journal（2026年7月16日公開）『Google’s AI Mode Now Connects To Your Apps』

偽レビューと非開示のインセンティブレビューに新ガイドライン

7月24日、Googleはレビュー抜粋の構造化データに関するガイドラインを更新し、偽レビューや、対価があることを明示していないインセンティブレビューをページおよび構造化データへ含めないよう明記しました。

新たに示された対象には、実際の商品・サービス体験に基づかないレビューのほか、金銭・割引・クーポン・無料商品の提供などを受けて投稿されたにもかかわらず、その事実が明瞭に開示されていないレビューが含まれます。

注意したいのは、「顧客へレビュー投稿を依頼する行為がすべて禁止された」わけではない点です。今回のガイドラインが問題としているのは、偽の体験談と、インセンティブの存在を開示していないレビューです。一方、Googleの機能やレビュー収集サービスによっては、インセンティブ自体を認めていない場合もあるため、レビューの利用先ごとにSearch Central・Merchant Center・Googleビジネスプロフィール・レビュー提供事業者の規約を分けて確認する必要があります。

構造化データの文法が正しくても、内容がガイドラインに違反していればレビューのリッチリザルトが表示されない可能性があります。

Googleは構造化データのガイドライン違反に対して手動による対策を行う場合があるとも説明しています。星の表示を増やすことに目が向きがちですが、今回の更新はレビューの「件数」だけでなく「取得方法」と「透明性」が問われることを示すものといえるでしょう。

企業が取るべき対策

自社サイトでレビューや評価を掲載している場合は、構造化データだけでなく、レビューの取得経路まで確認してください。

具体的には、以下を点検します。

実際の購入者や利用者によるレビューであるか
社員や関係者が一般顧客を装って投稿していないか
謝礼・割引・無償提供などの条件があるか
条件がある場合、その事実を閲覧者へ明瞭に開示しているか
ページ上に表示していないレビューを構造化データだけに含めていないか
他サイトの評価を自社レビューとして合算していないか
悪い評価だけを不自然に除外していないか

レビューキャンペーンを行う際は、「高評価を付けた人だけに特典を渡す」設計を避け、評価内容にかかわらず同じ条件で依頼することが重要です。投稿依頼文・特典条件・レビュー掲載基準も社内で記録しておきましょう。構造化データには、ページ上でユーザーが確認できるレビューや評価だけを反映してください。レビュー本文・投稿者名・評価点・対象商品やサービスの対応関係を明確にし、リッチリザルトテストとSearch Consoleでエラーを確認しましょう。

■参照情報

Google検索セントラル（2026年7月24日更新）『ドキュメントの最新の更新内容』
Google検索セントラル（2026年7月24日更新）『クチコミ抜粋（Review、AggregateRating）の構造化データ』
Search Engine Land（2026年7月24日公開）『Google says don’t include fake or undisclosed incentivized reviews in review snippet structured data』
Search Engine Journal（2026年7月27日公開）『Google Expands Review Guidelines And Warns Of Manual Actions』