GoogleのJSON-LD解析が「1回だけ」になった ── 二重エスケープを、自分の構造化データで確認する13項目（2026年8月時点）

01 何が起きたか — JSON-LDの解析が「1回だけ」になった

2026年8月21日、Google Search CentralがLinkedInで発表

2026年8月21日、GoogleのSearch Central公式LinkedInアカウントが、JSON-LD構造化データの解析方法を変更したと発表しました(Google Search Central公式LinkedIn投稿(2026年8月21日))。投稿本文には次のように書かれています。

"To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping."

(訳: パーサーをJSONおよび他の標準規格に合わせるため、JSON-LDの抽出方法を変更し、HTMLのアンエスケープ処理を1回のみ適用するようにしました。)

この発表は、当サイトが構造化データを日常的に扱っているWEBディレクター・EC担当者に向けて、今日から確認しておくべき技術的な変更です。海外のSEO専門メディアも即日から相次いで取り上げており(Google Changes JSON-LD Extraction For Googlebot(訳: GoogleがGooglebot向けのJSON-LD抽出方法を変更)(Search Engine Roundtable))、国内でも鈴木謙一氏が同日に解説記事を公開しています(GoogleのJSON-LD解析が変更、HTMLアンエスケープは1回だけに(海外SEO情報ブログ))。

何が変わったのか — 「自動補正」の停止

これまでGooglebotは、JSON-LD内に二重にエスケープされた文字参照が含まれていても、それを複数回アンエスケープして本来の値に「自動補正」して読み取っていました。今回の変更後は、この自動補正が行われなくなり、アンエスケープは1回のみに統一されます。GoogleのGary Illyes氏は、この変更がJSON文字列のエスケープ規則を定めたRFC 8259(JSON仕様)第7章に準拠させるためのものだと述べています。

具体的には、次のような変化が起きます。

• 入力値が &(&を二重にエスケープした形)だった場合、これまでは自動補正され & として読み取られていましたが、変更後は1回だけアンエスケープされ、文字通り & という文字列として読み取られます。
• 数値文字参照(例: ✔、チェックマークを表す参照を二重エスケープした形)についても同様に、1回のアンエスケープでは意図した文字(✔)にならず、そのままの文字列として残ります。

いつから適用されているか

公式LinkedIn投稿には、具体的な施行日(何月何日から適用開始か)は明記されていません。投稿が公開された2026年8月21日の時点で、既に変更後の挙動になっているという前提で扱うのが安全です。段階的なロールアウトなのか、投稿時点で一斉に切り替わったのかについても、公式発表には記載がなく、当サイトが確認した範囲では判断できません。

02 なぜ・背景 — なぜ「自動補正」をやめたのか

JSON仕様(RFC 8259)への準拠

JSON文字列の中でどの文字をどうエスケープするかは、RFC 8259の第7章で標準化されています(RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format(訳: RFC 8259: JavaScript Object Notation(JSON)によるデータ交換フォーマット))。この仕様に沿えば、通常は1回のエスケープ・1回のアンエスケープで正しく値が復元されます。Googlebotがこれまで行っていた「複数回のアンエスケープによる自動補正」は、この標準仕様には無い、Google独自の寛容な扱いだったと理解できます。今回の変更は、標準に無い独自の救済処置を取りやめ、仕様通りの挙動に揃えたものだと整理できます。

二重エスケープは、なぜ発生するのか

二重エスケープは、悪意や誤操作ではなく、多くの場合システムの重ね合わせによって生まれます。典型的なパターンは次の通りです。

• CMSが記事タイトルや商品名を保存する際、データベース保存用にHTMLエスケープする(例: & を & に変換)。
• テンプレートエンジンやJSON-LD生成プラグインが、その値をJSON-LDに埋め込む際、さらにJSON文字列としてエスケープを重ねてしまう。
• 結果として、本来1回で済むはずのエスケープが2回行われ、&のような二重の形になる。

これまでGooglebotがこの二重エスケープを自動補正してくれていたため、多くのサイト運営者はこの重ね合わせに気づかないまま公開を続けてきた可能性があります。今回の変更で自動補正が止まることで、これまで表に出ていなかった実装のズレが、初めて可視化されることになります。

何が壊れるのか — 具体的な影響

二重エスケープされた値を持つJSON-LDでは、変更後、意図した文字ではなく、エスケープされたままの文字列がリッチリザルトや構造化データの解析結果に反映される可能性があります。会社名・商品名・レビュー本文などに&や特殊記号を含むサイトほど、この影響を受けやすいと考えられます。

特に注意すべきサイトの傾向

すべてのサイトが同じ確率で影響を受けるわけではありません。当サイトが確認した限りでは、次のようなサイトほど、CMSやプラグイン、テンプレートエンジンを何層も経由して値を組み立てているため、二重エスケープが混入する経路が多いと考えられます。①複数のCMS・プラグインを組み合わせて構造化データを生成しているサイト、②会社名や商品名に&を含む企業のECサイト・コーポレートサイト、③多言語対応のために翻訳プラグインを経由して値を生成しているサイト、④外部フィード(在庫連携システム等)から取得した値をそのままJSON-LDに埋め込んでいるサイトです。いずれも「値がどのシステムを通って最終的なJSON-LDになったか」を運営者自身が把握しにくいという共通点があります。

03 この記事で出てくる用語

HTMLエスケープ・アンエスケープとは

HTMLエスケープとは、&や<のようにHTMLの中で特別な意味を持つ文字を、&や<のような文字参照に置き換える処理です。アンエスケープはその逆で、文字参照を元の文字に戻す処理を指します。本記事のタイトルにある「1回だけ」は、このアンエスケープ処理の回数のことです。

二重エスケープとは

本来1回で済むはずのエスケープ処理が、システムを重ねる過程で2回行われてしまう状態を指します。& が & になり、それがさらに & になる、というのが典型例です。この記事全体で扱っている問題の中心にある現象です。

Unicodeエスケープ(\uXXXX)とは

JSON文字列の中で、特殊文字を \u0026(&を表す)のような4桁の16進数コードで表現する方法です。HTML文字参照(&のような形)とは別の仕組みで、HTMLエスケープと重なって二重になる心配がありません。今回の発表でGoogleが推奨している回避策のひとつです。

リッチリザルトとは

構造化データを正しく実装したページに対して、Googleの検索結果に通常のタイトル・説明文以上の情報(評価の星・パンくずリスト・FAQ等)を表示する仕組みです。構造化データの値が正しく解析されなければ、リッチリザルトの表示にも影響が及ぶ可能性があります。

拡張(Enhancement)レポートとは

Search Consoleの左メニューにある、構造化データの実装状況をまとめたレポート群です。実装している構造化データの種類ごとに(パンくずリスト・商品・FAQ等)、有効なページ数・エラー・警告の件数が表示されます。本記事のチェックリストで「拡張レポートを確認する」とあるのは、このレポート画面を指しています。

04 型別 — 適用範囲・限界・手順

🅰 適用範囲 — この変更が及ぶ範囲

今回の変更はJSON-LD形式の構造化データに関するものです。特に、CMS(WordPress等)のSEOプラグインが自動生成するJSON-LD、ECサイトのテンプレートエンジンが動的に値を埋め込んでいるJSON-LD、複数のシステムを経由して値が組み立てられている構造化データが対象になります。手書きで静的にJSON-LDを記述しており、値の生成過程でエスケープを重ねていないサイトは、影響を受けにくいと考えられます。

🅱 この発表が明らかにしていないこと

公式LinkedIn投稿は短い告知であり、次の点は明らかにされていません。①具体的な施行開始日(投稿日と同時か、既に一定期間前から適用されていたか)、②JSON-LD以外の構造化データ形式(Microdata・RDFa)にも同様の変更が及ぶのか、③自動補正が完全に廃止されたのか、それとも一部のケースでは今後も維持されるのか。当サイトが確認した一次情報・複数の海外解説記事の範囲では、これらへの明確な回答は見つかりませんでした。「公式には明示されていない」という限界を持った情報として扱う必要があります。

🅲 手順 — 今日、自分の構造化データを確認する

推測でこの変更の影響範囲を判断する代わりに、今日から自分のサイトで確認できる3つの経路があります。①Google公式のRich Results Testで実際のページを検証する、②Search Consoleの「拡張」レポートでエラー・警告件数の推移を確認する、③自サイトのJSON-LDソースを直接開き、&を含む値が二重エスケープされていないか目で確認する。05章のチェックリストで、この3つを具体的な作業手順に落とし込みます。

この3つの経路には、それぞれ得意・不得意があります。Rich Results Testは特定の構造化データ形式(商品・FAQ・パンくずリスト等)ごとの表示可否を確認できますが、サイト全体を一括で検証する機能ではないため、主要ページを個別に確認する手間がかかります。Search Consoleの拡張レポートは、既にインデックスされた全ページを対象にエラーの推移を追えますが、反映までに数日のタイムラグがあり、今日変更した内容がすぐには反映されません。JSON-LDソースの直接確認は最も確実ですが、値の数が多いサイトでは全件を目視するのは現実的ではなく、まずは主要ページに絞って確認するのが実務的です。

05 自分の構造化データを確認するチェックリスト

以下は、今日から確認できる項目です。1つあたり5分程度で確認できるものを選んでおり、Rich Results TestとSearch Consoleの画面を1回ずつ開けば、大半の項目に一度で対応できます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• Rich Results Testを開き、自社サイトのトップページを検証する
• 検証結果に表示されるエラー・警告の件数を控える
• Search Consoleの「拡張」レポートで、構造化データに関するエラー件数の直近の推移を確認する
• 自社サイトの主要ページ(トップ・主要カテゴリ・主要商品または記事)を3つ選び、それぞれのページのソースを表示する
• ソース内でapplication/ld+jsonのscriptタグを1つ探して開く
• その中の値に&のような二重の文字参照が含まれていないか、目で確認する
• 会社名・商品名など&を含みやすい値を3件書き出し、それぞれの表記を確認する
• 自社サイトでJSON-LDをどのように生成しているか(手書き・CMSのプラグイン・テンプレートエンジン)を1行でメモする
• プラグインを使っている場合、そのプラグイン名とバージョンを控える
• そのプラグインの公式サポートページやリリースノートを検索し、今回の変更への言及があるか確認する
• 3ページ分のRich Results Testの検証結果を、今日の日付と一緒に記録に残す
• 1週間後に同じ3ページを再度検証し、エラー件数がどう変化したかを比較する
• 次にJSON-LDを更新する予定があれば、Unicodeエスケープでの記述に切り替えるかどうかを、更新予定のメモに書き残す

06 エスケープ方法の比較

3つの記述方法を比較する

今回の変更を踏まえ、JSON-LD内で特殊文字を含む値をどう記述するかには、主に3つの選択肢があります。それぞれのリスクと推奨度を整理します。

方法	内容	今回の変更への耐性
HTML文字参照のまま埋め込む	&を&と記述する	二重エスケープの原因になりやすい。非推奨
Unicodeエスケープ(\uXXXX)	&を\u0026と記述する	HTMLエスケープと重ならないため、二重化しない
生文字のままJSONエンコード	&をそのまま&として値に含め、JSONエンコーダに処理を任せる	JSON標準の仕組みに従うため、二重化しない
プラグイン任せ(未確認)	生成方法を把握していない	まず04章の手順で、どちらの方式か確認する必要がある

表の4つの選択肢のうち、「HTML文字参照のまま埋め込む」方法だけが、今回の変更で新たにリスクを持つことになります。Unicodeエスケープと生文字のままJSONエンコードする方法は、どちらもHTMLエスケープの層を経由しないため、二重化する余地がありません。公式LinkedIn投稿でGoogleが挙げていた回避策も、この2つに相当します。

実務上どちらを選ぶべきかについては、公式投稿は優劣を明示していません。当サイトが確認した範囲では、Unicodeエスケープは既存のJSON-LD生成コードへの変更箇所が少なく済む一方、値の中に含まれる文字を機械的に変換する処理が別途必要になります。生文字のままJSONエンコードする方法は、標準的なJSONエンコーダ(多くのプログラミング言語に標準搭載されている)にエスケープ処理を任せられるため、実装としてはよりシンプルになりますが、既存のテンプレートが文字列を組み立てる過程を作り直す必要が出てくる場合があります。どちらを選ぶにしても、「HTMLエスケープ済みの値を、そのままJSON文字列に流し込まない」という原則を守ることが共通の対策になります。

🔧 WEBサイト・構造化データ自動作成ツール — 構造化データのたたき台を、今回の記述方法を踏まえて作り直す

07 当サイトの実測

当サイトも、構造化データのズレを見落としていた経験がある

当サイトが過去に、FAQPageスキーマが壊れていたことに気づいた記録を公開しています(archives/70)。このときは今回のような外部要因ではなく、当サイト側の実装ミスが原因でしたが、「構造化データは、意識的に確認しない限り壊れていることに気づけない」という点は、今回のGoogleの変更にもそのまま当てはまります。この事故を踏まえて、当サイトでは構造化データを新しく実装した後、必ずRich Results Testで検証してから公開する手順を運用に組み込んでいます。今回のようなGoogle側の解析ロジックの変更は、その運用の中に「定期的な再検証」という項目を加える必要があることを示しています。

値だけが違う穴を、後から見つけた経験

当サイトが別の回で、出力そのものは正常に見えるのに、datePublished・og:type・用語ハイライト・sitemapという4箇所で「値だけが違う」穴を見つけた記録も公開しています(archives/128)。今回の二重エスケープも、ページが正常に表示されているように見えても、構造化データの値だけがずれているという同じ性質の問題です。見た目が正常でも、値の中身までは保証されていないという前提を、当サイト自身の実測から持っています。この記録では、4箇所のうち3箇所が「HTTPステータスは200で、ページも正常にレンダリングされているのに、値そのものだけが古いままだった」という共通点を持っていました。今回の二重エスケープも、ページの見た目やHTTPステータスからは判別できず、JSON-LDの中身を直接開かない限り気づけないという点で、同じ構造の問題だと考えています。

今回の変更で、当サイトが確認したこと

この記事の執筆にあたり、当サイトの主要ページのJSON-LDについても05章のチェックリストと同じ手順で確認しました。当サイトのJSON-LDは、記事タイトルや説明文をシステム側で1回だけHTMLエスケープしてからJSON-LDに埋め込む構成になっており、二重エスケープには該当していません。ただし、この確認は今回の記事執筆時点でのものであり、テンプレートや生成方法を変更した際には、改めて同じ手順で確認する必要があります。

08 このテーマの、これまで

JSON-LDは、Googleが長く推奨してきた構造化データの記述形式

JSON-LDは、HTML本文とは独立したスクリプトブロックとして構造化データを記述できる形式で、Googleは以前からMicrodata・RDFaと並ぶ選択肢として、公式ドキュメントの中でこの形式を推奨してきました(構造化データに関する一般的なガイドライン(Google Search Central))。テンプレートの他の部分に手を入れずに構造化データだけを差し替えられる扱いやすさから、多くのCMSやプラグインがJSON-LD形式を採用しています。

Rich Results Testと、構造化データの検証手段の変遷

Googleは構造化データの検証手段として、以前の「構造化データテストツール」を廃止し、現在は「Rich Results Test」(Rich Results Test(Google公式ツール))を提供しています。今回のような解析ロジックの変更があった際、サイト運営者が実際の挙動を自分で確認できる手段が公式に用意されていること自体は、構造化データの点検を続ける上での前提になります。

「自動補正」が持っていた役割

今回廃止された「複数回のアンエスケープによる自動補正」は、これまで多くのサイトの実装上の揺れを、Googlebot側が黙って吸収してくれていた仕組みだったと言えます。標準に厳密に沿った処理へと変わったことで、これまで見えていなかった実装のズレが、今後は表面化しやすくなるという変化が起きています。今回の変更は単発の技術的な告知ですが、「Googleが暗黙に許容していた揺れを、今後は許容しなくなる」という方向性そのものは、構造化データに限らず今後も起こりうるものとして、継続的に確認していく価値があります。

解析ツール側の変遷

構造化データの検証手段自体も、Googleの側で何度か形を変えてきました。以前提供されていた「構造化データテストツール」は現在利用できず、Rich Results Testに一本化されています。検証の窓口が一本化されたこと自体は運営者にとって分かりやすい一方で、検証ツールの裏側にある解析ロジックが、今回のように予告なく更新されることがあるという点は変わっていません。ツールが「エラーなし」と表示することと、その裏側の解析ロジックが今後も同じ挙動を続けることは、別の話として扱う必要があります。