JSON-LD 結構化資料驗證工具
貼上HTML或原始JSON-LD即可驗證FAQPage、BreadcrumbList、Article等結構化資料，快速發現缺失的必需屬性以及Google富媒體搜尋結果中常見的錯誤。
使用提示
- FAQPage的acceptedAnswer務必將回答內容作為純字串放入text屬性中，如果填入物件或陣列，Google的富媒體搜尋結果將無法識別。
- BreadcrumbList的position需要從1開始連續編號，如果存在缺號或重複，將無法被識別為正確的麵包屑導航。
- Article的headline建議控制在110個字元以內，這是Google給出的大致標準，過長的標題在搜尋結果中可能會被截斷顯示。
- 即使貼上整個HTML頁面也沒問題，工具會自動提取 <script type="application/ld+json"> 程式碼塊中的內容進行驗證，只貼上JSON本身也同樣有效。
- 如果一個頁面中放置了多種結構化資料，建議分別寫在不同的 <script> 標籤中，這樣更便於維護和排查問題。
常見問題
JSON-LD是在獨立於HTML正文的<script>標籤內以JSON格式記錄結構化資料的方式。而Microdata和RDFa則是直接嵌入到HTML標籤的屬性（如itemprop）中，因此需要改動現有的HTML結構。Google近年來推薦使用JSON-LD，憑藉其易於實現的特點，目前已成為主流方式。
結構化資料本身並不是直接影響搜尋排名的因素。但如果FAQPage、BreadcrumbList等被正確實現，搜尋結果中可能會顯示富媒體搜尋結果（例如FAQ的摺疊展開顯示、麵包屑導航顯示），從而有望提升點選率（CTR）。
Schema.org規範要求acceptedAnswer.text必須是純文本字串。如果誤將text的值設定為物件或陣列（例如巢狀成{"value": "回答內容"}這樣的結構），Google的富媒體搜尋結果測試工具會將其標記為警告或錯誤。
完全沒有問題。FAQPage、BreadcrumbList、Article等多種型別的結構化資料，可以分別寫在同一頁面中不同的 <script type="application/ld+json"> 標籤內。本工具也會從一次輸入中一併檢測並驗證多個程式碼塊、多個實體。
可以在Google Search Console的“增強功能”報告中檢視，或使用Google官方的“富媒體搜尋結果測試”工具，針對實際已釋出的URL確認Google是如何解析的。本工具更適合在釋出前的草稿階段或修改後進行自我檢查時使用。
閒話 ― JSON-LD為何取代了Microdata與RDFa
JSON-LD（JSON for Linking Data）最初是W3C社群小組在2010年代初期制定的一種關聯資料格式。與Microdata、RDFa等傳統結構化資料寫法（直接將標記嵌入HTML元素的屬性中）不同，JSON-LD可以作為一段獨立的JSON，完整地寫在<script>標籤內，因此在新增或刪除結構化資料時完全不會破壞現有的HTML佈局。Google從2015年前後開始將JSON-LD定位為推薦格式，如今的富媒體搜尋結果文件也幾乎都以JSON-LD的寫法為前提進行說明。
本網站自身的FAQ區塊也是如此運作的：作者只需撰寫一次問答內容，系統便會在後臺自動生成對應的FAQPage格式JSON-LD。這樣一來，人類閱讀的視覺化手風琴列表與搜尋引擎讀取的結構化資料無需重複手動維護兩份，其中一處修改後另一處也會自動同步，從而避免了顯示內容與結構化資料不一致的問題。
即使JSON在語法上完全正確，如果缺少Schema.org要求的必需屬性，或者缺少Google建議提供的推薦屬性，富媒體搜尋結果（例如搜尋結果中的FAQ展開顯示、麵包屑導航顯示等）也可能無法生效。acceptedAnswer.text這類巢狀層級較深的屬性，正是實現時容易出錯的典型案例。在釋出前使用此類工具進行機械化檢查，可以比事後在Search Console的“增強功能”報告中才發現錯誤更早地發現問題。