データ整合性こそ新しいテクニカルSEO――Search Engine Journalが「クロールから信頼へ」の移行を論じる【2026年7月】

何が起きたか:テクニカルSEOの重心が「クロールされるか」から「信頼されるか」へ

記事(Alex Moss氏、2026年7月28日付、9分読了)が出発点に置くのは、リッチリザルトの縮小です。「この2年で、Googleはリッチリザルトの検索ギャラリーから9つのItemTypeのサポートを打ち切った(“In the past two years, Google has dropped support for nine ItemTypes from its rich result search gallery”)」とし、それがChatGPTのローンチと大量採用が始まった時期からそれほど経たないうちに起きたと指摘しています。なお、その9種類が具体的に何であるかの列挙は記事本文にありません。

そのうえで記事は「プロトコルを追いかけるな、その下のレイヤーを自分のものにしろ(“Don’t Chase The Protocol, Own The Layers Underneath”)」という節を最後に置き、「ランキングは古いウェブにおける成功指標だった。信頼、整合性、正確性、そして妥当性。これを勝ち取ることが、いまもSEOの役割だ(“Rankings were the success metrics of the old web. Trust, integrity, accuracy, and validity. Earning this is still the role of an SEO.”)」と結んでいます。順位という単一の指標ではなく、機械に正しく読まれる状態そのものを成果と見なす、という立て付けです。

詳細①:「スキーマは死んだ」のか――FAQ廃止の文言をもう一度読む

記事によれば、9種類のうち直近の削除がFAQ/FAQPageで、これが将来のSearchにおけるschema.orgの役割をめぐる議論を引き起こしたとされています。スキーマがプラットフォームの回答内での引用に本当にプラスの影響を与えるのかを検証するテストについては、Gianluca Fiorelli氏が、私たちは限られたデータセットの上でそうしたテストを行っているのかもしれない、と注目すべき指摘をしたと紹介しています。

そのうえで記事は、FAQリッチリザルトの非推奨化(deprecation)を告げた文言をあらためて引用します。「…2026年6月に、FAQの検索での見え方、リッチリザルトレポート、およびリッチリザルトテストでのサポートを終了します(“…We will be dropping the FAQ search appearance, rich result report, and support in the Rich results test in June 2026.”)」。

著者が強調するのは、この文言が言っていないことです。すなわち「FAQスキーマの使用がもはや必須ではない」とは書かれていない。廃止されたのはリッチリザルト、つまり表示機能(a display feature)だけであり、スキーマそのものは「理解のレイヤー(a comprehension layer)」――エンティティと、それらの関係性を特定するもの――だからだ、という整理です。「スキーマは死んだのか。私の意見では、まったくそんなことはない」と述べ、非推奨になるプロパティがある一方でProductのように拡張されているものもあると付け加えています。ただしスキーマを追加すれば引用が伸びるという魔法の弾丸ではないことも認め、その成長は引用数やインプレッションといった従来の指標の外側にあるとしています。

関連して記事は、Suganthan Mohanadasan氏がスキーマには3つの「生」があると書いた記事に言及し、次の3つを挙げています。

1. Googleのインデックスパイプライン
2. LLMの事前学習(間接的)
3. LLMの実行時の検索取得(runtime retrieval)

SEO担当者は歴史的に1番目を、成功指標に寄与しうるものとして重視してきた。しかしスキーマの働きは、私たちが慣れ親しんだ範囲、より正確に言えばレポートできる範囲を超えている、というのが記事の指摘です。結論は「スキーマは死につつあるのではない。スキーマが恩恵を受けていた1つの表示機能が縮小しているだけだ」というものです。

詳細②:SEO最大の脅威は「曖昧さ」――データ整合性の5レイヤー

記事は「SEO最大の脅威:曖昧さ(An SEO’s Biggest Threat: Ambiguity)」という節で、リスクの連鎖を次のように説明します。スキーマはウェブ標準としてのオントロジーであり、データ整合性に寄与しうる。そのデータ整合性に対するリスクが曖昧さであり、曖昧さはハルシネーション(hallucination、事実に基づかない生成)を招く。ハルシネーションは雪だるま式に膨らみ、やがて結果が複合して、不正確な結果や、さらには誤ったLLMの事前学習につながりかねない。事前学習に入り込んだ誤りは、より長く尾を引く影響を持ちうる、という筋道です。ここで置かれているのが「もしエージェントがあなたを読み違えられるのなら、いつかは必ず読み違える(“If an agent can misread you, at some point it will.”)」という一文です。

さらにLLMは、事実から離れて物語(narrative)の側に引き寄せられる「セマンティックドリフト(semantic drift)」に陥るリスクがあるとし、Andrea Volpini氏とChiara Carrozza氏による「Sangue e Grafi: Teaching a Small Model to Read the Bloodline」という記事を参照しています。同記事では、フロンティアモデルが事実よりも物語に引き寄せられる傾向を見せた一方、ナレッジグラフのツールを与えられた小規模モデルがそれらと肩を並べた、と紹介されています。

こうしたことのすべてが、SEOの役割はデータ整合性を最大化することでありスキーマがそこで一定の役割を果たす、という自身の考えを裏付けていると著者は書きます。そのうえで、データ整合性が含みうる5つのレイヤーを次のように図示しています。

1. エンティティ(Entities):何が存在し、それが何であるか。Thing、Organization、Personを@idで安定させ、Wikidata、GS1、ISNI、ORCIDといった権威にひも付けることで、エージェントはあなたの「Apple」を果物と区別できる
2. 関係性(Relationships):それらがどうつながるか。@idとsameAs、RDF。Yoast SEOのスキーマ集約機能や、Dixon Jones氏によるEntityMap
3. 形式(Format):構造がどうシリアライズされ、配信されるか。JSON-LD、RDFa、Microdata。さらにmarkdown(LLMs.txt、agents.md、OKFを包含する)と、エンドポイント(コンテンツネゴシエーション、ARD、MCP)
4. アクション(Actions):何ができるかをエージェントに向けて宣言する。BuyActionのようなSchema.orgのActionsに加え、より新しいWebMCP、ACP、UCP
5. 認識(Perception):グラウンディング、第三者からの認識、センチメントなど

詳細③:プロトコル群は「集約・指針・消費」の3つの目的に分かれる

著者は昨年10月の投稿で「SEO担当者はウェブの両側と、その両方にどう対応するかを考えなければならなくなる(“SEOs will have to consider both sides of the web and how to serve both.”)」と述べていたと振り返り、直近2年で登場したプロトコル群がそれを裏付けていると書きます。新しい「エージェント的グラウンディングスタック(agentic grounding stack)」は、おおむね3つの目的のいずれかを取るという整理で、原文の一覧表には集約(Aggregation)が8件、指針(Guidance)が2件、消費(Consumption)が7件の計17件が並びます。

記事は、これら3つの目的がリクエスト数を減らしつつトークン効率を高めるのに役立つと説明しています。いくつかはSearch Engine Journalでより詳しく扱われており、ACPとUCPについては著者自身の記事が、OKFやARDなどについては今月初めのEmina Demiri-Watson氏の記事があると案内しています。

背景:合意なき標準化――Schema.orgやXMLサイトマップとの決定的な違い

記事が最も強く問題視するのは「合意も、合意された標準も存在しない(There Is No Consensus Or Agreed Standard)」という点です。Schema.orgはGoogle、Microsoft/Bing、Yahoo!(のちにYandexも参加)の合意から生まれ、共同のガバナンスの下でローンチされた。その5年前のXMLサイトマップでも同じことが起きた。検索エンジンが標準を必要としたとき、彼らは単に一堂に会し、共同でそれを作った、という書き方です。

しかし、いま同じことは起きていない。記事は、これは自分の担当するサイトに何を実装し何を実装しないべきかについて本当に明確さを求めているSEO担当者にとって不利益だ、と述べます。消費(Consumption)に関する基本的な事実さえ争点になっており、markdownをめぐる議論はその好例だとしています。著者の見立てでは、プラットフォーム各社が集まって1つの普遍的な標準に合意する場は存在しない。エコシステムは劇的に変化し、これらの企業はもはや検索とウェブの善のためのビジネスにいるのではなく、自社のビジネスが雇用、経済、生活、そして人類全体の未来にどう影響するかを乗りこなさなければならない。であれば、SEO担当者が投げかける疑問が優先度の上位に来るとは思えない、というわけです。記事は締めくくりでも、提案やプロトコルの段階からウェブ標準へと進む単独の「勝者」は見当たらないと重ねて指摘しています。

実務への影響:著者が示す実装の優先順位

記事は「いま、あなたに何ができるか(What Can You Do About It Now?)」という節で、5つのレイヤーのうち自分でコントロールできるのは4つだとしたうえで、検討事項は多く目的も技術的負債も異なるため、自社に最も当てはまるものを見極め、技術的負債が大きくなりすぎないものを採用するよう勧めています。そのうえで「もし自分が順序を選ぶとしたら」として、次の並びを挙げています。

1. まず@idを安定させ、Wikidataやその他の権威へのsameAsリンクを追加する。他のすべてがこの上に立つため
2. 次に、グラフが自分の意図どおりに読まれていると仮定するのではなく、NLWebを使って実際にどう解釈されているかをテストする
3. ECであれば、派手なものに手を出す前に商品フィードを監査し、ついでにBuyActionも見ておく。今日、実運用と呼べる規模で展開されているのはReadActionとSearchActionだけなので、この領域は本当に空いている。Product構造化データに何が追加されたかについての最近のニュースも確認する
4. WebMCPの実装を試みる。これはどんなウェブサイトでも可能で、ECである必要はない
5. markdownの配信とコンテンツネゴシエーションは、エンジニアリングの余力ができるまで後回しでよい(CloudflareのMarkdown for Agentsを使える場合を除く)
6. OKFとARDを調べる。Googleが新しいプロトコルを出したときは常に注目している。とくに、エージェントやLLMがサイト全体をどう理解するかという点で

著者はこの並びについて「これは特定のプロトコルへの賭けではない」と明言しています。いずれかを実装することは、LLMが答えを組み立てるために「遠回り(“the long way round”)」をしなければならないリスクを下げる、という考え方です。著者自身も、コンテンツネゴシエーション、markdownのalternate、llms.txt、WebMCPといった複数の「エージェント対応(agentic ready)」プロトコルを動かす形で個人サイトを作り直したと明かし、大規模サイトから離れた小さな実験であっても、結果を見るためだけでなくそれらが実際にどう動くのかを理解するために試す価値があるとしています。

今日からできる確認手順(Scale Basics編集部の補足)

ここからは記事本文には書かれていない、Scale Basics編集部による一般的な実務上の補足です。上の優先順位を日本のサイト運用に落とし込むと、着手しやすいのは次の順番だと考えます。

1. 自社が出力しているJSON-LDを代表的な5ページ(トップ、会社概要、サービス、記事、問い合わせ)ぶん実際に取得し、OrganizationとPersonに@idが付いているか、その@idがページ間で同じ文字列かを確認する。テーマやプラグイン任せだと、同じ会社を指す@idがページごとに違うという状態が起こりがちです
2. @idを固定できたら、自社名でWikidataに項目があるかを確認し、あればそのURIを、なければ公式サイト、公式SNSアカウント、業界団体の会員一覧ページなど第三者から参照されうるURLをsameAsに列挙する
3. 著者情報を出しているメディアなら、著者ページのPersonにも同じ処理を行う。執筆者が研究者向けの識別子を持っているなら、それも候補になります
4. ページ単位のJSON-LDがサイト全体で1つのグラフとしてつながっているかを確認する。記事、著者、発行組織が互いを参照し合っていない状態は、原文の言う「関係性」レイヤーが空であるのとほぼ同じです
5. ECサイトなら、商品フィードと商品ページのProduct構造化データで価格・在庫・識別子の定義がずれていないかを突き合わせる
6. llms.txtやWebMCPのような新しい仕組みは、いきなり本番の主要サイトに入れず、小規模なサイトや検証環境で挙動を確かめてから判断する

所感

ここからは記事本文にはない、Scale Basics編集部の見解です。この寄稿でいちばん実務に効くのは、「表示機能が終わったこと」と「その記述が不要になったこと」を明確に切り分けている点だと考えます。FAQリッチリザルトの廃止を受けて、日本の現場でも「FAQスキーマはもう外してよいのか」という判断が繰り返し発生しました。表示のためだけに入れていたなら整理する理由になりますが、ページ内の問答をエンティティとして機械に伝える役割まで同時に捨てるかどうかは、本来は別の意思決定です。原文が引くGoogleの文言も、終了するのは検索での見え方とレポートとテストツールであって、記述の要否には触れていません。

もうひとつ重要なのは「合意された標準はもう来ない」という前提を、感情ではなく投資判断として扱っている点です。標準化される保証のない仕組みが17も並ぶ状況では、どれか1つに全社の工数を賭ける決定は取りにくくなります。著者が示す順序が、技術的負債の小さいもの、かつ他のすべての土台になるものから始まっているのは、そのための現実的な折り合いだと読めます。日本のサイトに引き付けると、最初の一手である@idの安定化とsameAsは多くの現場でまだ手つかずのはずで、構造化データをテーマやプラグインに任せていると、同じ会社を指す識別子がページごとに揺れていたり、著者名が実在の人物としてどこにもひも付いていなかったりします。ここを直さないままmarkdown配信やWebMCPを先に議論するのは順序が逆になりやすく、「エージェントに読み違えられうる状態は、いつか必ず読み違えられる」という原文の一文は、施策の優先順位を社内で説明するときにそのまま使える整理だと思います。なお、これらの施策が順位やAIによる引用にどれだけ効くかの定量的な保証はなく、原文自身も従来の指標では捉えきれない領域だと述べている点は、KPIを握る前に共有しておきたいところです。

まとめ

・YoastのプリンシパルSEOでFireCask共同創業者のAlex Moss氏が、2026年7月28日付のSearch Engine Journalに寄稿し、テクニカルSEOの重心が「クロールされるか」から「信頼されるか」へ移っていると論じた

・この2年でGoogleはリッチリザルトの検索ギャラリーから9つのItemTypeのサポートを打ち切っており、直近の削除であるFAQ/FAQPageは表示機能の終了であって、スキーマそのものは「理解のレイヤー」だと著者は整理している

・データ整合性はエンティティ、関係性、形式、アクション、認識という5つのレイヤーで構成され、そのうち自分でコントロールできるのは4つだとされる

・エージェント的グラウンディングスタックとして挙がるプロトコルは集約8件・指針2件・消費7件の計17件に整理され、いずれもリクエスト数の削減とトークン効率の向上に寄与するとされる

・Schema.orgやXMLサイトマップのような合意形成の場は現在存在せず、著者は特定のプロトコルに賭けず、@idの安定化とsameAsを起点に順に進めることを勧めている

よくある質問

Q1: FAQリッチリザルトが廃止されたので、FAQスキーマの記述はもうやめてよいのですか?

記事は、廃止を告げた文言が「FAQスキーマの使用がもはや必須ではない」とは述べていない点に注意を促しています。終了するのはFAQの検索での見え方、リッチリザルトレポート、リッチリザルトテストでのサポートであり、廃止されたのは表示機能です。スキーマそのものはエンティティと、それらの関係性を特定する「理解のレイヤー」だ、というのが著者の整理で、「スキーマは死につつあるのではない。スキーマが恩恵を受けていた1つの表示機能が縮小しているだけだ」と述べています。ただし著者は、スキーマを追加すれば引用が伸びるという魔法の弾丸ではないことも同時に認めています。

Q2: 記事が挙げる「データ整合性の5つのレイヤー」とは何ですか?

エンティティ、関係性、形式、アクション、認識の5つです。エンティティはThing、Organization、Personを@idで安定させ、Wikidata、GS1、ISNI、ORCIDといった権威にひも付ける層。関係性は@idとsameAs、RDFでつながりを示す層で、Yoast SEOのスキーマ集約機能やDixon Jones氏のEntityMapが例に挙げられています。形式はJSON-LD、RDFa、Microdataに加えmarkdownやエンドポイントを含む層、アクションはBuyActionのようなSchema.orgのActionsやWebMCP、ACP、UCPで何ができるかを宣言する層、認識はグラウンディングや第三者からの認識、センチメントなどを指します。著者は、このうち自分でコントロールできるのは4つだとしています。

Q3: 数多くのプロトコルのうち、まず何から手を付けるべきですか?

著者が「もし自分が順序を選ぶとしたら」として挙げているのは、最初に@idを安定させてWikidataなどの権威へのsameAsを追加すること、次にNLWebを使って自分のグラフが実際にどう解釈されているかをテストすること、ECであれば商品フィードの監査とBuyActionの確認、続いてWebMCPの実装を試みること、markdownの配信とコンテンツネゴシエーションはエンジニアリングの余力ができるまで後回しでよいこと、最後にOKFとARDを調べること、という順序です。著者はこれを特定のプロトコルへの賭けではないとし、いずれかを実装すればLLMが答えを組み立てるために遠回りをするリスクが下がると説明しています。

出典:Why Data Integrity Is The New Technical SEO: From Crawling To Trust(Search Engine Journal、Alex Moss氏、2026年7月28日)https://www.searchenginejournal.com/why-data-integrity-is-the-new-technical-seo-from-crawling-to-trust/582189/