GoogleがJSON-LDの読み取りを厳格化。7パターン検証で分かった「壊れるのは2つだけ」
2026年8月21日、Googleが構造化データ（JSON-LD）の読み取り方を変えたと告知しました。これまでは書き方に多少の乱れがあっても補正して読んでいたのが、標準どおりの書き方を求めるようになったという内容です。
「社名に&が入っていたら危ない」という説明を見て不安になった方もいると思います。実際にGoogleのリッチリザルトテストで7パターン試してみました。結果を先に言うと、壊れたのは2パターンだけで、&が入っているだけのサイトは何も問題ありませんでした。何が壊れて何が無事なのかを、検証画面つきで整理します。
この記事でわかること
- Googleが変えたのは「HTMLアンエスケープを1回だけにした」という一点
- 7パターンを実際にテストした結果（壊れたのは2つだけ）
- &が入っているだけなら問題ない。危ないのは「2回エスケープされている」場合
- 二重エスケープが知らないうちに生まれる仕組み
- 自社サイトを1〜2分で点検する手順
- JSON-LDの正しい書き方（記号ごとの早見表）
まず結論｜押さえるのは3つだけ
この記事の要点
- 変わったのは1点だけ。GooglebotがJSON-LDを読むとき、HTMLアンエスケープを1回しか適用しなくなりました
- &や引用符が入っているだけなら大丈夫。検証した7パターンのうち、値が壊れたのは「2回エスケープされている」2パターンだけでした
- 点検は1〜2分で終わります。リッチリザルトテストにURLを入れるだけ。エラーが出なければ、今回の件で慌てて直す必要はありません
※ この記事は報道ベースです。Googleの公式ドキュメントへの反映と適用開始日は、2026年8月24日時点で確認できていません。既存のリッチリザルトが実際に失われるかも明言されていません。ただし「正しい書き方」の部分は、GoogleとJSONの公式仕様で裏を取っています。
何が変わったのか｜Googleの説明はこの一文
Googleが述べているのは、次の一文です。
Googleの告知（Search Engine Roundtable の報道より）
「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回だけ適用するようにしました）
そして、実務上の影響としてこう続きます。
同じ告知より
「Practically speaking, this means that double-escaped entities (like & or ✔) will no longer be unrolled.」（実際のところ、これは二重エスケープされた実体参照が、もう展開されなくなるということです）
「If you’re using JSON-LD for structured data, be sure to update your code to standard JSON escapes or Unicode hexadecimal escapes (like \u0026).」（JSON-LDを使っているなら、標準のJSONエスケープかUnicodeの16進エスケープに直してください）
Googleのゲイリー・イリェーシュ氏は、根拠としてRFC 8259のセクション7を挙げています。これはJSONの文字列とエスケープを定めた規格で、エスケープが必須なのは引用符（”）・バックスラッシュ（\）・制御文字の3つだけ、と書かれています。
公式ドキュメントには、まだ反映されていない
正直に書いておきます。この変更は、2026年8月24日時点でGoogleの公式ドキュメントに反映されていません。確認したのは、Google検索セントラルの「構造化データの general guidelines」と「構造化データの仕組み」のページですが、どちらにも今回の記述は見当たりませんでした。
適用開始日も示されていません。「もう変わった」のか「これから変わる」のかも、告知の文面からは断定できません。ですからこの記事は「危ないから今すぐ全部直せ」という話ではなく、「1〜2分で点検して、出ていたら直す」という話として読んでください。
実際に試した｜7パターンをリッチリザルトテストに入れてみた
検証のやり方
Googleのリッチリザルトテストには、URLではなくHTMLコードを直接貼り付けて試せる「コード」タブがあります。ここに、同じ記号を7通りの書き方で並べたJSON-LDを入れて、Googleがそれぞれをどう読み取るかを見ました。
使ったのはパンくずリスト（BreadcrumbList）です。項目名がテスト結果の画面にそのまま表示されるので、「書いた文字列」と「読み取られた値」を1対1で見比べられるからです。
結果｜壊れたのは2パターンだけだった
| JSON-LDにこう書いた | Googleはこう読み取った | 判定 | |
|---|---|---|---|
| A | &（そのまま） | & | OK |
| B | &（1回エスケープ） | & | OK |
| C | &（2回エスケープ） | & | 記号が残る |
| D | \u0026（Unicodeエスケープ） | & | OK（推奨） |
| E | ✔（数値文字参照） | チェックマーク記号 | OK |
| F | ✔（2回エスケープ） | ✔ | 記号が残る |
| G | "（引用符のHTMLエスケープ） | " | OK |
検証：株式会社NEXTORIAが Google リッチリザルトテストの「コード」タブで実施（2026年8月24日）。1つのBreadcrumbListに7項目を並べ、テスト結果の詳細画面に表示された name の値を読み取った。
ここが今回いちばん伝えたいところです。&や引用符が入っているだけのサイトは、何も問題ありません。A・B・D・E・Gはすべて正しく読み取られました。
壊れたのはCとFの2つ、どちらも「2回エスケープされている」ケースだけです。
本来「&」と表示させたかったものが、「&」という記号の並びのまま読み取られています。これが検索結果に出れば、社名が「山田&パートナーズ」のように見えることになります。
1回だけのエスケープは、これまでどおり無事
チェックマークを✔と書いた行は、きちんと記号に変換されました。「HTMLエスケープを使うのをやめろ」という話ではありません。1回なら今までどおり動きます。
引用符を入れても、ブロックは壊れなかった
検証前にいちばん心配していたのがここでした。JSON-LDの中に"と書いてあると、アンエスケープされて"になり、JSONの文字列の切れ目が壊れて、構造化データ全体が読めなくなるのではないかと考えたからです。
結果は問題なしでした。値は正しく"に変換され、構造化データ全体も「1件の有効なアイテムを検出しました」と出ています。アンエスケープは、JSONの解析を壊さない形で行われているということです。ここは実際に試してみないとわからない部分でした。
なぜ二重エスケープが生まれるのか
「そんな書き方、誰もしないのでは」と思われるかもしれません。ところが手で書いていないからこそ起きるのが、この問題の厄介なところです。
ポイントは2番と3番が別々の場所で起きていることです。エディタやデータベースが記号をHTMLエスケープして保存するのは正常な動作で、SEOプラグインがJSON-LDを出力するときにエスケープするのも、それ自体は正常な動作です。両方が正しく動いた結果として、二重エスケープができあがります。
起きやすいのはどんなサイトか
- CMSやプラグインがJSON-LDを自動生成しているサイト。手打ちのHTMLではまず起きません
- 社名・住所・サービス名に記号が入っているサイト。&、引用符、全角の特殊記号など
- FAQや施工事例の本文をそのまま構造化データに流し込んでいるサイト。本文中の記号が一緒に運ばれます
※ この流れは当社が検証結果から組み立てた説明であり、Googleが公式に図示したものではありません。
自社と支援先サイトを点検した結果
当社サイトと、支援先の住宅会社サイト1件のJSON-LDを実際に取り出して調べました。
| 当社サイト（nextoria.jp） | 支援先の住宅会社サイト | |
|---|---|---|
| JSON-LDのブロック数 | 1 | 1 |
| JSONとして解析できるか | できる | できる |
| 二重エスケープの痕跡 | なし | なし |
| 値に実体参照が残っているか | 残っていない | 残っていない |
| 使っている型 | Organization／WebSite／PostalAddress／ContactPoint ほか | LocalBusiness／PostalAddress／GeoCoordinates／OfferCatalog ほか |
| 構成 | WordPress＋SEO SIMPLE PACK | WordPress |
支援先サイトはサイト名を伏せています。調査：株式会社NEXTORIAがブラウザから script[type="application/ld+json"] の中身を取得して確認（2026年8月24日）。
2サイトとも問題ありませんでした。数が少ないので一般化はできませんが、少なくとも「WordPressで構造化データを自動生成しているサイトは軒並み危ない」というような話ではなさそうです。
この記事の目的は不安を煽ることではありません。1〜2分で確かめられるのだから、確かめてから考えましょうということです。
今日やること｜3ステップ、1サイト2分
点検の手順
- リッチリザルトテストを開いて、URLを入れる（1分）
search.google.com/test/rich-resultsにアクセスし、自社サイトのURLを入力してテストします。トップページだけでなく、会社概要・よくある質問・施工事例のページもそれぞれ試してください。構造化データはページごとに違います - エラーと警告を見る（30秒）
緑のチェックで「有効なアイテムを検出しました」と出れば、その時点では問題ありません。赤いエラーが出た場合だけ、次に進みます - 検出された値に、記号の並びが残っていないか見る（30秒）
検出項目を開いて、社名や住所の値を確認します。そこに&や'のような記号の並びがそのまま表示されていたら、それが二重エスケープです。エラーが出ていなくても、値がおかしければ直す対象になります
3番目が今回のポイントです。二重エスケープは「エラー」としては報告されません。JSONとしては正しく、schema.orgの型としても正しいからです。おかしいのは中身の文字だけなので、値を目で見るしかありません。
直し方｜JSON-LDの正しい書き方
エラーや記号の残りが見つかった場合の直し方です。記号ごとの早見表にしました。
| 出したい文字 | 推奨する書き方 | これでも動く | 書いてはいけない |
|---|---|---|---|
| &（アンパサンド） | \u0026 | & そのまま／& | & |
| “（引用符） | \"（JSONの標準エスケープ） | " | " |
| <（小なり） | \u003c | — | &lt; |
| \（バックスラッシュ） | \\ | — | そのまま1つだけ書く |
| 改行 | \n | — | 生の改行をそのまま入れる |
| ✔ などの記号 | 文字をそのまま入れる | ✔ | &#10004; |
RFC 8259 セクション7 では、エスケープが必須なのは「引用符・バックスラッシュ・制御文字（U+0000〜U+001F）」の3種類と定められています。それ以外の文字はそのまま書けます。
< を \u003c にする理由
JSON-LDは <script> タグの中に書きます。値の中に </script> という並びが現れると、そこでスクリプトが終わったとブラウザが判断して、JSON-LDが途中で切れます。FAQの回答文にHTMLタグの例を載せるようなときは、< を \u003c に置き換えておくと安全です。
WordPressの場合、どこを直すか
プラグインが自動生成している場合、JSON-LDそのものを直しても次の更新で戻ります。直すべきは元のデータです。
- 社名・住所：SEOプラグインの設定画面（SEO SIMPLE PACKなら「一般設定」、Yoastなら「サイト表示情報」）に入っている値。ここに
&と入力されていないか確認します - FAQの質問・回答：投稿本文のブロック。エディタを「HTMLとして編集」に切り替えて、記号がどう入っているかを見ます
- それでも直らない場合：プラグイン側の出力の問題です。プラグインを最新版に更新してから、もう一度テストしてください。今回の変更を受けて各プラグインが対応する可能性があります
まだわかっていないこと
| 論点 | 状況 |
|---|---|
| Googleの公式ドキュメントへの反映 | 検索セントラルの構造化データ関連ページには記載が見当たらない |
| 適用開始日 | 告知に日付の記載がない。すでに適用済みか、これからかも不明 |
| 既存のリッチリザルトが失われるか | 明言されていない。当社の検証では、値が壊れてもアイテム自体は「有効」と判定された |
| 各CMS・プラグインの対応状況 | 未確認。更新履歴を追う必要がある |
3番目は補足が要ります。今回の検証で、二重エスケープがあってもリッチリザルトテストは「有効なアイテム」と判定しました。つまりリッチリザルトの表示自体は消えないが、表示される文字がおかしくなるという状態になります。「エラーが出ていないから大丈夫」とは言い切れない、ということです。
よくある質問
Q. 社名に&が入っています。すぐ直したほうがいいですか？
まず点検してください。検証したとおり、&が1つ入っているだけなら問題ありません。リッチリザルトテストで社名の値を見て、「&」のような並びで表示されていなければ、何もする必要はありません。
Q. 構造化データを入れていません。関係ありますか？
ありません。ただしWordPressのSEOプラグインを入れていると、意識していなくても構造化データが自動で出力されていることがほとんどです。「入れていないつもり」でも、一度テストしてみる価値はあります。
Q. エラーが出ました。放っておくとどうなりますか？
今回の件で出るのは、多くの場合エラーではなく「値の文字がおかしい」という状態です。検索結果のパンくずやFAQに & が表示されることになります。順位が下がる話ではありませんが、検索結果に出る社名が崩れているのは、見た人の印象に直接効きます。
Q. プラグインが自動生成しているので、直しようがありません
元データ（プラグインの設定画面や投稿本文）を直せば、出力も直ります。それでも直らない場合はプラグインの不具合なので、更新を待つか、開発元に報告してください。出力されたJSON-LDを手で書き換えるのは、次の更新で戻るのでおすすめしません。
Q. 検証に使ったコードを教えてください
パンくずリスト（BreadcrumbList）に7つの項目を並べ、それぞれの name に別々の書き方の記号を入れただけの、20行程度のHTMLです。同じことをご自身のサイトの社名で試したい場合は、リッチリザルトテストの「コード」タブにHTMLを貼り付ければ、公開せずに確かめられます。
まとめ｜慌てる前に、2分で確かめる
- 変わったのは「HTMLアンエスケープが1回だけになった」という一点。Googleが2026年8月21日にLinkedInで告知した
- 7パターン試して、壊れたのは2つだけ。どちらも「2回エスケープされている」ケースだった
- &や引用符が入っているだけなら問題ない。1回エスケープの記述は今までどおり動く
- 二重エスケープはCMSとプラグインの合わせ技で生まれる。手打ちのHTMLではまず起きない
- 点検はリッチリザルトテストで1〜2分。エラーだけでなく、検出された値の文字も目で見る
- 公式ドキュメントへの反映と適用日は未確認。報道ベースの情報として扱う
構造化データは、工務店・住宅会社のサイトでは会社名・住所・電話番号・よくある質問あたりに入っていることがほとんどです。どれもお客様が最初に目にする情報ですから、そこが崩れて表示されるのは避けたいところです。
とはいえ、今回の件で本当に困るサイトは多くないはずです。まず点検して、問題がなければそれで終わり。それだけの話として扱ってください。同じように「指標や仕様が変わったように見えて、実は影響が限定的だった」件は最近続いています。YouTubeの視聴回数カウント変更も、Search Consoleに増えた生成AIレポートもそうでした。発表を見て慌てる前に、自社の数字と画面で確かめる。これが遠回りに見えていちばん速い方法です。
その後、同じ形の件がMeta広告でも出てきました。広告セットから配置の除外が消えるという海外発の報道を日本の支援先アカウントで実機確認したところ、報道の一部が正確ではないことが分かりました。詳しくはMeta広告の「手動配置」が消える件をご覧ください。
点検から修正まで、まとめてお引き受けします。
株式会社NEXTORIAは、工務店・住宅会社・リフォーム会社に特化したAI×Webマーケティング支援を行っています。構造化データの点検と修正、プラグイン設定の見直し、検索結果での見え方の改善まで、マーケティングチームが対応します。累計60社を超えるご支援のなかで蓄積した、住宅・リフォーム業界に固有の型をそのままお使いいただけます。
出典
- Search Engine Roundtable「JSON-LD Extraction For Googlebot Now Does One Pass Of HTML Unescaping」（2026年8月21日／GoogleのLinkedIn投稿とGary Illyes氏のコメントを報じたもの。2026年8月24日に確認）
https://www.seroundtable.com/json-ld-extraction-googlebot-41921.html - RFC 8259「The JavaScript Object Notation (JSON) Data Interchange Format」セクション7 Strings（エスケープが必須な文字と、定義されているエスケープ表記。2026年8月24日に確認）
https://www.rfc-editor.org/rfc/rfc8259#section-7 - Google 検索セントラル「構造化データの一般的なガイドライン」（技術的なガイドライン・テスト方法。2026年8月24日に確認）
https://developers.google.com/search/docs/appearance/structured-data/sd-policies?hl=ja - Google 検索セントラル「構造化データ マークアップの仕組みについて」（JSON-LDの記述形式。2026年8月24日に確認）
https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data?hl=ja - 検証：株式会社NEXTORIAが Google リッチリザルトテストの「コード」タブで7パターンを実施（2026年8月24日）
- 点検：株式会社NEXTORIAが自社サイトおよび支援先の住宅会社サイト1件のJSON-LDを取得して確認（2026年8月24日）
