記事執筆者：認定SEOコンサルタント 三田健司
「制作会社に入れてもらった構造化データが、正しく機能しているのか分からない」。そんなご相談を受けることがあります。
構造化データは画面に表示されない情報なので、書き方が乱れていても誰も気づきません。そのまま何年も放置されているケースは、決して珍しくありません。
2026年8月21日、Googleが構造化データの読み取り方を変更したことが明らかになりました。これまでGoogle側が黙って補正してくれていた「書き方の乱れ」が、今後はそのままの文字として読み取られるという内容です。
本記事では、この変更が何を意味するのかを技術者でない方にも分かる言葉で整理し、自社サイトが影響を受けていないかを確認する手順、そしてWordPressサイトでの現実的な対応までをまとめます。
Googleが構造化データの読み取り仕様を変更した
2026年8月にGoogleが公表した内容
Googleは自社のソーシャルアカウントを通じて、JSON-LDの抽出処理を変更したと発表しました。JSON-LDとは、構造化データをページに埋め込むための書式のことです。
発表の中でGoogleは、パーサー（読み取りプログラム）をJSONなどの標準規格に合わせるため、HTMLのアンエスケープ処理を1回だけ適用するように変更したと説明しています。
つまり、これまで2回分の変換を親切に行ってくれていた処理が、規格どおり1回だけになったということです。
この変更を海外のSEO専門メディアであるSearch Engine Roundtableが8月21日に報じ、国内でも技術者の間で話題になりました。
「アンエスケープ1回」が意味すること
Googleは実務的な影響として、二重にエスケープされた文字が今後は元に戻されなくなる、と明記しています。
これまでは、多少おかしな書き方をしていてもGoogle側が推測して正しい文字に直してくれていました。その「おせっかい」がなくなった、と考えると分かりやすいはずです。
結果として、会社名やサービス名に記号が含まれるサイトでは、構造化データの中の文字が意図しない形で読み取られる可能性が出てきました。
根拠はRFC 8259という国際規格
Googleの担当者は、JSONにおける正しいエスケープの定義はRFC 8259という文書の第7章に明確に書かれている、と補足しています。
RFCとは、インターネットの技術仕様をまとめた国際的な文書群のことです。特定の企業が決めたルールではなく、業界全体で共有されている取り決めだと理解してください。
言い換えると、今回の変更はGoogle独自の新ルールが増えたのではなく、もともとの標準に合わせただけという位置づけになります。
そのため「Googleの気まぐれだからいずれ元に戻る」という期待は持たないほうが安全です。標準に合わせた書き方に直す、というのが唯一の対応になります。
二重エスケープとは何か｜まず言葉を整理する
エスケープの基本的な考え方
エスケープとは、そのまま書くと意味が変わってしまう文字を、別の書き方に置き換える作業のことです。
たとえばHTMLでは、記号の「小なり」はタグの始まりを意味します。文章として小なりを表示したい場合は、専用の書き方に置き換える必要があります。
アンド記号も同じで、HTMLの中では & と書くことで、画面上に「&」として表示されます。これがエスケープの仕組みです。
ここまでは、ホームページ制作に関わったことがある方なら見覚えのある話だと思います。
なぜ「二重」になってしまうのか
問題は、構造化データがHTMLの中に埋め込まれたJSONである、という二階建ての構造にあります。
JSONにはJSONのエスケープ規則があり、HTMLにはHTMLのエスケープ規則があります。両方の処理が重なると、1文字が2回変換されてしまうことがあるのです。
これが二重エスケープで、見た目には気づきにくいのが厄介なところです。
ブラウザで普通にページを見ている限り、本文は正常に表示されます。壊れているのは、画面に出ない構造化データの中身だけだからです。
Googleが例に挙げた具体的な文字
Googleは発表の中で、二重エスケープされた実体参照として & や ✔ といった書き方を例示しました。
前者はアンド記号、後者はチェックマークを表そうとした結果、変換が余分に一段かかってしまった状態です。
これまでのGoogleは、こうした書き方を見つけると元の記号に戻して解釈していました。今後は文字列としてそのまま受け取ります。
結果として、会社名が「株式会社A&B」ではなく、記号部分がそのまま文字列として認識されてしまう、という事態が起こり得ます。
なぜ自社サイトで二重エスケープが起きるのか
原因の多くはプラグインやテンプレート
二重エスケープは、担当者が手で書き間違えて起きるとは限りません。むしろ自動処理の副作用として発生するほうが多い印象です。
WordPressをはじめとするCMSでは、入力された文字を安全に扱うためにエスケープ処理を自動で行います。その値を構造化データに流し込むとき、もう一度エスケープがかかることがあるのです。
つまり、悪気なく標準的な作りをしているサイトほど、この問題を抱えている可能性があります。
筆者がこれまで見てきた中でも、古いテーマや自作の出力処理を使っているサイトで、この種の乱れが残っているケースがありました。
テンプレートの二段構えが引き金になる
もうひとつよくあるのが、テンプレートエンジンとJSON生成処理が別々にエスケープを行っているパターンです。
それぞれの処理は正しく動いているのに、組み合わせると余分な変換が一段増えてしまいます。開発者から見ても、原因が特定しにくい種類の不具合です。
制作会社が変わったタイミングや、テーマを乗り換えたタイミングで顕在化することもあります。
コピー＆ペーストで持ち込まれることもある
構造化データ生成ツールで作ったコードを、Webページ上から選択してコピーし、そのまま貼り付けているケースにも注意が必要です。
画面表示用にエスケープされた状態の文字列をコピーしてしまうと、貼り付けた時点で既に一段余計な変換がかかっていることになります。
ツールが用意している「コピー」ボタンを使えば防げることが多いので、手作業で範囲選択する運用は避けたほうが安全です。
些細な作業手順の違いに見えますが、こうした積み重ねがサイト全体の品質に効いてきます。
気づかないまま何年も残ることがある
二重エスケープの厄介さは、サイトの見た目にまったく現れない点にあります。訪問者からの指摘も入りません。
構造化データは画面に表示されない情報なので、日常の更新作業をしている限り、誰も気づかないまま何年も残り続けます。
これまではGoogle側が補正していたため、実害が出ていなかったサイトも多いはずです。今回の変更は、その「見えていなかった負債」が表に出るきっかけになります。
逆に言えば、今のタイミングで一度点検しておけば、長年放置されていた不具合をまとめて解消できるということでもあります。
影響が出やすいのはどんな構造化データか
社名やサービス名に記号が入る会社
最も影響を受けやすいのは、社名や店名にアンド記号やスラッシュ、引用符などの記号が含まれている会社です。
「株式会社◯&◯」「◯◯’s ◯◯」といった名称は、エスケープ処理の対象になりやすく、二重変換のリスクが高まります。
会社情報を伝えるOrganizationの構造化データが崩れると、Googleに正しい社名を伝えられなくなる恐れがあります。
社名は検索結果でもAI検索でも軸になる情報なので、優先して確認したい箇所です。
商品名・パンくず・レビュー
ECサイトの商品名にも、記号やチェックマークのような装飾文字が使われることがあります。
パンくずリストのカテゴリ名、レビューの投稿者名なども同様です。ユーザーが自由に入力できる項目は、想定外の文字が入り込みやすくなります。
これらの文字が崩れた場合、検索結果に表示される文言がおかしくなることがあります。順位そのものが下がるという話ではありませんが、見え方の印象に差が出ます。
説明文にHTMLタグを含めている場合
descriptionなどの説明文に、改行タグや強調タグを含めたまま構造化データへ渡している実装も見かけます。
この場合、タグの記号がエスケープ処理を受けるため、やはり二重変換の温床になります。
構造化データの説明文には、そもそもHTMLタグを含めない設計にしておくのが無難です。Googleは構造化データの内容がページ上の内容と一致していることを求めており、装飾は本文側で行えば足ります。
整理してしまえば、あとの運用も楽になります。
自社サイトを確認する3つの手順
手順1：リッチリザルトテストにかける
まずはGoogleが公開しているリッチリザルトテストに、自社の主要ページのURLを入力します。トップページ、会社概要、主力サービスページ、代表的なブログ記事の4つを見れば全体の傾向はつかめます。
ここで注目したいのは、エラーの有無だけではありません。検出された構造化データの中身を開き、社名や商品名が意図した文字で表示されているかを目で確認してください。
エラーが出ていなくても、文字が壊れていることはあります。
不自然な記号の並びが見えたら、そこが二重エスケープの疑い箇所です。
手順2：Search Consoleの拡張レポートを見る
次にSearch Consoleを開き、左メニューの「拡張」にあたる項目を確認します。パンくずリスト、商品、レビューなどの種類ごとに、有効なページ数とエラー数が表示されます。
ここで注目すべきは、直近の推移です。ある時期を境に有効なページ数が急に減っていないか、グラフの形を見てください。
ただし、Googleの再クロールと再処理には時間がかかります。今回の変更の影響が数字に現れるまで、数週間単位のずれが出る可能性があります。
すぐに変化がないからといって「問題なし」と決めつけず、しばらく定点観測するのが現実的です。
手順3：ページのソースを直接確認する
最も確実なのは、ページのHTMLソースを直接見る方法です。ブラウザでページを開き、ページのソースを表示する機能を使います。
表示されたソースの中から application/ld+json という文字列を検索すると、構造化データの塊が見つかります。
その中身を読み、記号の前に余計な変換が残っていないかを確認します。セミコロンで終わる不自然な文字列が並んでいたら要注意です。
技術に不慣れな場合は、この作業だけ制作会社や社内の詳しい方に見てもらうのが早道です。判断そのものは難しくありません。
確認の優先順位をどうつけるか
ページ数の多いサイトでは、すべてを一度に確認するのは現実的ではありません。優先順位を決めて進めます。
最優先はトップページです。会社情報を表す構造化データが集約されていることが多く、影響範囲も最も広くなります。
次に、問い合わせにつながる主力サービスページと、検索からの流入が多い記事ページを見ます。Search Consoleの検索パフォーマンスで、クリック数の上位10ページを抜き出すと選びやすくなります。
残りのページは、同じテンプレートを使っているものが多いはずです。代表的な1ページを確認して問題がなければ、同じ型のページも同様と判断して差し支えありません。
正しい書き方に直す方法
JSONの標準エスケープに合わせる
Googleが示した対応方針は明快です。標準のJSONエスケープ、もしくはUnicodeの16進数エスケープに書き換えること、とされています。
JSONの文字列では、二重引用符とバックスラッシュ、そして制御文字だけをエスケープすれば足ります。それ以外の文字は、そのまま書いて構いません。
アンド記号やチェックマークは、JSONにとって特別な文字ではありません。HTMLの実体参照に置き換える必要はない、ということです。
ただし、JSON-LDはHTMLのscriptタグの中に置かれるため、値に山かっこが含まれるとHTML側の解釈が壊れることがあります。実務では、次に説明するUnicodeエスケープを使っておくほうが安全です。
Unicodeエスケープという選択肢
それでも記号をそのまま置きたくない事情がある場合は、Unicodeの16進数エスケープが使えます。
Googleが例として挙げたのは \u0026 という書き方です。これはアンド記号を表すJSONの正式な記法で、読み取り側は確実に元の記号として解釈します。
HTMLの実体参照とJSONのエスケープは別物である、という点さえ押さえておけば混乱しません。
構造化データの中で使うべきなのは、HTMLの書き方ではなくJSONの書き方です。
出力処理そのものを見直す
個別のページを手で直しても、出力処理が変わらなければ同じ問題が繰り返されます。
根本的な解決は、構造化データを組み立てる処理で、HTML用のエスケープをかけないようにすることです。JSONへの変換は、専用の関数に任せるのが原則になります。
この部分は開発者の領域なので、制作会社に依頼する際は「構造化データの出力でHTMLエスケープを二重にかけていないか確認してほしい」と伝えれば話が通じます。
依頼の言葉が具体的であるほど、対応は速くなります。
直したあとに確認すべきこと
修正が終わったら、必ず結果を確認します。直したつもりで直っていない、というのは実務でよくある話です。
まずリッチリザルトテストで、修正したページのURLを再度入力します。ここで社名や商品名が意図した文字で表示されていれば、出力自体は正しくなっています。
次に、Search Consoleでインデックス登録をリクエストしておくと、再クロールのきっかけになります。ただし、いつ処理されるかをGoogleが保証しているわけではありません。
その後は、拡張レポートの有効ページ数が戻っていくかを数週間かけて見守ります。すぐに数字が動かなくても、慌てて設定を触らないことが大切です。
WordPressサイトでの実務対応
まず構造化データの出どころを特定する
WordPressの場合、構造化データはテーマが出しているか、SEO系のプラグインが出しているか、あるいは両方が出しているかのいずれかです。
ページのソースを見て application/ld+json の塊がいくつあるかを数えると、出どころの当たりがつきます。
複数のプラグインが同じ種類の構造化データを重複して出力しているサイトも珍しくありません。まずは整理して、どこを直せばよいかをはっきりさせましょう。
出どころが分からないまま設定をいじると、状況が複雑になるだけです。
プラグインとテーマを最新にする
今回の変更は開発者向けの情報として発信されているため、主要なプラグインは順次対応していくと考えられます。ただし、対応時期を確約できるものではありません。
まずはプラグインとテーマを最新版に保つことが、最も手間のかからない対策です。更新前にはバックアップを取り、ステージング環境がある場合はそちらで先に確認してください。
ただし、更新すれば必ず直るとは限りません。更新後にもう一度リッチリザルトテストで確認する、という手順まで含めて対応と考えるのが安全です。
サイト設定に入っている社名を見直す
意外な落とし穴が、WordPressの一般設定に入力されているサイトのタイトルやキャッチフレーズです。
ここに記号が入っている場合、その値が構造化データに流用されることがあります。管理画面での入力時点で実体参照を書いてしまっていると、二重変換の起点になります。
管理画面には、実体参照ではなく実際の記号をそのまま入力するのが原則です。
あわせて、会社概要ページに書かれている社名・住所・電話番号が構造化データの内容と一致しているかも確認しておくとよいでしょう。
制作会社に依頼するときの伝え方
外部の制作会社に依頼する場合、症状ではなく事実を伝えると話が早く進みます。
具体的には、Googleが2026年8月にJSON-LDのHTMLアンエスケープを1回のみに変更したこと、自社サイトの構造化データに二重エスケープが残っていないか確認してほしいこと、この2点を書けば十分です。
あわせて、確認してほしいページのURLを3〜5本添えると、見積もりの精度も上がります。
「検索結果の表示がおかしい気がする」といった曖昧な伝え方だと、調査に時間がかかり費用も膨らみます。伝え方ひとつで結果が変わる部分です。
AI検索時代に構造化データを整える意味
機械が読む情報の正確さが問われる
構造化データは、人間ではなく機械に向けて自社の情報を伝えるための仕組みです。
検索結果でリッチリザルトを得るためだけのものと捉えられがちですが、Googleが自社の情報を理解するための手がかりでもあります。
社名が壊れて伝わることは、機械に対する自己紹介を間違えているのと同じです。
過度な期待はしない
一方で、構造化データを入れれば順位が上がる、AI検索に必ず引用される、といった話ではありません。
Googleは構造化データそのものをランキング要因として扱うとは述べていません。あくまで、対象となる検索結果の表示形式に対応するための情報提供という位置づけです。
とはいえ、壊れたまま放置する理由もありません。直す手間が小さく、放置するリスクだけが残るなら、直すほうが合理的です。
点検を運用に組み込む
今回のように、Google側の処理が静かに変わることは今後もあります。
おすすめしたいのは、月に一度、主要ページをリッチリザルトテストにかけるという簡単な習慣です。所要時間は10分程度で済みます。
Search Consoleの拡張レポートを月初に開く、という運用でも構いません。気づける仕組みを持っているかどうかが、対応の速さを分けます。
担当者が変わっても続くように、確認手順をチェックリストとして残しておくとなお良いはずです。
よくある質問（FAQ）
構造化データを入れていない場合も影響がありますか
構造化データをまったく出力していないサイトであれば、今回の変更による直接の影響はありません。
ただし、多くのWordPressテーマやSEOプラグインは、設定していなくても自動で構造化データを出力しています。まずは自社サイトが実際に出力しているかどうかを確認することをおすすめします。
影響を受けると検索順位は下がりますか
構造化データが読み取れなくなったこと自体で順位が下がる、とGoogleは説明していません。
影響が出るとすれば、リッチリザルトとしての表示資格を失うことによるクリック率の変化です。順位の話とは分けて考えてください。反映の時期についても、確約できるものではありません。
いつから適用されているのですか
Search Engine Roundtableが報じたのは2026年8月21日です。Googleは「すでに変更した」という趣旨で説明していますが、適用開始日そのものは明示していません。
また、Googleが変更を適用しても、各ページが再クロール・再処理されるまでには時間差があります。今すぐ数字に出ていなくても、しばらくは様子を見る必要があります。
自社で直せる範囲はどこまでですか
管理画面に入力されている社名やキャッチフレーズの修正、プラグインとテーマの更新までは、社内で対応できる範囲だと思います。
一方、テーマのテンプレートやプラグインの出力処理そのものに手を入れる作業は、専門知識が必要です。無理に触ってサイトが表示されなくなるリスクを考えると、制作会社に相談するほうが安全です。
構造化データはどれを入れるべきですか
中小企業のサイトであれば、会社情報を表すOrganizationとパンくずリストの2つを正しく出しておくのが基本です。
種類を増やすことより、出している内容が正確でページの実態と一致していることのほうが重要です。Googleも、ページに書かれていない内容を構造化データに書かないよう求めています。
構造化データを削除してしまうのは有効ですか
壊れているなら消してしまえばよい、という判断はおすすめできません。
構造化データを削除すると、パンくずリストなど現在表示されている要素まで失われる可能性があります。壊れている箇所を直すほうが、得られるものは大きいはずです。
まとめ｜構造化データは書いて終わりではない
2026年8月、GoogleはJSON-LDの読み取り処理を変更し、HTMLのアンエスケープを1回だけ適用する方式に切り替えました。二重にエスケープされた文字は、今後そのまま文字列として扱われます。
これはGoogle独自のルールが増えたのではなく、JSONの国際規格に処理を合わせたものです。したがって、書き方を標準に直す以外の対応策はありません。
影響を受けやすいのは、社名や商品名に記号が含まれるサイト、そしてCMSやプラグインの自動処理が二段構えになっているサイトです。手作業のミスではなく、仕組みの副作用として起きる点が今回の特徴です。
確認は、リッチリザルトテスト、Search Consoleの拡張レポート、ページのソース確認という3段構えで行います。エラーが出ていなくても文字が壊れていることがあるため、中身を目で見るところまでが確認作業です。
今日できることを1つ挙げるなら、自社のトップページをリッチリザルトテストにかけて、検出された社名の表記を確認してみてください。数分で終わり、問題の有無がはっきりします。
構造化データのご相談はアクセス・リンクへ
株式会社アクセス・リンクは、栃木県下野市を拠点に、SEOコンサルティングとホームページ制作を行っている会社です。代表の三田健司は全日本SEO協会の認定SEOコンサルタントとして、中小企業のWeb集客を支援してきました。
Web制作に携わって10年以上、延べ1,000件を超えるサイトに関わってきた経験から、構造化データの点検や出力処理の見直しについても、技術用語を使わずに現状と対応策をご説明します。「自社サイトが影響を受けているか分からない」という段階でのご相談も歓迎です。
構造化データの確認やSEO全般についてのご相談は、お問い合わせフォームよりお気軽にご連絡ください。
記事執筆・株式会社アクセス・リンク 代表取締役
Webサイト制作歴10年以上の経験を元にSEOコンサルティングを行い、延べ1,000件以上のサポート実績を誇ります。個人事業主や中小企業向けのホームページ制作やSEOコンサルティングを得意としています。
（社）全日本SEO協会 認定SEOコンサルタント
コメント