タグ: SEO

Googleが8月18日に「August 2026 spam update」の展開を始め、2日16時間ほどで完了しました。検索セントラルのランキング更新履歴に記録されているとおり、対象は全言語・全地域です。お盆明けに検索からの流入が少し動いた、という心当たりのある方もいるかもしれません。

スパムアップデートという名前は身構えさせますが、内容はGoogleがすでに公開しているスパムポリシーに沿って、違反を見つける自動システムを調整するものです。新しい違反の種類が増えたわけではありません。とはいえ、ふつうにサイトを運営していても意図せず触れてしまう項目はいくつかあります。公開資料をもとに、確かめておきたい場所を整理してみます。

今年三度目のスパムアップデート

Googleは検索の順位に関わる大きな更新を、ステータスダッシュボードのランキング履歴に記録しています。そこを見ると、今年のスパムアップデートは3月24日、6月24日、そして今回の8月18日で三度目です。コアアップデートのほうは3月27日と5月21日の二回でした。

目を引くのは展開の速さです。今回は2日16時間で完了し、6月の更新も2日1時間でした。11日以上かかった5月のコアアップデートや、26日を超えた昨年8月のスパムアップデートと比べると、明らかに短くなっています。展開が短いということは、順位の動きが出るならすぐ出て、すぐ落ち着くということでもあります。数日ぶんの数字だけで判断を急がないほうがよさそうです。

コアアップデートとは狙いが違う

コアアップデートは検索システム全体の評価の見直しで、違反がなくても順位は動きます。一方でスパムアップデートは、スパムポリシーに反する手法を検出する仕組みの精度を上げるものです。Googleはポリシーの冒頭で、違反行為は自動システムと、必要に応じた人によるレビューの両方で検出されると説明しています。後者は手動による対策につながり、違反したサイトは順位が下がるか、結果に表示されなくなるとしています。

この二段構えは実務のうえでけっこう重要です。手動による対策を受けた場合はSearch Consoleに通知が届きますが、自動システム側の評価が変わっただけなら通知は来ません。通知がないから何も起きていない、とは言い切れない一方で、通知が届いていれば原因の在りかははっきりしている、という読み方になります。

運営していると意外に触れやすい項目

ポリシーを読み直すと、悪意なく運営していても引っかかりうる項目が並んでいます。ひとつは利用者が投稿できる場所に溜まるスパムです。ブログのコメント、フォーラムの書き込み、ファイルのアップロード先などが例に挙げられており、サイト運営者自身が気づいていないことが多い、とGoogle自身が書いています。

もうひとつは、改ざんによって置かれたコンテンツです。既存ページへのコード挿入、新しいページの追加、本文への隠しリンクの混入、そして条件つきのリダイレクトが例示されています。検索結果から来た人だけ別のページに飛ばし、URLを直接開いた運営者には何も起きない、という形が典型です。長く動いているサイトほど、使わなくなったプラグインやテーマが入り口になりやすいところです。

第三者の記事を載せる形も気になりますが、ここはGoogleが線引きを明記しています。問題になるのは、ホスト側がすでに持っている評価を借りて上位に出すことが主な目的のときです。読者に直接届けることを目的とした寄稿、社説、記事広告、あるいは掲示板やコメント欄のような利用者投稿の仕組みは該当しない、と例外が並べられています。

安心してよい表現と、確かめたいリンク

隠しテキストの項目もよく誤解されます。白背景に白文字を置く、文字サイズや不透明度をゼロにする、CSSで画面外に飛ばすといった手法は違反ですが、アコーディオンやタブ、スライダー、ツールチップ、スクリーンリーダー向けのテキストは違反ではないと明示されています。使い勝手のために内容を出し分ける設計は、そのまま続けて構いません。

リンクについても同じで、広告やスポンサーとしてリンクを売り買いすること自体は否定されていません。rel=”nofollow” か rel=”sponsored” を付けて評価を渡さないようにしていれば、ポリシー違反にはならないと書かれています。過去に受けた掲載営業の名残が残っていないか、記事下やフッターのテンプレートも含めて見ておくとよさそうです。

順位が動いたと感じたら、まずSearch Consoleで手動による対策の通知を確認し、次に落ちたクエリとページを特定する。この順番で見れば、慌てて本文を書き換える前に原因の見当がつきます。展開はすでに終わっているので、ここからの数字は落ち着いた状態のものとして読めます。

検索結果の見た目にかかわる仕組みは、この数年でずいぶん整理されてきた。中でも設置していたサイトが多かったのが、質問と回答を検索結果の中に折りたたんで見せるFAQのリッチリザルトだ。表示そのものは今年の五月に止まり、その後もSearch Console側の対応が段階的に外されてきた。最後まで残っていたAPIのサポートが、今月で終わる。

ひとつの表示形式が消えるという話にとどまらず、構造化データを何のために書くのかという前提が静かに動いている。過去に廃止された型の顔ぶれと、逆に細かくなっている領域を並べて見ると、その動きが見えてくる。

段階的に外されてきた対応が今月で終わる

時系列を整理しておく。FAQのリッチリザルトが検索結果に出なくなったのは五月七日で、翌日の五月八日にGoogleのドキュメントへ廃止の告知が入った。六月にはSearch Consoleの検索での見え方のレポートと、リッチリザルトテストからFAQの扱いが外れた。ドキュメント側でもFAQのリッチリザルトに関する記述そのものが削除されている。そして八月、Search Console APIからのサポートが外れる。

実務上の影響は、どこまで自動化しているかで変わる。管理画面を目視で確認しているだけなら、六月の時点でレポートが消えているので今月は何も起きない。一方、APIを叩いてレポートを自社ツールやスプレッドシートへ流し込んでいる場合、FAQの項目を参照している処理は今月のどこかで結果が返らなくなる。制作会社が保守で運用レポートを自動生成しているケースでは、ここが静かに壊れる。数字が出なくなるのではなく、項目そのものが無くなるという壊れ方なので、エラーで気づけるとは限らない点に注意したい。

付け加えると、Googleは表示をやめただけで、ページに書かれたFAQの構造化データを読むこと自体はやめていないと説明している。マークアップを急いで剥がす必要はない、という整理になる。

消えていった型に共通していたもの

廃止されたのはFAQだけではない。手順を検索結果に並べて見せるHowToは、モバイルでの表示が絞られたあと、二〇二三年九月にデスクトップでも出なくなった。教育系のサイトで使われていたPractice Problemは、今年一月にSearch Consoleとそのレポート機能からサポートが外れている。

共通しているのは、表示される機会がそもそも少なく、表示されても利用者があまり触っていなかった型だという点だ。Googleの説明でも、使われる頻度が低く利用者への価値が大きくない機能を整理した、という言い方をしている。逆に言えば、検索結果の面積は有限で、そこに何を出すかは常に取捨選択の対象だということでもある。

もうひとつ見落としやすいのが、FAQのリッチリザルトが後半では、政府機関や医療分野の、広く知られた権威あるサイトにしか出なくなっていたことだ。同じマークアップを書いても表示されるかどうかは相手次第で、それ以外のサイトでは書いても出ないという状態が先に来ていた。今回の廃止は、その状態を正式に確定させたに近い。

この経緯は、リッチリザルトを前提にページを設計することの危うさも示している。手順を並べる形式が有利だと聞いてHowTo用にページを組み直した制作現場は当時それなりにあったはずだが、その表示は数年で消えた。表示形式は検索側の都合で入れ替わるものだと考えておくほうが、長い目で見れば手戻りが少ない。

構造化データ全体が縮んでいるわけではない

廃止の告知が続いたことで、構造化データそのものを縮小していく方針なのではという受け取り方が一部で広がった。ただ、Googleはこれを明確に否定している。整理の対象はあくまで使われていない一部の型であり、基本的な情報の伝え方をやめるわけではない、という立場だ。担当者からは、表示形式は移り変わるものだが、タイトルタグやrobotsの指定のように手放してはいけないものもある、という趣旨の説明も出ている。

実際、記事、パンくず、事業所情報、商品、動画といった定番の型は今も現役で、廃止の予定は出ていない。中小企業のサイトで効いてくるのは元々このあたりで、FAQの有無で検索流入が大きく動いていたサイトはそう多くないはずだ。手を入れる優先順位を決めるときは、廃止された型の話より、こうした残っている型が正しく出力できているかを見るほうが実りがある。

商品や価格まわりはむしろ細かくなっている

縮小の反対側で、記述が細かくなっている領域もある。七月には、販売者向けの商品情報にcategoryプロパティが追加された。文字列でカテゴリ名を書く方法と、コード体系で指定する方法の両方が使えるようになっている。加えて、セール期間の扱いを説明する節が新設され、開始と終了の日時を表すvalidFrom、validThrough、そして表示価格の有効期限を示すpriceValidUntilの使い分けが整理された。

この方向は分かりやすい。人間が読む文章から機械的に取り出しにくい情報ほど、構造化データで明示する価値が残るということだ。質問と回答は本文を読めば分かるが、そのセール価格がいつまで有効なのかは本文の書きぶり次第で判別できない。だからこそ価格や在庫、期間といった要素は、むしろ書式が整えられていく。

通販をやっていないサイトでも、この考え方は流用できる。営業時間、所在地、対応エリア、料金の条件といった、本文中では表現がばらつきやすい情報を構造化データ側で揃えておくと、後から自分たちで検算しやすくなる。表示のためというより、データとしての整合性を保つための作業に近い。

付随して、期間を持つ情報には失効という考え方がついて回る点も押さえておきたい。終了日を書いた以上、その日を過ぎた記述が残っていれば、それは単に古い情報になる。構造化データを入れるということは、更新の責任を一つ増やすことでもある。誰がいつ見直すのかを決めないまま項目だけ増やすと、数年後に手をつけられない塊になりやすい。

口コミの扱いに条件が足された

七月下旬には、レビュースニペットのガイドラインにも追記があった。やらせのレビューや、報酬と引き換えに書かれたレビューについての基準が加わっている。星の数を検索結果に出す仕組みは以前から人気があるが、その分だけ、出所の怪しい評価を集めて表示させようとする動きも起きやすい。基準が明文化されたのは、そこに線を引く必要があったからだろう。

地方の事業者にとっては、他人事ではない話でもある。レビューを集める施策を外部の業者に任せている場合、その集め方がガイドラインに触れていないかは一度確認しておきたい。表示が止まるだけならまだしも、サイト全体の評価に影響が及ぶ形になると、回復に時間がかかる。

制作の現場で見直しておきたいところ

まず、FAQのブロック自体は消さなくていい。検索結果に出なくなっただけで、訪問者にとって質問と回答の形式が読みやすいことは変わらない。むしろ、リッチリザルト目当てで無理に質問形式へ変形させていたページがあるなら、この機会に読み物として自然な形へ戻すほうが素直だ。表示のために作られた文章は、たいてい読みにくい。

次に、構造化データの出所を把握しておきたい。WordPressで運用しているサイトの多くは、SEO系のプラグインやテーマが自動で出力している。プラグインを乗り換えたり、テーマを入れ替えたりしたときに、古い型と新しい型が二重に出ていたり、逆にどこからも出なくなっていたりすることがある。リッチリザルトテストやスキーマの検証ツールで、主要なページを何枚か抜き取って確認するだけでも状況はつかめる。

そして、レポートの自動化をしているなら今月のうちに参照箇所を確認しておく。APIの項目が消える変更は、画面を見ているだけでは気づきにくい。数年単位で運用するサイトほど、こういう小さな失効が積み重なって、いつの間にか誰も中身を保証できない状態になりやすい。

構造化データは、検索結果を飾るための道具から、ページの内容を機械に正しく渡すための道具へと、役割の重心が移りつつある。飾りが減ったぶん、書いた内容が正しいかどうかだけが残る。派手さはないが、こちらのほうが手入れのしがいはある。Google検索セントラルの更新履歴は日付順に並んでいるので、こうした変更を追うときの起点として使いやすい。

Googleが今月、Search Consoleに「プラットフォームプロパティ」という新しい種類のプロパティを追加したと公式ブログで発表した。InstagramやTikTok、X、YouTubeに投稿したコンテンツが、Google検索やDiscoverでどのように表示され、どんな検索語句から人が来ているのかを、Search Consoleの画面の中で確認できるようになるというもの。すぐに全員が使えるわけではなく、数週間かけて段階的に開放されると案内されている。

これまでのSearch Consoleは、ドメインやURLの所有権を確認したうえで使うツールだった。自分で管理していないSNS上の投稿は、検索結果に出ていたとしても計測する手段がなく、実質的に見えない領域として残っていた。今回のプラットフォームプロパティは、サイトを持っていなくてもアカウントを連携するだけで登録できる点が従来と大きく違う。プロパティを追加する操作自体は既存の流れと同じで、追加画面から対象のサービスを選び、連携を承認していく形になる。

用意されているレポート

見られるのはパフォーマンスとインサイトの二種類のレポートとされている。パフォーマンスのほうは、クリック数や表示回数といったおなじみの数字に加えて、どの投稿とどの検索語句が実際の流入につながっているかを絞り込んで確認できる。インサイトのほうは、直近の傾向や反応の良かった投稿、検索から自分のアカウントがどう見つけられているかを大づかみに把握するための画面という位置づけになっている。ウェブサイトのプロパティで見慣れている画面構成にかなり近いので、普段からSearch Consoleを開いている人なら戸惑うところは少なそうだ。サイトを持たずに発信している人にも数字が届くようにしたい、という意図が説明されている。

気をつけたいのは、ここに出てくるのはあくまでGoogle検索とDiscover経由の数字で、各サービスのアプリの中で見られた分は含まれないという点。SNSの管理画面が出す数字とは母数がまったく違うので、単純に足したり、どちらが正しいかを比べたりするような使い方には向かない。あくまで検索という入口からの流入を見るための道具として、別枠で扱うのが無難だと思う。連携そのものも各サービスの認証を通す形になるので、誰のアカウントを誰が繋ぐのか、社内で運用担当が分かれている場合は先に決めておいたほうがあとで混乱しない。

中小企業のサイト運営という視点で見ると、これは「SNSは検索とは別のもの」という前提を少し見直す材料になりそうだ。店名やサービス名で検索したときに、自社サイトより先にSNSの投稿が並んでいるケースは珍しくない。どの投稿がどの語句で拾われているのかが分かれば、サイト側でどんな情報を厚くすべきかの判断もしやすくなる。連携できるアカウントを運用しているなら、自分のところに機能が届いたタイミングで一度のぞいてみる価値はあると思う。