Google 在 2026 年 8 月 21 日於 LinkedIn 發出公告，Googlebot 讀取 JSON-LD 結構化資料時，對 HTML 跳脫（escape）字串只還原一層。被跳脫兩次的字串，例如 &，以前會被自動一路還原成 &，現在停在剩一層的 &，Googlebot 讀到的內容從此不同。這是技術 SEO 級的解析器變更，牽動的是複合式搜尋結果裡的名字與連結讀不讀得到。自己手寫 schema 的網站多半沒事；踩到雷的，通常是讓範本或外掛自動輸出 schema 的網站。
重點先看
Google 在 2026 年 8 月 21 日公告，Googlebot 解析 JSON-LD 時只做一輪 HTML 還原跳脫，被跳脫兩次的字串不再自動展開，變更已經生效。
只寫一層跳脫（
&）或直接寫&的網站不受影響；要處理的是&、✔這種被跳脫兩次的字串。Search Console 與 Rich Results Test 目前看不出這個問題，因為 JSON 語法仍然合法，出錯的是欄位裡的內容。
修法是把字串改成標準 JSON 跳脫（
\u0026）或直接寫原字元&，並且從生成 schema 的源頭修，別直接在上線的頁面裡硬改字串。現在就檢查 JSON-LD。首頁按檢視原始碼，搜
ld+json再搜&，5 分鐘；接著挑一頁商品頁或最新文章照做一次，10 分鐘內可以把高風險頁面掃完一輪。
Googlebot 到底改了什麼
Google Search Central 在 2026 年 8 月 21 日上午 9 點 04 分（UTC），於 LinkedIn 發出公告。全文很短，逐字如下。
“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. 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 與其他標準。行為是 Googlebot 抽出 JSON-LD 之後，對內容裡的 HTML 跳脫字串，現在只做一輪「還原跳脫」（unescape，把 & 這類寫法解回原字元的動作），被跳脫兩次的字串，像公告點名的 & 與 ✔，不再被自動展開。動作是如果你用 JSON-LD 做結構化資料，請把程式碼換成標準 JSON 跳脫，或 Unicode 十六進位跳脫。
公告用的是過去式，講的是已經做完的變更，沒有預告的成分。Google 沒有給生效日期，沒有分批推出的排程，也沒有說既有頁面會不會被重新處理，這幾件事在公告裡完全沒有答案。網站能做的判斷也就很明確，把字串修成公告建議的寫法，時間表的問題留給 Google。
公告指名的使用者也寫得很精確，原文是 “If you’re using JSON-LD for structured data”，只講 JSON-LD。microdata 與 RDFa 這兩種把結構化資料直接寫在 HTML 標籤屬性裡的作法，公告一個字都沒提，有沒有同樣待遇，目前沒有官方說法。
Googlebot 是 Google 負責檢索網頁的機器人，解析器（parser，負責讀內容並轉成內部資料的程式）讀 JSON-LD 是整條檢索流程裡的一環。這次變更動的是讀資料的那一步，不是網頁本身。你的原始碼一個字都沒變，變的是 Googlebot 讀完之後拿到的內容。
哪些網站可以把心放回去，也可以先講。JSON-LD 是手寫的、內容裡沒有 &、沒有 emoji 或特殊符號的網站，掃一輪沒事就結束。該繃緊的是名單上的常客，品牌名帶 &、網址帶查詢參數、schema 由外掛或範本生成，條件同時成立得越多，需要處理的機率越高。
擷取當下是 2026 年 8 月 22 日，公告約有 1,377 個反應、33 則留言，數字會持續漂動。Search Engine Roundtable 在當天美東早上 7 點 15 分做了首發報導，Barry Schwartz 的導語寫得相當精準：”Google’s crawler now strictly enforces standard JSON formatting when reading your site’s structured data, schema markup, instead of auto-correcting double-escaped HTML text.” 意思是 Googlebot 現在嚴格按標準 JSON 格式讀結構化資料，不再自動校正被跳脫兩次的文字。Search Engine Watch 同日跟進，Sachin Patel 的句子抓到重點：”Since Google’s parser now only unescapes once, any code that depended on double-unescaping won’t work the way it used to.” 靠自動雙層還原才能運作的程式碼，行為會跟著改。Barry Schwartz 也在 X 用 @rustybrick 帳號轉發，文字與導語相同。
Google’s crawler now strictly enforces standard JSON formatting when reading your site’s structured data, schema markup, instead of auto-correcting double-escaped HTML text.
— Barry Schwartz (@rustybrick) August 21, 2026
到 8 月 22 日為止，Search Central 的 X 帳號、官方部落格、開發者文件都還沒有隻字片語，X 帳號的時間軸最新一則停在 8 月 18 日的垃圾內容更新，訊息只存在 LinkedIn 這一則公告，加上 Gary Illyes 的接力分享。
雙重跳脫是什麼，& 是怎麼來的
跳脫是什麼，用一個品牌名講清楚
JSON-LD 是把結構化資料以 JSON 格式寫進頁面 script 區塊的作法，位置常在 <head> 裡，用檢視原始碼就看得到，背景概念可以看結構化資料的完整介紹。寫進去的字串有一條規則要先懂，跳脫。
跳脫的意思，是把一個字元換成另一串固定的文字寫法，避免它被系統誤會成別的用途。HTML 裡的 & 有特殊角色，所以網頁原始碼會把 AT&T 寫成 AT&T，把 M&M 寫成 M&M，瀏覽器看到 & 再顯示成 &。數字寫法也在同一套規則裡，打勾符號 ✔ 可以寫成 ✔。這種替身寫法叫 entity，中文常譯「實體」。讀者該管它的原因只有一個，JSON-LD 的字串會被 Google 原樣讀走，頁面上顯示 AT&T，機器讀到的可能是 AT&T，中間的落差全從跳脫次數來。
單層與雙層差在哪
被跳脫兩次，就是同一個字元被換了兩次。系統先把 & 換成 &，另一個環節不知道已經換過，又換了一次，字串就變成 &amp;。打勾符號走同樣的路，✔ 被再跳脫一次，變成 &#10004;。
雙重跳脫像把已經包裝好的東西再包一層。以前 Google 願意把兩層包裝全拆掉，現在只拆外層，拆完的名字就留著一層撕不掉的標籤；對應到原始碼，那層標籤就是字面上的 amp; 四個字元。
舉個具體例子。一家店的品牌名是 AT&T，商品頁 JSON-LD 的 name 欄位被跳脫了兩次，寫成 AT&amp;T。舊解析一路還原到底，Googlebot 讀到 AT&T，複合式搜尋結果上顯示的也是 AT&T。新解析只還原一層，讀到的是字面文字 AT&T，顯示出來就多出 amp; 這串字。名稱欄位錯，搜尋結果上直接看得到；網址欄位錯，連結會對不起來。
整條路走一遍會更清楚。資料庫裡的商店名是 AT&T。系統把它放進 HTML 頁面時跳脫一次，得到 AT&T，這是第一層，頁面顯示正確。範本接著要把同一份內容放進 JSON-LD 的 script 區塊，安全機制又跳脫一次，得到 AT&amp;T，這是第二層。頁面顯示不受影響，script 區塊內的 entity 瀏覽器本來就不會解；Googlebot 的舊解析會把兩層都拆掉，讀回 AT&T，新解析只拆一層，讀到 AT&T。整條鏈上每個環節單獨看都合理，出錯的是組合。
雙重跳脫通常是系統做出來的
人不太會手寫出 &amp;，這種字串幾乎都是兩段程式接力做出來的。英國 SEO 顧問 Szymaniak Digital 在事發當天的分析裡，把這條路徑寫得很直白，內容管理系統先把欄位內容跳脫成安全的 HTML，範本把內容放進 script 區塊時，又跳脫了第二次。
兩段程式各自都有理由。內容管理系統跳脫文字是為了安全，未經處理的 <、>、& 進到 HTML，可能被瀏覽器當成標籤或特殊符號，跳脫過再輸出是標準防護。範本再跳脫一次，是因為它不知道這份內容已經處理過，秉著同樣的安全原則又處理一遍。每段程式都照規矩做事，出錯的是兩邊沒有講好誰負責跳脫。
這條自動管線存在於許多常見工具裡。Szymaniak 點名的有 Shopify 自動生成結構化資料的 App、WordPress 的自動化外掛、Hugo 與 Jekyll 與 Eleventy 這類靜態網站產生器、headless CMS，以及共用的範本庫。公告留言區裡，Louis Smith 講的也是同一個位置，Shopify 的主題與 App 自動生成 JSON-LD，輸出沒有人檢查。用這些工具的網站，檢查流程要走完整一輪。
哪些寫法要改，哪些本來就沒事
新舊解析對照表
這張表整理六種寫法在舊解析與新解析下讀到的內容，以及要不要改。
| JSON-LD script 裡的寫法 | 舊解析讀到的內容 | 新解析讀到的內容 | 要不要改 |
|---|---|---|---|
&amp;（跳脫兩次） | & | 字面文字 & | 要改，公告點名 |
&#10004;（跳脫兩次） | ✔ | 字面文字 ✔ | 要改，公告點名 |
&（跳脫一次） | & | & | 不必改 |
✔（跳脫一次） | ✔ | ✔ | 不必改 |
&（原字元） | & | & | 不必改，標準寫法 |
\u0026（JSON 跳脫） | & | & | 不必改，Google 建議 |
表格有兩個地方要交代。舊解析欄對「跳脫兩次」那兩列的展開結果，是從公告 “no longer be unrolled” 的用語往回推的，Google 沒有提供舊版的對照文件。原字元那一列合法，因為 JSON 規格裡必須跳脫的字元不包括 &，依據放在後面規格的段落。
這張表的用法很直接。左欄是原始碼裡實際看得到的字串，檢視原始碼搜尋就能對號。中間兩欄是 Googlebot 舊與新讀到的內容，差異只發生在跳脫兩次的那兩列。右欄直接當結論用，搜到的字串對上左欄，該不該改就有依據。
只跳脫一次的網站，行為不變
& 經過一輪還原就是 &，第二輪沒有東西可展開，所以新舊解析的結果相同，跳脫一次的寫法，這次變更碰不到。這是從公告的機制推導的結論，Google 沒有逐條背書，但推導鏈很短，中間沒有別的變數。
同樣的推法放到數字寫法也成立，✔ 經過一輪還原就是 ✔，第二輪沒有東西可展開，新舊解析讀到的都是 ✔。換句話說，這次變更的分界線畫在跳脫次數上，一次安全，兩次中獎，更深層的寫法在舊解析下讀到什麼，公告沒有載明。
還有一個務實的判斷。跳脫一次的 & 現在讀值正確，但它走的仍是 HTML entity 這條路，也就是 Google 寬容處理的範圍。公告的建議句寫的是 standard JSON escapes 或 Unicode hexadecimal escapes，兩種都是 JSON 自己的路徑。範本要動工的話，順手換到 JSON 路徑最省事。
同一個網站也可能混合出現。手寫的欄位乾淨，範本生成的欄位出事，這種情況檢查看欄位說話，一頁全對不代表全站全對，範本碰過的欄位要再掃一遍。
怎麼檢查你的 JSON-LD 有沒有雙重跳脫
五分鐘快查，檢視原始碼就夠
檢查不需要付費工具，瀏覽器一個就夠，流程照著走。要檢查的是上線的 HTML，編輯器裡的預覽不算數。文章、商品、帶參數的網址各代表一種範本，輸出行為可能不同，各掃一頁才算數。
- 打開網站首頁，右鍵選「檢視原始碼」。Windows 快捷鍵 Ctrl+U，Mac 是 Cmd+Option+U。
- 在原始碼裡搜
ld+json。每個搜到的位置，都是一段 JSON-LD 的 script 區塊。 - 把搜尋字串換成
&amp;。搜得到，就是被跳脫兩次，中獎。 - 再換成
&#搜一次，數字寫法的雙層跳脫會在這裡現形。 - 換頁面再來一輪。最新一篇文章、一頁商品頁、一頁帶查詢參數的網址，各掃一次，走完通常 10 分鐘以內。
搜得到 &amp; 或 &#，被跳脫兩次，要修。只看得到 &，屬於單層跳脫，目前不受影響。什麼都搜不到，乾淨，收工。修完範本之後，同一套搜法再跑一次，等於最便宜的驗收。
搜尋有兩個小訣竅。先搜 & 再往下翻，看到 & 後面又接著 amp; 或 # 的字串，就是雙層，連變體都會現形。還有，要看的是「檢視原始碼」那份伺服器送出的原始文件，那才是 Googlebot 實際抓到的內容。
高風險欄位，雙重跳脫最常藏在哪
表格整理雙重跳脫最常出現的欄位類型，以及每一類先檢查的理由。
| 欄位類型 | 常見內容 | 為什麼先查 | 檢查什麼 |
|---|---|---|---|
| name、description、headline | 品牌名或商品名帶 &（AT&T、M&M）、標題裡的引號與符號 | 這些欄位直接放上複合式搜尋結果，多一串字看得到 | 搜品牌名與 & 出現的位置 |
| url、sameAs、offers.url | 網址查詢字串裡的 &，UTM、分頁、篩選參數 | 網址多四個字元，連結或優惠就對不起來 | 搜參數附近的字串，如 ref=、utm_ |
| 範本預設值 | 主題或外掛寫死的站名、店家名、版權文字 | 預設內容常被範本再跳脫一次，站長通常不會去改 | 搜站名與預設文字 |
這幾類欄位的共通點，是內容都會被 Google 拿去用。名稱被拿去顯示，網址被拿去連，優惠價格被拿去比對。也因為這樣，同樣多出 amp; 四個字元，放在 name 是難看，放在 url 是連不上。
範本預設值那一列特別容易漏。站名、版權文字、店家名稱，全站每一頁都輸出一次，只要被跳脫兩次，等於每一頁的 schema 都帶著同一個錯。也因為這些字串太基礎，反而沒有人會去檢查。
三個問題判斷你的 CMS 或外掛會不會雙重跳脫
生成端有沒有風險，不需要跑爬蟲，回答幾個問題就有輪廓。
- schema 是手寫的，還是範本或外掛生成的？手寫的 JSON-LD 通常不會有這個問題，字串自己可控；生成的要驗輸出，因為兩段跳脫常藏在自動管線裡。
- 網站系統輸出 HTML 時，會不會自動跳脫所有文字？許多範本引擎為了安全預設都會，這是第二層跳脫最常見的來源。不確定的話，找一頁內容確定含 & 的頁面，對照它在純文字位置與 script 區塊內各長什麼樣，兩邊都看不到裸露的 &、只看得到
&這類跳脫寫法，系統就有自動跳脫。 - 品牌名、商品名或網址參數裡有沒有 &？完全沒有 & 的網站，就算被跳脫兩次也不會出現
&amp;，中獎機率很低。
答案落在高風險側的項目有兩個，就照快查流程走一輪。用 WordPress 的人，外掛的選擇與設定可以對照WordPress SEO 的整理，生成的 schema 一樣用原始碼驗輸出。
Rich Results Test 與 Search Console 目前都看不見這個問題
Rich Results Test 是官方免費工具之一，一般情境下很好用，這次幫不上忙。照錯誤類型說明頁，它的錯誤清單是 “Bad escape sequence in string”、”Invalid Unicode escape sequence: four digits expected”、”Empty escape sequence in string” 這類反斜線語法錯，項目裡沒有 HTML entity 雙重跳脫這一種。字串合法，測試就過關。
Search Console 那邊，英國顧問 Szymaniak Digital 的分析講得直接，JSON 仍然合法、屬性都還在，而 Search Console 的結構化資料報告只標語法錯誤與缺少必要屬性，兩種檢查都碰不到這種狀況，幾乎確定不會報錯。這個推論的結構可以拆開看。Search Console 的結構化資料報告做兩種檢查，語法層與必要屬性層。雙重跳脫不改變 JSON 的合法性，語法層過關；屬性一個沒少，必要屬性層也過關。報告的設計裡沒有「內容對不對」這個維度，所以兩種檢查都繞過它。報告本身怎麼讀，可以對照Search Console 完整教學。要留意的是，不會報錯的判斷來自顧問，Google 沒有背書。
工具看的是語法，不是欄位裡的內容被多包了幾層。結論也就很簡單，工具安靜不等於網站沒事，原始碼自己看。
&amp; 要修成什麼樣子才對
標準寫法長什麼樣
公告的建議句寫得具體，把字串換成 standard JSON escapes 或 Unicode hexadecimal escapes。對應到實際寫法有兩個選項，兩個都合法。
選項一，直接寫原字元。JSON 規格裡必須跳脫的字元只有三類，雙引號、反斜線、以及 U+0000 到 U+001F 的控制字元，& 不在名單上，所以 AT&T 本來就能直接寫進 JSON 字串。乾淨、好讀，任何解析器都讀對。
選項二，用 JSON 的跳脫寫法 \u0026。寫法是六個字元，反斜線、小寫 u、四個十六進位數字。& 在 Unicode 裡的編號（碼位，code point）是 U+0026，所以寫成 \u0026；打勾符號 ✔ 的碼位是 U+2714，對應寫成 \u2714。這種寫法走 JSON 自己的路，不經過 HTML entity，也是公告建議的方向。
兩個選項怎麼挑，看原始碼的可讀性與內容的風險。直接寫原字元最乾淨，但內容裡若可能出現 </script> 這類序列，就要靠跳脫擋下來。六字元寫法可讀性差一點，勝在完全避開 HTML 的特殊字元，範本引擎再怎麼自動跳脫，對反斜線路徑也沒有作用。
被跳脫兩次的字串，回頭修的時候照這兩個選項改。源頭資料是什麼字元，就寫回什麼字元，商品名 AT&T 就寫 AT&T，或寫 AT\u0026T。保留單層 & 也可以讀對，但那是留在 Google 寬容範圍裡的寫法，改版時順手升級比較穩。
修的位置，依生成方式而定
工具不同，跳第二次的那一環也不同，修的位置跟著不一樣。
- WordPress 的外掛與主題。有些外掛提供 filter 或設定可以調整輸出，沒有的話直接回報開發商，附上出事頁面與搜到的字串。主題自己輸出的 schema，走主題的支援管道，責任在同一個位置。
- Shopify 的主題與 App。App 生成的部分找 App 開發商，主題範本裡的自動跳脫是常見的第二層來源，改範本先在預備環境驗過再上線。
- Hugo、Jekyll、Eleventy 這類靜態網站產生器。跳脫發生在範本層，Hugo 社群 2019 年起用 htmlUnescape 搭 plainify 的組合處理，就是範本端的標準解法。
- headless CMS。源頭資料保持原字元，跳脫只留在輸出 JSON 的那一刻，交給 JSON 的規則處理，責任切乾淨就不會多出一層。
該做與別做
修法只有一條主線，找到跳第二次的那個環節，讓字串在源頭保持原樣，輸出時交給 JSON 的規則處理。
- 從生成端修。範本或外掛裡多跳脫的那一環要移掉，源頭不改，下一次重新生成，問題會原封不動長回來。
- 該交給 JSON 的字元就交給 JSON。& 寫
\u0026或原字元；內容裡出現<時寫\u003C，順便避開</script>提前結束區塊的風險。 - 在範本層加回歸測試。輸出一個含 & 的測試字串，自動檢查最終 HTML 落在
\u0026或原字元，一旦出現&amp;就讓測試失敗。有這道測試顧著，未來升級範本或換外掛，都不用靠人工重掃。
別做的事也有清單，每一項都有理由。
- 別在輸出端用字串替換把
&硬換成 &。這一刀會把合法的單層跳脫一起砍掉，也可能砍掉防</script>的保護。script 區塊裡真的出現</script>這串字時，瀏覽器會認為區塊結束，後半段 JSON 全部失效。 - 別等工具報錯再動。Rich Results Test 與 Search Console 目前都不會標這件事，等下去沒有結果。
- 別把所有字元都換成
\uXXXX。合法，但原始碼可讀性變差，必要的字元處理就好。
rich results 會不會消失，官方說到哪裡為止
官方對後果的措辭，精確到只剩一個動詞，”will no longer be unrolled”，加上一句改寫法的建議。整份公告沒有出現 rich result、資格（eligibility）、invalid 任何字眼，也沒有量化影響。所以「會不會掉 rich results」這個問題，Google 官方等於沒有回答。要判斷風險，只能把官方動詞與第三方推論分開擺，各看各的證據強度。
rich results 的中文是複合式搜尋結果，出現在搜尋結果頁上，比一般連結多了星星、價格、常見問題展開的版位，星星來自評論標記，價格來自 Product 的 offers，常見問題來自 FAQPage，版位讀的正是 schema 欄位。用 QAPage 或 FAQPage 這類 schema 經營版位的網站，適用同一套檢查，QAPage 的教學裡的欄位一樣要掃。
留言區裡最值得參考的推論，來自 Philipp Enders。他是第三方工具商，公司在公告當天上線了一個免費檢查工具。他的判斷是，要盯的是 url、sameAs、offers.url 裡的雙重跳脫 &，單輪還原後，欄位裡的內容跟真實網址對不起來，連結或優惠會「安靜地」退出 rich results。這段話是工具商的推論，跟工具生意相關，讀的時候把身分放進去，方向仍然值得參考。
把各欄位的後果分開看，會更懂他在盯什麼。name 裡的雙重跳脫，複合式搜尋結果顯示 AT&T，難看但站還連得到。url 裡的雙重跳脫，Google 讀到的網址多出 amp;，那個網址不存在，比對與點擊都會失敗。offers.url 同理，優惠指到不存在的頁面，等於默默失效。工具商把注意力放在網址一類，原因就在後果最實際。
這個推論可以換成網址的例子來看。假設特價頁的網址是 https://example.com/sale?q=shoes&ref=menu，JSON-LD 裡的 offers.url 被跳脫兩次，寫成 ...sale?q=shoes&amp;ref=menu。新解析還原一輪後，Googlebot 讀到的是 ...&ref=menu，多出 amp; 四個字元，網址從此指不到正確的頁面。損失就發生在看得到報表之前。
microdata 與 RDFa 的處境，前面提過官方零措辭。Szymaniak Digital 的分析推論這兩種格式不受影響，理由是它們的資料寫在 HTML 屬性裡，值跟著 HTML 文件走，少了「先包成 JSON 再放進 script 區塊」這一層，兩種跳脫規則交錯的機會自然小。推論合理，但來源是顧問分析。
官方動詞停在哪裡，解讀就跟到哪裡。會不會掉版位，目前只有第三方推論，沒有官方答案。
Google 為什麼要這樣改？RFC 8259 第 7 節講了什麼
改動的理由，主公告只給了一句，”To bring our parser up to JSON and other standards”，把解析器對齊 JSON 與其他標準。RFC 8259 這個文件名稱不在公告裡，是 Gary Illyes 在主公告後八分鐘，於自己的 LinkedIn 補上的。他的說法很輕鬆，如果想知道 JSON 裡「正確的跳脫」是什麼，有好消息，RFC 8259 第 7 節寫得非常非常清楚。核對時間戳，主公告是 09:04 UTC，接力是 09:12 UTC，同一天，2026 年 8 月 21 日。
Gary Illyes 是 Google Search Central 團隊的成員，長期在社群回答搜尋的運作細節，他的補充常被當成官方說法的延伸。嚴格講，RFC 三個字確實不在主公告文字裡。
RFC 8259 是 JSON 的正式規格，全名 “The JavaScript Object Notation (JSON) Data Interchange Format”，2017 年 12 月定版，等級是網際網路標準（Internet Standard）。第 7 節的標題是 Strings，講字串怎麼寫。規定可以濃縮成一句話。JSON 字串裡必須跳脫的字元只有三類，雙引號 "、反斜線 \、以及 U+0000 到 U+001F 的控制字元。
控制字元是鍵盤上按不出來的那一類，換行、定位、退格都在這個範圍，它們在字串裡看不見，卻會改變解析器的行為，規格才強制跳脫。& 在 JSON 裡沒有任何特殊角色，JSON 的結構靠大括號、中括號、冒號、逗號這幾個符號撐起來，& 就是一般文字，跟 A、跟 5 沒有兩樣。
同一段還給了 \u0026 的依據。原文寫 “Any character may be escaped”，任何字元都可以跳脫，基本多語言平面裡的字元（U+0000 到 U+FFFF）可以用六個字元表示，反斜線、小寫 u、四個十六進位數字。所以 & 與 \u0026 兩種寫法都在規格裡，直接寫原字元合法，跳脫寫也合法。
HTML 那一側還有背景，這段能回答一個更根本的問題，Google 為什麼之前要自己動手還原。照 WHATWG 的 HTML 標準，瀏覽器讀到 script 區塊時進入 script data 狀態，這個狀態不會把 & 解回 &，字串寫什麼就照印什麼。所以 JSON-LD script 裡的字面 &amp;，送到任何標準 JSON 解析器手上，讀到的都是字面 &amp;。會多做 HTML 還原的，從頭到尾都是 Google 自己。這是 Google 自己加的處理，標準裡沒有這項要求，這次變更等於把它收回一格。
一次還是零次，規格上的灰色地帶
W3C 手上的 JSON-LD 1.1 規格，第 9 節寫得直接，”A JSON-LD document MUST be valid JSON text as described in RFC 8259″。JSON-LD 沒有自訂跳脫規則，正確輸出就是合法 JSON，兩份規格到這裡一致。
同一份規格的第 7.2 節，章節名 “Restrictions for contents of JSON-LD script elements”，有一則附註，性質標明 non-normative，非規範性。附註寫 “the content will remain escaped after processing through the JSON-LD API”，內容經過 JSON-LD API 處理後，跳脫會原樣保留。該節的對照表明列 & 對應 &，但目的只有一個，避開 </script>、<!--、--> 這些會提前終止 script 區塊的序列，& 只是順便出現在表裡。
照 W3C 的劇本，你寫 &，處理完還是字面 &，一層都不解。JSON-LD API 的規格解碼次數是零。零次的感覺可以用具體例子看，送 {"name":"AT&T"} 進 JSON-LD API，出來的 name 就是字面上的 AT&T，& 這五個字元原封不動，處理器不做任何還原，責任完全在寫入的人身上。對照之下，Google 這次保留一輪還原，仍然是規格之外多做的一輪，只是彈性比以前小。
留言者 Fabio Rovai 據此提出規格論點。既然 JSON-LD API 是零次，規格一致的次數就是零，Googlebot 停在一次，沒有降到零，是相容性的選擇。他把分析整理成 GitHub 專案 fabio-rovai/jsonld-escaping-conformance。
他宣稱的數字未經獨立驗證，引用時當成他個人的分析。Tranco 前 10,000 大網域裡，他量到 10 個網域的 JSON-LD 受這次變更影響。另一組是 199 個網域，欄位內容在零次解析器與 Googlebot 的讀法下本來就不同。199 計的是網域數，跟前面那 10 個是兩批不同的站。這個落差變更前就在，變更後也還在，規模約 20 比 1。他的推估還有一句，如果 Google 真的降到零次，約 7% 的 JSON-LD 發布者，欄位內容會在一夜之間改變。Google 對這些數字沒有回應。
兩份規格其實沒有真正對立。RFC 8259 管 JSON 文字本身，JSON-LD 1.1 的那則附註標明非規範性，兩派都拿不到百分之百的規格高地。對網站來說，爭議的實際意義比勝負大，不管 Google 未來停在幾次，把字串修到規格路徑上，兩種結局都過關，這是不用賭的走法。立場一句話，規格寫的是零次，Google 停在一次，官方沒有解釋為什麼。
這其實是個老問題
爭議的時間軸可以往前拉很長。公告前十個月，2025 年 10 月，Google Search Central 社群就有一則討論串，一家新聞站的 JSON-LD headline 裡出現 ’、' 這類 entity，站長問會不會影響 rich results。前者是右單引號 ’ 的寫法，後者是撇號 ‘ 的數字寫法，新聞標題裡的引號很平常，問題同樣出在字串被跳脫了幾次。
回覆的是 barryhunter，官方社群的 Diamond Product Expert，掛的是產品專家頭銜，不是 Google 員工。這個頭銜屬於 Google 官方社群的制度，頒給活躍回答問題的社群成員，回答不等於 Google 立場。他當時寫 “there is no official specification”，並建議別依賴這種還原行為，消費端要不要還原 entity 由各家自己決定，Google 似乎會試著解，Rich Results Test 看得到，但因為沒有規格，最好別依賴。這段對話的價值在兩個時間點，它證明變更前 Google 的解析器確實會還原 entity，也證明這件事長期沒有官方規格。
Szymaniak Digital 的同一篇分析，把更早的歷史也挖了出來。schema.org 的郵件論壇 2015 年就有 Martin Hepp 正式提出這個歧義，W3C 的 JSON-LD 工作組 2018 年也記錄過。Hugo 社群也從 2019 年起有範本層的解法在流傳。同一個坑，工程師至少踩了七年。
還沒有答案的事
不確定性一次列清楚，查核基準日是 2026 年 8 月 22 日。列清單的用處很實際，這些空白直接影響你要不要急、修到哪個程度，先知道邊界在哪，動作才好排優先順序。
- 生效日期與重新處理。公告用過去式，變更已在線上。Google 沒有講哪一天生效，沒有分批排程，也沒有說既有頁面會不會被重新檢索與重新處理。
- 官方文件進度。結構化資料說明頁最近一次更新，EN 版停在 2025 年 12 月 10 日，zh-TW 版停在 12 月 18 日，全文沒有任何跳脫指引。Search Central 的文件更新日誌，最新條目是 2026 年 8 月 20 日的偏好來源自訂按鈕，沒有 JSON-LD unescaping 的條目。官方部落格最新文章停在 7 月。
- 還原的時點。那一輪還原發生在 JSON 解析之前還是之後，官方沒有說明，機制描述點到公告為止。
- 更深層的跳脫。公告點名的是兩層案例，超過兩層的舊行為沒有載明。
- 第三方推論的位置。Search Console 不報錯是顧問分析，microdata 與 RDFa 不受影響是結構推論，rich results 會掉是留言推論，Google 對這些說法都沒有背書。
- 單層跳脫行為不變。機制推導的結論，公告沒有逐條背書。
Google 八月的動作是連著來的，同一個月才剛處理完垃圾內容更新，搜尋圈的討論被分掉不少。追蹤後續最省力的方式，是盯 Search Central 的文件更新日誌，JSON-LD unescaping 的條目出現那天，再回來對照一次。
下一步
按時間排，可以這樣動。今天花 5 分鐘，首頁檢視原始碼，搜 &amp; 與 &#，什麼都沒有就先過關。本週挑 10 分鐘，文章頁、商品頁、帶查詢參數的頁面各掃一頁，重點翻品牌名與網址參數附近的字串。真的搜到東西，開一張工單給範本或外掛的維護者，指定修生成端、加回歸測試，別讓下一版又把問題生成回來。之後盯著文件更新日誌等官方條目，條目出現那天，把新舊對照再對一次，看跟推導有沒有落差。修完順手把有問題的頁面與修法留一份紀錄，下次 Google 再動解析器，對照起來快。
常見問題
我的網站要怎麼檢查有沒有雙重跳脫？
首頁按檢視原始碼，先搜 ld+json 找到 JSON-LD 區塊，再搜 &amp; 與 &#。搜得到字串就是有雙重跳脫；只看到 & 屬於單層跳脫，目前不受影響。接著換文章頁與商品頁各掃一頁，品牌名與網址參數是重點。搜到東西先別急著手改，記下頁面與欄位，回到生成端修，才不會改了又被生成回來。全程用瀏覽器就夠，不需要付費工具。
\u0026 是什麼？為什麼 Google 建議這種寫法？
\u0026 是 JSON 的跳脫寫法，六個字元，反斜線、小寫 u、四個十六進位數字，0026 對應 & 的碼位。RFC 8259 第 7 節允許任何字元用這種形式跳脫，這種寫法走 JSON 自己的路，不經過 HTML entity。同一份規格也允許直接寫原字元 &，兩種都標準。
我用的是 microdata 或 RDFa，也受影響嗎？
公告只點名 JSON-LD，microdata 與 RDFa 一個字都沒提。顧問分析推論這兩種格式不受影響，理由是資料寫在 HTML 屬性裡，沒有 script 區塊內 JSON 與 HTML 跳脫交錯的結構。推論合理，Google 沒有背書，用這兩種格式的網站照原始碼快查掃一輪最踏實。
這個變更什麼時候生效？已收錄的頁面會被重新處理嗎？
公告用過去式，變更已經在線上，Google 沒有給生效日期與推出排程。既有頁面會不會被重新檢索與重新處理，官方同樣沒講。能做的事是把字串修成標準寫法，時程的球在 Google 那邊。官方唯一確定的是行為已變，不確定的都屬於時程與範圍，急不急的判斷不需要等這些答案。
單層跳脫的 & 需要一起改成 \u0026 嗎？
不急。單層跳脫經過一輪還原讀值正確，公告的機制下行為不變。要動的話，趁範本改版一起換到 JSON 路徑，順手而且一次處理到位。公告的方向是把解析器往規格搬，跟著規格走的手寫內容，風險永遠最小。
Rich Results Test 或 Search Console 會告訴我有問題嗎？
兩者目前都不會。Rich Results Test 的錯誤類型是反斜線類的語法錯，清單裡沒有 HTML entity 雙重跳脫的項目；Search Console 的結構化資料報告只標語法錯誤與缺少必要屬性，這種語法合法但內容錯了的狀況，兩邊都碰不到。顧問分析講得直接，幾乎確定不會報錯，但判斷來自顧問，Google 沒有背書。這也是這次變更麻煩的地方，錯誤就放在那裡，報表不叫，測試不叫，只有原始碼知道。
用 WordPress 外掛或 Shopify App 自動生成 schema，要找誰修？
先用檢視原始碼確認輸出真的有雙重跳脫，再找生成鏈的維護者。WordPress 外掛找外掛開發商，Shopify 找主題或 App 的開發商，自架範本找自己的工程團隊。修的位置在生成端，上線後的 HTML 不要動。開工單時附上出事的頁面網址與搜到的字串，往返會快很多。
